From nobody Wed Apr 3 22:22:22 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B52120437 for ; Wed, 3 Apr 2019 22:22:20 -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 U6o22UytxCvG for ; Wed, 3 Apr 2019 22:22:18 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C8B1203E9 for ; Wed, 3 Apr 2019 22:22:18 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id u21so821854lfu.2 for ; Wed, 03 Apr 2019 22:22:18 -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 :content-transfer-encoding; bh=11KalnGZZ5PhhIdKUJoLxLam1h+7l3+Evo/+xgpZVv0=; b=dkJl4rYSqgD17ZCqLa7SNCXeHEuwFCKeP4j4q+M/dZb01Mz7M2EXlWbI9aZEsbnmlv tSc2HZ2T4WPZ10ERnxhNi57OPUb/Td14ZUN91KaMUrgt18TcgzUqeqArxXlEe+MH+PdO URwATvwWfNTbtgbOZQ6vf32qrCwo4tICJ5aBOgAkAYctRjtQNeVzsSTCvEOvJc5uvF+K h0qxGyHSfaknlpGj1X08uR089wN6Z903qnNWSZACWSjlkZYpKNEozdz/YKA9UEJya46T haGmbAmQCiN/8Lch8FG/NhcoH1ZMy4dMvqfJKBFhALAZikcXczJP0Vh/dqxjBHOIjv9a z2IQ== 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:content-transfer-encoding; bh=11KalnGZZ5PhhIdKUJoLxLam1h+7l3+Evo/+xgpZVv0=; b=qj2LqIxmPEddCeT1zAEWvux5250ZCVg7I8+VNTT2oNvbIyJY8piTXFho8f9nLIR6DR W7Xjs8akwrcjUWeK+jLyyqPL/30OHwBpoESb4yFp5O+/uwv6K5JkouU8Zj+J5sLvKzu/ sQWgaWRIZEEcNsjLMUVjd2IfwF1Hs8AzaTPYXZdteuybqCuUvfjBExKXKXguAKwh3zYj 7zgsM7dXV8vTCjHpeeI6lGr9vWHawpwvrQmBLfSylrZUp04IO2R0LuSTHtxl5gSTyzaG 30jQn9zolaW1useTiM0lHAm7LDbnpwp7fyKMof0Mnem+yVAO8YAmdGi+NeGio70F9Wua c66w== X-Gm-Message-State: APjAAAV6+B5UJuKMfuY/7b57TJkgiPFY2zb9TTwLvKN8Kxte4nI0lQ/N qQ2pmaNqMZYAyYJWBnTUBED6gTPFaVxRiH54O+OZTbSE X-Google-Smtp-Source: APXvYqwm8GL7KYkkIvEWUfIoahA719NWOSPAra72sTMaI2z6dzOl6i9XkYJOGE4XF8/sAqoJYVONX553MZMa9sPMjZ0= X-Received: by 2002:a19:7914:: with SMTP id u20mr1852963lfc.41.1554355336574; Wed, 03 Apr 2019 22:22:16 -0700 (PDT) MIME-Version: 1.0 References: <155435502215.22668.17009854749523198767.idtracker@ietfa.amsl.com> In-Reply-To: <155435502215.22668.17009854749523198767.idtracker@ietfa.amsl.com> From: Kazuho Oku Date: Thu, 4 Apr 2019 14:22:04 +0900 Message-ID: Subject: Fwd: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt To: 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.29 Precedence: list List-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, 04 Apr 2019 05:22:21 -0000 Hi, I have (finally) submitted "Address-bound Token for QUIC" I-D, that proposes a QUIC extension allowing tokens to be shared between connections that go to the same server address, even when the value of SNI is different. Having such tokens would maximize our chance of skipping address validation and slow-start phase. The I-D and the repo can be found at the links below: I-D: https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-t= oken/ Github repo: https://github.com/kazuho/draft-kazuho-quic-address-bound-= token Please let us know what you think. Rationale behind the proposal: The startup phase (a.k.a. slow-start) is one of the things that has negative impact on user experience. QUIC, in addition to reducing the connection establishment latency from TCP, provides the possibility of a server skipping the startup phase when a client provides a valid token. However, the probability of a server being able to skip the startup phase relies on how frequent a user revisits a particular server, identified by the value of the TLS SNI extension. To put another way, there is a missed opportunity if a client is visiting a server instance that it has previously visited with a different server name. Our proposal addresses exactly that. The proposed extension allows a client to use a token for a different server name, if the server address is the same. This maximizes the chance of the server skipping address validation and the startup phase. ---------- Forwarded message --------- From: Date: 2019=E5=B9=B44=E6=9C=884=E6=97=A5(=E6=9C=A8) 14:17 Subject: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt To: Kazuho Oku A new version of I-D, draft-kazuho-quic-address-bound-token-00.txt has been successfully submitted by Kazuho Oku and posted to the IETF repository. Name: draft-kazuho-quic-address-bound-token Revision: 00 Title: Address-bound Token for QUIC Document date: 2019-04-04 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-kazuho-quic-address-bound-token-= 00.txt Status: https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/ Htmlized: https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-kazuho-quic-address-bound-token Abstract: This document describes a QUIC extension for an address-bound token. This token can be used for sharing address validation and congestion controller state between the same two endpoints across multiple connections and origins. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 Kazuho Oku From nobody Wed Apr 3 23:15:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01FE12039A for ; Wed, 3 Apr 2019 23:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNMdJuxGSg-4 for ; Wed, 3 Apr 2019 23:15:19 -0700 (PDT) Received: from mail-it1-x142.google.com (mail-it1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA2C120338 for ; Wed, 3 Apr 2019 23:15:19 -0700 (PDT) Received: by mail-it1-x142.google.com with SMTP id 139so1831528ita.4 for ; Wed, 03 Apr 2019 23:15:19 -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=g+/bBcAwORTV2pYifYdyO4FWS0C8Lix+9rOG2D9Hs/c=; b=TCkwJGjZIQhXoqaBevDg23M/DFo4xpF6CKooQbNKTVno4m753cXrIZP+R8UgPqnZPX DNiotm0XV+3InmMCPLbJ90FEZM1G+1i9dXe4j152QNphWgoYrf6XPvHrFGRM4yVDTVV8 7VpgbSX0Og3J8696Bk7U/1iKsr9RGXyWvCNHjM2d30d2CPsvcUdJDp7/w8z5VwH9wAT1 lVt1ucj++qoZbgvOUqiasyjOaJivrHYPq6LVRUIDIRvx5FJ0I50Liikews1PlAjw9gCV XYXsORgUDXJyRB1tNv4MIRgFckdZu1/lGaktvTCRtgV8LpkWlkg+HEQmq4LdiJ6c4xne 8xrg== 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=g+/bBcAwORTV2pYifYdyO4FWS0C8Lix+9rOG2D9Hs/c=; b=m9uope3BQcjpOB6e5b4sp/+1hdjUF3ho6j5kiUN3nSKjgkVwnxenMWX8CYela4Qaec OVthKP7GG0VZkolNnnMXmUEJwA8sEHMeGwTxy9L8OLj7md4PuMOhI2RCkaVWuK0NUXqi xnNXFHS6pAqT4Typ6vkdawsQIrApQjtXDHF/gJoAm2x6CyJ5kdWCGI/XhZIgojXnQuOy qz1kNSFq2Sh1/rgUm4E0qyADPRuilxxPooreDZhvc/9dBF4jLBhu/JQxPLRPSqXyD1xN nPHKR+AjlORfQz+iFEwZWKwf1sXQYlF5GSoi1QLpjWthPffLv58D/2/7oLN1BiqBcEcB CuKw== X-Gm-Message-State: APjAAAVo5Q15uUsDFZOQ+o7EjK/Ax3ztTC5ExzHPsh0X6Bwu2WJlUvQI uy4MmB9V1smeUGrBdf7MW8rPC1WMlq80POKUF2BZiw== X-Google-Smtp-Source: APXvYqx//P9i7VWasELkC4EKg2NY98FGFkct0cbBoLx3xrr75+Tw1blOD6Mg2FHYIxP2QAZiEPXa4luFzWi1A0zqNG8= X-Received: by 2002:a24:4d:: with SMTP id 74mr3624886ita.6.1554358518727; Wed, 03 Apr 2019 23:15:18 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 4 Apr 2019 06:15:17 +0000 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <155435502215.22668.17009854749523198767.idtracker@ietfa.amsl.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 4 Apr 2019 06:15:17 +0000 Message-ID: Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt To: IETF QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000005cc8b90585ae4ba0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 04 Apr 2019 06:15:23 -0000 --0000000000005cc8b90585ae4ba0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nice work. Just a minor thing on priority in the appendix: what about IPv6 priorities? That, and flow labels - are we starting to bypass much of the IPv6 design because it is not (yet?) sufficiently widely deployed? Or are there security implications, and if so, should QUIC consider authenticating parts of the IPv6 header? Also, on name based alternative: I=E2=80=99m wondering which non-HTTP/3 connections would really benefit as = new designs can build in multi-purpose into the protocol whereas HTTP/3 must follow HTTP semantics. You could argue about WebRTC/3 - but then - what should it co-locate with which has sufficient intelligence to share the congestion controller? You could argue share with HTTP/3, but that would probably not rule out a name based solution either. I=E2=80=99m not saying name based CG sharing is necessarily better, I=E2=80= =99m just wondering. OTOH if name based sharing is used that could place some assumptions on a given load balancers tuple stickiness, if I understand correctly. That could be unfortunate. Or, if name sharing is only to target address validation of the client perhaps different server hosts could share that information successfully with a random or round robin load balancer? Mikkel On 4 April 2019 at 07.22.32, Kazuho Oku (kazuhooku@gmail.com) wrote: Hi, I have (finally) submitted "Address-bound Token for QUIC" I-D, that proposes a QUIC extension allowing tokens to be shared between connections that go to the same server address, even when the value of SNI is different. Having such tokens would maximize our chance of skipping address validation and slow-start phase. The I-D and the repo can be found at the links below: I-D: https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token= / Github repo: https://github.com/kazuho/draft-kazuho-quic-address-bound-toke= n Please let us know what you think. Rationale behind the proposal: The startup phase (a.k.a. slow-start) is one of the things that has negative impact on user experience. QUIC, in addition to reducing the connection establishment latency from TCP, provides the possibility of a server skipping the startup phase when a client provides a valid token. However, the probability of a server being able to skip the startup phase relies on how frequent a user revisits a particular server, identified by the value of the TLS SNI extension. To put another way, there is a missed opportunity if a client is visiting a server instance that it has previously visited with a different server name. Our proposal addresses exactly that. The proposed extension allows a client to use a token for a different server name, if the server address is the same. This maximizes the chance of the server skipping address validation and the startup phase. ---------- Forwarded message --------- From: Date: 2019=E5=B9=B44=E6=9C=884=E6=97=A5(=E6=9C=A8) 14:17 Subject: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt To: Kazuho Oku A new version of I-D, draft-kazuho-quic-address-bound-token-00.txt has been successfully submitted by Kazuho Oku and posted to the IETF repository. Name: draft-kazuho-quic-address-bound-token Revision: 00 Title: Address-bound Token for QUIC Document date: 2019-04-04 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-kazuho-quic-address-bound-token-= 00.txt Status: https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/ Htmlized: https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-kazuho-quic-address-bound-token Abstract: This document describes a QUIC extension for an address-bound token. This token can be used for sharing address validation and congestion controller state between the same two endpoints across multiple connections and origins. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 Kazuho Oku --0000000000005cc8b90585ae4ba0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Nice work.
Just a minor thing on priority= in the appendix: what about IPv6 priorities? That, and flow labels - are w= e starting to bypass much of the IPv6 design because it is not (yet?) suffi= ciently widely deployed? Or are there security implications, and if so, sho= uld QUIC consider authenticating parts of the IPv6 header?

Also, on name based alternative:
I=E2=80=99m wonde= ring which non-HTTP/3 connections would really benefit as new designs can b= uild in multi-purpose into the protocol whereas HTTP/3 must follow HTTP sem= antics. You could argue about WebRTC/3 - but then - what should it co-locat= e with which has sufficient intelligence to share the congestion controller= ? You could argue share with HTTP/3, but that would probably not rule out a= name based solution either.
I=E2=80=99m not saying name based CG sharing is necessarily= better, I=E2=80=99m just wondering.

OTOH if name based sharing is used that could place some as= sumptions on a given load balancers tuple stickiness, if I understand corre= ctly. That could be unfortunate. Or, if name sharing is only to target addr= ess validation of the client perhaps different server hosts could share tha= t information successfully with a random or round robin load balancer?

Mikkel

On 4 April 2019 at 07.22.32, Kazuho Oku (kazuhooku@gmail.com) wrote:

Hi,

I have (finally) submitted "Address-bound Token for QUIC" I-D= , that
proposes a QUIC extension allowing tokens to be shared between
connections that go to the same server address, even when the value of
SNI is different. Having such tokens would maximize our chance of
skipping address validation and slow-start phase.

The I-D and the repo can be found at the links below:

I-D: https://datatracker.ietf.org/doc/draft-kazuho-quic-ad= dress-bound-token/
Github repo: https://github.com/kazuho/draft-kazuho-quic-address-b= ound-token

Please let us know what you think.

Rationale behind the proposal:

The startup phase (a.k.a. slow-start) is one of the things that has
negative impact on user experience. QUIC, in addition to reducing the
connection establishment latency from TCP, provides the possibility of
a server skipping the startup phase when a client provides a valid
token.

However, the probability of a server being able to skip the startup
phase relies on how frequent a user revisits a particular server,
identified by the value of the TLS SNI extension. To put another way,
there is a missed opportunity if a client is visiting a server
instance that it has previously visited with a different server name.

Our proposal addresses exactly that. The proposed extension allows a
client to use a token for a different server name, if the server
address is the same. This maximizes the chance of the server skipping
address validation and the startup phase.


---------- Forwarded message ---------
From: <internet-drafts@i= etf.org>
Date: 2019=E5=B9=B44=E6=9C=884=E6=97=A5(=E6=9C=A8) 14:17
Subject: New Version Notification for
draft-kazuho-quic-address-bound-token-00.txt
To: Kazuho Oku <kazuhooku@gma= il.com>



A new version of I-D, draft-kazuho-quic-address-bound-token-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name: draft-kazuho-quic-address-bound-token
Revision: 00
Title: Address-bound Token for QUIC
Document date: 2019-04-04
Group: Individual Submission
Pages: 6
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-qu= ic-address-bound-token-00.txt
Status:
https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bou= nd-token/
Htmlized:
https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token= -00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-quic-ad= dress-bound-token


Abstract:
This document describes a QUIC extension for an address-bound token.
This token can be used for sharing address validation and congestion
controller state between the same two endpoints across multiple
connections and origins.




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

The IETF Secretariat



-- =20
Kazuho Oku

--0000000000005cc8b90585ae4ba0-- From nobody Wed Apr 3 23:47:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764EC1203A5 for ; Wed, 3 Apr 2019 23:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3555xkQzvDLN for ; Wed, 3 Apr 2019 23:47:51 -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 237B4120350 for ; Wed, 3 Apr 2019 23:47:51 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx120.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hBwA3-000Awx-I5 for quic@ietf.org; Thu, 04 Apr 2019 08:47:47 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1hBw9w-0001sA-G9 for quic@ietf.org; Thu, 04 Apr 2019 02:47:40 -0400 Received: (qmail 20404 invoked from network); 4 Apr 2019 06:47:35 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.204]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Apr 2019 06:47:35 -0000 To: quic@ietf.org References: <155435502215.22668.17009854749523198767.idtracker@ietfa.amsl.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <7a20865a-b368-80eb-378d-1744c9577117@huitema.net> Date: Wed, 3 Apr 2019 23:47:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------942329243C51A49BA1114D80" Content-Language: en-US Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt X-Originating-IP: 168.144.250.223 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ivNkfDBxHaPUY6T83xL7gV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVir61OAGdjmkrJVl9R6767mc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1RPScEHpAUegZl9l9jeRl05EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMT7wWCQ1bNVxVHMt1HKpEkC019jkkBafIM3k/pS+1FRKk6yZ5OEY7+D 4D8iYBKTDOhk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAliU20wPuSTm+IJBmdo0FC1ZZYSpQQtCkh8qZ SV0LCxteVx8FVyk8wh2eovY663+x6ciV/i+cUz5az04Uqf+1ai4hu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uKxlHEurUN5OnjeiFCqHX+Ta9UshveVgoiypAicYsWUtd8y9Ga5iCmdJFIvDE Jb+pKY4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 04 Apr 2019 06:47:55 -0000 This is a multi-part message in MIME format. --------------942329243C51A49BA1114D80 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am reading the draft, and I think that the discussion of congestion control should be removed. Senders have all latitude to coordinate transmission control across multiple connections, including using some form of multi-connection congestion control. I think the draft would be easier to read if it concentrated on just one purpose, the linkage of new tokens to server addresses instead of service identities. We probably need a slightly larger security analysis. What if a service part of a farm issued such a token without coordinating with the other services that use the same address? Could that be a form of DOS? -- Christian Huitema On 4/3/2019 11:15 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Nice work. > > Just a minor thing on priority in the appendix: what about IPv6 > priorities? That, and flow labels - are we starting to bypass much of > the IPv6 design because it is not (yet?) sufficiently widely deployed? > Or are there security implications, and if so, should QUIC consider > authenticating parts of the IPv6 header? > > Also, on name based alternative: > I=E2=80=99m wondering which non-HTTP/3 connections would really benefit= as new > designs can build in multi-purpose into the protocol whereas HTTP/3 > must follow HTTP semantics. You could argue about WebRTC/3 - but then > - what should it co-locate with which has sufficient intelligence to > share the congestion controller? You could argue share with HTTP/3, > but that would probably not rule out a name based solution either. > I=E2=80=99m not saying name based CG sharing is necessarily better, I=E2= =80=99m just > wondering. > > OTOH if name based sharing is used that could place some assumptions > on a given load balancers tuple stickiness, if I understand correctly. > That could be unfortunate. Or, if name sharing is only to target > address validation of the client perhaps different server hosts could > share that information successfully with a random or round robin load > balancer? > > Mikkel > > On 4 April 2019 at 07.22.32, Kazuho Oku (kazuhooku@gmail.com > ) wrote: > >> Hi, >> >> I have (finally) submitted "Address-bound Token for QUIC" I-D, that >> proposes a QUIC extension allowing tokens to be shared between >> connections that go to the same server address, even when the value of= >> SNI is different. Having such tokens would maximize our chance of >> skipping address validation and slow-start phase. >> >> The I-D and the repo can be found at the links below: >> >> I-D: >> https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token= / >> Github repo: >> https://github.com/kazuho/draft-kazuho-quic-address-bound-token >> >> Please let us know what you think. >> >> Rationale behind the proposal: >> >> The startup phase (a.k.a. slow-start) is one of the things that has >> negative impact on user experience. QUIC, in addition to reducing the >> connection establishment latency from TCP, provides the possibility of= >> a server skipping the startup phase when a client provides a valid >> token. >> >> However, the probability of a server being able to skip the startup >> phase relies on how frequent a user revisits a particular server, >> identified by the value of the TLS SNI extension. To put another way, >> there is a missed opportunity if a client is visiting a server >> instance that it has previously visited with a different server name. >> >> Our proposal addresses exactly that. The proposed extension allows a >> client to use a token for a different server name, if the server >> address is the same. This maximizes the chance of the server skipping >> address validation and the startup phase. >> >> >> ---------- Forwarded message --------- >> From: > >> Date: 2019=E5=B9=B44=E6=9C=884=E6=97=A5(=E6=9C=A8) 14:17 >> Subject: New Version Notification for >> draft-kazuho-quic-address-bound-token-00.txt >> To: Kazuho Oku > >> >> >> >> A new version of I-D, draft-kazuho-quic-address-bound-token-00.txt >> has been successfully submitted by Kazuho Oku and posted to the >> IETF repository. >> >> Name: draft-kazuho-quic-address-bound-token >> Revision: 00 >> Title: Address-bound Token for QUIC >> Document date: 2019-04-04 >> Group: Individual Submission >> Pages: 6 >> URL: >> https://www.ietf.org/internet-drafts/draft-kazuho-quic-address-bound-t= oken-00.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token= / >> Htmlized: >> https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-kazuho-quic-address-bound-= token >> >> >> >> Abstract: >> This document describes a QUIC extension for an address-bound token. >> This token can be used for sharing address validation and congestion >> controller state between the same two endpoints across multiple >> connections and origins. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> >> >> >> --=20 >> Kazuho Oku >> --------------942329243C51A49BA1114D80 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I am reading the draft, and I think that the discussion of congestion control should be removed. Senders have all latitude to coordinate transmission control across multiple connections, including using some form of multi-connection congestion control. I think the draft would be easier to read if it concentrated on just one purpose, the linkage of new tokens to server addresses instead of service identities.

We probably need a slightly larger security analysis. What if a service part of a farm issued such a token without coordinating with the other services that use the same address? Could that be a form of DOS?

-- Christian Huitema

On 4/3/2019 11:15 PM, Mikkel Fahnøe Jørgensen wrote:
Nice work.

Just a minor thing on priority in the appendix: what about IPv6 priorities? That, and flow labels - are we starting to bypass much of the IPv6 design because it is not (yet?) sufficiently widely deployed? Or are there security implications, and if so, should QUIC consider authenticating parts of the IPv6 header?

Also, on name based alternative:
I’m wondering which non-HTTP/3 connections would really benefit as new designs can build in multi-purpose into the protocol whereas HTTP/3 must follow HTTP semantics. You could argue about WebRTC/3 - but then - what should it co-locate with which has sufficient intelligence to share the congestion controller? You could argue share with HTTP/3, but that would probably not rule out a name based solution either.
I’m not saying name based CG sharing is necessarily better, I’m just wondering.

OTOH if name based sharing is used that could place some assumptions on a given load balancers tuple stickiness, if I understand correctly. That could be unfortunate. Or, if name sharing is only to target address validation of the client perhaps different server hosts could share that information successfully with a random or round robin load balancer?

Mikkel

On 4 April 2019 at 07.22.32, Kazuho Oku (kazuhooku@gmail.com) wrote:

Hi,

I have (finally) submitted "Address-bound Token for QUIC" I-D, that
proposes a QUIC extension allowing tokens to be shared between
connections that go to the same server address, even when the value of
SNI is different. Having such tokens would maximize our chance of
skipping address validation and slow-start phase.

The I-D and the repo can be found at the links below:

I-D: https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/
Github repo: https://github.com/kazuho/draft-kazuho-quic-address-bound-token

Please let us know what you think.

Rationale behind the proposal:

The startup phase (a.k.a. slow-start) is one of the things that has
negative impact on user experience. QUIC, in addition to reducing the
connection establishment latency from TCP, provides the possibility of
a server skipping the startup phase when a client provides a valid
token.

However, the probability of a server being able to skip the startup
phase relies on how frequent a user revisits a particular server,
identified by the value of the TLS SNI extension. To put another way,
there is a missed opportunity if a client is visiting a server
instance that it has previously visited with a different server name.

Our proposal addresses exactly that. The proposed extension allows a
client to use a token for a different server name, if the server
address is the same. This maximizes the chance of the server skipping
address validation and the startup phase.


---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: 2019年4月4日(木) 14:17
Subject: New Version Notification for
draft-kazuho-quic-address-bound-token-00.txt
To: Kazuho Oku <kazuhooku@gmail.com>



A new version of I-D, draft-kazuho-quic-address-bound-token-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name: draft-kazuho-quic-address-bound-token
Revision: 00
Title: Address-bound Token for QUIC
Document date: 2019-04-04
Group: Individual Submission
Pages: 6
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-quic-address-bound-token-00.txt
Status:
https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/
Htmlized:
https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-quic-address-bound-token


Abstract:
This document describes a QUIC extension for an address-bound token.
This token can be used for sharing address validation and congestion
controller state between the same two endpoints across multiple
connections and origins.




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

The IETF Secretariat



--
Kazuho Oku

--------------942329243C51A49BA1114D80-- From nobody Thu Apr 4 00:20:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5570612044E for ; Thu, 4 Apr 2019 00:20: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, 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 Ch7RmkLV3Xx6 for ; Thu, 4 Apr 2019 00:20:25 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::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 58E40120448 for ; Thu, 4 Apr 2019 00:20:25 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id h21so1084943ljk.13 for ; Thu, 04 Apr 2019 00:20:25 -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=myoEAdBQZ8W0++3qZD1M6Z46A7Gysm3idC/BW7GoHmE=; b=RZjKsPOY7pZKgheVzd08FQOb4VUlaaPibntz17ImS04pelkKGklyMXPvw41M7+711N b21FiEC3e55TAKAMwPDMrbJgJyB2AjhFS9eN3AO9CGIYkNFLG6Wv0joq1grTMUbXcnyG 6ze2a3L+fHZmi1YR7Tjn27yTMvGW+hagZ2us94t9VifMszSioaRZus2Lc46hTNcxrtHe ZPq8nOpxdHLxTcMr3BOXcQFiJb3p15ozOKhnnn3DXUeMMSaSKU7aOm6cXpai9XlmMyuE 4DCO+OS7GXb9MIGzZKzgY1bOvmiFUEpP/XGfGgNSTO/q2oA4WyrOVBpq3Z3LVe0JoAxj 5qyA== 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=myoEAdBQZ8W0++3qZD1M6Z46A7Gysm3idC/BW7GoHmE=; b=ZswuFKsf3IsykCtVvuIyuvxsx7ZDP4AH7Qtxw0NMN0EpWttQqiz2XpyNpo3jX6qtV+ hNDVMgE0MoIOwCGqDCD+IxjmTAdZxvf1qUr+KDsCGl4pAAuEvaVaQWhdQc3yiO881S40 FOONkLFbT+bFPfhi5mmLiX63bFxIEoTu6KNWEIzHQPRazwgE7K3Dd1sYLQn2w3YbgVgX ZvlwUP32exsNQdJQ55q2qt2n8hRtnMPFV2PVlCXAquTNDn5c+7ByfNPJ7P9+t+yxjIjN tLPo26NWauu8OrQx5ySHFAH75yuNcI+iTMmRVMHXCi0LMs3loAJM7Jtd1mrgp55x7cis emeQ== X-Gm-Message-State: APjAAAXHZrHyJbJS6Np39vRBuC6v4x6d0OfdLGUBtX6G7D0gJDCHNjP+ z5W9mkjyHZNgwT110YPkI3f9PV15n2dQR1KqhAM= X-Google-Smtp-Source: APXvYqwoCJ88diSkddpsnBN5kiIaH+PRuBrYQGsaH3mBsuhk+5vY5BboooKwHjHAVbnMup6uHX6asE1kSNadJo8MTGg= X-Received: by 2002:a2e:910b:: with SMTP id m11mr2574664ljg.14.1554362423544; Thu, 04 Apr 2019 00:20:23 -0700 (PDT) MIME-Version: 1.0 References: <155435502215.22668.17009854749523198767.idtracker@ietfa.amsl.com> In-Reply-To: From: Kazuho Oku Date: Thu, 4 Apr 2019 16:20:11 +0900 Message-ID: Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 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.29 Precedence: list List-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, 04 Apr 2019 07:20:30 -0000 Hi Mikkel, Thank you for your comments. My responses inline. 2019=E5=B9=B44=E6=9C=884=E6=97=A5(=E6=9C=A8) 15:15 Mikkel Fahn=C3=B8e J=C3= =B8rgensen : > > Nice work. > > Just a minor thing on priority in the appendix: what about IPv6 prioritie= s? That, and flow labels - are we starting to bypass much of the IPv6 desig= n because it is not (yet?) sufficiently widely deployed? Or are there secur= ity implications, and if so, should QUIC consider authenticating parts of t= he IPv6 header? I do not have an opinion on the design aspects of IPv6, but I can see at least two use-cases where you would want to use the priority scheme described in the I-D. 1. Prioritization between different browser tabs. A web browser can raise the priority of a connection that is bound to the window tab that's in the front. This is the type of signal should not be exposed to on-path observers, though we have thought that it's beneficial between endpoints (IIRC that was one of the use-cases when we designed the HTTP/2 prioritization scheme). 2. End-to-end cross-connection prioritization on a connection using VPN. Related thought: maybe we need a separate TP that allows a client to opt-out from a server using IP precedence. > > Also, on name based alternative: > I=E2=80=99m wondering which non-HTTP/3 connections would really benefit a= s new designs can build in multi-purpose into the protocol whereas HTTP/3 m= ust follow HTTP semantics. You could argue about WebRTC/3 - but then - what= should it co-locate with which has sufficient intelligence to share the co= ngestion controller? You could argue share with HTTP/3, but that would prob= ably not rule out a name based solution either. > I=E2=80=99m not saying name based CG sharing is necessarily better, I=E2= =80=99m just wondering. I am not sure if I am following, but I'd argue that there are two ways of using the token. One is to consolidate the congestion controller, and the other is to reuse the most up-to-date path information (e.g., BDP, RTT). For the former, it's essential to use the IP address as the scope, because that's what identifies a server instance within which a state can be shared. For the latter, the scope does not matter, though the probability of receiving a fresh taken rises as the scope gets bigger. That's one of the reasons the scope proposed by the draft is "union of server-name and server's address tuple" (the other reason is to avoid sending two types of tokens). > > OTOH if name based sharing is used that could place some assumptions on a= given load balancers tuple stickiness, if I understand correctly. That cou= ld be unfortunate. Or, if name sharing is only to target address validation= of the client perhaps different server hosts could share that information = successfully with a random or round robin load balancer? > > Mikkel > > On 4 April 2019 at 07.22.32, Kazuho Oku (kazuhooku@gmail.com) wrote: > > Hi, > > I have (finally) submitted "Address-bound Token for QUIC" I-D, that > proposes a QUIC extension allowing tokens to be shared between > connections that go to the same server address, even when the value of > SNI is different. Having such tokens would maximize our chance of > skipping address validation and slow-start phase. > > The I-D and the repo can be found at the links below: > > I-D: https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-tok= en/ > Github repo: https://github.com/kazuho/draft-kazuho-quic-address-bound-to= ken > > Please let us know what you think. > > Rationale behind the proposal: > > The startup phase (a.k.a. slow-start) is one of the things that has > negative impact on user experience. QUIC, in addition to reducing the > connection establishment latency from TCP, provides the possibility of > a server skipping the startup phase when a client provides a valid > token. > > However, the probability of a server being able to skip the startup > phase relies on how frequent a user revisits a particular server, > identified by the value of the TLS SNI extension. To put another way, > there is a missed opportunity if a client is visiting a server > instance that it has previously visited with a different server name. > > Our proposal addresses exactly that. The proposed extension allows a > client to use a token for a different server name, if the server > address is the same. This maximizes the chance of the server skipping > address validation and the startup phase. > > > ---------- Forwarded message --------- > From: > Date: 2019=E5=B9=B44=E6=9C=884=E6=97=A5(=E6=9C=A8) 14:17 > Subject: New Version Notification for > draft-kazuho-quic-address-bound-token-00.txt > To: Kazuho Oku > > > > A new version of I-D, draft-kazuho-quic-address-bound-token-00.txt > has been successfully submitted by Kazuho Oku and posted to the > IETF repository. > > Name: draft-kazuho-quic-address-bound-token > Revision: 00 > Title: Address-bound Token for QUIC > Document date: 2019-04-04 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-kazuho-quic-address-bound-toke= n-00.txt > Status: > https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/ > Htmlized: > https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kazuho-quic-address-bound-tok= en > > > Abstract: > This document describes a QUIC extension for an address-bound token. > This token can be used for sharing address validation and congestion > controller state between the same two endpoints across multiple > connections and origins. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > -- > Kazuho Oku > --=20 Kazuho Oku From nobody Thu Apr 4 00:33:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A64120448 for ; Thu, 4 Apr 2019 00:33:15 -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 JNy5zuXL8425 for ; Thu, 4 Apr 2019 00:33:12 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E29C12042E for ; Thu, 4 Apr 2019 00:33:12 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id r25so984085lfn.13 for ; Thu, 04 Apr 2019 00:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=y6zUS4Thnni22fCymppy7WpO/yq0Ygd7WO+gUNs6x7w=; b=WDDfm8dL9zak5oM5f3GGRhdmuvML/aFrfRkg8ZbWLDQ7bscd+v5oK0UN446yCoDN7P ++N3rZLfgjsTYTloZxmSeZQF2pC8li5Fosq5nfNv9wnN8lTmBIAxfIv1T2Onvri/gllI 49SNiq3kScJ5cLPspWdQBBip90sp8rnYt9ETM3Wn4St8IVeYr6gn+9+KhDOfTckEGCdF QCNC4bB7JPuw0Rv1Awmk/+GcbkQ4gOCVahTPbtApyvkqjD8aDcLS0mA+EgTFUV29de/u HY209F9wgYrs/DiWpKhUc0pzRiEitbl/s3PYQZKuN3tUSJhCBAAT52S4Xq1pmt2I/XRU kL2w== 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=y6zUS4Thnni22fCymppy7WpO/yq0Ygd7WO+gUNs6x7w=; b=cHzsoYpk8vVLfFTVMmqs4KoStbdLMmXAoh9T2t2BB34oBtvyytP+EIykYDg99plnYU W+BWGSwn4mYEl1HpJvdKSSjcrfPeVCs4GHTQC4Y4uw20kOZkW2zM/AMllh8ghvD8qd4X A/adIOxfTjG0YKwS6AFfjbgul8d7uAO+i7D6OiIJtlmI3dzjQ0Rzhang88htr+5txlX0 SdB1Gz4Nc3KMP5K7I6h/JAZkBI7ex+1TBZg2Wp3vGFHlp8x2xcC8P+jUeVD1Z7kMc93c h5o86LwFah9Zw+tTUn7nhiWpzSBb/SqduUOaH3wYt/MfHAAxpv8WqmCar2KrHR0od9MZ 56xw== X-Gm-Message-State: APjAAAXCiEMzKC6y8zGJw6DpqVeFHGl4EQWCpt3wCRxdAzrB+DyyhXMM KzvhCRLlHRWrfZhqJr/dpbVR3uYed4IOw3tIqNx0kf4G X-Google-Smtp-Source: APXvYqyIDwFROWj0qafFNXOZVX5fWWIvJYQJnSx5mZ+PNBYZX9jVQEGvd/1SwIMKKIOvnrGVFjVTlskPuDQlcKkl6CY= X-Received: by 2002:ac2:489a:: with SMTP id x26mr2272610lfc.49.1554363190192; Thu, 04 Apr 2019 00:33:10 -0700 (PDT) MIME-Version: 1.0 References: <155435502215.22668.17009854749523198767.idtracker@ietfa.amsl.com> <7a20865a-b368-80eb-378d-1744c9577117@huitema.net> In-Reply-To: <7a20865a-b368-80eb-378d-1744c9577117@huitema.net> From: Kazuho Oku Date: Thu, 4 Apr 2019 16:32:58 +0900 Message-ID: Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt To: Christian Huitema 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.29 Precedence: list List-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, 04 Apr 2019 07:33:15 -0000 Hi Christian, Thank you for your comments. My responses inline. 2019=E5=B9=B44=E6=9C=884=E6=97=A5(=E6=9C=A8) 15:48 Christian Huitema : > > I am reading the draft, and I think that the discussion of congestion con= trol should be removed. Senders have all latitude to coordinate transmissio= n control across multiple connections, including using some form of multi-c= onnection congestion control. I think the draft would be easier to read if = it concentrated on just one purpose, the linkage of new tokens to server ad= dresses instead of service identities. That's a good suggestion. I agree that it does not need to be in this document, even though I think it is beneficial to describe how you could have a shared congestion controller. At the very least, it should be moved to the appendix. > > We probably need a slightly larger security analysis. What if a service p= art of a farm issued such a token without coordinating with the other servi= ces that use the same address? Could that be a form of DOS? Would you mind elaborating about the scenario a bit more? I ask this because I am not sure if that is a practical attack. Assuming that it is about an attacker running on the same server tuple, why can't the attacker just send packets by itself? I might also point out that section 8.1.3 of the transport draft [1] prevents such attacks from being run. [1] https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.secti= on.8.1.3 > > -- Christian Huitema > > On 4/3/2019 11:15 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > Nice work. > > Just a minor thing on priority in the appendix: what about IPv6 prioritie= s? That, and flow labels - are we starting to bypass much of the IPv6 desig= n because it is not (yet?) sufficiently widely deployed? Or are there secur= ity implications, and if so, should QUIC consider authenticating parts of t= he IPv6 header? > > Also, on name based alternative: > I=E2=80=99m wondering which non-HTTP/3 connections would really benefit a= s new designs can build in multi-purpose into the protocol whereas HTTP/3 m= ust follow HTTP semantics. You could argue about WebRTC/3 - but then - what= should it co-locate with which has sufficient intelligence to share the co= ngestion controller? You could argue share with HTTP/3, but that would prob= ably not rule out a name based solution either. > I=E2=80=99m not saying name based CG sharing is necessarily better, I=E2= =80=99m just wondering. > > OTOH if name based sharing is used that could place some assumptions on a= given load balancers tuple stickiness, if I understand correctly. That cou= ld be unfortunate. Or, if name sharing is only to target address validation= of the client perhaps different server hosts could share that information = successfully with a random or round robin load balancer? > > Mikkel > > On 4 April 2019 at 07.22.32, Kazuho Oku (kazuhooku@gmail.com) wrote: > > Hi, > > I have (finally) submitted "Address-bound Token for QUIC" I-D, that > proposes a QUIC extension allowing tokens to be shared between > connections that go to the same server address, even when the value of > SNI is different. Having such tokens would maximize our chance of > skipping address validation and slow-start phase. > > The I-D and the repo can be found at the links below: > > I-D: https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-tok= en/ > Github repo: https://github.com/kazuho/draft-kazuho-quic-address-bound-to= ken > > Please let us know what you think. > > Rationale behind the proposal: > > The startup phase (a.k.a. slow-start) is one of the things that has > negative impact on user experience. QUIC, in addition to reducing the > connection establishment latency from TCP, provides the possibility of > a server skipping the startup phase when a client provides a valid > token. > > However, the probability of a server being able to skip the startup > phase relies on how frequent a user revisits a particular server, > identified by the value of the TLS SNI extension. To put another way, > there is a missed opportunity if a client is visiting a server > instance that it has previously visited with a different server name. > > Our proposal addresses exactly that. The proposed extension allows a > client to use a token for a different server name, if the server > address is the same. This maximizes the chance of the server skipping > address validation and the startup phase. > > > ---------- Forwarded message --------- > From: > Date: 2019=E5=B9=B44=E6=9C=884=E6=97=A5(=E6=9C=A8) 14:17 > Subject: New Version Notification for > draft-kazuho-quic-address-bound-token-00.txt > To: Kazuho Oku > > > > A new version of I-D, draft-kazuho-quic-address-bound-token-00.txt > has been successfully submitted by Kazuho Oku and posted to the > IETF repository. > > Name: draft-kazuho-quic-address-bound-token > Revision: 00 > Title: Address-bound Token for QUIC > Document date: 2019-04-04 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-kazuho-quic-address-bound-toke= n-00.txt > Status: > https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/ > Htmlized: > https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kazuho-quic-address-bound-tok= en > > > Abstract: > This document describes a QUIC extension for an address-bound token. > This token can be used for sharing address validation and congestion > controller state between the same two endpoints across multiple > connections and origins. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > -- > Kazuho Oku > --=20 Kazuho Oku From nobody Sat Apr 6 17:45:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0273412017E for ; Sat, 6 Apr 2019 17:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ZdM+58pW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=5LKKkyYd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERbv2Tlue-vZ for ; Sat, 6 Apr 2019 17:45:23 -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 CB3ED120264 for ; Sat, 6 Apr 2019 17:45:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C1A0821BD6 for ; Sat, 6 Apr 2019 20:45:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 06 Apr 2019 20:45:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=Dm7I7JOegRfOwq1aQMb6O7s04ZJVvNukY87QRHyIBs8=; b=ZdM+58pW KdU1TkOCVF9RUpnDYiam1IGgGVh3duoVRuY7Bl4f0RoIcEikAv5CQArf6uYhbceV tAs0PAKCwawFRURTJbnHcgie3n0uplxOZrd3rWWthLeKDTfy/MDBDYRiVc5/OaAR nGyWzffgkITxurM9KDeXh+RPP6YbCsI8F1jgUrnDB5uPTB4dWI6Z87kIH0Lh4DQr 0lV+C4OiPJ393SwLk7wHFyDt9LH4svoazLrEp8a3jxnL7yPpEyUdKmeiRdfzIFM+ 3WoGBTSz3gKDqodwEDDqHwnMoHoAX+UtnIp7cz15TX4ThWUtCGgSRIbw7tsYt/NP 3XoYU4087YN9EA== 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-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Dm7I7JOegRfOwq1aQMb6O7s04ZJVv NukY87QRHyIBs8=; b=5LKKkyYdsykByyOJkX6FEnt75O7RW4CQuIPYg1avAZMFg VEZ27F7EsnSgEDzraM18OvDLVMRC+yCIYMmZoSkVYnz0RGOuzWlgwZlHvZnfPq92 zt8iXoDpoOt2SdstVhCyfIV1DTVDP8zio9778uE+i0iHG2DtMn7htsTf2548cIBa S6UFKUOvE3PU9F0H7vX5afMat0WfxmPZ5xg6LkYDcJX0X3pFlgHffbgo1dZddto3 yxE5bg1IHAvpAJcjMwaAhyGm00+yCi0mojMY3utDyMNT2eLYMmFzdw8AIZM/51gY om3m76YmPkVvEIyvrg4xDQRgHwXkZYTb4dbxDnVEQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddtgdefkeculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurheptggghf fvufesrgdttdertddtjeenucfhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihho nhhsuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepudduledrledrgeefrddvgedunecurfgrrhgrmhep mhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluh hsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id BA820E40E3 for ; Sat, 6 Apr 2019 20:45:18 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id E0735C5423 for ; Sun, 7 Apr 2019 00:45:15 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============8784130035326508072==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190407004515.E0735C5423@cloud.mnot.net> Date: Sun, 7 Apr 2019 00:45:15 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 00:45:28 -0000 --===============8784130035326508072== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+7/-7/=F0=9F=92=AC48) 7 issues created: - H3 spec fails to warn about initial_max_stream_data_uni (by huitema) https://github.com/quicwg/base-drafts/issues/2589 = - Construction of address validation token (by kirsey) https://github.com/quicwg/base-drafts/issues/2587 = - Attacks Against Address Migration (by martinduke) https://github.com/quicwg/base-drafts/issues/2582 = - Bring back AEAD_AES_128_CCM_8 now that we pad the plaintext (by DavidSc= hinazi) https://github.com/quicwg/base-drafts/issues/2581 = - Is path validation a SHOULD or a MUST -- pick one! (by igorlord) https://github.com/quicwg/base-drafts/issues/2580 = - Path validation should be done even for what looks like NAT rebinding (= by igorlord) https://github.com/quicwg/base-drafts/issues/2579 = - ClientFinished is HoL blocking, but has no normative text (by ianswett) https://github.com/quicwg/base-drafts/issues/2572 [-tls] = 16 issues received 48 new comments: - #2568 Reduce restrictions on valid RTT samples (9 by kazuho, mikkelfj, = janaiyengar, nibanks, ianswett) https://github.com/quicwg/base-drafts/issues/2568 [-recovery] [design] = - #2589 H3 spec fails to warn about initial_max_stream_data_uni (7 by mar= ten-seemann, huitema, LPardue) https://github.com/quicwg/base-drafts/issues/2589 = - #2552 Saving a round-trip time in the initial handshakes with retry (6 = by kirsey, martinthomson, mikkelfj, janaiyengar, ianswett) https://github.com/quicwg/base-drafts/issues/2552 [-transport] = - #2579 Path validation should be done even for what looks like NAT rebin= ding (5 by DavidSchinazi, erickinnear, igorlord, tatsuhiro-t) https://github.com/quicwg/base-drafts/issues/2579 = - #2581 Bring back AEAD_AES_128_CCM_8 now that we pad the plaintext (4 by= kazuho, LPardue, mikkelfj) https://github.com/quicwg/base-drafts/issues/2581 = - #2554 Congestion control during application limited state (4 by janaiye= ngar, pravb, ianswett) https://github.com/quicwg/base-drafts/issues/2554 [-recovery] [design] = - #2572 ClientFinished is HoL blocking, but has no normative text (3 by D= avidSchinazi, martinthomson) https://github.com/quicwg/base-drafts/issues/2572 [-tls] [editorial] = - #2566 Usage of "epoch" term in recovery draft (example code in appendix= es) (2 by DavidSchinazi, janaiyengar) https://github.com/quicwg/base-drafts/issues/2566 [-recovery] [editoria= l] = - #2184 kInitialRtt of 100 msec is too aggressive (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2184 [-recovery] [design] = - #2569 RTT sample should be taken only once for each largest_acked (1 by= ianswett) https://github.com/quicwg/base-drafts/issues/2569 [-recovery] [editoria= l] = - #2570 RTT computation section needs to mention largest_acked (1 by ians= wett) https://github.com/quicwg/base-drafts/issues/2570 [-recovery] [editoria= l] = - #2587 Construction of address validation token (1 by kazuho) https://github.com/quicwg/base-drafts/issues/2587 = - #2496 QUIC Version Ossification (1 by philsbln) https://github.com/quicwg/base-drafts/issues/2496 [-transport] [design] = - #2540 Version negotiation, reserved or 0x?a?a?a?a (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2540 [-transport] [editori= al] = - #2546 ACK of ACK are useful (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2546 [-transport] = - #2556 Should kPersistentCongestionThreshold be 2 or 3? (1 by pravb) https://github.com/quicwg/base-drafts/issues/2556 [-recovery] [design] = 7 issues closed: - Version negotiation, reserved or 0x?a?a?a?a https://github.com/quicwg/b= ase-drafts/issues/2540 [-transport] [editorial] = - Definition of Stream Final Size is ambiguous https://github.com/quicwg/= base-drafts/issues/2481 [-transport] [editorial] = - ACK Delay interactions with RTT calculation https://github.com/quicwg/b= ase-drafts/issues/2137 [-recovery] [editorial] = - Usage of "epoch" term in recovery draft (example code in appendixes) ht= tps://github.com/quicwg/base-drafts/issues/2566 [-recovery] [editorial] = - kInitialRtt of 100 msec is too aggressive https://github.com/quicwg/bas= e-drafts/issues/2184 [-recovery] [design] = - kInitialRtt of 100 msec is too aggressive https://github.com/quicwg/bas= e-drafts/issues/2184 [-recovery] [design] = - Stateless Reset Lacks Normative Text https://github.com/quicwg/base-dra= fts/issues/2471 [-transport] [design] = Pull requests ------------- * quicwg/base-drafts (+11/-8/=F0=9F=92=AC19) 11 pull requests submitted: - Don't arm the handshake timer if there's no data (by ianswett) https://github.com/quicwg/base-drafts/pull/2590 = - First handshake timeout at 1 second (by ianswett) https://github.com/quicwg/base-drafts/pull/2586 = - Replace recovery epoch with congestion event (by ianswett) https://github.com/quicwg/base-drafts/pull/2585 [-recovery] [editorial] = - Call OnPacketAckedCC() for in-flight packets, not just ack-eliciting (b= y ghedo) https://github.com/quicwg/base-drafts/pull/2584 = - Spell 'Application' correctly (by ghedo) https://github.com/quicwg/base-drafts/pull/2583 = - No state transition if RESET_STREAM is suppressed (by martinthomson) https://github.com/quicwg/base-drafts/pull/2578 [-transport] [editorial= ] = - Distinguish between reserved versions (by martinthomson) https://github.com/quicwg/base-drafts/pull/2577 [-transport] [editorial= ] = - Clarify final size definition (by martinthomson) https://github.com/quicwg/base-drafts/pull/2576 [-transport] [editorial= ] = - Normative text for 1-RTT before handshake completion (by martinthomson) https://github.com/quicwg/base-drafts/pull/2575 [-tls] [editorial] = - Add normative language for stateless reset (by martinthomson) https://github.com/quicwg/base-drafts/pull/2574 [-transport] [editorial= ] = - introduce a version alias transport parameter (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2573 = 11 pull requests received 19 new comments: - #2573 introduce a version alias mechanism (7 by martinthomson, marten-s= eemann, kazuho, martinduke, mikkelfj) https://github.com/quicwg/base-drafts/pull/2573 = - #2574 Add normative language for stateless reset (2 by martinduke, mikk= elfj) https://github.com/quicwg/base-drafts/pull/2574 [-transport] [editorial= ] = - #2584 Call OnPacketAckedCC() for in-flight packets, not just ack-elicit= ing (2 by ghedo, ianswett) https://github.com/quicwg/base-drafts/pull/2584 = - #2575 Normative text for 1-RTT before handshake completion (1 by mikkel= fj) https://github.com/quicwg/base-drafts/pull/2575 [-tls] [editorial] = - #2585 Replace recovery epoch with congestion event (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/2585 [-recovery] [editorial] = - #2586 First handshake timeout at 1 second (1 by pravb) https://github.com/quicwg/base-drafts/pull/2586 = - #2588 Use Congestion Recovery Period in psuedocode (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2588 [-recovery] [editorial] = - #2510 all HTTP/3 protocol violations should lead to connection errors (= 1 by kazuho) https://github.com/quicwg/base-drafts/pull/2510 [-http] = - #2524 Specify behavior for post-handshake CRYPTO messages (1 by nharper) https://github.com/quicwg/base-drafts/pull/2524 [-transport] [design] = - #2529 Allow not creating QPACK codec streams (1 by ghedo) https://github.com/quicwg/base-drafts/pull/2529 = - #2281 Include handshake anti-deadlock logic in pseudocode (1 by Ralith) https://github.com/quicwg/base-drafts/pull/2281 [-recovery] = 8 pull requests merged: - Use Congestion Recovery Period in psuedocode https://github.com/quicwg/base-drafts/pull/2588 [-recovery] [editorial] = - Distinguish between reserved versions https://github.com/quicwg/base-drafts/pull/2577 [-transport] [editorial= ] = - Clarify final size definition https://github.com/quicwg/base-drafts/pull/2576 [-transport] [editorial= ] = - Clarify RTT calculations in recovery https://github.com/quicwg/base-drafts/pull/2506 [-recovery] = - Replace recovery epoch with congestion event https://github.com/quicwg/base-drafts/pull/2585 [-recovery] [editorial] = - First handshake timeout at 1 second https://github.com/quicwg/base-drafts/pull/2586 = - Spell 'Application' correctly https://github.com/quicwg/base-drafts/pull/2583 = - Call OnPacketAckedCC() for in-flight packets, not just ack-eliciting https://github.com/quicwg/base-drafts/pull/2584 = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============8784130035326508072== 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 07, 2019

Issues

quicwg/base-drafts (+7/-7/=F0=9F=92=AC48)

7 issues created:

16 issues received 48 new comments:

7 issues closed:

Pull requests

quicwg/base-drafts (+11/-8/=F0=9F=92=AC19)

11 pull requests submitted:

11 pull requests received 19 new comments:

8 pull requests merged:

Repositories tracked by this digest:

--===============8784130035326508072==-- From nobody Sun Apr 7 18:42:46 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E4D1201C2 for ; Sun, 7 Apr 2019 18:42:44 -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=lowentropy.net header.b=EuuN5nNm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o9x3h7Ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffb9FVsSWD0D for ; Sun, 7 Apr 2019 18:42:42 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477C51200C4 for ; Sun, 7 Apr 2019 18:42:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 143FF21C47 for ; Sun, 7 Apr 2019 21:42:41 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 07 Apr 2019 21:42:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=JzDI7uFOl6aCKB5OE1fPlfikXs9nAyK n82qZPxsPETg=; b=EuuN5nNmwo3lDCMSWYc1iULH2tUyNtymxmDBmpUGEPijo01 6VoBf5E+QZm7dqMcCvfVz8o3tFgrCiMqe00fP3/QBbIkxGOyk1EZo47TroS++Sre q4WEG6lNkgJR6fFg8EfMBfxI5Eg0RMaM6N7EZuFu4M84glyhvZEgAiNdRHVL5tRN pSEWl3+DZUOOpDiy+Q2goQ/H/FczJ+7mJukpTfZYvTJ4VQmskCugmvM488K4VNPf 0ImTN6OCkIZli1+EWIWB+tkVxrpyT7IxZ6i38kgU12Pz/w/ayBvoK2FojZP0BAde d0p7aTPrncEiKzjsnnXlvv44vb7Nhbn8ZKjQMBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=JzDI7u FOl6aCKB5OE1fPlfikXs9nAyKn82qZPxsPETg=; b=o9x3h7CaJY2k2r7rIn+8mc ZFLyh6lL722f+o/6qYtJUM5f6oPStOaaVLggG2dhrmLuQksa+MNiZGTXL7ZMxQpY AQF7oGJGuCXjY3slfoRcEGBBlktV1fQKw3bKOLf3VfnT/JtDZWlhvFKgRX4dpqai kkqqoa8MFkVvup7EUk5wiRkmnYFb/X5Fi70LyVsXVS8tqkMJyrp+zre0OMkJYJnL ncEtp2hGFXc2mDiSa5KqgchMgdRrf1HR6IomGYyqKmTlMRoWQEeoaO7NZurhhxEG Gdojgy9RvokzQEFEvfezvccobJ7g9QYV2yzu3CSscKseb2iXsKPB7XQymYH3lo7w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvgdehtdculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfgg fkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhm shhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihii vgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A088E7C1B9; Sun, 7 Apr 2019 21:42:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <155435502215.22668.17009854749523198767.idtracker@ietfa.amsl.com> <7a20865a-b368-80eb-378d-1744c9577117@huitema.net> Date: Sun, 07 Apr 2019 21:42:34 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: =?UTF-8?Q?Re:_Fwd:_New_Version_Notification_for_draft-kazuho-quic-addres?= =?UTF-8?Q?s-bound-token-00.txt?= Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 01:42:45 -0000 On Thu, Apr 4, 2019, at 18:33, Kazuho Oku wrote: > > We probably need a slightly larger security analysis. What if a service part of a farm issued such a token without coordinating with the other services that use the same address? Could that be a form of DOS? > > Would you mind elaborating about the scenario a bit more? I ask this > because I am not sure if that is a practical attack. Assuming that it > is about an attacker running on the same server tuple, why can't the > attacker just send packets by itself? I might also point out that > section 8.1.3 of the transport draft [1] prevents such attacks from > being run. I don't think that this is a particularly important consideration. Servers make their own determination about whether clients present a risk of denial of service. If, as the proposed mechanism proves, the server has recently communicated with the client on the same address, the risk of DoS exposure might reasonably be discounted. This isn't the only consideration here though. When we were discussing the use of resumption tickets across different connections, I pointed out that there is no harm in using a ticket with any connection. Tokens aren't significantly different in this regard - a server still needs to treat them with suspicion. But linkability concerns might cause clients to avoid use of a token: 1. When you use a token, you can't use it again (or you link any sessions that use the same token). 2. When you use a token, you link that use to the source of the token. The first is what motivates having a clear signal from the server about the scope over which the token is usable. Otherwise, the client might waste a token on a connection attempt that was never able to use the token. Whether or not the second will determine use of the token is largely a question of client policy. There is some advice we can offer, but ultimately clients will make their own determination. For instance, it might be reasonable to use a token if the connection is being made in response to resolving a URL that was provided by the first server. But there are numerous constraints on connection establishment that might alter any determination. Anything we might consider publishing needs some treatment of these considerations. From nobody Sun Apr 7 19:07:25 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F424120265 for ; Sun, 7 Apr 2019 19:07:23 -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=lowentropy.net header.b=PbGy4bmT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KSUHAJD6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDkWHYJevLiC for ; Sun, 7 Apr 2019 19:07:21 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053251201F8 for ; Sun, 7 Apr 2019 19:07:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id ACE462201F for ; Sun, 7 Apr 2019 22:07:19 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 07 Apr 2019 22:07:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=KVZZWBj+Rhb27wooTalca6vhW9VtX2UXYsGY+1oK8z0=; b=PbGy4bmT vfbbX54WboXsKe1ZI2hUm+I69F0Dq5K7OpozVTxOYai4LLTMSeojuZuUjfctbAPa jQMGIaHvN21g1p3QDazLn4E/NVLZkFsthqq69wR3r1gyCj1B+pH7R9D4TrPyDB2s rCRhEahdTXhiswmOC5ypBtv5sPMWY1Myfhv22LNrS9QxJ+wkfiHP24ugCxjicMCI AVQ6x9DOkM/NM9Ay97FVyjla6bG8IubXnbMDFfmE3p81MQniMSEMX+G07zFfUwDi ig+vfO1Q6uhBZMXf3F5HrK6hsvlMy+XrW6fbmw2XXS2D94+4TbgmMIXwoq4nkHDk ny09owMxKt4z5A== 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-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=KVZZWBj+Rhb27wooTalca6vhW9VtX 2UXYsGY+1oK8z0=; b=KSUHAJD6IG8MvCF70hSPZuUiOkMU4SgoXZxHdY8ipZ6Ru bdPLMPVgrfcgK8PMqmYJ+JwoKjQPuGStznTrQItFcrMuxG/4x7+4xM0I4Tk0H6Ao WwG2yCuiwr8F/duelgpAcJIMP5t92x1RgEkrDX643EVId6mtBhOoDi4ZNgZDuY6p cWC0Pfc/RVX9BrZPjcYHdN2fHDog7Q1cASjRaDquPW6cRwJkPWK1MYBSx5C5WGEJ ZoBNaHVeuVWVIqFXxi/YtBMA0LDcvJPxD934Ngo8+xI4ZHrX4IWuHjHrZrXW2mfS wPEhg2r2FMuSgDfAvoEMSES8xz/iBWeT3NX1TE3Hg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvgdehieculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfgg fkfffhvffutgesthdtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshho nhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthh husgdrtghomhenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E9CFD7C1B9; Sun, 7 Apr 2019 22:07:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> Date: Sun, 07 Apr 2019 22:07:21 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Version Negotiation Greasing Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 02:07:23 -0000 Philip's idea for greasing the version number field of the long packet header is an interesting one. It creates a way for servers and clients to cooperatively negotiate new versions without state. It encourages middleboxes to either: a) allow new versions, because they routinely see new versions in use, or b) block new versions and either block those connections or slow them down if clients retry The question of whether retrying is necessary is an interesting one that we might want to take up before we conclude this. I tend to think that as long as this mechanism comes with a commitment to support the version as long as QUIC is supported, retries won't be necessary. The PR (https://github.com/quicwg/base-drafts/pull/2573, thanks Marten) includes not just a version number, but also a salt value, which I think is very important. Clients can use the new fake version, with different encryption keys on every version. Servers can avoid holding state by using a static key (maybe one derived from the same base as they use for stateless reset) and generating the salt from the version using a PRF, such as salt = HKDF-Expand-Label(static, "label for " + version.hex(), 16). This allows servers to use all 2^32-2 spare version numbers without holding any significant amount of state. As we add more versions, the version number space might need to be divided between different base versions, but this is still a good amount of variation. The version number space might need to be divided further to allow rotation of the key over time, but that doesn't change the calculus much. This seems like it could be subject to gaming by middleboxes, who can connect to the server and learn the salt for different versions. However, if servers only offer a small number of fake versions in response to connection attempts (1 is enough for this purpose, but more on that below), and those fake versions are selected randomly or using a counter, the work required to find a matching value goes up pretty significantly. 2^16 connections are required to have a 50% chance of getting the same value if they are chosen randomly; and - counter-intuitively - more if the server supports >1 version because the middlebox needs to make connections in all possible versions. The state a middlebox needs to commit to remembering all salt values is pretty high - assuming that the entire space is covered. This is in the order of 2^36 bytes if we insist on a 16 byte salt, though we might reasonably insist on longer salts. Our current salt is 20 bytes, and 32 byte salt is no more expensive to compute or produce with HKDF-SHA256, so we could probably go that high. So I think that this is a good change, the best we can do in our current state. I do think that it needs a little more text about the operation of this mechanism, and we still need to sort out the lifetime thing, but it's pretty good. I might propose some text amendments. This might be better attached to NEW_TOKEN, which corresponds more closely with connection establishment patterns. A transport parameter is simpler, but the use of a version number will link sessions, so you can't realistically use a fake version over multiple connections. That suggests to me that altering NEW_TOKEN is better than what is proposed. From nobody Sun Apr 7 22:04:52 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BD11203A8 for ; Sun, 7 Apr 2019 22:04: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=ajrt2EHt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pFmTSlXX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbuDfmhOTttP for ; Sun, 7 Apr 2019 22:04:48 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3661B1203A6 for ; Sun, 7 Apr 2019 22:04:48 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 34E5E2250C; Mon, 8 Apr 2019 01:04:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 08 Apr 2019 01:04:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=Z502HlOdY1Va0XusZ6xmeFj4axg95P N6Rsk4aKa58Ok=; b=ajrt2EHthrzzQ6vgbGPBTJukVjjfaYXdH3TWHjAeg4ZHKN ImbbzV19nhDOKDzewJI8tCBSVYhEJ3iS0kbM7pENR9WqwKwgedXa77RYWbIQEbNm VgPGbv7gjomkIT2PhLv4k/fF2bvN9DszGHchnf1px/tyjj07KP39JEOSELa8JKMJ mNQF+lQpNkxjGFCZutP3RH5dq+frh6dt0Ir+Z4TSXyr5yC8AFMmUOOZ1hqZYqFua ZImQduEo4+bYWJ8MpGyA2znO+s7lZHUgfcits0PY8h5y+YhSlokkZOjwOnm8L1iu EHXKmuWYZanxP1B6zfRLorclQG69OaMtils2tKiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Z502Hl OdY1Va0XusZ6xmeFj4axg95PN6Rsk4aKa58Ok=; b=pFmTSlXXbLcb5tVOKDDNum SVVkxKJff4JYGkbTm6NDekI4IBy4kDBDPoJggPJGOW2vlM1QPBLzqcEWgfJ6Hu0e 7t4NgAa+rmwgAYe5/dAk9uLU5kC2VZVKyYr+QrGpC9aZHyjgtIM6U8SsyPt2Py1u olWBwc/vsH3IFL+slKSW0gFpZ6Qea0F9IZM1/CK1X4LuJa5z1NRq8Yjv1bpocUpP VMvFZKe7L+NT7zlsp2RVdBy7PyVBiRZUcdbFbTKaSRvUTMwwcBiZtoVYCNGxs8ss tO3nOrB0m9OUZpUSKWRY3GiFOWxmDvWzoXOMRCNeaNIVMvSb4JHNYcAkvtdMqDUg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtgfgggfukfffvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfho thhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgih hthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddv keenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlh hushhtvghrufhiiigvpedu X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 676B210310; Mon, 8 Apr 2019 01:04:45 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: DRAFT minutes from IETF104 Prague Message-Id: Date: Mon, 8 Apr 2019 15:04:44 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 05:04:51 -0000 ... are available at: https://github.com/quicwg/wg-materials/blob/master/ietf104/minutes.md As always, thanks to our scribes. Please make suggestions for improvements as pull requests, or responses = to this e-mail. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Apr 8 00:28:05 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29871203B6 for ; Mon, 8 Apr 2019 00:28:03 -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 Sjogo55YfqaT for ; Mon, 8 Apr 2019 00:28:01 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512121200A3 for ; Mon, 8 Apr 2019 00:28:01 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id v8so16440133itf.0 for ; Mon, 08 Apr 2019 00:28:01 -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=aZf6cONLkPte3FYP3O4VcYh1g0sH+RvpxIgNB391Rc0=; b=LqPjG5yXLmRzLD88dKZcBX9MlorlSuIVzocHDb/qA00zGfugGh9RzsYAExduUs6NJ1 /ZVVeEbsf7oFxrC5VFNQ14OYKNqdRDGR/t6lAbIJd7jPUAtcGTNcyIWpPlIFgFsi4OBj EfZsIkrkvLDn9UfPCR/kXlHD4gj+RTwVKWhmXUI4GrAwy7SoRmiLNejqwc88rOQQGPFP iWKsSwtNmp9JeZIjbNm1/qI5hLOnG2H1dP5yRQyi+3iO3ChwsbiL07/8GOsBSkgK7w+Z e43QjTiHzdjTGE6acWCeTQ+sI9pgBaNmqeXvXD9UvMNVnIgmprjjJB1AcsfKayZjbyMP /tTQ== 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=aZf6cONLkPte3FYP3O4VcYh1g0sH+RvpxIgNB391Rc0=; b=lULLFbLF26d8+EYuCx3ZfQ24kV90y4jhKyJPk5DYQztw/l8J9GgAi+mpt6rlXdALpH NpJmTNapWZQNJVUY5Iw4N+d5T8dexdIWhJHjJkWzH1b9AK1Tl1cThp37Kjs8+QyZfX3B jWIffdpBt8KmOEogb7jq9UBgKtcz5kXt2SdXdbMH68X8YSzcqF5VEHBKUan3f742ER1Y To5n3UIQx7nKJ9PoRAVDVX9kbncuCJBvvKYjqQLw9+g5FTOChzOUkCL0HFeFa5QVMBZo qxhV5POlpKLPrXRn+bgPFs1DhRB9PyeUiCIY39soAj8s41jWy8nBvG3xPYbbMOf8h0zh yn+Q== X-Gm-Message-State: APjAAAV7C0Ho1fV7ynw9by+pkSReu9oLF/0Y0SJDCZ96ddTKcMkxxLL1 XHp836unZPi6ukeaUMEoaNRyGGm2Tw52BZpHSZkr7w== X-Google-Smtp-Source: APXvYqyrUws2mPUYrjXcCZw92XswJX5TJuy+m7dHmuTmTXFT3Hfl6GzeT6kykLRGI3SXD1qeZDZx8NKy1JlJHr9t/Q0= X-Received: by 2002:a24:c544:: with SMTP id f65mr19427357itg.90.1554708480596; Mon, 08 Apr 2019 00:28:00 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 8 Apr 2019 00:27:59 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 8 Apr 2019 00:27:59 -0700 Message-ID: Subject: Re: Version Negotiation Greasing To: Martin Thomson , quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000b71fde0585ffc6c0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 07:28:04 -0000 --000000000000b71fde0585ffc6c0 Content-Type: text/plain; charset="UTF-8" Should we consider a longer version number to reduce the chance of odd conflicts? Mikkel On 8 April 2019 at 04.07.35, Martin Thomson (mt@lowentropy.net) wrote: Philip's idea for greasing the version number field of the long packet header is an interesting one. It creates a way for servers and clients to cooperatively negotiate new versions without state. It encourages middleboxes to either: a) allow new versions, because they routinely see new versions in use, or b) block new versions and either block those connections or slow them down if clients retry The question of whether retrying is necessary is an interesting one that we might want to take up before we conclude this. I tend to think that as long as this mechanism comes with a commitment to support the version as long as QUIC is supported, retries won't be necessary. The PR (https://github.com/quicwg/base-drafts/pull/2573, thanks Marten) includes not just a version number, but also a salt value, which I think is very important. Clients can use the new fake version, with different encryption keys on every version. Servers can avoid holding state by using a static key (maybe one derived from the same base as they use for stateless reset) and generating the salt from the version using a PRF, such as salt = HKDF-Expand-Label(static, "label for " + version.hex(), 16). This allows servers to use all 2^32-2 spare version numbers without holding any significant amount of state. As we add more versions, the version number space might need to be divided between different base versions, but this is still a good amount of variation. The version number space might need to be divided further to allow rotation of the key over time, but that doesn't change the calculus much. This seems like it could be subject to gaming by middleboxes, who can connect to the server and learn the salt for different versions. However, if servers only offer a small number of fake versions in response to connection attempts (1 is enough for this purpose, but more on that below), and those fake versions are selected randomly or using a counter, the work required to find a matching value goes up pretty significantly. 2^16 connections are required to have a 50% chance of getting the same value if they are chosen randomly; and - counter-intuitively - more if the server supports >1 version because the middlebox needs to make connections in all possible versions. The state a middlebox needs to commit to remembering all salt values is pretty high - assuming that the entire space is covered. This is in the order of 2^36 bytes if we insist on a 16 byte salt, though we might reasonably insist on longer salts. Our current salt is 20 bytes, and 32 byte salt is no more expensive to compute or produce with HKDF-SHA256, so we could probably go that high. So I think that this is a good change, the best we can do in our current state. I do think that it needs a little more text about the operation of this mechanism, and we still need to sort out the lifetime thing, but it's pretty good. I might propose some text amendments. This might be better attached to NEW_TOKEN, which corresponds more closely with connection establishment patterns. A transport parameter is simpler, but the use of a version number will link sessions, so you can't realistically use a fake version over multiple connections. That suggests to me that altering NEW_TOKEN is better than what is proposed. --000000000000b71fde0585ffc6c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Should we consider a= longer version number to reduce the chance of odd conflicts?

Mikkel

On 8 April 2019 at 04.0= 7.35, Martin Thomson (mt@lowentropy.ne= t) wrote:

<= div>
Philip's idea for greasing the version number field of t= he long packet header is an interesting one. It creates a way for servers = and clients to cooperatively negotiate new versions without state. It enco= urages middleboxes to either:

a) allow new versions, because they routinely see new versions in use, = or
b) block new versions and either block those connections or slow them d= own if clients retry

The question of whether retrying is necessary is an interesting one tha= t we might want to take up before we conclude this. I tend to think that a= s long as this mechanism comes with a commitment to support the version as = long as QUIC is supported, retries won't be necessary.

The PR (htt= ps://github.com/quicwg/base-drafts/pull/2573, thanks Marten) includes n= ot just a version number, but also a salt value, which I think is very impo= rtant. Clients can use the new fake version, with different encryption key= s on every version.

Servers can avoid holding state by using a static key (maybe one derive= d from the same base as they use for stateless reset) and generating the sa= lt from the version using a PRF, such as salt =3D HKDF-Expand-Label(static,= "label for " + version.hex(), 16). This allows servers to use a= ll 2^32-2 spare version numbers without holding any significant amount of s= tate. As we add more versions, the version number space might need to be = divided between different base versions, but this is still a good amount of= variation. The version number space might need to be divided further to a= llow rotation of the key over time, but that doesn't change the calculu= s much.

This seems like it could be subject to gaming by middleboxes, who can c= onnect to the server and learn the salt for different versions. However, i= f servers only offer a small number of fake versions in response to connect= ion attempts (1 is enough for this purpose, but more on that below), and t= hose fake versions are selected randomly or using a counter, the work requi= red to find a matching value goes up pretty significantly. 2^16 connection= s are required to have a 50% chance of getting the same value if they are c= hosen randomly; and - counter-intuitively - more if the server supports >= ;1 version because the middlebox needs to make connections in all possible = versions.

The state a middlebox needs to commit to remembering all salt values is= pretty high - assuming that the entire space is covered. This is in the or= der of 2^36 bytes if we insist on a 16 byte salt, though we might reasonabl= y insist on longer salts. Our current salt is 20 bytes, and 32 byte salt i= s no more expensive to compute or produce with HKDF-SHA256, so we could pro= bably go that high.

So I think that this is a good change, the best we can do in our curren= t state. I do think that it needs a little more text about the operation o= f this mechanism, and we still need to sort out the lifetime thing, but it&= #39;s pretty good. I might propose some text amendments.

This might be better attached to NEW_TOKEN, which corresponds more clos= ely with connection establishment patterns. A transport parameter is simpl= er, but the use of a version number will link sessions, so you can't re= alistically use a fake version over multiple connections. That suggests to= me that altering NEW_TOKEN is better than what is proposed.

--000000000000b71fde0585ffc6c0-- From nobody Mon Apr 8 01:30:08 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BFE1201CE for ; Mon, 8 Apr 2019 01:30: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 QaarcptiNFo7 for ; Mon, 8 Apr 2019 01:30:05 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF82812006D for ; Mon, 8 Apr 2019 01:30:04 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id D193F30182 for ; Mon, 8 Apr 2019 11:30:02 +0300 (EEST) Received: from slate.eggert.org (pf.eggert.org [172.16.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id B0ED0882A29 for ; Mon, 8 Apr 2019 11:28:31 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_9026F0DF-F4BB-4FD5-AEAD-1B7E18E1A3B0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Doodle poll for Spring 2019 QUIC Virtual Interop Day Message-Id: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> Date: Mon, 8 Apr 2019 11:28:30 +0300 To: QUIC WG X-MailScanner-ID: B0ED0882A29.A1A10 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 08:30:07 -0000 --Apple-Mail=_9026F0DF-F4BB-4FD5-AEAD-1B7E18E1A3B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please indicate your availability, if you have a stack you wish to test: = https://doodle.com/poll/ctxcirqtbnkaniqp (This will be a remote interop day. Next physical one will be with the = interim in London.) Lars --Apple-Mail=_9026F0DF-F4BB-4FD5-AEAD-1B7E18E1A3B0 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlyrBi4ACgkQVLXDCb9w wVdrUxAAqrrNqL9y+ThsxjAiaKc4pfJy7gaOsLvTdo9bWsv9+dGAE6w/33FarT+y FSuqinVCVk/hk7rYcdZYkxLHmLcbEjRBipzVQKoODIbEl+8TJGKattEmDAt3P1vN RPJPxpStzCnsIMyiicQ5H78RmXLkMftNNZ5phoPsto7SNY0KH0IRj8khljQAc8+r V+piRvDUl42xTNTXezXWU1GbgC4owxu80DymGFy8K23uCy8p7trXy5F/sm+WkKH5 XGX1KW5z2SJDweHXiXbU/e5+WhX2OhGTBWgGMGLhwo6pni+l9AtXPVhcvWFyfwe6 X1rirMsZc1z9L5vU5+DvEKa1xzX3i/gydrQmEL0QxblzfMPGYW51LD5Bc070XZKx CFIJ6L5fKEJGZWO3K/Paoyb9hGjG6OOTsonStXIZWlkljYrMGFXkueuoq7cuA4jL u+ZXK07BrGveIgkFey2WnyI6bNbe8RN69vtJMOfeC+k6ckmkF4K/IF/L3jVH4cR3 hRH+WlFRxci4RwUPkTf6/9rCgA/GxMUWo3gXS8LI6tnj2F8bgEpQTUs5SaNu8yIG PHZwpKsFx9LMRv48nCmnnXRZLCzItOSj3xSEK+w9TH50XF//PLDNhYXNKPyh+kLl 6Udk1Jg7ZxSKx28UIi5352/T2m6K0sneqrDbtclMKapRIF8Nhcc= =H6oc -----END PGP SIGNATURE----- --Apple-Mail=_9026F0DF-F4BB-4FD5-AEAD-1B7E18E1A3B0-- From nobody Mon Apr 8 01:38:31 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B7F1202C9 for ; Mon, 8 Apr 2019 01:38:29 -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 wU1Qrn4tsJep for ; Mon, 8 Apr 2019 01:38:28 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539961202AB for ; Mon, 8 Apr 2019 01:38:28 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 86D034007A for ; Mon, 8 Apr 2019 11:38:26 +0300 (EEST) Received: from slate.eggert.org (pf.eggert.org [172.16.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id BC0CC882A1F for ; Mon, 8 Apr 2019 11:37:13 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_A5EA65AA-D2DE-4F30-B1B6-181A85AD1479"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Register by Apr 20: QUIC (quic) WG Interim Meeting: 2019-05-22 Date: Mon, 8 Apr 2019 11:37:12 +0300 References: <155301916321.18151.8976693122612446640@ietfa.amsl.com> To: QUIC WG In-Reply-To: <155301916321.18151.8976693122612446640@ietfa.amsl.com> Message-Id: <1D3EF27C-6ADE-47A8-8037-1792C3C5EA03@eggert.org> X-MailScanner-ID: BC0CC882A1F.A4D87 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 08:38:30 -0000 --Apple-Mail=_A5EA65AA-D2DE-4F30-B1B6-181A85AD1479 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, reminder to please register for the interim by **April 20, 2019** for = both in-person and remote attendance. See = https://github.com/quicwg/wg-materials/blob/master/interim-19-05/arrangeme= nts.md Thanks, Lars On 2019-3-19, at 20:12, IESG Secretary wrote: >=20 > The QUIC (quic) Working Group will hold > a multi-day interim meeting. >=20 > Session 1: > 2019-05-22 09:30 to 17:30 Europe/London > Session 2: > 2019-05-23 09:30 to 17:30 Europe/London >=20 > Meeting Location: > London, GB >=20 > Agenda: > = https://github.com/quicwg/wg-materials/blob/master/interim-19-05/agenda.md= >=20 > Information about remote participation: > Remote attendance instructions will be emailed after registration. See = https://github.com/quicwg/wg-materials/blob/master/interim-19-05/arrangeme= nts.md >=20 > Registration is required for both in-person and remote attendance. = Preceded by non-IETF interop event on May 20-21. >=20 --Apple-Mail=_A5EA65AA-D2DE-4F30-B1B6-181A85AD1479 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAlyrCDgACgkQHbmKvSnu NPj6GBAAhKLyKr46eOXcWf0YnauEUu/dCWjg9Aod1Lx6xCU2333t9aguuuNBX0kB QOz+TRcnyPBwweKgUsUVdO/glr0mZ70+ytyoEGd1JIDIdiNbA0nuRtVQDk4LmBgl A/WowXZQJADlOdeXDQNE250BPlEeNb7SzCfhlDHgo7Z9CaFkQgpvUSQ8AoJ5bZfA Ls59A4wXFqkkbzeiX67ywiA3ehtXKs91EY46mfGQ7325ekKttnO/uuWKfH5fshbi Qdh1ACoavNuf52nu5k9sj6CFpa1lDjrmaPAWwbEExlkEUMO1CRLc+kBCMWU0c8sy Mm1tHjxJeYseTIvQBhRKTwrMv0zIyXW95ITFcA3X4A/AGam9GkKYqsDxSaKSv/C8 WxmdNAn/IWpPr4NauxJVLF7S86Bxn0UdV8xLAXhOkm+lHrH6hqbScriirleVoXhL MZuOqXm24DmN/PIZZ/7asb+Ce/HH3yw0SG0MXULySGybGo2ViZPpz1I5VhMjeQau jEg5gftj7CyKr4pyzaCHBRq67DKHFyhxF5OyGa/xky/rn4mwpDZPvDpNofSs+z2L Z7iD9GlIfhgvj+q8W4d+3cQwU9c/odjXkr/BCc4t99QQoIHpYXKSAs1+SKsCPGf7 eLpwsFYaCmKt9GcWLWlQjt7GTCtr3fLO9vEyKt79mjUoT2WkLMQ= =rRdq -----END PGP SIGNATURE----- --Apple-Mail=_A5EA65AA-D2DE-4F30-B1B6-181A85AD1479-- From nobody Mon Apr 8 15:04:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5D61200C5 for ; Mon, 8 Apr 2019 15:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=AfQ0LjaV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VI4V3RGl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8J3Poaupk2H for ; Mon, 8 Apr 2019 15:04:14 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C26A120052 for ; Mon, 8 Apr 2019 15:04:14 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 89276A2D for ; Mon, 8 Apr 2019 18:04:13 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 08 Apr 2019 18:04:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=48DtF6VjxagzSxERHsVq5EvREUWL+Bs xHgj0XmIjQtY=; b=AfQ0LjaVfwcmJHZL0v7UwdP3sYrXbALLTSUbm8gQ774hLsQ KYexo81DGQYtWhCej5vqOnxh9VR0O2qJfeoUTm+aIngXWNBRkl3DmOdHJBROPxTD KuL3Dk/GpvCV+v6dW28E++XklN1WuRgEvhzyckfi3Qx1sMK1n0jc8raI3KgwNU5N Ym/lcdiBYjbRf2vnGfvl5bZaosVFViRRJojVHbahxdza4yMndbYEv0enXu6me+QZ elEc8Jywj9c2CnQN9lNjhymNnN5zEOJIsuIQ0RZN9xJSgO4SGxxUOq6+EuV29Oy5 +DRchzP44h2NLwZ7W2C+qHu5MbJ3VySOqBHiSlw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=48DtF6 VjxagzSxERHsVq5EvREUWL+BsxHgj0XmIjQtY=; b=VI4V3RGlTssF4jaSaeFLDv z14fOG4gxVSGDaONW41LjlHGuyH94Rq+CwhDK10MaH2FqGLEbHh4qTJqa7c+/rcN ZrJu0miaOFQ8KLFBGx6AzyVWHDJ7wwPa2eJsJujrHiOxQu4OR3y5Zh31QSQRBlfB E2ZrTXW7dUEk9Ue3sNS1YOS0fx6KfDF9T+TV9f3/ATuMqJWzIniwrTRlPyRPcoXV JtnZd2XWZ6to78AhjdLwvBEU/BMIc6DzorODwCcna3zM79dJtOU3f8gQipX1yjvf RtLbsTzNNfsGZBLkqfUNFfCUgFFE7TtIUfbE1cRdcJvoXprmBG452Z9oRCiKDYpQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpeguohhoughlvgdrtghomhenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC9237C412; Mon, 8 Apr 2019 18:04:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> Date: Mon, 08 Apr 2019 18:04:12 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Doodle poll for Spring 2019 QUIC Virtual Interop Day Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 22:04:16 -0000 Spring is a long way off and these are Autumn dates. On Mon, Apr 8, 2019, at 18:30, Lars Eggert wrote: > Please indicate your availability, if you have a stack you wish to > test: https://doodle.com/poll/ctxcirqtbnkaniqp > > (This will be a remote interop day. Next physical one will be with the > interim in London.) > > Lars > > Attachments: > * signature.asc From nobody Mon Apr 8 15:07:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F0D120118 for ; Mon, 8 Apr 2019 15:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=LWbwJyEs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iluyESvg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EdK2RxdFR5t for ; Mon, 8 Apr 2019 15:07:48 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23F4120073 for ; Mon, 8 Apr 2019 15:07:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 33391B18 for ; Mon, 8 Apr 2019 18:07:47 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 08 Apr 2019 18:07:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=tUEeg PYstRrd7xAKLgRb8ugtMPjz+TjWOwnm0h0aE14=; b=LWbwJyEsPApYaWoHXrv5z Wutugm+MlqmUKuFfJbFQpOghviZbQAtH8GHAPo+If490OmeXc1F4pjrURaGf0Zdc oFwSzyqVQ1P5K7YPptDJAqsoFP3m9ueQ4HTBnSDbeflqmPGSPieuEtvn4yeDfm2L hwyEboFR0Aeps7ATAMFTJrXSndQabfG/mkYEWNe3TvxxE9rzSg4N0LxbIfkxdyzl jRLYuPg61r0VKjPOcqdjfkS3xOkqzOsdUD1FDOXNexE5v2iUvOu/WxS8+bORy1SC tpJRRtC1f/TujtKEWFjUZh2M0d9JTjRop04vigtA0czuC2kCA5LOmKg1+hjiYxWp Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=tUEegPYstRrd7xAKLgRb8ugtMPjz+TjWOwnm0h0aE 14=; b=iluyESvgoWCFEyD7yYuxBNOBROPo/k9Cy5NAnBoYTdKSy5YyEO1mZYCHF mwJoB5XG5g7DxolH22hJtlH1JB70JB1sC6fMC0YGeNG18VBI9IxSNTRLHCzMMukh Z08gPQIGoGtpRl2gOHaoOGr5F+1NklUeKudF2rvNuouEQ9FdnH+ADv/tYTX0xEJc Z8AF+j7Oe6IqxZ2e6KYHbWphbTInDdhAiW9pn98OtpoJhUD9JVPJQ7cU1VS2XzSi VegImREByDZYCdESpnRbCaHm1E+E4GbvBrx6cO62mLHihrfN26nUjANe7d7I0U+a 9VEyBt5Pw2APUv6tXh0KdWYedYuxA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6D2197C1B9; Mon, 8 Apr 2019 18:07:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <3c578c88-100f-41a5-a513-4ea184df900a@www.fastmail.com> In-Reply-To: References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> Date: Mon, 08 Apr 2019 18:07:46 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Version Negotiation Greasing Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 22:07:49 -0000 On Mon, Apr 8, 2019, at 17:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Should we consider a longer version number to reduce the chance of odd= =20 > conflicts? Not sure what sort of conflict you are talking about, but if you are tal= king about reducing the odds of collision to something trivial, then we'= re probably talking 128 bit version numbers. That starts to get unwield= y, and there are plenty of other ways in which this scheme fails before = then. 32 isn't terrible and has the advantage of not having to re-open = the patient. From nobody Mon Apr 8 15:49:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EB8120118 for ; Mon, 8 Apr 2019 15:49: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=CV3/Iebx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OyyuGju9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQH-ypg-Xi3f for ; Mon, 8 Apr 2019 15:49: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 97FF11200A0 for ; Mon, 8 Apr 2019 15:49:26 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A098A2358E; Mon, 8 Apr 2019 18:49:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 08 Apr 2019 18:49:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=e BXOopBGSp8nreldMwnthqaEMpzi6sk/j9W+PIGnua8=; b=CV3/Iebx7055iFGcI wv8jZe/e5Lv9y90UHmlVni1Hh0kVHJ9nWSk9sDWxQRMRzDeKbepqqr17oyFdaGnr WMzY9ZzIXAil7t5wa1ndZigdVX/2SiDgTrqCljEnPAuEj5p1sO/Bx8sOjiOX7nqx QRaiUXYnnJ/oowyKAIO0QrZb8DqR0rEdFM+DaLDJCuS0H2V3p36NXRXrhGocQ3pb BRZNQrDTOs29iePXGbzdoBnE4esIhCa+WWVs+WhyypGmTOGP8DoMraOsP4wJU2n1 nPAj2cFPv5+Pc5w2c3nZONGikwslEyOydJTBwd9G+Zy7u9OSQEipHHPHTYAN+ZfI Ywo3Q== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=eBXOopBGSp8nreldMwnthqaEMpzi6sk/j9W+PIGnu a8=; b=OyyuGju9qipCCcBF8n6aP1l7cloV/mR8+RJE5R4A42CqeppwKN/rRlVJP 8k2XH+c7f5FDJbIAMNoXdsH1Ykp0AxPsmRXIQQpm4YruZrC8pfq0+cKCBp4g5taq /76h37+AqhkTp2ETILZ0kJPteo/Ltt3Plm3SYP+yNl6MTzG6kOA3tlrydUypoEJq R/Ad91SWsdp8FnNzkMkw/SjqzCl8Ym6xmkrJanTfmTBCTnEoTk+Pb0IdO0gLaQsu ZwOrFm9c6S41CjjnDjJKtKssCJmNg0DcBWv/fFzymxDBXN+abvaqlIQjkuuZ2fvL SixQDHCdZoGYpBTy5Kq8Omp2Udh0A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtjehmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hmnhhothdrnhgvthdpughoohgulhgvrdgtohhmnecukfhppedugeegrddufeeirddujeeh rddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 6100510310; Mon, 8 Apr 2019 18:49:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Doodle poll for Spring 2019 QUIC Virtual Interop Day From: Mark Nottingham In-Reply-To: Date: Tue, 9 Apr 2019 08:49:21 +1000 Cc: quic@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <15A403C0-E559-469B-9AC0-A25B4B4EC492@mnot.net> References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> To: Martin Thomson X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 22:49:28 -0000 +1. > On 9 Apr 2019, at 8:04 am, Martin Thomson wrote: > > Spring is a long way off and these are Autumn dates. > > On Mon, Apr 8, 2019, at 18:30, Lars Eggert wrote: >> Please indicate your availability, if you have a stack you wish to >> test: https://doodle.com/poll/ctxcirqtbnkaniqp >> >> (This will be a remote interop day. Next physical one will be with the >> interim in London.) >> >> Lars >> >> Attachments: >> * signature.asc > -- Mark Nottingham https://www.mnot.net/ From nobody Mon Apr 8 15:55:55 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70EC12037F for ; Mon, 8 Apr 2019 15:55:48 -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 PLKY6aMBiVqh for ; Mon, 8 Apr 2019 15:55:46 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9B1120121 for ; Mon, 8 Apr 2019 15:55:42 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hDdAv-0005Zq-9s for quic@ietf.org; Tue, 09 Apr 2019 00:55:39 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp04.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hDdAL-0007mW-0Y for quic@ietf.org; Mon, 08 Apr 2019 18:55:31 -0400 Received: (qmail 17510 invoked from network); 8 Apr 2019 22:54:57 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.204]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Apr 2019 22:54:57 -0000 To: Martin Thomson , quic@ietf.org References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <3c578c88-100f-41a5-a513-4ea184df900a@www.fastmail.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Mon, 8 Apr 2019 15:54:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <3c578c88-100f-41a5-a513-4ea184df900a@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Version Negotiation Greasing X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.20) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qqQrbgP4pRtQUiA6jpoDQB602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVifr7VuQsVIHbMPxWgh50C+s7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBiuj1YIZWyGteeTEbAD/lb/vRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFt8i77Wu2Jb/TI0CxS53moc/SlgXpNwUDmiieE9G+9VqfZ1kay mqFCHRp6u+mIhIXg5jssJAnfERZ2C5vj1sOdsnQOD0r6/AaHZiEtdTMtMljoSvSqrGwueTSCQFid cy15jQ4HwbF4aWaRl0axA525ouWBOXp8nHKe0R+FkIqN7hkgzj0zEmu34GPXR572RNl5VgW9/bkt U41htiJ8fk7NkHmplbyYh4+w03es32OzjfSo5Jhwk+hMTKYppuA2BaWeipTPWMHGUquOFNpW9R6n Md9TLrF9l3ItGfA/WrnALV6y4t4La5KOjBsoSy5ilx7fZqY0WkD+XXhBRGrlXn3JpeiB3WUjThWG GGKjbLz7Xx1G047RODDSOAU8VRBdjarRhquvBzKEzdsRbaiLpp7t82t4C4SlaCuF6Oqyplz7a94E pv+Z3RfD+aRmwAVlEJHcERWeKKG4PAQYNyavp7c49NytKwXBULDghWx/HNECYBbSGe3okMCcn14J 4XO+5ud/T3PyrU8k7kOG1sksLbGuThBnfKTn7FqkG7MXqekUFYHRZ4YizZEe9VMcrJA1TtxdruwC 6/RsMQ4p0WvdrKbTQj5uZu6/KnCQVobYDADwqQCbJpStz/eIZMdQBf3zqXbW15Q6CZxYjafGpi3c b03a4ZFy04e73oo5Jp1iUunX3+VlFawbDxpzYifNwA/+CbHA2fz9gpiGyR7D15JIzS+z7i8K8WY4 szo4Gwow0vwlYMfpTQuMHNi5DO10BOGC1ZJT0NaIcaHtK0XZjSPnTTBX4w== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 22:55:54 -0000 On 4/8/2019 3:07 PM, Martin Thomson wrote: > On Mon, Apr 8, 2019, at 17:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:= >> Should we consider a longer version number to reduce the chance of odd= =20 >> conflicts? > Not sure what sort of conflict you are talking about, but if you are ta= lking about reducing the odds of collision to something trivial, then we'= re probably talking 128 bit version numbers. That starts to get unwieldy= , and there are plenty of other ways in which this scheme fails before th= en. 32 isn't terrible and has the advantage of not having to re-open the= patient. In practice, the "alt version" will have to be stored the same way server specific data is stored -- new token, session resume token, etc. That means specific to an SNI and possibly ALPN. But then we get a 32 bit token largely unique to an SNI, which does not play too well with SNI encryption. Unless of course version greasing is coordinated with SNI encryption. There will not be leakage if services that share the same fronting server select the same version number grease and salt. But then we have to consider what to do for services that hide behind several fronting servers, such as multiple CDN. It seems complicated. -- Christian Huitema From nobody Mon Apr 8 19:30:55 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BE2120184 for ; Mon, 8 Apr 2019 19:30:53 -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 xgmZVHu23fWH for ; Mon, 8 Apr 2019 19:30:51 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF3012017E for ; Mon, 8 Apr 2019 19:30:51 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id u17so1746463lfi.3 for ; Mon, 08 Apr 2019 19:30:51 -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=s/Oaqm9qCUhIzhIBX3LujtfUyR3sd21SpVoccnKP3A4=; b=pRj5LQAailBGXXYuZWmR7lyEYFX42xp7Nbh9Iu9iJgCbK7dNOAuEwR3hTuAkVUhoE2 EZvWX57DQh7pmK1KkrGMkLPaa+dT8OnlApC6zLiXRK5i3JutHhHgyE5wdO7dB3jILXa/ Ow/UWeWvXq/+8ALYOjuvHOiWcTX9AZQxj2lhr+3LJWQxMAcgtjY95RuB0TPJNwlmjQKg aRzFm0nhXNJhuOjGsKqRnpjJhvJHdOTnv/sq9bbn5xSXAV7WAvDMRdNPrBZQ90nujo4v sxGS/EJF0a7IldWgyt75frmKd6taN04ydzORdoJDaaGdNzWEb9/QuHeBmzsFDIPOmHrG OBkQ== 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=s/Oaqm9qCUhIzhIBX3LujtfUyR3sd21SpVoccnKP3A4=; b=trYP4cbH4RtCbp/DgeBZ+HdOBDU0H4VuV5fTayEoJcTeOA56jErMBXJzIcLAe4cKjV DgYBjs+Z8jkjkZ6bGBlWWtr5hptjlwqWzVeFbeTjRJwiBjVcH49e3/te9MW4tdZ1aw+9 sZLDlnwVq8g/0iqTN/hOPd1LEDr3hJUVOnkhC9kWWUo/+PhN1yXqXl7WeN8C918f5EQU 0mfM9rX+8IjmxxSybNauvrJRsyyxUPvKCQkot2JCblxoyMdh1hGSPtYXTDkJa3pOfNJe 230aOjHdeDB/2h0RRii2E07nDzhdg3vGf8OufWo/0Fnk0AZ3rXe2geyboGvj1IDu+f+C kwaw== X-Gm-Message-State: APjAAAWWcCzBu6JSqqkgtVhdM15I2lLm67DZTdNLf1Ku/W//97NRs5+I Rm3aKImuZFkUqrPS2/vxu33tGmWzG/sgN4UZ3A9Y73MQ X-Google-Smtp-Source: APXvYqzmgNTwF1Llt6iZjlaL99Znkc8aWdsSU90fK6bS6qvkSZR/bzbr8jD4wQHdh05l5BiuyCARLRrGb83/dsOF/gw= X-Received: by 2002:ac2:5bde:: with SMTP id u30mr5380751lfn.6.1554777049809; Mon, 08 Apr 2019 19:30:49 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <3c578c88-100f-41a5-a513-4ea184df900a@www.fastmail.com> In-Reply-To: From: Jana Iyengar Date: Mon, 8 Apr 2019 19:30:38 -0700 Message-ID: Subject: Re: Version Negotiation Greasing To: Christian Huitema Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="000000000000c247f005860fbdcc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 02:30:54 -0000 --000000000000c247f005860fbdcc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I like the mechanism quite a bit, and I agree with Martin's comment. I'll note that the lifetime is critical for us to be able to deploy newer versions, and I think the lifetime details are important to work out. I also like the idea of _not_ sending this in transport params but in a frame later. While I understand that it might go in the same store, the lifetime of this thing might be quite different to the address validation token. The considerations for the lifetime of address validation tokens have to do with rotation times for those keys, where a server could reasonably much longer lifetimes for versions. Unless there's an argument that they should be the same, I'd rather not tie the lifetimes of version selection and address validation. Instead of NEW_TOKEN, we could use a separate NEW_VERSION frame, to keep them semantically separate. Martin: I don't understand what you mean by "supporting the version as long as QUIC is supported". Also, a middlebox can force a version negotiation, how does it force a Retry? On Mon, Apr 8, 2019 at 3:56 PM Christian Huitema wrote: > > On 4/8/2019 3:07 PM, Martin Thomson wrote: > > On Mon, Apr 8, 2019, at 17:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > >> Should we consider a longer version number to reduce the chance of odd > >> conflicts? > > Not sure what sort of conflict you are talking about, but if you are > talking about reducing the odds of collision to something trivial, then > we're probably talking 128 bit version numbers. That starts to get > unwieldy, and there are plenty of other ways in which this scheme fails > before then. 32 isn't terrible and has the advantage of not having to > re-open the patient. > > In practice, the "alt version" will have to be stored the same way > server specific data is stored -- new token, session resume token, etc. > That means specific to an SNI and possibly ALPN. But then we get a 32 > bit token largely unique to an SNI, which does not play too well with > SNI encryption. > > Unless of course version greasing is coordinated with SNI encryption. > There will not be leakage if services that share the same fronting > server select the same version number grease and salt. But then we have > to consider what to do for services that hide behind several fronting > servers, such as multiple CDN. It seems complicated. > > -- Christian Huitema > > > > --000000000000c247f005860fbdcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like the mechanism quite a bit, and I agree with Martin&= #39;s comment. I'll note that the lifetime is critical for us to be abl= e to deploy newer versions, and I think the lifetime details are important = to work out.

I also like the idea of _not_ sending this in transpor= t params but in a frame later.=C2=A0 While I understand that it might go in= the same store, the lifetime of this thing might be quite different to the= address validation token. The considerations for the lifetime of address v= alidation tokens have to do with rotation times for those keys, where a ser= ver could reasonably much longer lifetimes for versions. Unless there's= an argument that they should be the same, I'd rather not tie the lifet= imes of version selection and address validation.=C2=A0 Instead of NEW_TOKE= N, we could use a separate NEW_VERSION frame, to keep them semantically sep= arate.

Martin: I don't understand what you mean by "su= pporting the version as long as QUIC is supported". Also, a middlebox = can force a version negotiation, how does it force a Retry?
=
On Mon= , Apr 8, 2019 at 3:56 PM Christian Huitema <huitema@huitema.net> wrote:

On 4/8/2019 3:07 PM, Martin Thomson wrote:
> On Mon, Apr 8, 2019, at 17:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote= :
>> Should we consider a longer version number to reduce the chance of= odd
>> conflicts?
> Not sure what sort of conflict you are talking about, but if you are t= alking about reducing the odds of collision to something trivial, then we&#= 39;re probably talking 128 bit version numbers.=C2=A0 That starts to get un= wieldy, and there are plenty of other ways in which this scheme fails befor= e then.=C2=A0 32 isn't terrible and has the advantage of not having to = re-open the patient.

In practice, the "alt version" will have to be stored the same wa= y
server specific data is stored -- new token, session resume token, etc.
That means specific to an SNI and possibly ALPN. But then we get a 32
bit token largely unique to an SNI, which does not play too well with
SNI encryption.

Unless of course version greasing is coordinated with SNI encryption.
There will not be leakage if services that share the same fronting
server select the same version number grease and salt. But then we have
to consider what to do for services that hide behind several fronting
servers, such as multiple CDN. It seems complicated.

-- Christian Huitema



--000000000000c247f005860fbdcc-- From nobody Mon Apr 8 19:39:11 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7431201D0 for ; Mon, 8 Apr 2019 19:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[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 Kh_EkjfIgWhg for ; Mon, 8 Apr 2019 19:39:08 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 D608A1200C4 for ; Mon, 8 Apr 2019 19:39:07 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id h16so13002572ljg.11 for ; Mon, 08 Apr 2019 19:39:07 -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=uIDXeOZdSxHOOW9FRKqpEVcP8vUfLFBuNA7eolzKRAI=; b=rVGkGrau/3VOcXK62MH7B8jDUFfcIvR64munI5QZDA+4vemq7aX5UPKkEo8GInL3i/ xriuQy2M1LMKmhVOc/Cg4Bdr2kTTLiPUfkjoBtmK8v98vW0mghiodwzIr16N4tf2t9LT ub7RW4VElAF0u8deiEHi6bOX0VUHFUI2tZquJh+nVAxd9IauchhSA7KH6yRNLME8fkux /yf+H9ts4nhcHRTpUNP10dasRPzZ5fp9zvfurXEkc+aShBQL6pcb75HLfvq+RCf8m2+Q hPsykcu9Ei6WZL9TvcDZjHZc3HZt79sEltdOKFaPujpWwULTC0+RePQvRegA73CbQ6jx Mcdg== 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=uIDXeOZdSxHOOW9FRKqpEVcP8vUfLFBuNA7eolzKRAI=; b=MWxlBVOe7QtSLuxfZAOZlyFo1Xo2n3z8zVvyn1b3CXmYNjZXxyrIwhdf8ya8r9k9AF pB7so4u9zIGCAFWZ6cEQoRkDi4uYfqCaubDtDofhUtOHss85ifvEtGiFqqH4IzupkQXt eXzYTHexXsMuXKaxaDluvWfFxu5eTwxNQ6w0e65NFWuCznlPuKIojWQej+iMGUq16Zv1 YkXo8Fe/F5FrUfZEEW1ZW+dLzAN5c6tqcAE2nffn5m+Afu0Kfn57/4kTp4L5wg6V7JGW jpKveHJD2C3rkELzRRMRkWv5545/DHEtH7R9PpXyVuuGOqoyQmUpAPLezDsWZnhJ4Hvi xNxg== X-Gm-Message-State: APjAAAVoa2/H71IrKKIeAfuo5kc2/lqXKS8h3i6CP0+otZfOyE6BTCah ASlH/iUbukMt31fUvwwlXFwB1Vg/kmXEbelbulc= X-Google-Smtp-Source: APXvYqwSoT/EQWfaWSjjB3GpwubzwI1+bltqVuQTaVSJO74W1ViTNBtKOrq7l2S4qUyTKVawe0RsmyZgt6eolF+sMv4= X-Received: by 2002:a2e:9812:: with SMTP id a18mr14886836ljj.146.1554777546120; Mon, 08 Apr 2019 19:39:06 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <3c578c88-100f-41a5-a513-4ea184df900a@www.fastmail.com> In-Reply-To: From: Jana Iyengar Date: Mon, 8 Apr 2019 19:38:55 -0700 Message-ID: Subject: Re: Version Negotiation Greasing To: Christian Huitema Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="0000000000005762ce05860fdb32" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 02:39:10 -0000 --0000000000005762ce05860fdb32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Christian: It seems to me that you could co-ordinate greasing with eSNI. Can you say more about what gets complicated with multiple fronting servers= ? On Mon, Apr 8, 2019 at 3:56 PM Christian Huitema wrote: > > On 4/8/2019 3:07 PM, Martin Thomson wrote: > > On Mon, Apr 8, 2019, at 17:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > >> Should we consider a longer version number to reduce the chance of odd > >> conflicts? > > Not sure what sort of conflict you are talking about, but if you are > talking about reducing the odds of collision to something trivial, then > we're probably talking 128 bit version numbers. That starts to get > unwieldy, and there are plenty of other ways in which this scheme fails > before then. 32 isn't terrible and has the advantage of not having to > re-open the patient. > > In practice, the "alt version" will have to be stored the same way > server specific data is stored -- new token, session resume token, etc. > That means specific to an SNI and possibly ALPN. But then we get a 32 > bit token largely unique to an SNI, which does not play too well with > SNI encryption. > > Unless of course version greasing is coordinated with SNI encryption. > There will not be leakage if services that share the same fronting > server select the same version number grease and salt. But then we have > to consider what to do for services that hide behind several fronting > servers, such as multiple CDN. It seems complicated. > > -- Christian Huitema > > > > --0000000000005762ce05860fdb32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Christian: It seems to me that you could co-ordinate greas= ing with eSNI. Can you say more about what gets complicated with multiple f= ronting servers?

On Mon, Apr 8, 2019 at 3:56 PM Christian Huitema <huitema@huitema.net> wrote:

On 4/8/2019 3:07 PM, Martin Thomson wrote:
> On Mon, Apr 8, 2019, at 17:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote= :
>> Should we consider a longer version number to reduce the chance of= odd
>> conflicts?
> Not sure what sort of conflict you are talking about, but if you are t= alking about reducing the odds of collision to something trivial, then we&#= 39;re probably talking 128 bit version numbers.=C2=A0 That starts to get un= wieldy, and there are plenty of other ways in which this scheme fails befor= e then.=C2=A0 32 isn't terrible and has the advantage of not having to = re-open the patient.

In practice, the "alt version" will have to be stored the same wa= y
server specific data is stored -- new token, session resume token, etc.
That means specific to an SNI and possibly ALPN. But then we get a 32
bit token largely unique to an SNI, which does not play too well with
SNI encryption.

Unless of course version greasing is coordinated with SNI encryption.
There will not be leakage if services that share the same fronting
server select the same version number grease and salt. But then we have
to consider what to do for services that hide behind several fronting
servers, such as multiple CDN. It seems complicated.

-- Christian Huitema



--0000000000005762ce05860fdb32-- From nobody Mon Apr 8 20:26:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166481202D0 for ; Mon, 8 Apr 2019 20:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 6w6x5Wa87aah for ; Mon, 8 Apr 2019 20:26:47 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79B8120286 for ; Mon, 8 Apr 2019 20:26:46 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 10so11090153lfr.8 for ; Mon, 08 Apr 2019 20:26:46 -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=XaTahSOi2mmpo1If9bEry3f8PSa1RjCJvdHzzVKNKDE=; b=gaBoFNnqnohLhbh41tVLm9rL2FvkEEAjveimOiJlIjOVeuQgiJ2yEgCNgA7GNyhahf BaoF9fSi0GitB6VEBYmyo8JjKa9DyyzPN8FFAJhzM0gDc3qwR4tstmum6TFmSj73mqm6 v5xwXAni0Gyr8IxzFiSJ5tbb4PJ320a5tRH9ZXCKFKL29D7qwu9+NNi0TWo8eHaJ96/l Z7idT900/XQrZF7/WZay7zLhPiI/8SIM2E6D40G6KEecDJue7iiDhFEmqZ7qEESCDbl+ ugBqU6V4VMNgqw/6bMgjW3iR55YQHEF0G+751pvJfVqEJOl2vEKCBSezWE4/2lKhyNZ7 CYqw== 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=XaTahSOi2mmpo1If9bEry3f8PSa1RjCJvdHzzVKNKDE=; b=qvWDrrobHY87N5RJjvypqXh1I1n1UM3YUfIGI/MDcI6C3Ef8Br6aQPs0Az/2VkM2Lw GOny7GDXIIlvWdaPEVbFTeWTzD3WolkHUJiQCuA1+nGs2MnZixpy/bZVTYjDSTmZhvEq IyjuDKc7CdKXCrji3yGqccSFupNrB8g+Mn2caPg7qSDxg19zD3QX4Grz7/acskfp9jVb aVtrOqy89EkvHziUpFOZrGlFYAgJM1dWaRJuAp1uIJtdcbVd6y/NsmnAWO3mrCdn/YI9 xcQ0tG5NPXlxzQmHK3JV28rK5S8ywVOMlJOKoG/Nl2eg2HLr0+v4p4T51o14GtqT7NbA 8crw== X-Gm-Message-State: APjAAAW8I3ceQQqhXqtVRnk+RYszB9F66aSLYEKvGuc8pBTOYfxICtXk tgxsafqQ9BZW4KVv9MEcxtqjlqoCt6TMwv5Cdx8= X-Google-Smtp-Source: APXvYqzU4L34RW036HlCVMCYEtk9G2Gu22Y7wGah8kgLS770j5luDzda2kKGFD3px8pn+AErjRu4Li+9uGEbMLNuHQw= X-Received: by 2002:ac2:420b:: with SMTP id y11mr18348136lfh.104.1554780405031; Mon, 08 Apr 2019 20:26:45 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> In-Reply-To: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> From: Kazuho Oku Date: Tue, 9 Apr 2019 12:26:34 +0900 Message-ID: Subject: Re: Version Negotiation Greasing To: Martin Thomson 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 03:26:49 -0000 2019=E5=B9=B44=E6=9C=888=E6=97=A5(=E6=9C=88) 11:07 Martin Thomson : > > Philip's idea for greasing the version number field of the long packet he= ader is an interesting one. It creates a way for servers and clients to co= operatively negotiate new versions without state. It encourages middleboxe= s to either: > > a) allow new versions, because they routinely see new versions in use, or > b) block new versions and either block those connections or slow them dow= n if clients retry > > The question of whether retrying is necessary is an interesting one that = we might want to take up before we conclude this. I tend to think that as = long as this mechanism comes with a commitment to support the version as lo= ng as QUIC is supported, retries won't be necessary. Correct me if I'm missing something, but my view is that retry (i.e. fallback to v1) is necessary. Not requiring retry means that a server cannot forget the randomized version number. As you state, a server can use a PRF to calculate the version number. But even in such case, a server needs to retain the static key being fed to the PRF. If the server loses the static key, clients would fail to reestablish connections. This is kind of a requirement that we have not had. In TLS (or the current draft of QUIC), it is possible to setup a new server just by generating a new private key and by obtaining a new certificate. No "persistent state" is required for running a server. Note also that we would not be able to switch to a different server that uses a different PRF. Going back to the discussion of the proposed approach in general, I think that it is a good idea. At the same time, I have a fear that trying to make this part of v1 might slow down the standardization process. Can't it be a v1 extension, considering the fact that the intent is to grease, and greasing works if only _some_ of the implementations support the feature? Until v1 gets finalized, we will be effectively greasing the version number field by exchanging private (Chromium) and experimental version numbers (0xffffffxx). Assuming that we can create a stable WG I-D of a greasing proposal by the time v1 gets finalized, we will have the room to continue running multiple versions. Another benefit of defining it as an extension is that it could have tighter requirements, such as requiring the server to retain persistent state. > > The PR (https://github.com/quicwg/base-drafts/pull/2573, thanks Marten) i= ncludes not just a version number, but also a salt value, which I think is = very important. Clients can use the new fake version, with different encry= ption keys on every version. > > Servers can avoid holding state by using a static key (maybe one derived = from the same base as they use for stateless reset) and generating the salt= from the version using a PRF, such as salt =3D HKDF-Expand-Label(static, "= label for " + version.hex(), 16). This allows servers to use all 2^32-2 sp= are version numbers without holding any significant amount of state. As w= e add more versions, the version number space might need to be divided betw= een different base versions, but this is still a good amount of variation. = The version number space might need to be divided further to allow rotatio= n of the key over time, but that doesn't change the calculus much. > > This seems like it could be subject to gaming by middleboxes, who can con= nect to the server and learn the salt for different versions. However, if = servers only offer a small number of fake versions in response to connectio= n attempts (1 is enough for this purpose, but more on that below), and tho= se fake versions are selected randomly or using a counter, the work require= d to find a matching value goes up pretty significantly. 2^16 connections = are required to have a 50% chance of getting the same value if they are cho= sen randomly; and - counter-intuitively - more if the server supports >1 ve= rsion because the middlebox needs to make connections in all possible versi= ons. > > The state a middlebox needs to commit to remembering all salt values is p= retty high - assuming that the entire space is covered. This is in the orde= r of 2^36 bytes if we insist on a 16 byte salt, though we might reasonably = insist on longer salts. Our current salt is 20 bytes, and 32 byte salt is = no more expensive to compute or produce with HKDF-SHA256, so we could proba= bly go that high. > > So I think that this is a good change, the best we can do in our current = state. I do think that it needs a little more text about the operation of = this mechanism, and we still need to sort out the lifetime thing, but it's = pretty good. I might propose some text amendments. > > This might be better attached to NEW_TOKEN, which corresponds more closel= y with connection establishment patterns. A transport parameter is simpler= , but the use of a version number will link sessions, so you can't realisti= cally use a fake version over multiple connections. That suggests to me th= at altering NEW_TOKEN is better than what is proposed. > --=20 Kazuho Oku From nobody Mon Apr 8 20:36:59 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01C5120388 for ; Mon, 8 Apr 2019 20:36: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=lowentropy.net header.b=AnEArf9D; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pbvzU6To Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmWQdkHuX4IA for ; Mon, 8 Apr 2019 20:36:57 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300AE120290 for ; Mon, 8 Apr 2019 20:36:57 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 41F6FB44 for ; Mon, 8 Apr 2019 23:36:56 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 08 Apr 2019 23:36:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=81Q0JiTtfxwglmFat43qHPDOUVMFAnP /+GpL811LFoY=; b=AnEArf9D5of4K4gIjwxBXdCI9v0weDCqS4zU0RFqr496TMO 3P6NLqwr7RdB3vv5PrCWe3ZuUuZjzyq7rddKilw/nd9KgG2/Y9KF7wktomUCrNBE JtDgYJaD9JiIkxiDLxOhl4xc1jSDhOEwscmNAF8M6xVuvyFiCFNqks7ndJRcKtsH iDS0XcnsV+BXhHxlSdJJq6kaFw++OZ/L4QR1tUP0EqKMFN/teOE3b32F8vaNAvGM FRbf8IRkolOT5tdeBFc6ZT5e1t6BbVlnxBTWFMMWYI1ibeGFw7L90bWrf14E3yOV da9iIyN8s+b7DpXUxvFxkRFFuLqngwNp+q7BPlg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=81Q0Ji TtfxwglmFat43qHPDOUVMFAnP/+GpL811LFoY=; b=pbvzU6Tom5beKtWGkgMbD2 kTHv4c1oVJh2jw0k3WKack0nxz1gyrvxnzhdJnIfL8TzhnjIdzIRERF4wKot0i4g 0nxwvMpI5ZbFV6jwoKGyaovyr4JijryneT1E6+G8TXTjf5NsYtWPGw20kyfjOcw0 i5qeO+/eM0ra+N40BY4N61QA41hTGvELSSbpYsBecyvv6lUwXmz0TCaHGimCC5jg QXOTyiKBeWk4keck6XDOUIiO0jBOSS6001yD9Jr/ppkOYlbXBCNdX7wwvmINPG+t GcUy6bZ12D825iwG6zmmJIxkwMjvNIhn+1GIDXHYuRdClv3cOBJmRPG6LCXiqIdQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5EDF37C1B9; Mon, 8 Apr 2019 23:36:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <3c578c88-100f-41a5-a513-4ea184df900a@www.fastmail.com> Date: Mon, 08 Apr 2019 23:36:56 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Version Negotiation Greasing Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 03:36:59 -0000 On Tue, Apr 9, 2019, at 12:31, Jana Iyengar wrote: > Martin: I don't understand what you mean by "supporting the version as > long as QUIC is supported". Also, a middlebox can force a version > negotiation, how does it force a Retry? I was being imprecise. I'm not talking about Retry, I'm talking about the client starting over with 0x1 rather than the aliased version. It's clear that an attacker can force a downgrade to TCP as long as you are willing to do that, but what I want to avoid is allowing an attacker to force a client to attempt another connection with version=0x00000001. If the alias comes with a commitment that says if 0xALIASEDV doesn't work, then 0x00000001 won't work either, then I think we're in a better place than we would be if we encouraged clients to fall back to 0x00000001. From nobody Mon Apr 8 20:44:45 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2C41206A2 for ; Mon, 8 Apr 2019 20:44:44 -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=lowentropy.net header.b=D04blSEu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qFVsq0tX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0H0KzkFHLj9 for ; Mon, 8 Apr 2019 20:44:42 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA49212069E for ; Mon, 8 Apr 2019 20:44:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 052EEB4F for ; Mon, 8 Apr 2019 23:44:41 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 08 Apr 2019 23:44:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=8J0bjFEHrIorePeJ8CCNQ0visbU+jnv W22DsD/BWS/Q=; b=D04blSEuIwlqvup5rxFq89pMeFAd2Gi3Rp30oxdrtMZJjWE jmQRqyHLxD7PyoWEvlCHB7lFOA0AW2J2/4tFNabIXHxJnuf0ra/I7ORAjXXDHEss XGVi5Pb57h0f0NFDTbTT47fdYx1y6n2xgGZvra1NDIMJa1DtPy9VweFpprVLpWzf w/4FIaxu2ChbNYB/N8+rtwScz2ydukAWNqW6k3Fn5C2seiTnbk0P1mXwLFCcQrXv EoDpLn4KjIC5Yo7lEMB74r14IIGGf4IjkqFRHvk2byUXjlt3iAyuoq98f6/bUuqT I877XzcX0wNOsLWxHnotcqjNKopeytQdnhau/IA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8J0bjF EHrIorePeJ8CCNQ0visbU+jnvW22DsD/BWS/Q=; b=qFVsq0tXSEPS3fQy3svqJr IAHSJiBnjDZwILmCc9pTsfj2mifmebCkUZfEQlij7qvGZ3RfeaqL2mgwMAesK9G7 sUqhKA30kR5WIUDWzbANJxsdpMB28JwTkner9yy1Bt3h9hM9QTEUmtgWEGdkSTc+ Fep+Yk2I147qqxDasVGkF8XSVxhPrhvsp1+XFVe/g2HzeYwznfDXfTPQsplh+fAS 81YHereMNlVvhg8lj7d2iWrv7Vb1KFyCasAWeMZWTHo0pRDg9JT5KseEk4VgkAqj nZp8I/8UXA+US4NF4cxrWBbQlunmIvbfqOg8G6V/iL4agyGGiI8m5WlLaoqOE4+Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 92C1F7C412; Mon, 8 Apr 2019 23:44:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> In-Reply-To: References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> Date: Mon, 08 Apr 2019 23:44:41 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Version Negotiation Greasing Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 03:44:44 -0000 On Tue, Apr 9, 2019, at 13:26, Kazuho Oku wrote: > Correct me if I'm missing something, but my view is that retry (i.e. > fallback to v1) is necessary. > > Not requiring retry means that a server cannot forget the randomized > version number. As you state, a server can use a PRF to calculate the > version number. But even in such case, a server needs to retain the > static key being fed to the PRF. If the server loses the static key, > clients would fail to reestablish connections. There is no obligation on the server to advertise a non-zero lifetime for this. If a deployment doesn't want to maintain a static key (which might be the same one that is used for stateless reset), then they don't have to. > At the same time, I have a fear that trying to make this part of v1 > might slow down the standardization process. Can't it be a v1 > extension, considering the fact that the intent is to grease, and > greasing works if only _some_ of the implementations support the > feature? Yes, this works pretty well as an extension. It works less well as a NEW_TOKEN addition, so there is some value to doing it now. > Until v1 gets finalized, we will be effectively greasing the version > number field by exchanging private (Chromium) and experimental version > numbers (0xffffffxx). Assuming that we can create a stable WG I-D of a > greasing proposal by the time v1 gets finalized, we will have the room > to continue running multiple versions. I'd like to eliminate the private use range, which I think is consistent with this design. After all, you only need to avoid collisions and the space is huge. (Note that it's possible to use alias to versions that have real semantics. You just have to ensure that the alias isn't active when you start talking those versions properly. We should discuss the consequences of that for middleboxes, but I tend to think that they turn out nicely in favour of the end to end model.) From nobody Mon Apr 8 20:56:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B78D1206FF for ; Mon, 8 Apr 2019 20:56:30 -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 F_Ln4lVZ9U7Q for ; Mon, 8 Apr 2019 20:56:27 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA1C120708 for ; Mon, 8 Apr 2019 20:56:27 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx61.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hDhs0-0005Di-W0 for quic@ietf.org; Tue, 09 Apr 2019 05:56:25 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp03.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hDhrv-0004Ep-G7 for quic@ietf.org; Mon, 08 Apr 2019 23:56:23 -0400 Received: (qmail 14121 invoked from network); 9 Apr 2019 03:56:09 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.204]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Apr 2019 03:56:09 -0000 To: Jana Iyengar Cc: QUIC WG , Martin Thomson References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <3c578c88-100f-41a5-a513-4ea184df900a@www.fastmail.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <1d902e55-b6ac-64d8-ec90-4ff6568b9914@huitema.net> Date: Mon, 8 Apr 2019 20:56:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------045FB27A210290B174ED3114" Content-Language: en-US Subject: Re: Version Negotiation Greasing X-Originating-IP: 168.144.250.223 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.23) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5kCG6U5HFWgODzEJ1/F2+BR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViIb/HfXZDYl1DK83XHTDG3s7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBo86SAdJ6bLtg5NStMc8F1x/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaKKIPrZJ10kMvva8ovj3zAHZqY0WkD+XXhBRGrlXn3JpQmmlZC3oVQ+ jcJ5OazzWexG047RODDSOAU8VRBdjarRhquvBzKEzdsRbaiLpp7t82t4C4SlaCuF6Oqyplz7a94E pv+Z3RfD+aRmwAVlEJHcERWeKKG4PAQYNyavp7c49PCP5Oeh0wumTJN3GP8dadTSGe3okMCcn14J 4XO+5ud/kQd20flzQbANLdk52AuMuB38Svk+UzDlV5QJ71ZZEZfRZ4YizZEe9VMcrJA1TtxdO4nN PsCHvSRYJiL/wE4eDk2AHKlQN6UeX0rDTzUF5HWi47L87arFMl038BorKljQ15Q6CZxYjafGpi3c b03a4ZFy04e73oo5Jp1iUunX3+VlFawbDxpzYifNwA/+CbHA2fz9gpiGyR7D15JIzS+z7i8K8WY4 szo4Gwow0vwlYMfpTQuMHNi5DO10BOGC1ZJT0NaIcaHtK0XZjSPnTTBX4w== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 03:56:36 -0000 This is a multi-part message in MIME format. --------------045FB27A210290B174ED3114 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jana, If you are handling just one ESNI key, coordination is simple. Each service could pick something like: alt-version =3D (32 bits of) hash(ESNI public key, iteration number) salt =3D (128 bits of) hash(ESNI public key, version number) Since all the children know the ESNI public key, they all pick the same set of version numbers for a given number of iterations, and outside observers cannot derive the actual SNI from the version number. The salt is somewhat predictable, but that's no worse than putting the salt value in the QUIC-TLS draft. Some services may be available behind multiple ESNI keys, maybe because they can be accessed by multiple CDN. In that case, I suppose that they can prepare different sets of version numbers for each ESNI key. Then, when they see an incoming connection from a client, if they know which ESNI key the client used, they can generate the appropriate version numbe= r. So handling the scenario may be simpler than I thought. I hope I am not overlooking a residual leak. In any case, we need to document the relation between ESNI and greasing. -- Christian On 4/8/2019 7:38 PM, Jana Iyengar wrote: > Christian: It seems to me that you could co-ordinate greasing with > eSNI. Can you say more about what gets complicated with multiple > fronting servers? > > On Mon, Apr 8, 2019 at 3:56 PM Christian Huitema > wrote: > > > On 4/8/2019 3:07 PM, Martin Thomson wrote: > > On Mon, Apr 8, 2019, at 17:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: > >> Should we consider a longer version number to reduce the chance > of odd > >> conflicts? > > Not sure what sort of conflict you are talking about, but if you > are talking about reducing the odds of collision to something > trivial, then we're probably talking 128 bit version numbers.=C2=A0= > That starts to get unwieldy, and there are plenty of other ways in > which this scheme fails before then.=C2=A0 32 isn't terrible and ha= s > the advantage of not having to re-open the patient. > > In practice, the "alt version" will have to be stored the same way > server specific data is stored -- new token, session resume token, > etc. > That means specific to an SNI and possibly ALPN. But then we get a = 32 > bit token largely unique to an SNI, which does not play too well wi= th > SNI encryption. > > Unless of course version greasing is coordinated with SNI encryptio= n. > There will not be leakage if services that share the same fronting > server select the same version number grease and salt. But then we > have > to consider what to do for services that hide behind several fronti= ng > servers, such as multiple CDN. It seems complicated. > > -- Christian Huitema > > > --------------045FB27A210290B174ED3114 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Jana,

If you are handling just one ESNI key, coordination is simple. Each service could pick something like:

alt-version = (32 bits of) hash(ESNI public key, iteration number)

salt = (128 bits of) hash(ESNI public key, version number)

Since all the children know the ESNI public key, they all pick the same set of version numbers for a given number of iterations, and outside observers cannot derive the actual SNI from the version number. The salt is somewhat predictable, but that's no worse than putting the salt value in the QUIC-TLS draft.

Some services may be available behind multiple ESNI keys, maybe because they can be accessed by multiple CDN. In that case, I suppose that they can prepare different sets of version numbers for each ESNI key. Then, when they see an incoming connection from a client, if they know which ESNI key the client used, they can generate the appropriate version number.

So handling the scenario may be simpler than I thought. I hope I am not overlooking a residual leak. In any case, we need to document the relation between ESNI and greasing.

-- Christian

On 4/8/2019 7:38 PM, Jana Iyengar wrote:
Christian: It seems to me that you could co-ordinate greasing with eSNI. Can you say more about what gets complicated with multiple fronting servers?

On Mon, Apr 8, 2019 at 3:56 PM Christian Huitema <huitema@huitema.net> wrote:

On 4/8/2019 3:07 PM, Martin Thomson wrote:
> On Mon, Apr 8, 2019, at 17:28, Mikkel Fahnøe Jørgensen wrote:
>> Should we consider a longer version number to reduce the chance of odd
>> conflicts?
> Not sure what sort of conflict you are talking about, but if you are talking about reducing the odds of collision to something trivial, then we're probably talking 128 bit version numbers.  That starts to get unwieldy, and there are plenty of other ways in which this scheme fails before then.  32 isn't terrible and has the advantage of not having to re-open the patient.

In practice, the "alt version" will have to be stored the same way
server specific data is stored -- new token, session resume token, etc.
That means specific to an SNI and possibly ALPN. But then we get a 32
bit token largely unique to an SNI, which does not play too well with
SNI encryption.

Unless of course version greasing is coordinated with SNI encryption.
There will not be leakage if services that share the same fronting
server select the same version number grease and salt. But then we have
to consider what to do for services that hide behind several fronting
servers, such as multiple CDN. It seems complicated.

-- Christian Huitema



--------------045FB27A210290B174ED3114-- From nobody Mon Apr 8 20:58:11 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562E1120293 for ; Mon, 8 Apr 2019 20:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 t8Y6iSgf6Wlo for ; Mon, 8 Apr 2019 20:58:07 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 277C4120292 for ; Mon, 8 Apr 2019 20:58:07 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id q66so13148506ljq.7 for ; Mon, 08 Apr 2019 20:58:07 -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=1jfDja9FC/43CCOQJ7samsz1mRrAJhfNqnCr4D7CUbk=; b=NTuw6BTMoFKqxbiJuMVxEtd40Kbm+rr3uig4pBJffRJdRFd25zaS0L3AMOeNc+/U/U naWchUoV4iXuNALM825ouB3808R0U6tpjgRlkfYAtkwoEXVGywYoQ4j05Oqv5+hlT3me hE32LdcG94T8JolWIrC5K8peH8DvpRojUVGMRJPtlzgsBfLw+hQD3kgccsbOxdfSDD2u NQYKcV9/EUBqh1NW6sqchI4YnGX0W4mNUk0YHQGIwqvOKQZSt4vfrMJy8g54UnyzT4kp ZfK5YgqVYpr/YAAnMMuhaWEpWnFUXmSPS4OHi7XpToB8uwKGlK8wyutDBAh/Pqx4/YjO okvA== 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=1jfDja9FC/43CCOQJ7samsz1mRrAJhfNqnCr4D7CUbk=; b=Y9ttLfNuadUZhdyOUJlkJkrcPha2Aihy8sgUf3V6z+zmQ/2qbecw5+xYoZ+k5ytmIl ypNbrNpjcc5qPa+GP0hSc8HqpPvvy/SuQwmr8Ja6/6tg8srZET0sqKEShg0YmkUfB2fa p5CHlGnrMewtlTwOZraM/R4DZEfJDHe8/+q1ecsyfHNMhrAunnDyrW/QTnw0+0K0USim WfLfL0Oj6nlASP1M7C0kkEbneSr66fAtu+dAMXS9BzELk0dG03okX8hOttaec5Yd0Qs1 EilE1t6uJrSMASCoULVd7NPGomPTVRDqPEAGfFT5l51i6zHPcl7cEMs4cgC7gM5I5F05 4Sjw== X-Gm-Message-State: APjAAAXkfpp3ACoIaNQ1tPKAabXLU5e5KbSBU7Q6a+1Uo0BhvCwbA87s CJWGF/hyqXeS/7FEzWVYo0jepxC9+hI1ujcUtCZx4Q== X-Google-Smtp-Source: APXvYqwaQcpv8slWe6RZD18xPBc0DxnI/PR5/+HwtUB3Pp8/tDvMrOVIvbrCm36HMK8E9S2MvcTbIwZgJX4h8TL4Kz8= X-Received: by 2002:a2e:9010:: with SMTP id h16mr17820682ljg.16.1554782285350; Mon, 08 Apr 2019 20:58:05 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> In-Reply-To: <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> From: Kazuho Oku Date: Tue, 9 Apr 2019 12:57:54 +0900 Message-ID: Subject: Re: Version Negotiation Greasing To: Martin Thomson 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 03:58:09 -0000 2019=E5=B9=B44=E6=9C=889=E6=97=A5(=E7=81=AB) 12:44 Martin Thomson : > > On Tue, Apr 9, 2019, at 13:26, Kazuho Oku wrote: > > Correct me if I'm missing something, but my view is that retry (i.e. > > fallback to v1) is necessary. > > > > Not requiring retry means that a server cannot forget the randomized > > version number. As you state, a server can use a PRF to calculate the > > version number. But even in such case, a server needs to retain the > > static key being fed to the PRF. If the server loses the static key, > > clients would fail to reestablish connections. > > There is no obligation on the server to advertise a non-zero lifetime for= this. If a deployment doesn't want to maintain a static key (which might = be the same one that is used for stateless reset), then they don't have to. Yeah. My point is that any server-side deployment that tries to use the feature will be required to retain something it can never forget for the lifetime of the alias. Something being either a static key or the alias versions themselves. For mass-scale deployments, such a requirement might not be an issue. Losing state is disastrous for them. OTOH, for small-scale deployments (e.g., standalone servers), it is a concern, because people often assume that they can try run a server, scrap it, and then run another one, which has been the case for TCP and TLS. > > At the same time, I have a fear that trying to make this part of v1 > > might slow down the standardization process. Can't it be a v1 > > extension, considering the fact that the intent is to grease, and > > greasing works if only _some_ of the implementations support the > > feature? > > Yes, this works pretty well as an extension. It works less well as a NEW= _TOKEN addition, so there is some value to doing it now. That's a fair point. I agree that the version aliases should better be carried by the NEW_TOKEN frame (or within the token), though I think that they should have it's own lifetime (due to the concern of server losing state; not being able to use a token and not being able to recognize a version alias have different consequences). > > > Until v1 gets finalized, we will be effectively greasing the version > > number field by exchanging private (Chromium) and experimental version > > numbers (0xffffffxx). Assuming that we can create a stable WG I-D of a > > greasing proposal by the time v1 gets finalized, we will have the room > > to continue running multiple versions. > > I'd like to eliminate the private use range, which I think is consistent = with this design. After all, you only need to avoid collisions and the spa= ce is huge. > > (Note that it's possible to use alias to versions that have real semantic= s. You just have to ensure that the alias isn't active when you start talk= ing those versions properly. We should discuss the consequences of that fo= r middleboxes, but I tend to think that they turn out nicely in favour of t= he end to end model.) > --=20 Kazuho Oku From nobody Mon Apr 8 22:15:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D78912017D for ; Mon, 8 Apr 2019 22:15:08 -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 a84KiInISDP8 for ; Mon, 8 Apr 2019 22:15:07 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 C3D44120048 for ; Mon, 8 Apr 2019 22:15:06 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id j89so13278578ljb.1 for ; Mon, 08 Apr 2019 22:15:06 -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=wpnjCpWrxdsQUPp7Wjc/PKiUvpjeRuY+NBEmQMzzSB0=; b=r0Kq0UxLVAJn3NxypZe1TX/EAiTUo3vdQIj//pf1tIhtxtPvG1SDJDWrP6QnsQt8VI P0MeKFRKpBanLPByQghVzpHOGM9OmYBz71SlCGVTIKBBzNesxq9NZb7FvFhxeRKhjzN5 6JOFDNBAycsCr3pGA8QOcFwbSSf7UMy93NttN98svmIKlMndsH609Icv12QzmPLLtqWE KuqKhrpBYZPRRXSR7lM7AjTD2Sfyyu0HdrRqfeTz72exhocM5bwPHo3mgelm5/SLelWH LObPkJSpswhUcr7WiTYl/Z0tGuH5nI/BfKEIoAoqepPhJm5G0Myv2vMVpJJtyszt4JUy CKog== 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=wpnjCpWrxdsQUPp7Wjc/PKiUvpjeRuY+NBEmQMzzSB0=; b=dfyQE0NFMdFLE4AcTJzjSL84duRKR7sKLFx9UPwJzWyD+Bg1IA+IcwXvFc2ELN7jUB n9hqbNcUr8dCyC5r6LmQnC/FIcjhI59k0yjWxGbmIKDSlWZVKNsuiY2e98fZXgVyR0Dm mvK2JkeVJjJqnINCKvTmWpFi0jCbmo7xx/37ER0JEAVlJyDb4gfr6lvLLvZtmSUbpoHO rWghs2BDqzreOGI6Qh67vnpBZeqAJMfBbuKCwHkFFhsOpzJ7nZ2HtArT97BSCH+Iqx4C SYV0SP41I3mofQlysUdyz5fanihzO2ULt+LiIXYMAVJYf5pI3ep3f8vdDQYdvsJ0I+zr Bujw== X-Gm-Message-State: APjAAAXClj7MrZSvn6jsxudaBT52Vdr1GwOahIxVse5WgNAAlrsWXrQZ cQfrFipY3X4xI/0he5rLlg0le73LmxQI4YwyZb8= X-Google-Smtp-Source: APXvYqy/3+a33wGET1aijPVGridqDIFHO2nF2RXKZZiCBAVmp0YjjYBHwL+oaO5Wv49sKMxxTKkA7J3SdLaMjqDRfZw= X-Received: by 2002:a2e:9812:: with SMTP id a18mr15187789ljj.146.1554786905047; Mon, 08 Apr 2019 22:15:05 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> In-Reply-To: From: Jana Iyengar Date: Mon, 8 Apr 2019 22:14:54 -0700 Message-ID: Subject: Re: Version Negotiation Greasing To: Kazuho Oku Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000002d460b058612091f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 05:15:09 -0000 --0000000000002d460b058612091f Content-Type: text/plain; charset="UTF-8" > Yeah. My point is that any server-side deployment that tries to use > the feature will be required to retain something it can never forget > for the lifetime of the alias. Something being either a static key or > the alias versions themselves. > > For mass-scale deployments, such a requirement might not be an issue. > Losing state is disastrous for them. > > OTOH, for small-scale deployments (e.g., standalone servers), it is a > concern, because people often assume that they can try run a server, > scrap it, and then run another one, which has been the case for TCP > and TLS. > You're right that this is a new requirement/constraint, so we need to articulate the implications clearly. That said, on this particular point, a small deployment could just as easily choose to not advertise an alias if it cannot guarantee that it will be able to remember the alias. > > At the same time, I have a fear that trying to make this part of v1 > > > might slow down the standardization process. Can't it be a v1 > > > extension, considering the fact that the intent is to grease, and > > > greasing works if only _some_ of the implementations support the > > > feature? > > > > Yes, this works pretty well as an extension. It works less well as a > NEW_TOKEN addition, so there is some value to doing it now. > > That's a fair point. I agree that the version aliases should better be > carried by the NEW_TOKEN frame (or within the token), though I think > that they should have it's own lifetime (due to the concern of server > losing state; not being able to use a token and not being able to > recognize a version alias have different consequences). > Yes, the lifetime difference is why I suggested using a NEW_VERSION frame. That also aligns nicely with separating this as an extension. --0000000000002d460b058612091f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0
Yeah. My point is that any server-side = deployment that tries to use
the feature will be required to retain something it can never forget
for the lifetime of the alias. Something being either a static key or
the alias versions themselves.

For mass-scale deployments, such a requirement might not be an issue.
Losing state is disastrous for them.

OTOH, for small-scale deployments (e.g., standalone servers), it is a
concern, because people often assume that they can try run a server,
scrap it, and then run another one, which has been the case for TCP
and TLS.

You're right that this is = a new requirement/constraint, so we need to articulate the implications cle= arly. That said, on this particular point, a small deployment could just as= easily choose to not advertise an alias if it cannot guarantee that it wil= l be able to remember the alias.

> > At the same time, I have a fear that trying to make this part of = v1
> > might slow down the standardization process. Can't it be a v1=
> > extension, considering the fact that the intent is to grease, and=
> > greasing works if only _some_ of the implementations support the<= br> > > feature?
>
> Yes, this works pretty well as an extension.=C2=A0 It works less well = as a NEW_TOKEN addition, so there is some value to doing it now.

That's a fair point. I agree that the version aliases should better be<= br> carried by=C2=A0 the NEW_TOKEN frame (or within the token), though I think<= br> that they should have it's own lifetime (due to the concern of server losing state; not being able to use a token and not being able to
recognize a version alias have different consequences).

Yes, the lifetime difference is why I suggested using a NE= W_VERSION frame. That also aligns nicely with separating this as an extensi= on.
--0000000000002d460b058612091f-- From nobody Mon Apr 8 22:35:12 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D89120715 for ; Mon, 8 Apr 2019 22:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[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 jYTH-0sHebl3 for ; Mon, 8 Apr 2019 22:35:08 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 56E0112011D for ; Mon, 8 Apr 2019 22:35:08 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id h16so13245346ljg.11 for ; Mon, 08 Apr 2019 22:35:08 -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=nNpH+IkuHTQVlye1BpGIwzJ52l04Hy4IpLYleo/dY7w=; b=Q7L34lY3IPG0Ohk/vwjWTxYj+7E3YzIWFPue+x7ME3ag77MNDVQYro7exUV+BVzhA2 1A+ghBqF79p0w/mWBQDHRQOWAGyP/BwgdEZ4yeLN76ejQ/oaDRwVRVwo4WyrJGrhROaj +1K7eEcmw2rL1Jp5T5WyQesVC85mIUXN+Rm1zI30lfde7dOSF5zPb27HkZdlcHaOMFxY fKYlAJkpuY6g0utGm/dg05vIcNkaN5eF1bn2e9CTJpmDLBH7hIjjVprku8PyKqPnglEm +VGFLY6FOZK8+QJ+HWrPTe4WRLW7U0GPLRxKZhSgNNfvYXmBT/+3gHEY4NQiUVhP/vkq IfAw== 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=nNpH+IkuHTQVlye1BpGIwzJ52l04Hy4IpLYleo/dY7w=; b=pn3ZsznoVzzRB3eLz5new0uObzQitHoMLlNDk4/qNbnfmBRrGeNXmQdyr9aRbjPWU2 ERTFzoJoDcX5ZbqepndDXoGwpmRPjQkwSfWRST8ld0Sfes+knuqmVDeyAThdgpnDbZjn VaTtm4BgGkMw+HEsL5nr971V9o3ZTsTcUPVEJ8Bj29bTL7ynjJi/yIlOXr5cvd8HwZZd IdlWGdMIL1RpqduAK5c/n7cwullT4XDF+srDNOV4E4fNNdPQscI79Q5O50H47imA6ZDm eXRS7FEkJ1gLMaHRXeqrIferEFJkOEC876C98j40GvrfUtE/XsNVaBPg1RhlLitTIxa9 493Q== X-Gm-Message-State: APjAAAWnfzQ9Ee8NbNgVU0H68ABJR/p0LtdJUrVDceaatBG+lEwy+cLE TB63yUnDQrIRqy7ZkYk2Q2DNMNoN2p73eB8btak= X-Google-Smtp-Source: APXvYqypkPa92bz9gWVUTuyTIEEFWqm3jeM1LKRnkvLszHTU13lqoYlg3P1/Jlk3RIeQwvpkx36GrkIbl9ZmAibk+zk= X-Received: by 2002:a2e:2a03:: with SMTP id q3mr18119453ljq.56.1554788106493; Mon, 08 Apr 2019 22:35:06 -0700 (PDT) MIME-Version: 1.0 References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> <15A403C0-E559-469B-9AC0-A25B4B4EC492@mnot.net> In-Reply-To: <15A403C0-E559-469B-9AC0-A25B4B4EC492@mnot.net> From: Jana Iyengar Date: Mon, 8 Apr 2019 22:34:55 -0700 Message-ID: Subject: Re: Doodle poll for Spring 2019 QUIC Virtual Interop Day To: Mark Nottingham Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="000000000000c9e25905861250c4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 05:35:11 -0000 --000000000000c9e25905861250c4 Content-Type: text/plain; charset="UTF-8" Depending on where you are, it might not be Day either. On Mon, Apr 8, 2019 at 3:49 PM Mark Nottingham wrote: > +1. > > > On 9 Apr 2019, at 8:04 am, Martin Thomson wrote: > > > > Spring is a long way off and these are Autumn dates. > > > > On Mon, Apr 8, 2019, at 18:30, Lars Eggert wrote: > >> Please indicate your availability, if you have a stack you wish to > >> test: https://doodle.com/poll/ctxcirqtbnkaniqp > >> > >> (This will be a remote interop day. Next physical one will be with the > >> interim in London.) > >> > >> Lars > >> > >> Attachments: > >> * signature.asc > > > > -- > Mark Nottingham https://www.mnot.net/ > > --000000000000c9e25905861250c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Depending on where you are, it might not be Day either.
On = Mon, Apr 8, 2019 at 3:49 PM Mark Nottingham <mnot@mnot.net> wrote:
+1.

> On 9 Apr 2019, at 8:04 am, Martin Thomson <mt@lowentropy.net> wrote:
>
> Spring is a long way off and these are Autumn dates.
>
> On Mon, Apr 8, 2019, at 18:30, Lars Eggert wrote:
>> Please indicate your availability, if you have a stack you wish to=
>> test: https://doodle.com/poll/ctxcirqtbnkaniqp<= br> >>
>> (This will be a remote interop day. Next physical one will be with= the
>> interim in London.)
>>
>> Lars
>>
>> Attachments:
>> * signature.asc
>

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

--000000000000c9e25905861250c4-- From nobody Mon Apr 8 22:35:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13FD120740 for ; Mon, 8 Apr 2019 22:35:24 -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 fvB-MY-4BNf8 for ; Mon, 8 Apr 2019 22:35:22 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5456E120748 for ; Mon, 8 Apr 2019 22:35:22 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id x7so13182354ioh.4 for ; Mon, 08 Apr 2019 22:35:22 -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=LOqinhnpoHyp5CdG276957qG2WVqfgd+0kWjCLlLlv8=; b=kZrVVDOBMdG/DFDdjJmkaTpH/pI8L7aUmJNTjvyBPgyAJDMzUGYyYu+8zWe7fEpqMA l43Tfr/sSXKOgCSoufrYbbqV0Tq9BB8AVGK7o0180iv+TRcBhXnrucftBUzrKMYbLZzy kjhBPkl36S7sKADMZmh3Wx5o1KqlkFxcccGB4ZrcxXzYwYS1mcyg9Iz83ee/qWZqkoLV h4XrnzNu6tN42F+A8U2gH0hzTNCqdlrojf9FxFYRKCwBCvA9aHHURN2JyA+c8I47B0Pm LFOFDThAbiVfkhAlrKu4Ii7OqVAUE58gLHJNJEjALUQkUaxV8zyCnumnadOAnq4LFhbq YDSg== 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=LOqinhnpoHyp5CdG276957qG2WVqfgd+0kWjCLlLlv8=; b=TqR9NnaUi3JMJ8K8RtLwARG2hEesfG+w1pHq+jq009GJdAyCdTg/pOPo4S18wxvMc0 VXtPMgvocoMyJgwaOW5aM2AKiiVgOb8lKxdvdDqFJkpSZj3jamA+s8ldu8RK+m0jytG7 oU1ayeOR902mt4LGXlVo0qD/LwnLAlBYbPdzWRe0W5WsczDNoYzGZ8xyRat1MNCfogxk e9NLn1eZ/kIAtml621+zRagWOUmWEv8BZb4BiL/KNEsE7U6euKO/iSn5glFoDbaiSJE8 ejNI+PrcH47oJ/QhDqBEC6s7UwJ+c0k41QLgUIEFgnOc9vn8E7O7/6Q74Sp+1vcYUbEX A4OQ== X-Gm-Message-State: APjAAAWtxsEyPNN0bL3OUDZ9U2rYVMXce1ov4rwJSOitnp+BLB5TeZyu jneMjJ1ApX+xPUJZqGHb5uN+LnEBBIZ63Btb/wU= X-Google-Smtp-Source: APXvYqyywDwZ2KtgaANnJaQPjL+oKGsmL9kfy44NnArPfj2W1muf6G1JafAlls9XuqPjlvRuTyhkDFD2EwKfTYt8bo8= X-Received: by 2002:a6b:ca87:: with SMTP id a129mr22468293iog.187.1554788121571; Mon, 08 Apr 2019 22:35:21 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> In-Reply-To: From: Marten Seemann Date: Tue, 9 Apr 2019 14:35:10 +0900 Message-ID: Subject: Re: Version Negotiation Greasing To: Jana Iyengar Cc: Kazuho Oku , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000aff698058612512e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 05:35:31 -0000 --000000000000aff698058612512e Content-Type: text/plain; charset="UTF-8" The problem with making this an extension is how clients would advertise support for this extension. Ideally, we'd avoid sending a transport parameter in the ClientHello, otherwise middleboxes would be able inspect the ClientHello and block this extension. 1. If this alias versions are advertised in a transport parameter in the EncryptedExtensions, there wouldn't be any need to advertise support for this extension at all. Servers could just send the transport parameter, and clients would just skip over the unknown parameter if they don't support it. The downside of this approach is that the server is wasting bytes exactly when it's most constrained by congestion control and the amplification limit. 2. A frame has the advantage that it can be sent at any time. However, we'd need an encrypted signal from the client that it is able to parse the VERSION_ALIAS frame, so we'd probably have to define a signaling frame that has to be sent by the client first. In order to avoid this complexity I'd prefer to not make this an extension, but part of the v1 spec. On Tue, Apr 9, 2019 at 2:15 PM Jana Iyengar wrote: > > >> Yeah. My point is that any server-side deployment that tries to use >> the feature will be required to retain something it can never forget >> for the lifetime of the alias. Something being either a static key or >> the alias versions themselves. >> >> For mass-scale deployments, such a requirement might not be an issue. >> Losing state is disastrous for them. >> >> OTOH, for small-scale deployments (e.g., standalone servers), it is a >> concern, because people often assume that they can try run a server, >> scrap it, and then run another one, which has been the case for TCP >> and TLS. >> > > You're right that this is a new requirement/constraint, so we need to > articulate the implications clearly. That said, on this particular point, a > small deployment could just as easily choose to not advertise an alias if > it cannot guarantee that it will be able to remember the alias. > > > > At the same time, I have a fear that trying to make this part of v1 >> > > might slow down the standardization process. Can't it be a v1 >> > > extension, considering the fact that the intent is to grease, and >> > > greasing works if only _some_ of the implementations support the >> > > feature? >> > >> > Yes, this works pretty well as an extension. It works less well as a >> NEW_TOKEN addition, so there is some value to doing it now. >> >> That's a fair point. I agree that the version aliases should better be >> carried by the NEW_TOKEN frame (or within the token), though I think >> that they should have it's own lifetime (due to the concern of server >> losing state; not being able to use a token and not being able to >> recognize a version alias have different consequences). >> > > Yes, the lifetime difference is why I suggested using a NEW_VERSION frame. > That also aligns nicely with separating this as an extension. > --000000000000aff698058612512e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The problem with making this an extension is how clients w= ould advertise support for this extension.
Ideally, we'd avoid send= ing a transport parameter in the ClientHello, otherwise middleboxes would b= e able inspect the ClientHello and block this extension.
  1. If this alias versions are advertised in a transport = parameter in the EncryptedExtensions, there wouldn't be any need to adv= ertise support for this extension at all. Servers could just send the trans= port parameter, and clients would just skip over the unknown parameter if t= hey don't support it. The downside of this approach is that the server = is wasting bytes exactly when it's most constrained by congestion contr= ol and the amplification limit.
  2. A frame = has the advantage that it can be sent at any time. However, we'd need a= n encrypted signal from the client that it is able to parse the VERSION_ALI= AS frame, so we'd probably have to define a signaling frame that has to= be sent by the client first.
In order to avoid this complexi= ty I'd prefer to not make this an extension, but part of the v1 spec.

On Tue, Apr 9, 2019 at 2:15 PM Jana Iyengar <jri.ietf@gmail.com> wrote:
=C2=A0
Yeah. My point is that any server-side deployment that tries to use the feature will be required to retain something it can never forget
for the lifetime of the alias. Something being either a static key or
the alias versions themselves.

For mass-scale deployments, such a requirement might not be an issue.
Losing state is disastrous for them.

OTOH, for small-scale deployments (e.g., standalone servers), it is a
concern, because people often assume that they can try run a server,
scrap it, and then run another one, which has been the case for TCP
and TLS.

You're right that this is = a new requirement/constraint, so we need to articulate the implications cle= arly. That said, on this particular point, a small deployment could just as= easily choose to not advertise an alias if it cannot guarantee that it wil= l be able to remember the alias.

> > At the same time, I have a fear that trying to make this part of = v1
> > might slow down the standardization process. Can't it be a v1=
> > extension, considering the fact that the intent is to grease, and=
> > greasing works if only _some_ of the implementations support the<= br> > > feature?
>
> Yes, this works pretty well as an extension.=C2=A0 It works less well = as a NEW_TOKEN addition, so there is some value to doing it now.

That's a fair point. I agree that the version aliases should better be<= br> carried by=C2=A0 the NEW_TOKEN frame (or within the token), though I think<= br> that they should have it's own lifetime (due to the concern of server losing state; not being able to use a token and not being able to
recognize a version alias have different consequences).

Yes, the lifetime difference is why I suggested using a NE= W_VERSION frame. That also aligns nicely with separating this as an extensi= on.
--000000000000aff698058612512e-- From nobody Mon Apr 8 22:50:55 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA1312071D for ; Mon, 8 Apr 2019 22:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3ioRUrrj9IY for ; Mon, 8 Apr 2019 22:50:53 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BA6120733 for ; Mon, 8 Apr 2019 22:50:52 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 3F86630062; Tue, 9 Apr 2019 08:50:49 +0300 (EEST) Received: from slate.eggert.org (pf.eggert.org [172.16.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 8700D881F08; Tue, 9 Apr 2019 08:49:52 +0300 (EEST) From: Lars Eggert Message-Id: <41ADF962-1ED0-429F-8414-8E86023DA280@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_05243719-736D-449E-BFC8-EDB9C08AD850"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Doodle poll for First-Quarter 2019 QUIC Virtual Interop Event (was: Re: Doodle poll for Spring 2019 QUIC Virtual Interop Day) Date: Tue, 9 Apr 2019 08:49:33 +0300 In-Reply-To: Cc: quic@ietf.org To: Martin Thomson References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> X-MailScanner-ID: 8700D881F08.A3EBD X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 05:50:55 -0000 --Apple-Mail=_05243719-736D-449E-BFC8-EDB9C08AD850 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii All good now? :-) Lars --Apple-Mail=_05243719-736D-449E-BFC8-EDB9C08AD850 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAlysMm0ACgkQHbmKvSnu NPhuuQ//QBFu/kEc2x5TWYpDIOyZwdM4vLQM41E+paB1Uw9HEKWPg2MOHNg3SgUQ aEFFHOZOa/Y7fGFmoWD6QPmHRZ53BI7pI8Hd+GJe9PrcuPUXQiJ9b3KDgC7/l0yE 7GKhY6n/hb/KaD9XP8F3lsbMNQHQXuQ7Axwj2wfZfgpUrDCexDlpIlnejT+D2QsS x03ttLUM7tUQQTGGvFS657mCKvSmaDgOu3tAEm5lipGN9p2O9eHSME6gN3qQcx7E zvAJeWFZZS16p+uod8gQWahmSixitjwgGX9GCgROAwOTGy2acFXU0mmHxAhipJPY JByuBFnAx0SYmXdMrkhz27z5N5FJ4CRp/ixPdvX7HWqMxVkTpoqImh3iiyVM0DnL 9mg9lft/8lRJFXunFtu4giu4BGCEGFXRdkkemGrfOAyImvi8+9gVjRcmYPJ4dN+S NTY/qq16Eop995HXYS11f5PVe6AXXRt7BbZamrxSFNi4raUzI51pfWoQAzc2z+2c zdjo+tseE42c3F7ps1jxgRi9FouwUKQi0Ecj9KGV/SC1TMTRmWYdtRd/nBasCWQf u3jj9ZYPMcpf9uVItXTdHbKiKoXrHtyPNmSRUZNPYdRdfd3nnWm901exlxc2zOe+ glQEG03Uroo/gUMZB1cDePSj2Twt5RlnoVkLX0TrJQa5crgDiAE= =3aGe -----END PGP SIGNATURE----- --Apple-Mail=_05243719-736D-449E-BFC8-EDB9C08AD850-- From nobody Mon Apr 8 22:52:00 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4DB120735 for ; Mon, 8 Apr 2019 22:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJCRVfBwvDIP for ; Mon, 8 Apr 2019 22:51:57 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id CCE07120733 for ; Mon, 8 Apr 2019 22:51:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 99A546601F5; Tue, 9 Apr 2019 08:51:55 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXqQy18Z-A3U; Tue, 9 Apr 2019 08:51:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 5D95366016C; Tue, 9 Apr 2019 08:51:54 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Doodle poll for Spring 2019 QUIC Virtual Interop Day From: Jari Arkko In-Reply-To: Date: Tue, 9 Apr 2019 08:51:54 +0300 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <7B4CA352-F9C9-4A5F-9A29-1D6FE938EDCD@piuha.net> References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> <15A403C0-E559-469B-9AC0-A25B4B4EC492@mnot.net> To: Jana Iyengar , Mark Nottingham , Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 05:51:59 -0000 Heh. I prefer hacking during the night and the winter season. = Fortunately time of day and season (or at least temperature as a proxy = thereof) can be adjusted by changing latitude and longitude :-)=20 What time btw would an interop day typically run? I blocked two days = because I knew I would have an European afternoon/evening event. Jari From nobody Mon Apr 8 22:55:54 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA46120739 for ; Mon, 8 Apr 2019 22:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSehpKXuj8Nc for ; Mon, 8 Apr 2019 22:55:50 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590F31200F4 for ; Mon, 8 Apr 2019 22:55:50 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id a190so3002481ite.4 for ; Mon, 08 Apr 2019 22:55:50 -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=uAqCAZxN8Eagt39XMhrADiCoQGgdfqb2+fHdt6akHbc=; b=AFiJBAcqYACcWoA9/DqUnYivvx7XP3o5AQBqnXQmtGxL3wWRj/Gkd0qghx6+lCg8Uo XUn8vc7Ut/s7o4Tj2WypeN8lTjAGjx5R0mCj9Ght4P+Fbnm6WksjBXpuGJUcjf3LERLw S2fv5b+SBrkp3w4G2xaSs2/09ydWcgzNK20gDdYpnjkXQlXppm8I5bgyjgeASU/Ex4CQ +oWquc89EWOksCrjL7f6KNyVQBO63FFlTNh3Zcj4WV+Uq5htgTPyel5KnG8r6oIYZ+ry j59oT2ozc9TOvWXAgDNvkHIH4jov9KsyBjpJ1+5z+21ZFUdF4BeD093JSfd7MOtmWpj3 g9yQ== 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=uAqCAZxN8Eagt39XMhrADiCoQGgdfqb2+fHdt6akHbc=; b=kDI3pjDSJ+cQSFvZwxFVkJtW7HsZt1CaG5gGc55H87gSTKbotcDwcx0C8YRdU/dcM0 8gsr9A9YNi/UKZd9egOS1fblpVCgyWJPiqX0NX2D8A9tahC1UL4SUkr1gses1pTCu1uj TBgfPnC6xOyEI/2UEOp0biwo5d0CVwP1kfsRfKWqrrwH2j3tRowAmOTZN4PoX3CQJH2K 2J6s0N5Ljt2Ji0bWCGrp0+wi5rDz5n+U/PrSLGiGYaf1+NbALTYTCguGo5o1rcHgGpY9 xmE37ASx/ZaXzXdSkm7E2s0fuY6HuAiofggpZijErxsC7LPN1dulzymgHpPU5yVKM2Ky 5cmA== X-Gm-Message-State: APjAAAWOk46I8eSYS7PkhGN3wFXoaISIzaC05e/uzlCQmrr8OAPywy2m MydYsBZQdkk2LKJItGh2I9jBhX3xq2QlUd9M+/OdyQ== X-Google-Smtp-Source: APXvYqy2DgsrI2PM0tGcG4369GsEllD2XeOizXFKE8SCDxS+pvAm/1Hx5P1lWtTeUAgE/U+RNggmLvGpScvCIDiXCf4= X-Received: by 2002:a24:4d:: with SMTP id 74mr25045562ita.6.1554789349705; Mon, 08 Apr 2019 22:55:49 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Apr 2019 01:55:48 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <41ADF962-1ED0-429F-8414-8E86023DA280@eggert.org> References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> <41ADF962-1ED0-429F-8414-8E86023DA280@eggert.org> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 9 Apr 2019 01:55:48 -0400 Message-ID: Subject: Re: Doodle poll for First-Quarter 2019 QUIC Virtual Interop Event (was: Re: Doodle poll for Spring 2019 QUIC Virtual Interop Day) To: Lars Eggert , Martin Thomson Cc: quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000e3ce360586129aa5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 05:55:52 -0000 --000000000000e3ce360586129aa5 Content-Type: text/plain; charset="UTF-8" Second-Quarter 2019 perhaps? At least for earthlings. Mikkel On 9 April 2019 at 07.51.04, Lars Eggert (lars@eggert.org) wrote: All good now? :-) Lars --000000000000e3ce360586129aa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Second-Quarter 2019 = perhaps? At least for earthlings.

Mikkel


On 9 April 2019 at 07.51.04, Lars Eggert (<= a href=3D"mailto:lars@eggert.org">lars@eggert.org) wrote:

All good now= ? :-)

Lars
--000000000000e3ce360586129aa5-- From nobody Mon Apr 8 22:56:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6118120739 for ; Mon, 8 Apr 2019 22:56: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, 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 0YolHN-uFIPR for ; Mon, 8 Apr 2019 22:56:30 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6939120744 for ; Mon, 8 Apr 2019 22:56:29 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id o199so4206392lfo.1 for ; Mon, 08 Apr 2019 22:56:29 -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=frSqk/grzMM7Juf73RFwXScn8bI51QWOpC8pNUk4I2w=; b=oJiN/N60J7ZgdOSPkDkgjO0bSPSKjswkPpTs5yMmYAcNfC6xXHln/qnL3evBBDJNgG qHW9CoYi9wVoGJOUZUIthTDYrlUcFTHX9gG0zRY4tnRHQepqFYjgLfNzomXrZQ/ygqI9 xeJ00ySxKmbBV9JtAbzb+PDUFwsv83KltUZXI3AI/wQ1eJvfeOrSVbq6Np59BpeGOd/P XayOBy3onfeesii3pkojlTDyWSkRCytmNzdf77BtJzVSQhRQsqyNB7PyD0CgN0mNYrik QZ8chjkPjyZJIFb0Zi3MYTS52W4K2pP1dioNX3hR9YsV8r7ve5zf0LL2wP/N8JgQ9IwN cbIg== 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=frSqk/grzMM7Juf73RFwXScn8bI51QWOpC8pNUk4I2w=; b=nOFeorh4TjpKNQiPBfB8t78TzShwJJbuQyrZdbIHVE+aUzVCMOhUYMc4XppCHEnxeA OfSL4ncgQppZRJ672p8+LbqGoSNsrQ9Vpoj+44LuHDOlNj2rb7C2Zkxsni0Js7CKXeb0 vxzC1Qy8M6sRYkYGxj76QKQqBj4SBk/vbFlmXBFiOG1sHfFvQAaqXSkKISeB9q7ZaZHH Tzb66cFjBzyB9ZpIElagA1n0YonsosqDH8UOv/eqM8qbCS3jyekhGcxjYnKMIR9LxQNz AawHz8gy1LvbMhLEHQl7Swd9FS3YRHiDrmRWRhjWZrgJZk3wTd+S31wnV5oHcwBc9jT8 82ow== X-Gm-Message-State: APjAAAVRQULxPs+Eh1EWvsP+345r2U3VJjIlo/MhqRYGFR0SgUUtheYq m+8UbK5w3XoiGJCF2DRN2IkA8jBQp5j+Z3XUqk4= X-Google-Smtp-Source: APXvYqyQ5nyUg462VNe253KIbmiN3DPFn1ppIc802aLkkj/yKYvVSAuJnvM0zbHLFn+oZRuJkmnFhD557yRFUuwonIU= X-Received: by 2002:a19:7914:: with SMTP id u20mr17457018lfc.41.1554789388008; Mon, 08 Apr 2019 22:56:28 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> In-Reply-To: From: Kazuho Oku Date: Tue, 9 Apr 2019 14:56:16 +0900 Message-ID: Subject: Re: Version Negotiation Greasing To: Marten Seemann Cc: Jana Iyengar , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 05:56:34 -0000 2019=E5=B9=B44=E6=9C=889=E6=97=A5(=E7=81=AB) 14:35 Marten Seemann : > > The problem with making this an extension is how clients would advertise = support for this extension. > Ideally, we'd avoid sending a transport parameter in the ClientHello, oth= erwise middleboxes would be able inspect the ClientHello and block this ext= ension. I'm not sure if I agree with the framing. If the threat model is middleboxes dropping Initial packets based on the payload, the proposed approach is insufficient because it does not hide the content of Initial packets. A middlebox can just trial-decrypt the Initial packets using the v1 keys, then drop packets that do not look like v1. To rephrase, the proposal does not give us the freedom to circumvent through middleboxes that check the payload, even though it prevents middleboxes ossifying the version number field. Assuming that we agree that the only intent is to prevent ossification, advertising the capability using ClientHello TP seems fine to me. PS. Yes, I am suggesting that we might want to consider using a different encryption key for Initial packets, _if_ we agree that retry (i.e. fallback to v1) is unnecessary. > If this alias versions are advertised in a transport parameter in the Enc= ryptedExtensions, there wouldn't be any need to advertise support for this = extension at all. Servers could just send the transport parameter, and clie= nts would just skip over the unknown parameter if they don't support it. Th= e downside of this approach is that the server is wasting bytes exactly whe= n it's most constrained by congestion control and the amplification limit. > A frame has the advantage that it can be sent at any time. However, we'd = need an encrypted signal from the client that it is able to parse the VERSI= ON_ALIAS frame, so we'd probably have to define a signaling frame that has = to be sent by the client first. > > In order to avoid this complexity I'd prefer to not make this an extensio= n, but part of the v1 spec. > > On Tue, Apr 9, 2019 at 2:15 PM Jana Iyengar wrote: >> >> >>> >>> Yeah. My point is that any server-side deployment that tries to use >>> the feature will be required to retain something it can never forget >>> for the lifetime of the alias. Something being either a static key or >>> the alias versions themselves. >>> >>> For mass-scale deployments, such a requirement might not be an issue. >>> Losing state is disastrous for them. >>> >>> OTOH, for small-scale deployments (e.g., standalone servers), it is a >>> concern, because people often assume that they can try run a server, >>> scrap it, and then run another one, which has been the case for TCP >>> and TLS. >> >> >> You're right that this is a new requirement/constraint, so we need to ar= ticulate the implications clearly. That said, on this particular point, a s= mall deployment could just as easily choose to not advertise an alias if it= cannot guarantee that it will be able to remember the alias. >> >>> > > At the same time, I have a fear that trying to make this part of v1 >>> > > might slow down the standardization process. Can't it be a v1 >>> > > extension, considering the fact that the intent is to grease, and >>> > > greasing works if only _some_ of the implementations support the >>> > > feature? >>> > >>> > Yes, this works pretty well as an extension. It works less well as a= NEW_TOKEN addition, so there is some value to doing it now. >>> >>> That's a fair point. I agree that the version aliases should better be >>> carried by the NEW_TOKEN frame (or within the token), though I think >>> that they should have it's own lifetime (due to the concern of server >>> losing state; not being able to use a token and not being able to >>> recognize a version alias have different consequences). >> >> >> Yes, the lifetime difference is why I suggested using a NEW_VERSION fram= e. That also aligns nicely with separating this as an extension. -- Kazuho Oku From nobody Mon Apr 8 23:13:27 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78822120758 for ; Mon, 8 Apr 2019 23:08: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=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 wvjVBuLMeFtk for ; Mon, 8 Apr 2019 23:08:06 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::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 D454C120750 for ; Mon, 8 Apr 2019 23:08:05 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id f23so13387683ljc.0 for ; Mon, 08 Apr 2019 23:08: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:content-transfer-encoding; bh=QGS3Vp2hz0QvU4pRM8pq0LahTXypg3IOK0nxE5+lKYs=; b=nNzBXuYHnESk/PFiHGXSy3zQ9JJZ67RtcDFndF8Yw2Yk5il5wps55cRA1wuWzJgLRW daWLnxvghCWZm0YnXRUMLEbjMJKVQ/h6Cu1syvhqWEoKVRYq4/ulhB1Zs/V8KhDS9Y41 oZPnugyaxKaeaoac8bdP2d4+FggiZJaD59gXsspg6ez+aUrldroIk3glmkPYvTb+W4ql a+rfEj0xby876iKWy5MM3HQPFcv7cuYrFHJvwwSzuCtSLHB0LRJ7vS8RRN7CjdRQHkyI BlFwXaJJ/aZSM1AUxHyJJr7uDYkYBUbZ752hSM5NtCFAYbM+7EYVuXWxyP1u1ObGtMPc /rPw== 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=QGS3Vp2hz0QvU4pRM8pq0LahTXypg3IOK0nxE5+lKYs=; b=SGMbVfGlbb9CDKr0sJBlPdIPAKsGk7BJr2oKE9zPaL2YsCWC10OQyL/HAx6IIoroFF IW+Hh2Bu+R16CeBrQwAB4ROeSrry3KRmOJtSiMdqedeDYOGn4s33q686CBSPUOdHFcjq uQvF1ubSIUB0pTjXA9q9OQUg7JZgm5UKJTN27/HQMppsm4ZbCF8opd8sFzV9y0zXt07+ tyxUGVUlBHDQMRmWKoRMg8Nd48fZwecbZwuDubkqo+ykxfqsDSsNuoM97jGCkj2LJPk9 l3ad77fI/xniphjbTbPbcM1kk5ftRAcXKWm6gNTqGHQN5q41NqDfUyqCgDartmjZ5957 2M8w== X-Gm-Message-State: APjAAAV6P35opMAHu4Ul+Qfmq1H/V+x/7D9aPYtbLITnCEM9h3scDquB sT9uvqwurdoxPCtT4SmMvZ0M+fb4WcanRoOorT4= X-Google-Smtp-Source: APXvYqxSNem+BEkhQrNSnPzJ0c0CJhciCCWCLwtaW+6vNpR8887GLWxcRnJvTvA/FOboZYFSCc99ZV5RLTX28ZVokFo= X-Received: by 2002:a2e:88c5:: with SMTP id a5mr1329697ljk.5.1554790084007; Mon, 08 Apr 2019 23:08:04 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> In-Reply-To: From: Kazuho Oku Date: Tue, 9 Apr 2019 15:07:52 +0900 Message-ID: Subject: Re: Version Negotiation Greasing To: Marten Seemann Cc: Jana Iyengar , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 06:08:08 -0000 2019=E5=B9=B44=E6=9C=889=E6=97=A5(=E7=81=AB) 14:56 Kazuho Oku : > > 2019=E5=B9=B44=E6=9C=889=E6=97=A5(=E7=81=AB) 14:35 Marten Seemann : > > > > The problem with making this an extension is how clients would advertis= e support for this extension. > > Ideally, we'd avoid sending a transport parameter in the ClientHello, o= therwise middleboxes would be able inspect the ClientHello and block this e= xtension. > > I'm not sure if I agree with the framing. > > If the threat model is middleboxes dropping Initial packets based on > the payload, the proposed approach is insufficient because it does not > hide the content of Initial packets. A middlebox can just > trial-decrypt the Initial packets using the v1 keys, then drop packets > that do not look like v1. > > To rephrase, the proposal does not give us the freedom to circumvent > through middleboxes that check the payload, even though it prevents > middleboxes ossifying the version number field. Assuming that we agree > that the only intent is to prevent ossification, advertising the > capability using ClientHello TP seems fine to me. > > PS. Yes, I am suggesting that we might want to consider using a > different encryption key for Initial packets, _if_ we agree that retry > (i.e. fallback to v1) is unnecessary. My bad, I missed the fact that the PR already carries a salt. And I think I might agree that we might want to have the feature defined in v1. It's basically a non-issue for endpoints that are not participating in the effort (i.e. clients ignore, servers do not send). I am still concerned about the possibility of the feature delaying the standardization process, but we can land the proposal after we start seeing the draft versions of QUIC being used in the wild. > > > > > > If this alias versions are advertised in a transport parameter in the E= ncryptedExtensions, there wouldn't be any need to advertise support for thi= s extension at all. Servers could just send the transport parameter, and cl= ients would just skip over the unknown parameter if they don't support it. = The downside of this approach is that the server is wasting bytes exactly w= hen it's most constrained by congestion control and the amplification limit= . > > A frame has the advantage that it can be sent at any time. However, we'= d need an encrypted signal from the client that it is able to parse the VER= SION_ALIAS frame, so we'd probably have to define a signaling frame that ha= s to be sent by the client first. > > > > In order to avoid this complexity I'd prefer to not make this an extens= ion, but part of the v1 spec. > > > > On Tue, Apr 9, 2019 at 2:15 PM Jana Iyengar wrote: > >> > >> > >>> > >>> Yeah. My point is that any server-side deployment that tries to use > >>> the feature will be required to retain something it can never forget > >>> for the lifetime of the alias. Something being either a static key or > >>> the alias versions themselves. > >>> > >>> For mass-scale deployments, such a requirement might not be an issue. > >>> Losing state is disastrous for them. > >>> > >>> OTOH, for small-scale deployments (e.g., standalone servers), it is a > >>> concern, because people often assume that they can try run a server, > >>> scrap it, and then run another one, which has been the case for TCP > >>> and TLS. > >> > >> > >> You're right that this is a new requirement/constraint, so we need to = articulate the implications clearly. That said, on this particular point, a= small deployment could just as easily choose to not advertise an alias if = it cannot guarantee that it will be able to remember the alias. > >> > >>> > > At the same time, I have a fear that trying to make this part of = v1 > >>> > > might slow down the standardization process. Can't it be a v1 > >>> > > extension, considering the fact that the intent is to grease, and > >>> > > greasing works if only _some_ of the implementations support the > >>> > > feature? > >>> > > >>> > Yes, this works pretty well as an extension. It works less well as= a NEW_TOKEN addition, so there is some value to doing it now. > >>> > >>> That's a fair point. I agree that the version aliases should better b= e > >>> carried by the NEW_TOKEN frame (or within the token), though I think > >>> that they should have it's own lifetime (due to the concern of server > >>> losing state; not being able to use a token and not being able to > >>> recognize a version alias have different consequences). > >> > >> > >> Yes, the lifetime difference is why I suggested using a NEW_VERSION fr= ame. That also aligns nicely with separating this as an extension. > > > > -- > Kazuho Oku --=20 Kazuho Oku From nobody Tue Apr 9 12:09:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1B8120196 for ; Tue, 9 Apr 2019 12:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 zV2tqWxQ7sBU for ; Tue, 9 Apr 2019 12:09:35 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0EF21200B4 for ; Tue, 9 Apr 2019 12:09:34 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id j11so949461lfm.0 for ; Tue, 09 Apr 2019 12:09:34 -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=JnTrs7GkMJ79A7tUPx/BuPke64bKZ1V5nu/BprNMgrQ=; b=SmGbeg9WCMqGiX85KcJSIT5Kj5MBxf+uhU0Ud4wfEGCpbIkll1X7QMiWXzLMRj/WSW AhJMLEqIe6k6m3uLUtrA3O8mOcsjg8hBe4Ljr3F8Jj5IqO8CqGVNpLkxX8noDTS2LnZZ 4TtjIe0HNaj8REWPnaQ8kxwNLRFPFt9JBa2CPdL//oZ7Q80D3mo0OCYhDtiRPtyQKPM6 SsQeDRl9AtJqTCrH+m0dGn0kD2gO7Tc8bnBwB3qIOPv22Xv+IhUisxHrFspapys3+YWb 04dvJM0P8g3BFFeKKekaKoFFa5e7rNuaVksMPN52PmSveVV7+2EVqR9qJnMfH/L+JIiG 9kCw== 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=JnTrs7GkMJ79A7tUPx/BuPke64bKZ1V5nu/BprNMgrQ=; b=W+e7T9FV48Sh8QwHruo6O72tORYi7teYC1jDraVZYkPWoGUF2+MlbmQzz/9bOLmwMq vxe8DShd/Xv/UT9sUzq5HVP5RD4nXdfGFQdWZrS9wWwy3MueAIakEaZLzGVmjbg/CB30 SMH7v7QdjtYl3FK7WlSqBtlejH1M0WbAZ7dk5wfRv3ELKFD0AcwPdyQRT/aeGweJ4eQQ jAqPQsWFT/4CSsZ257LJLx1NnVHtmcNXZuaEJlNQ/Ii947T53QNOTfdjpjEnBXLHfUDi mZ6irTbQ/WBZN3efiO5YCyo2AmLtYi9r0KvVKmV2CqMi5l9ReUl0SEigS6kxoh9IDYO+ WF/w== X-Gm-Message-State: APjAAAWI5gZXb2Z2SyGSiHY+oNUoG/iHxkLIIR5VA9x9w6juF9ldyq9T L2dxsdAMLhifTac+Usc0W94PGJJe9zUFDOY/m3Q= X-Google-Smtp-Source: APXvYqw1N1PT3KSSOigQatFzEr4cqVOXHnMsvyMLYrx/NFiCxl61v4rZ/NqwOEGBae7YzBzk59LjVybNvRCrPpGKqpU= X-Received: by 2002:a19:7007:: with SMTP id h7mr3548792lfc.23.1554836973072; Tue, 09 Apr 2019 12:09:33 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> In-Reply-To: From: Jana Iyengar Date: Tue, 9 Apr 2019 12:09:22 -0700 Message-ID: Subject: Re: Version Negotiation Greasing To: Kazuho Oku Cc: Marten Seemann , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="00000000000076b7f905861db11b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 19:09:38 -0000 --00000000000076b7f905861db11b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hm, perhaps I'm missing something. As an extension, the server would simply advertise the alias in a transport parameter. A client that understands this transport parameter could use it, others would not. Why does the server need to know that the client understands and will use the new alias? There need not be a requirement on a client to do it. On Mon, Apr 8, 2019 at 11:08 PM Kazuho Oku wrote: > 2019=E5=B9=B44=E6=9C=889=E6=97=A5(=E7=81=AB) 14:56 Kazuho Oku : > > > > 2019=E5=B9=B44=E6=9C=889=E6=97=A5(=E7=81=AB) 14:35 Marten Seemann : > > > > > > The problem with making this an extension is how clients would > advertise support for this extension. > > > Ideally, we'd avoid sending a transport parameter in the ClientHello, > otherwise middleboxes would be able inspect the ClientHello and block thi= s > extension. > > > > I'm not sure if I agree with the framing. > > > > If the threat model is middleboxes dropping Initial packets based on > > the payload, the proposed approach is insufficient because it does not > > hide the content of Initial packets. A middlebox can just > > trial-decrypt the Initial packets using the v1 keys, then drop packets > > that do not look like v1. > > > > To rephrase, the proposal does not give us the freedom to circumvent > > through middleboxes that check the payload, even though it prevents > > middleboxes ossifying the version number field. Assuming that we agree > > that the only intent is to prevent ossification, advertising the > > capability using ClientHello TP seems fine to me. > > > > PS. Yes, I am suggesting that we might want to consider using a > > different encryption key for Initial packets, _if_ we agree that retry > > (i.e. fallback to v1) is unnecessary. > > My bad, I missed the fact that the PR already carries a salt. > > And I think I might agree that we might want to have the feature > defined in v1. It's basically a non-issue for endpoints that are not > participating in the effort (i.e. clients ignore, servers do not > send). > > I am still concerned about the possibility of the feature delaying the > standardization process, but we can land the proposal after we start > seeing the draft versions of QUIC being used in the wild. > > > > > > > > > > > > If this alias versions are advertised in a transport parameter in the > EncryptedExtensions, there wouldn't be any need to advertise support for > this extension at all. Servers could just send the transport parameter, a= nd > clients would just skip over the unknown parameter if they don't support > it. The downside of this approach is that the server is wasting bytes > exactly when it's most constrained by congestion control and the > amplification limit. > > > A frame has the advantage that it can be sent at any time. However, > we'd need an encrypted signal from the client that it is able to parse th= e > VERSION_ALIAS frame, so we'd probably have to define a signaling frame th= at > has to be sent by the client first. > > > > > > In order to avoid this complexity I'd prefer to not make this an > extension, but part of the v1 spec. > > > > > > On Tue, Apr 9, 2019 at 2:15 PM Jana Iyengar > wrote: > > >> > > >> > > >>> > > >>> Yeah. My point is that any server-side deployment that tries to use > > >>> the feature will be required to retain something it can never forge= t > > >>> for the lifetime of the alias. Something being either a static key = or > > >>> the alias versions themselves. > > >>> > > >>> For mass-scale deployments, such a requirement might not be an issu= e. > > >>> Losing state is disastrous for them. > > >>> > > >>> OTOH, for small-scale deployments (e.g., standalone servers), it is= a > > >>> concern, because people often assume that they can try run a server= , > > >>> scrap it, and then run another one, which has been the case for TCP > > >>> and TLS. > > >> > > >> > > >> You're right that this is a new requirement/constraint, so we need t= o > articulate the implications clearly. That said, on this particular point,= a > small deployment could just as easily choose to not advertise an alias if > it cannot guarantee that it will be able to remember the alias. > > >> > > >>> > > At the same time, I have a fear that trying to make this part o= f > v1 > > >>> > > might slow down the standardization process. Can't it be a v1 > > >>> > > extension, considering the fact that the intent is to grease, a= nd > > >>> > > greasing works if only _some_ of the implementations support th= e > > >>> > > feature? > > >>> > > > >>> > Yes, this works pretty well as an extension. It works less well > as a NEW_TOKEN addition, so there is some value to doing it now. > > >>> > > >>> That's a fair point. I agree that the version aliases should better > be > > >>> carried by the NEW_TOKEN frame (or within the token), though I thi= nk > > >>> that they should have it's own lifetime (due to the concern of serv= er > > >>> losing state; not being able to use a token and not being able to > > >>> recognize a version alias have different consequences). > > >> > > >> > > >> Yes, the lifetime difference is why I suggested using a NEW_VERSION > frame. That also aligns nicely with separating this as an extension. > > > > > > > > -- > > Kazuho Oku > > > > -- > Kazuho Oku > --00000000000076b7f905861db11b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hm, perhaps I'm missing something. As an extension, th= e server would simply advertise the alias in a transport parameter. A clien= t that understands this transport parameter could use it, others would not.= Why does the server need to know that the client understands and will use = the new alias? There need not be a requirement on a client to do it.

On Mon, Apr 8, 2019 at 11:08 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
2019=E5=B9=B44=E6=9C=889=E6=97=A5(=E7= =81=AB) 14:56 Kazuho Oku <kazuhooku@gmail.com>:
>
> 2019=E5=B9=B44=E6=9C=889=E6=97=A5(=E7=81=AB) 14:35 Marten Seemann <= martenseemann@= gmail.com>:
> >
> > The problem with making this an extension is how clients would ad= vertise support for this extension.
> > Ideally, we'd avoid sending a transport parameter in the Clie= ntHello, otherwise middleboxes would be able inspect the ClientHello and bl= ock this extension.
>
> I'm not sure if I agree with the framing.
>
> If the threat model is middleboxes dropping Initial packets based on > the payload, the proposed approach is insufficient because it does not=
> hide the content of Initial packets. A middlebox can just
> trial-decrypt the Initial packets using the v1 keys, then drop packets=
> that do not look like v1.
>
> To rephrase, the proposal does not give us the freedom to circumvent > through middleboxes that check the payload, even though it prevents > middleboxes ossifying the version number field. Assuming that we agree=
> that the only intent is to prevent ossification, advertising the
> capability using ClientHello TP seems fine to me.
>
> PS. Yes, I am suggesting that we might want to consider using a
> different encryption key for Initial packets, _if_ we agree that retry=
> (i.e. fallback to v1) is unnecessary.

My bad, I missed the fact that the PR already carries a salt.

And I think I might agree that we might want to have the feature
defined in v1. It's basically a non-issue for endpoints that are not participating in the effort (i.e. clients ignore, servers do not
send).

I am still concerned about the possibility of the feature delaying the
standardization process, but we can land the proposal after we start
seeing the draft versions of QUIC being used in the wild.

>
>
>
>
> > If this alias versions are advertised in a transport parameter in= the EncryptedExtensions, there wouldn't be any need to advertise suppo= rt for this extension at all. Servers could just send the transport paramet= er, and clients would just skip over the unknown parameter if they don'= t support it. The downside of this approach is that the server is wasting b= ytes exactly when it's most constrained by congestion control and the a= mplification limit.
> > A frame has the advantage that it can be sent at any time. Howeve= r, we'd need an encrypted signal from the client that it is able to par= se the VERSION_ALIAS frame, so we'd probably have to define a signaling= frame that has to be sent by the client first.
> >
> > In order to avoid this complexity I'd prefer to not make this= an extension, but part of the v1 spec.
> >
> > On Tue, Apr 9, 2019 at 2:15 PM Jana Iyengar <jri.ietf@gmail.com> wrote: > >>
> >>
> >>>
> >>> Yeah. My point is that any server-side deployment that tr= ies to use
> >>> the feature will be required to retain something it can n= ever forget
> >>> for the lifetime of the alias. Something being either a s= tatic key or
> >>> the alias versions themselves.
> >>>
> >>> For mass-scale deployments, such a requirement might not = be an issue.
> >>> Losing state is disastrous for them.
> >>>
> >>> OTOH, for small-scale deployments (e.g., standalone serve= rs), it is a
> >>> concern, because people often assume that they can try ru= n a server,
> >>> scrap it, and then run another one, which has been the ca= se for TCP
> >>> and TLS.
> >>
> >>
> >> You're right that this is a new requirement/constraint, s= o we need to articulate the implications clearly. That said, on this partic= ular point, a small deployment could just as easily choose to not advertise= an alias if it cannot guarantee that it will be able to remember the alias= .
> >>
> >>> > > At the same time, I have a fear that trying to = make this part of v1
> >>> > > might slow down the standardization process. Ca= n't it be a v1
> >>> > > extension, considering the fact that the intent= is to grease, and
> >>> > > greasing works if only _some_ of the implementa= tions support the
> >>> > > feature?
> >>> >
> >>> > Yes, this works pretty well as an extension.=C2=A0 I= t works less well as a NEW_TOKEN addition, so there is some value to doing = it now.
> >>>
> >>> That's a fair point. I agree that the version aliases= should better be
> >>> carried by=C2=A0 the NEW_TOKEN frame (or within the token= ), though I think
> >>> that they should have it's own lifetime (due to the c= oncern of server
> >>> losing state; not being able to use a token and not being= able to
> >>> recognize a version alias have different consequences). > >>
> >>
> >> Yes, the lifetime difference is why I suggested using a NEW_V= ERSION frame. That also aligns nicely with separating this as an extension.=
>
>
>
> --
> Kazuho Oku



--
Kazuho Oku
--00000000000076b7f905861db11b-- From nobody Tue Apr 9 12:27:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC65C1203F3 for ; Tue, 9 Apr 2019 12:27:42 -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 IqLg2dzR2vi7 for ; Tue, 9 Apr 2019 12:27:41 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 2AD8D1203F2 for ; Tue, 9 Apr 2019 12:27:41 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id v13so15531690ljk.4 for ; Tue, 09 Apr 2019 12:27:41 -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=qegTCQVqsJRPZk1MqV3w9HFOt3ELvVjVYNz8o0zSvNw=; b=l1DN5tp4xdCkWkoQCSdOCe2W32UMD3yKQGYzAWZFAH0EMqeStElsq0xFJ3aTZp1tay K5csskwVIVIlOt3V4CI/KJ0VbwY6Gvm/nsmkRIeMehHUKT5hzTnJjYWFVAqWQQDodFLp JIAsMU+Yd+IZc5HSWnr/VZttYc8CIpU6U21wV/7K1AhxFZGQieGNjHt/tCtCvKWo3ep4 aH3VnzxOCZSfNp4ha99YNXTKcO/7ri5IqAUsqmxhTME9hWG/8+FIUyLTA0kiCPq0ZB2B DRpiGEcuXgrsN8rPMQL1RjnrD4lUFd2I4jfE9TJRqs28MLhVFDbszea0aKknb5D7OZiI 9V/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qegTCQVqsJRPZk1MqV3w9HFOt3ELvVjVYNz8o0zSvNw=; b=SuT32oe1ZHAutnTvWvh9lnEKyYiPAuFByLHmbcwKz8u0J89EdSyQIbE2zIhyFyEoNP qtvok3z5jS83uPZZzkW8g6h3kz6pIBIjrplXlNiqz1MvrihtvQWrEIrHlrQUe1MV36Y9 j4U4gBKHvVjYOal5M4LqASaoPyS/gmD+X2casWtD9HQru4XGP9leCJhOvcPqM5b82WBN miOimCEks7dCxdRWoow6cL1KuR5A3zWUk1saVxFxmce2Vu1Bga3VUtm1u6lzGDvV8UOL DKYWcRxnUcPv7PFgPL/ufjSuf/n4dcq/8tJKddhRziw3MHFFI3fMmHtHg+bMiumZa9vW uygA== X-Gm-Message-State: APjAAAVbAiZzx5EW3XUXB//ISAeO1Mw/n4W9s1VcJyfnUpiN8D0EB7/L eymnDVXRbKtT7qeOqjVWpjzwuHVTin3keWA0IdWn7Q== X-Google-Smtp-Source: APXvYqwXwsTv5BMNynRqfXxhdgwsTfQb8eYevYsDAVJKh/0QqNpWzisVSBoRLyrOp/NBI2UqWWQFYDs8gZDOCkEMPAk= X-Received: by 2002:a2e:974d:: with SMTP id f13mr20431999ljj.140.1554838059074; Tue, 09 Apr 2019 12:27:39 -0700 (PDT) MIME-Version: 1.0 From: Jana Iyengar Date: Tue, 9 Apr 2019 12:27:28 -0700 Message-ID: Subject: EPIQ workshop To: QUIC WG Content-Type: multipart/alternative; boundary="00000000000031c88105861df281" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 19:27:43 -0000 --00000000000031c88105861df281 Content-Type: text/plain; charset="UTF-8" Friendly PSA: The EPIQ workshop deadline is fast approaching. If you're doing interesting things with QUIC, you might want to consider submitting. --00000000000031c88105861df281 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Friendly PSA: The EPIQ workshop deadline is fast appr= oaching. If you're doing interesting things with QUIC, you might want t= o consider submitting.

--00000000000031c88105861df281-- From nobody Tue Apr 9 19:34:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75AD120091 for ; Tue, 9 Apr 2019 19:34: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=lowentropy.net header.b=q1lumoX1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TGbJXx6b Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iLFcbRgANp4 for ; Tue, 9 Apr 2019 19:34:54 -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 E540312000E for ; Tue, 9 Apr 2019 19:34:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 244BA2607E for ; Tue, 9 Apr 2019 22:34:51 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 09 Apr 2019 22:34:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=8MtDihVLv5DGU/hs1qianwdOlj2B09E 45QpVQmuYIac=; b=q1lumoX1C9VkgPjCsYIxBSj6NvaFkvCVzidMEH5uF6U5r8b yGhqi8nvFko6rJdPVY1H17joMp4VX9STyhJ9feCKCSzogodTq+k9G1MszCysY7gC G7QDhvfOtZt5IZvJXyLB9oVCKKcc1vuBcLFe739WTFzgdjde4o9NjeTEfTxrO87h 7m2+bdM2vIrrVA0SrGFTKl90XIp3YMsihDQYLtX5jOT1HuwcNhsvcCpnK4hw0KAD ib2B8FfJMok6o7TvdLJmORnJBmySUYHVLwRIO3BPIHJa5czDvCwnZSv11QVTCelb qDVS8v9816wdo9r10Lj9t7G1pDl07+LUl3zJj/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8MtDih VLv5DGU/hs1qianwdOlj2B09E45QpVQmuYIac=; b=TGbJXx6bzKwMhuEZB0uTWC FYw8oQcfNpiwJSoAJ8Z65nqLJmLMebN3a93q/NVSb+l1F8wc1MrmSEEW+ldE/lcK uuRFdEqC9n9/HrEOXP7oz2MO/qXI0AGzqVEjaU2kpjM/d4/XLKQyv+90FgPOWpjM ytv9a4ZMeyNHR29GZ7/ENizE76Ky0bYa65zaKV/p4nkKhzYrUQoGoFHuM6K26lAA 0JsEyeGDXRYMWPRp5O+MIQ8FEJj7hXG8JRSmxY2k/hkfospdla+MKrLh7/xngLRw H2wLHDcGvu+oeBj/RT9Dxq4vSxyp2kuJmvNpRXRfa2YPjVbm9VGdcirVAWU9FQ1w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeigdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5A9A17C1B9; Tue, 9 Apr 2019 22:34:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.com> In-Reply-To: References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> Date: Tue, 09 Apr 2019 22:34:52 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Version Negotiation Greasing Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 02:34:56 -0000 On Wed, Apr 10, 2019, at 05:09, Jana Iyengar wrote: > Hm, perhaps I'm missing something. As an extension, the server would > simply advertise the alias in a transport parameter. A client that > understands this transport parameter could use it, others would not. > Why does the server need to know that the client understands and will > use the new alias? There need not be a requirement on a client to do it. There seems to be reasonable amounts of demand for a new frame, which would require that the client signal that it is willing to accept one. From nobody Tue Apr 9 20:16:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49A41200B3 for ; Tue, 9 Apr 2019 20:16: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, 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 JobP_BjmMpFg for ; Tue, 9 Apr 2019 20:16:17 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 B30EE12009C for ; Tue, 9 Apr 2019 20:16:16 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v13so679783ljk.4 for ; Tue, 09 Apr 2019 20:16:16 -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=tgGflyftL2FT+0poOGDICQ6odiEjdzG/kI7ZbUO7Tks=; b=P1ZxrnxPozYK1FI1W2Mn/gu78BOw7UqbROYSyLJUxiOxQT0/Ldm0TqwMlmIe9iOwV9 oQ4Qo8wuYSjiZi43QzkWTYqv/Uu+U4hCqEbZ4sEBLz4eGt/+KgNQnThYU3rSRPPNkUjW 0wGkY6gwP6eDFblTQQRmi8hitGi7+Kfa5FE7xIP7dmDXE33KjxV4u8zwM8NfwbSJGCxJ 3ZiDFNScEmrCRFFTRSQYWk1tHet8Zutu+RhXLlwaktiXtuwRit0cSDMEdiaD664dCxhO JG4PlttnRZ/Gnrks3xkrYB4AHSQCr5v1IbuPeik8I3wDjGbHj4upecDvTzOo66FjEsTb 2mUw== 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=tgGflyftL2FT+0poOGDICQ6odiEjdzG/kI7ZbUO7Tks=; b=HTpEBZ3sCmJIjGiGRGIa0Chfe6DmUPW17NeVv/qH9fHO8qYQ1i4vzFRAYqXLqA9nZp fd6R1f66tgIKJjUA1VZ3vGd0cZsePUhFzTw3qeejjJSYvjswQl94uzW+f3NyCRVOuPRR 9L/xWIvy/vG/sVWaYdSCAv75OmX6DE0lBU86ZIe6bT7lBtyd+bnTv3yyHCPYZizlwKy0 oLw6lctN0i+ttx+/0qAJWKlu/DRIgvBWq0ebCIWETqW98MAnzuSkzWkSqh4amhPFHdKN v8oWj06kZCG7KstjbNcGltQ0DXR+VJrYOtS5DWybkrlQWYPACqUWKSaewwwOFTPELQQZ d0IQ== X-Gm-Message-State: APjAAAUYFZ+gwGR4YxxrMGKOTs4b2R0dbHD9PFSRwxBxhbxtlqcqLlnq 3nh67mkUvuBZC1ydb2Hx+7D8CicEkt8gQtTTC4gZOceZ X-Google-Smtp-Source: APXvYqwPRXQfxRtLhk5nkeVS4+Zq08yxCZIxP21Sxh/WCXDg6Qz/fLPxrxrLUq0ipZ89hIvGJz+ZG6k0NPK7sVCs0ds= X-Received: by 2002:a2e:711a:: with SMTP id m26mr21675021ljc.40.1554866174835; Tue, 09 Apr 2019 20:16:14 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.com> In-Reply-To: <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.com> From: Kazuho Oku Date: Wed, 10 Apr 2019 12:16:04 +0900 Message-ID: Subject: Re: Version Negotiation Greasing To: Martin Thomson 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 03:16:19 -0000 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 11:35 Martin Thomson : > > On Wed, Apr 10, 2019, at 05:09, Jana Iyengar wrote: > > Hm, perhaps I'm missing something. As an extension, the server would > > simply advertise the alias in a transport parameter. A client that > > understands this transport parameter could use it, others would not. > > Why does the server need to know that the client understands and will > > use the new alias? There need not be a requirement on a client to do it= . > > There seems to be reasonable amounts of demand for a new frame, which wou= ld require that the client signal that it is willing to accept one. Agreed. Though assuming that we'd use a frame for sending version aliases, the trade-off is between: * a) define the frame in v1 * b) define an extension, that suggests a client to use a TP to signal it's support for the extension where, a has the (potential) risk of delaying the standardization process, b has the risk of middleboxes detecting and dropping connection establishment attempts using the extension. I do not think the downside of b is that important (because a middlebox can simply block all the QUIC connections), but the risk in a is also small. All in all, I think avoiding having an extension that changes the behavior of QUIC stacks outweighs the risks. And FWIW, I prefer extending the token for carrying the version alias as MT suggests. Because that would allow the server to decipher the correct version number from the contents of the token. --=20 Kazuho Oku From nobody Tue Apr 9 21:13:48 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD61E120283 for ; Tue, 9 Apr 2019 21:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, 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 Bdt_Hmv4wpNu for ; Tue, 9 Apr 2019 21:13:44 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BD312022D for ; Tue, 9 Apr 2019 21:13:44 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id n8so538104plp.10 for ; Tue, 09 Apr 2019 21:13:44 -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=tMuDAVjMTauHD4j6h9GygE3y+Uqy/1SVklJ11gKcPMY=; b=KbMtXnUESKy+gTFfTuIzT628JbYCtVOeB0slklq485GvBSHuLly32G5bLH35ivR8K2 X1aVhyJXGZop/09DNx0iwVlpVFEfPARffVEuD+cJzpWdKUVPRynepQZ3yZe+R5lr3G5y fXho5Umn7ZFsoLQm9rMbPdgBLzQLO41+yvAkm2hM0YnwJRWWOgSVXi3Kv3AbrCxPejwc g8RKKps1IweMf4aIhkDHVuD97Pk43gave3hlQYDQxSHEZ4MzP6NFOKDAtM8yrkhrx9bd HIHv28TmRk0Sn2/U3oryxE/W6/D4F9T+aw3A7qq6rZlsBMqiNlj18eGkkYlA+OuMhe0t u0MA== 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=tMuDAVjMTauHD4j6h9GygE3y+Uqy/1SVklJ11gKcPMY=; b=MoixTt92Yhp2mgLF2ScA6EJzAZtrpxUdH4nQXhk0a59yMXnOMsMvYSCKWI/63zttc0 /rwj9+PevyYms+6a7oxaZLF7QWt13a+c7Fc9lKxPLMgoyg8GlGMauxSYuQUbj8rf9RbO Xti9TLM4SMIeyWblexrKqNVSbh2XvraTGIVzjNXSE/XoExoLDFYkNt0xR5CbWHBKyhw5 yp5eZAm/Xwqm4JrWTrWjV4RZzAiibTlFkS5NgOLYKoDcIjudHbamPz8XnEjQLdWVRBmO ikLgUY3U1UDgiTveAoN7p9zrX04RntlRxyKMuyC97QP8uPt5kcmmiRz17P36yqstfVYo kUWg== X-Gm-Message-State: APjAAAWNyCY2QoI5DcQafVDqS9yak6osGxiAadw4qCcKdM2MxEEG1fY1 h0Crc0z5spkV6/qfyKiuURA= X-Google-Smtp-Source: APXvYqyWRh62j3R7MqfB5jxHHT91cQyNegxNJx2DPXe8t1mjPWXWMskRZsVaFgk28k9L3QKgy71TCQ== X-Received: by 2002:a17:902:469:: with SMTP id 96mr40758673ple.46.1554869623617; Tue, 09 Apr 2019 21:13:43 -0700 (PDT) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.61]) by smtp.gmail.com with ESMTPSA id w21sm46149890pfn.48.2019.04.09.21.13.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 21:13:42 -0700 (PDT) From: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= To: Kazuho Oku , Martin Thomson CC: IETF QUIC WG Subject: Re: Version Negotiation Greasing Thread-Topic: Version Negotiation Greasing Thread-Index: ATMwNTQzfTb5JtlfOBCkqnZ7jmpnWVFIX0FfY2NiNDV3MndQNWdrdHl4QTI0VkpnbWFVQUF2aC1QZ0h5aDkyZGI0N3dwZjhYpwpT8a0= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 10 Apr 2019 04:13:33 +0000 Message-ID: References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.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_DB6PR10MB1766D1435AB06F0E5D5FBAB9AC2E0DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 04:13:47 -0000 --_000_DB6PR10MB1766D1435AB06F0E5D5FBAB9AC2E0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2h5IG5vdCBqdXN0IGR1bXAgdGhlIHZlcnNpb24rc2FsdCBpbiBUUCBhcyBKYW5hIHN1Z2dlc3Rz PyBBIG5ldyBmcmFtZSB3YXMgYXJndWVkIHZzIG1vZGlmeWluZyBhbm90aGVyIGZyYW1lLCBidXQg aWYgeW91IGNhbiBkbyBpdCBhbGwgaW4gVFAsIHRoYXQgaXMgYSB2b2lkIGFyZ3VtZW50LiBTaWdu YWxsaW5nIGluIFRQIHNvdW5kcyBvdmVyLWNvbXBsaWNhdGVkLiBVbmxpa2UgTkVXX1RPS0VOLCB5 b3UgZG9u4oCZdCBoYXZlIHRvIHdhaXQgZm9yIFRMUyB0byBlbWl0IHNvbWV0aGluZy4NCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJhOiBRVUlDIDxxdWljLWJvdW5jZXNA aWV0Zi5vcmc+IHDDpSB2ZWduZSBhZiBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPg0K U2VuZHQ6IG9uc2RhZywgYXByaWwgMTAsIDIwMTkgNToxNiBBTQ0KVGlsOiBNYXJ0aW4gVGhvbXNv bg0KQ2M6IElFVEYgUVVJQyBXRw0KRW1uZTogUmU6IFZlcnNpb24gTmVnb3RpYXRpb24gR3JlYXNp bmcNCg0KMjAxOeW5tDTmnIgxMOaXpSjmsLQpIDExOjM1IE1hcnRpbiBUaG9tc29uIDxtdEBsb3dl bnRyb3B5Lm5ldD46DQo+DQo+IE9uIFdlZCwgQXByIDEwLCAyMDE5LCBhdCAwNTowOSwgSmFuYSBJ eWVuZ2FyIHdyb3RlOg0KPiA+IEhtLCBwZXJoYXBzIEknbSBtaXNzaW5nIHNvbWV0aGluZy4gQXMg YW4gZXh0ZW5zaW9uLCB0aGUgc2VydmVyIHdvdWxkDQo+ID4gc2ltcGx5IGFkdmVydGlzZSB0aGUg YWxpYXMgaW4gYSB0cmFuc3BvcnQgcGFyYW1ldGVyLiBBIGNsaWVudCB0aGF0DQo+ID4gdW5kZXJz dGFuZHMgdGhpcyB0cmFuc3BvcnQgcGFyYW1ldGVyIGNvdWxkIHVzZSBpdCwgb3RoZXJzIHdvdWxk IG5vdC4NCj4gPiBXaHkgZG9lcyB0aGUgc2VydmVyIG5lZWQgdG8ga25vdyB0aGF0IHRoZSBjbGll bnQgdW5kZXJzdGFuZHMgYW5kIHdpbGwNCj4gPiB1c2UgdGhlIG5ldyBhbGlhcz8gVGhlcmUgbmVl ZCBub3QgYmUgYSByZXF1aXJlbWVudCBvbiBhIGNsaWVudCB0byBkbyBpdC4uDQo+DQo+IFRoZXJl IHNlZW1zIHRvIGJlIHJlYXNvbmFibGUgYW1vdW50cyBvZiBkZW1hbmQgZm9yIGEgbmV3IGZyYW1l LCB3aGljaCB3b3VsZCByZXF1aXJlIHRoYXQgdGhlIGNsaWVudCBzaWduYWwgdGhhdCBpdCBpcyB3 aWxsaW5nIHRvIGFjY2VwdCBvbmUuDQoNCkFncmVlZC4gVGhvdWdoIGFzc3VtaW5nIHRoYXQgd2Un ZCB1c2UgYSBmcmFtZSBmb3Igc2VuZGluZyB2ZXJzaW9uDQphbGlhc2VzLCB0aGUgdHJhZGUtb2Zm IGlzIGJldHdlZW46DQoqIGEpIGRlZmluZSB0aGUgZnJhbWUgaW4gdjENCiogYikgZGVmaW5lIGFu IGV4dGVuc2lvbiwgdGhhdCBzdWdnZXN0cyBhIGNsaWVudCB0byB1c2UgYSBUUCB0byBzaWduYWwN Cml0J3Mgc3VwcG9ydCBmb3IgdGhlIGV4dGVuc2lvbg0KDQp3aGVyZSwgYSBoYXMgdGhlIChwb3Rl bnRpYWwpIHJpc2sgb2YgZGVsYXlpbmcgdGhlIHN0YW5kYXJkaXphdGlvbg0KcHJvY2VzcywgYiBo YXMgdGhlIHJpc2sgb2YgbWlkZGxlYm94ZXMgZGV0ZWN0aW5nIGFuZCBkcm9wcGluZw0KY29ubmVj dGlvbiBlc3RhYmxpc2htZW50IGF0dGVtcHRzIHVzaW5nIHRoZSBleHRlbnNpb24uDQoNCkkgZG8g bm90IHRoaW5rIHRoZSBkb3duc2lkZSBvZiBiIGlzIHRoYXQgaW1wb3J0YW50IChiZWNhdXNlIGEN Cm1pZGRsZWJveCBjYW4gc2ltcGx5IGJsb2NrIGFsbCB0aGUgUVVJQyBjb25uZWN0aW9ucyksIGJ1 dCB0aGUgcmlzayBpbg0KYSBpcyBhbHNvIHNtYWxsLiBBbGwgaW4gYWxsLCBJIHRoaW5rIGF2b2lk aW5nIGhhdmluZyBhbiBleHRlbnNpb24gdGhhdA0KY2hhbmdlcyB0aGUgYmVoYXZpb3Igb2YgUVVJ QyBzdGFja3Mgb3V0d2VpZ2hzIHRoZSByaXNrcy4NCg0KQW5kIEZXSVcsIEkgcHJlZmVyIGV4dGVu ZGluZyB0aGUgdG9rZW4gZm9yIGNhcnJ5aW5nIHRoZSB2ZXJzaW9uIGFsaWFzDQphcyBNVCBzdWdn ZXN0cy4gQmVjYXVzZSB0aGF0IHdvdWxkIGFsbG93IHRoZSBzZXJ2ZXIgdG8gZGVjaXBoZXIgdGhl DQpjb3JyZWN0IHZlcnNpb24gbnVtYmVyIGZyb20gdGhlIGNvbnRlbnRzIG9mIHRoZSB0b2tlbi4N Cg0KLS0NCkthenVobyBPa3UNCg0K --_000_DB6PR10MB1766D1435AB06F0E5D5FBAB9AC2E0DB6PR10MB1766EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOiBsdHI7Ij5XaHkgbm90IGp1c3QgZHVtcCB0 aGUgdmVyc2lvbiYjNDM7c2FsdCBpbiBUUCBhcyBKYW5hIHN1Z2dlc3RzPyBBIG5ldyBmcmFtZSB3 YXMgYXJndWVkIHZzIG1vZGlmeWluZyBhbm90aGVyIGZyYW1lLCBidXQgaWYgeW91IGNhbiBkbyBp dCBhbGwgaW4gVFAsIHRoYXQgaXMgYSB2b2lkIGFyZ3VtZW50LiBTaWduYWxsaW5nIGluIFRQIHNv dW5kcyBvdmVyLWNvbXBsaWNhdGVkLiBVbmxpa2UgTkVXX1RPS0VOLCB5b3UNCiBkb27igJl0IGhh dmUgdG8gd2FpdCBmb3IgVExTIHRvIGVtaXQgc29tZXRoaW5nLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibXMtb3V0bG9vay1pb3Mtc2lnbmF0dXJlIj48L2Rp dj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxociBzdHlsZT0iZGlzcGxheTppbmxpbmUt YmxvY2s7d2lkdGg6OTglIiB0YWJpbmRleD0iLTEiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyIg ZGlyPSJkaXI9JnF1b3Q7bHRyJnF1b3Q7Ij48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlm IiBzdHlsZT0iZm9udC1zaXplOjExcHQiIGNvbG9yPSIjMDAwMDAwIj48Yj5GcmE6PC9iPiBRVUlD ICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IHDDpSB2ZWduZSBhZiBLYXp1aG8gT2t1ICZs dDtrYXp1aG9va3VAZ21haWwuY29tJmd0Ozxicj4NCjxiPlNlbmR0OjwvYj4gb25zZGFnLCBhcHJp bCAxMCwgMjAxOSA1OjE2IEFNPGJyPg0KPGI+VGlsOjwvYj4gTWFydGluIFRob21zb248YnI+DQo8 Yj5DYzo8L2I+IElFVEYgUVVJQyBXRzxicj4NCjxiPkVtbmU6PC9iPiBSZTogVmVyc2lvbiBOZWdv dGlhdGlvbiBHcmVhc2luZw0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZm9udD48L2Rpdj4NCjIwMTnl ubQ05pyIMTDml6Uo5rC0KSAxMTozNSBNYXJ0aW4gVGhvbXNvbiAmbHQ7bXRAbG93ZW50cm9weS5u ZXQmZ3Q7OiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gV2VkLCBBcHIgMTAsIDIwMTksIGF0IDA1 OjA5LCBKYW5hIEl5ZW5nYXIgd3JvdGU6IDxicj4NCiZndDsgJmd0OyBIbSwgcGVyaGFwcyBJJ20g bWlzc2luZyBzb21ldGhpbmcuIEFzIGFuIGV4dGVuc2lvbiwgdGhlIHNlcnZlciB3b3VsZCA8YnI+ DQomZ3Q7ICZndDsgc2ltcGx5IGFkdmVydGlzZSB0aGUgYWxpYXMgaW4gYSB0cmFuc3BvcnQgcGFy YW1ldGVyLiBBIGNsaWVudCB0aGF0IDxicj4NCiZndDsgJmd0OyB1bmRlcnN0YW5kcyB0aGlzIHRy YW5zcG9ydCBwYXJhbWV0ZXIgY291bGQgdXNlIGl0LCBvdGhlcnMgd291bGQgbm90LiA8YnI+DQom Z3Q7ICZndDsgV2h5IGRvZXMgdGhlIHNlcnZlciBuZWVkIHRvIGtub3cgdGhhdCB0aGUgY2xpZW50 IHVuZGVyc3RhbmRzIGFuZCB3aWxsIDxicj4NCiZndDsgJmd0OyB1c2UgdGhlIG5ldyBhbGlhcz8g VGhlcmUgbmVlZCBub3QgYmUgYSByZXF1aXJlbWVudCBvbiBhIGNsaWVudCB0byBkbyBpdC4uIDxi cj4NCiZndDsgPGJyPg0KJmd0OyBUaGVyZSBzZWVtcyB0byBiZSByZWFzb25hYmxlIGFtb3VudHMg b2YgZGVtYW5kIGZvciBhIG5ldyBmcmFtZSwgd2hpY2ggd291bGQgcmVxdWlyZSB0aGF0IHRoZSBj bGllbnQgc2lnbmFsIHRoYXQgaXQgaXMgd2lsbGluZyB0byBhY2NlcHQgb25lLg0KPGJyPg0KPGJy Pg0KQWdyZWVkLiBUaG91Z2ggYXNzdW1pbmcgdGhhdCB3ZSdkIHVzZSBhIGZyYW1lIGZvciBzZW5k aW5nIHZlcnNpb24gPGJyPg0KYWxpYXNlcywgdGhlIHRyYWRlLW9mZiBpcyBiZXR3ZWVuOiA8YnI+ DQoqIGEpIGRlZmluZSB0aGUgZnJhbWUgaW4gdjEgPGJyPg0KKiBiKSBkZWZpbmUgYW4gZXh0ZW5z aW9uLCB0aGF0IHN1Z2dlc3RzIGEgY2xpZW50IHRvIHVzZSBhIFRQIHRvIHNpZ25hbCA8YnI+DQpp dCdzIHN1cHBvcnQgZm9yIHRoZSBleHRlbnNpb24gPGJyPg0KPGJyPg0Kd2hlcmUsIGEgaGFzIHRo ZSAocG90ZW50aWFsKSByaXNrIG9mIGRlbGF5aW5nIHRoZSBzdGFuZGFyZGl6YXRpb24gPGJyPg0K cHJvY2VzcywgYiBoYXMgdGhlIHJpc2sgb2YgbWlkZGxlYm94ZXMgZGV0ZWN0aW5nIGFuZCBkcm9w cGluZyA8YnI+DQpjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgYXR0ZW1wdHMgdXNpbmcgdGhlIGV4 dGVuc2lvbi4gPGJyPg0KPGJyPg0KSSBkbyBub3QgdGhpbmsgdGhlIGRvd25zaWRlIG9mIGIgaXMg dGhhdCBpbXBvcnRhbnQgKGJlY2F1c2UgYSA8YnI+DQptaWRkbGVib3ggY2FuIHNpbXBseSBibG9j ayBhbGwgdGhlIFFVSUMgY29ubmVjdGlvbnMpLCBidXQgdGhlIHJpc2sgaW4gPGJyPg0KYSBpcyBh bHNvIHNtYWxsLiBBbGwgaW4gYWxsLCBJIHRoaW5rIGF2b2lkaW5nIGhhdmluZyBhbiBleHRlbnNp b24gdGhhdCA8YnI+DQpjaGFuZ2VzIHRoZSBiZWhhdmlvciBvZiBRVUlDIHN0YWNrcyBvdXR3ZWln aHMgdGhlIHJpc2tzLiA8YnI+DQo8YnI+DQpBbmQgRldJVywgSSBwcmVmZXIgZXh0ZW5kaW5nIHRo ZSB0b2tlbiBmb3IgY2FycnlpbmcgdGhlIHZlcnNpb24gYWxpYXMgPGJyPg0KYXMgTVQgc3VnZ2Vz dHMuIEJlY2F1c2UgdGhhdCB3b3VsZCBhbGxvdyB0aGUgc2VydmVyIHRvIGRlY2lwaGVyIHRoZSA8 YnI+DQpjb3JyZWN0IHZlcnNpb24gbnVtYmVyIGZyb20gdGhlIGNvbnRlbnRzIG9mIHRoZSB0b2tl bi4gPGJyPg0KPGJyPg0KLS0gPGJyPg0KS2F6dWhvIE9rdSA8YnI+DQo8YnI+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_DB6PR10MB1766D1435AB06F0E5D5FBAB9AC2E0DB6PR10MB1766EURP_-- From nobody Tue Apr 9 21:30:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4588120110 for ; Tue, 9 Apr 2019 21:30:55 -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 ySVz8W6pAU5G for ; Tue, 9 Apr 2019 21:30:53 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 64005120090 for ; Tue, 9 Apr 2019 21:30:53 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id y6so744597ljd.12 for ; Tue, 09 Apr 2019 21:30:53 -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=IC6aP6NixhrGasGqV4cQhq6d2g8PpE5z9mPkJDzLhIY=; b=PVOcsJRbv2SFv6nqVGT1mCoEW1u6Nv9iQdgfE7yBmDfxTnv06jbwijxwByG0dXSw+4 /stRVZApsF2dqaGV/PEZD7XMNTgsJxb6KKpoZb9PuBipfp1Gji0txb2sd4aDkFeut/NV iHzjsB9UKn6Ph0b/A6apd9m03V3zwxWwnvPyODI6Atmh3BfytLYo+wcLCCw0e3+Oo/si bbdEf2xSeczZLcTWhRIejyS7KhxDlFk2ZVggH82uGXM18d7icywFrZlG81pbAPZQNDA/ MhrsH1pO/tl1bZNdakpIRoFLIj9znb0+xtowsmin/vvCJ6wUpidy2d41Sv+wM0fMYcaW ILsA== 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=IC6aP6NixhrGasGqV4cQhq6d2g8PpE5z9mPkJDzLhIY=; b=F6Dhkg35opfMPniLlXisM3i6p9P1+dojS9RABPOLRh8tmlkhGyyWsFhXjBZGwMYlip /eZSZZisGTlnM/hpdJG1arqzYeuA3hMkfhyNRAJV8LCkg70dv15f+tUrBKEMMNriKs8P h4MlIcVbI+DWow71sga3IIqRuz6GPycys5xjVcSOjycPtwFn4TSIb+A2vKb1OI7DHKZl wFzKaG5pzPXwMhUK5AtCV2QVGRElBdXdzall1I+kjyjVUhQUjGHhiiyKwGxlyILG2FIo dBztRiLCvTCPrPWfFZrLX2cLq9p9teojmS7cGOcPcKuZmMNI9Z+EjFqrajYVvPtkNPpM 4GtA== X-Gm-Message-State: APjAAAX7Toa9QjohJKJz8a9v9pWO7imP3NFLuqQPO3g6LHYuUgveZByD Q6mv6NedZ4p7U3Wx2PNqZz0BEPfJ9sjeCKYuv9M= X-Google-Smtp-Source: APXvYqzSNGBFdFVfFwRJrySuSF18pO0Z0GRiIkGjkVIvk/4bYrfJy6N6ROJdFS9cyeemcke5qMh+axxSYHbPNweyyLE= X-Received: by 2002:a2e:9010:: with SMTP id h16mr21477963ljg.16.1554870651585; Tue, 09 Apr 2019 21:30:51 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.com> In-Reply-To: From: Kazuho Oku Date: Wed, 10 Apr 2019 13:30:40 +0900 Message-ID: Subject: Re: Version Negotiation Greasing To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 04:30:56 -0000 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 13:13 Mikkel Fahn=C3=B8e J=C3= =B8rgensen : > > Why not just dump the version+salt in TP as Jana suggests? I think Two reasons have been pointed out so far: * Sending in TP reduces the amount of things a server can send in the first flight (we are trying hard to fit the certificate chain in 3 packets; pointed out by Marten). * Binding aliases to token let's servers issue different aliases for each connection. Sending the aliases in TP would imply that they can be used without a matching token. In such a design, it is impossible to have different aliases for every connection (pointed out by MT). > A new frame was argued vs modifying another frame, but if you can do it a= ll in TP, that is a void argument. Signalling in TP sounds over-complicated= . Unlike NEW_TOKEN, you don=E2=80=99t have to wait for TLS to emit somethin= g. > > > ________________________________ > Fra: QUIC p=C3=A5 vegne af Kazuho Oku > Sendt: onsdag, april 10, 2019 5:16 AM > Til: Martin Thomson > Cc: IETF QUIC WG > Emne: Re: Version Negotiation Greasing > > 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 11:35 Martin Thomson : > > > > On Wed, Apr 10, 2019, at 05:09, Jana Iyengar wrote: > > > Hm, perhaps I'm missing something. As an extension, the server would > > > simply advertise the alias in a transport parameter. A client that > > > understands this transport parameter could use it, others would not. > > > Why does the server need to know that the client understands and will > > > use the new alias? There need not be a requirement on a client to do = it.. > > > > There seems to be reasonable amounts of demand for a new frame, which w= ould require that the client signal that it is willing to accept one. > > Agreed. Though assuming that we'd use a frame for sending version > aliases, the trade-off is between: > * a) define the frame in v1 > * b) define an extension, that suggests a client to use a TP to signal > it's support for the extension > > where, a has the (potential) risk of delaying the standardization > process, b has the risk of middleboxes detecting and dropping > connection establishment attempts using the extension. > > I do not think the downside of b is that important (because a > middlebox can simply block all the QUIC connections), but the risk in > a is also small. All in all, I think avoiding having an extension that > changes the behavior of QUIC stacks outweighs the risks. > > And FWIW, I prefer extending the token for carrying the version alias > as MT suggests. Because that would allow the server to decipher the > correct version number from the contents of the token. > > -- > Kazuho Oku > --=20 Kazuho Oku From nobody Tue Apr 9 21:35:03 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DAB1200FB for ; Tue, 9 Apr 2019 21:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, 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 OoytzD8uaiFj for ; Tue, 9 Apr 2019 21:34:59 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DB712002E for ; Tue, 9 Apr 2019 21:34:59 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id k45so751405edb.6 for ; Tue, 09 Apr 2019 21:34:59 -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=TvqvBlJaKK5gucK8N/c0DuzPWefe5FwAxTb374Eehog=; b=tGrul3QLtyAcZ1uXowfCOYc95xTJUFzks32Z5u7Cqn/bn03OuC/u8Ssv1JCSvJJAke 1W9VvmHGlgBz00Rre5SSSTlzjs32/5ORursVWVPQ1Cvs5UKnVji9A8gbzfn2vJ4W7bp+ dOaoQNXk3CnW6Zh2Ggjb+kvJ02bBICjHNP9o6I+YI0vtwe6JHNePHFhWjv/WeWEccvId d1kIjf2FVFVCmPe6rRYWx3ZLCTZLXPq+QZOuaT6/KnyFtNhy/6neE2oUJHRpXjqCtnKE IaNY/T8PJzcRZ7bBJO/ZDuv958Z9M9IDJ9ehsy+xGafKHiHnT4fBQCSaXG2q05jhYb/L 8hwQ== 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=TvqvBlJaKK5gucK8N/c0DuzPWefe5FwAxTb374Eehog=; b=AGEPKEkNX1PKOxYog18PdExoxbS73xVHfntrWq6ycfDuloICEHhaK0TyoUVxWRsi6g kzp52uOLJ7rBmIIQtxxg/kPrGk9ALLqiGXEd9Mn8hDESnZ8vqJ7I7hnmcYJlW51/0MTe zjnO45nWFztYWFfA80HbYoqIVoEpq8XGqkpjLEhmcyjWzrtKP8KCR1x3fSXW842PSmBd wfFhLSgunziyBQyvcD/Oj+odF5g+ubXV3Lo0Ah9xz+JiFhlwvk7Cm+ypPIBy5wxhCFbl K5+ICxnmJcoBUA2J+JiZfQa7hY0kUa6NcAfC2WBctKGo9LJX+zlzao7v5mP1OeiVAAZx zUAg== X-Gm-Message-State: APjAAAX81ks3VgCQlhP86YQ685gPKTzO6xZSRNvcdlpVKKQ++YPUtzaW HmcooosdejwWVI58JopQ8Ks= X-Google-Smtp-Source: APXvYqxv3GDNMf4o0f5F+NguuyHQpFmBLSuzVoaPOKMt1JAN4/vvnUDvBxe5KLKL9JZQ2A/AsEwXNw== X-Received: by 2002:a50:9856:: with SMTP id h22mr26391736edb.186.1554870897916; Tue, 09 Apr 2019 21:34:57 -0700 (PDT) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.61]) by smtp.gmail.com with ESMTPSA id c16sm8253422edc.75.2019.04.09.21.34.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 21:34:56 -0700 (PDT) From: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= To: Kazuho Oku CC: Martin Thomson , IETF QUIC WG Subject: Re: Version Negotiation Greasing Thread-Topic: Version Negotiation Greasing Thread-Index: ATMwNTQzfTb5JtlfOBCkqnZ7jmpnWVFIX0FfY2NiNDV3MndQNWdrdHl4QTI0VkpnbWFVQUF2aC1QZ0h5aDkyZGI0N3dwZjhYMEEwMzF3V3djd6HNldwC X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 10 Apr 2019 04:34:54 +0000 Message-ID: References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.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_DB6PR10MB1766EE0620E3C5FD4AA67BBEAC2E0DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 04:35:02 -0000 --_000_DB6PR10MB1766EE0620E3C5FD4AA67BBEAC2E0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBwb2ludHMuIFdoYXQgaWYgdGhlIGNvbm5lY3Rpb24gZ29lcyBkb3duIGJldHdlZW4gbmV3 IHRva2VuIGFuZCBuZXcgdmVyc2lvbiBhbGlhcz8gSXMgdGhlIHRva2VuIHVzYWJsZSBpbiBpdHMg b3duPw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcmE6IEthenVobyBP a3UgPGthenVob29rdUBnbWFpbC5jb20+DQpTZW5kdDogb25zZGFnLCBhcHJpbCAxMCwgMjAxOSA2 OjMwIEFNDQpUaWw6IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCkNjOiBNYXJ0aW4gVGhvbXNv bjsgSUVURiBRVUlDIFdHDQpFbW5lOiBSZTogVmVyc2lvbiBOZWdvdGlhdGlvbiBHcmVhc2luZw0K DQoyMDE55bm0NOaciDEw5pelKOawtCkgMTM6MTMgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8 bWlra2VsZmpAZ21haWwuY29tPjoNCj4NCj4gV2h5IG5vdCBqdXN0IGR1bXAgdGhlIHZlcnNpb24r c2FsdCBpbiBUUCBhcyBKYW5hIHN1Z2dlc3RzPw0KDQpJIHRoaW5rIFR3byByZWFzb25zIGhhdmUg YmVlbiBwb2ludGVkIG91dCBzbyBmYXI6DQoqIFNlbmRpbmcgaW4gVFAgcmVkdWNlcyB0aGUgYW1v dW50IG9mIHRoaW5ncyBhIHNlcnZlciBjYW4gc2VuZCBpbiB0aGUNCmZpcnN0IGZsaWdodCAod2Ug YXJlIHRyeWluZyBoYXJkIHRvIGZpdCB0aGUgY2VydGlmaWNhdGUgY2hhaW4gaW4gMw0KcGFja2V0 czsgcG9pbnRlZCBvdXQgYnkgTWFydGVuKS4NCiogQmluZGluZyBhbGlhc2VzIHRvIHRva2VuIGxl dCdzIHNlcnZlcnMgaXNzdWUgZGlmZmVyZW50IGFsaWFzZXMgZm9yDQplYWNoIGNvbm5lY3Rpb24u IFNlbmRpbmcgdGhlIGFsaWFzZXMgaW4gVFAgd291bGQgaW1wbHkgdGhhdCB0aGV5IGNhbg0KYmUg dXNlZCB3aXRob3V0IGEgbWF0Y2hpbmcgdG9rZW4uIEluIHN1Y2ggYSBkZXNpZ24sIGl0IGlzIGlt cG9zc2libGUNCnRvIGhhdmUgZGlmZmVyZW50IGFsaWFzZXMgZm9yIGV2ZXJ5IGNvbm5lY3Rpb24g KHBvaW50ZWQgb3V0IGJ5IE1UKS4NCg0KPiBBIG5ldyBmcmFtZSB3YXMgYXJndWVkIHZzIG1vZGlm eWluZyBhbm90aGVyIGZyYW1lLCBidXQgaWYgeW91IGNhbiBkbyBpdCBhbGwgaW4gVFAsIHRoYXQg aXMgYSB2b2lkIGFyZ3VtZW50LiBTaWduYWxsaW5nIGluIFRQIHNvdW5kcyBvdmVyLWNvbXBsaWNh dGVkLiBVbmxpa2UgTkVXX1RPS0VOLCB5b3UgZG9u4oCZdCBoYXZlIHRvIHdhaXQgZm9yIFRMUyB0 byBlbWl0IHNvbWV0aGluZy4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gRnJhOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IHDDpSB2ZWduZSBhZiBLYXp1 aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPg0KPiBTZW5kdDogb25zZGFnLCBhcHJpbCAxMCwg MjAxOSA1OjE2IEFNDQo+IFRpbDogTWFydGluIFRob21zb24NCj4gQ2M6IElFVEYgUVVJQyBXRw0K PiBFbW5lOiBSZTogVmVyc2lvbiBOZWdvdGlhdGlvbiBHcmVhc2luZw0KPg0KPiAyMDE55bm0NOac iDEw5pelKOawtCkgMTE6MzUgTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PjoNCj4g Pg0KPiA+IE9uIFdlZCwgQXByIDEwLCAyMDE5LCBhdCAwNTowOSwgSmFuYSBJeWVuZ2FyIHdyb3Rl Og0KPiA+ID4gSG0sIHBlcmhhcHMgSSdtIG1pc3Npbmcgc29tZXRoaW5nLiBBcyBhbiBleHRlbnNp b24sIHRoZSBzZXJ2ZXIgd291bGQNCj4gPiA+IHNpbXBseSBhZHZlcnRpc2UgdGhlIGFsaWFzIGlu IGEgdHJhbnNwb3J0IHBhcmFtZXRlci4gQSBjbGllbnQgdGhhdA0KPiA+ID4gdW5kZXJzdGFuZHMg dGhpcyB0cmFuc3BvcnQgcGFyYW1ldGVyIGNvdWxkIHVzZSBpdCwgb3RoZXJzIHdvdWxkIG5vdC4N Cj4gPiA+IFdoeSBkb2VzIHRoZSBzZXJ2ZXIgbmVlZCB0byBrbm93IHRoYXQgdGhlIGNsaWVudCB1 bmRlcnN0YW5kcyBhbmQgd2lsbA0KPiA+ID4gdXNlIHRoZSBuZXcgYWxpYXM/IFRoZXJlIG5lZWQg bm90IGJlIGEgcmVxdWlyZW1lbnQgb24gYSBjbGllbnQgdG8gZG8gaXQuLg0KPiA+DQo+ID4gVGhl cmUgc2VlbXMgdG8gYmUgcmVhc29uYWJsZSBhbW91bnRzIG9mIGRlbWFuZCBmb3IgYSBuZXcgZnJh bWUsIHdoaWNoIHdvdWxkIHJlcXVpcmUgdGhhdCB0aGUgY2xpZW50IHNpZ25hbCB0aGF0IGl0IGlz IHdpbGxpbmcgdG8gYWNjZXB0IG9uZS4NCj4NCj4gQWdyZWVkLiBUaG91Z2ggYXNzdW1pbmcgdGhh dCB3ZSdkIHVzZSBhIGZyYW1lIGZvciBzZW5kaW5nIHZlcnNpb24NCj4gYWxpYXNlcywgdGhlIHRy YWRlLW9mZiBpcyBiZXR3ZWVuOg0KPiAqIGEpIGRlZmluZSB0aGUgZnJhbWUgaW4gdjENCj4gKiBi KSBkZWZpbmUgYW4gZXh0ZW5zaW9uLCB0aGF0IHN1Z2dlc3RzIGEgY2xpZW50IHRvIHVzZSBhIFRQ IHRvIHNpZ25hbA0KPiBpdCdzIHN1cHBvcnQgZm9yIHRoZSBleHRlbnNpb24NCj4NCj4gd2hlcmUs IGEgaGFzIHRoZSAocG90ZW50aWFsKSByaXNrIG9mIGRlbGF5aW5nIHRoZSBzdGFuZGFyZGl6YXRp b24NCj4gcHJvY2VzcywgYiBoYXMgdGhlIHJpc2sgb2YgbWlkZGxlYm94ZXMgZGV0ZWN0aW5nIGFu ZCBkcm9wcGluZw0KPiBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgYXR0ZW1wdHMgdXNpbmcgdGhl IGV4dGVuc2lvbi4NCj4NCj4gSSBkbyBub3QgdGhpbmsgdGhlIGRvd25zaWRlIG9mIGIgaXMgdGhh dCBpbXBvcnRhbnQgKGJlY2F1c2UgYQ0KPiBtaWRkbGVib3ggY2FuIHNpbXBseSBibG9jayBhbGwg dGhlIFFVSUMgY29ubmVjdGlvbnMpLCBidXQgdGhlIHJpc2sgaW4NCj4gYSBpcyBhbHNvIHNtYWxs LiBBbGwgaW4gYWxsLCBJIHRoaW5rIGF2b2lkaW5nIGhhdmluZyBhbiBleHRlbnNpb24gdGhhdA0K PiBjaGFuZ2VzIHRoZSBiZWhhdmlvciBvZiBRVUlDIHN0YWNrcyBvdXR3ZWlnaHMgdGhlIHJpc2tz Lg0KPg0KPiBBbmQgRldJVywgSSBwcmVmZXIgZXh0ZW5kaW5nIHRoZSB0b2tlbiBmb3IgY2Fycnlp bmcgdGhlIHZlcnNpb24gYWxpYXMNCj4gYXMgTVQgc3VnZ2VzdHMuIEJlY2F1c2UgdGhhdCB3b3Vs ZCBhbGxvdyB0aGUgc2VydmVyIHRvIGRlY2lwaGVyIHRoZQ0KPiBjb3JyZWN0IHZlcnNpb24gbnVt YmVyIGZyb20gdGhlIGNvbnRlbnRzIG9mIHRoZSB0b2tlbi4NCj4NCj4gLS0NCj4gS2F6dWhvIE9r dQ0KPg0KDQoNCi0tDQpLYXp1aG8gT2t1DQo= --_000_DB6PR10MB1766EE0620E3C5FD4AA67BBEAC2E0DB6PR10MB1766EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOiBsdHI7Ij5GYWlyIHBvaW50cy4gV2hhdCBp ZiB0aGUgY29ubmVjdGlvbiBnb2VzIGRvd24gYmV0d2VlbiBuZXcgdG9rZW4gYW5kIG5ldyB2ZXJz aW9uIGFsaWFzPyBJcyB0aGUgdG9rZW4gdXNhYmxlIGluIGl0cyBvd24/PC9kaXY+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJtcy1vdXRsb29rLWlvcy1zaWduYXR1cmUi PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGhyIHN0eWxlPSJkaXNwbGF5Omlu bGluZS1ibG9jazt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScGx5Rndk TXNnIiBkaXI9ImRpcj0mcXVvdDtsdHImcXVvdDsiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMt c2VyaWYiIHN0eWxlPSJmb250LXNpemU6MTFwdCIgY29sb3I9IiMwMDAwMDAiPjxiPkZyYTo8L2I+ IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U2VuZHQ6PC9i PiBvbnNkYWcsIGFwcmlsIDEwLCAyMDE5IDY6MzAgQU08YnI+DQo8Yj5UaWw6PC9iPiBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gVGhvbXNvbjsgSUVURiBR VUlDIFdHPGJyPg0KPGI+RW1uZTo8L2I+IFJlOiBWZXJzaW9uIE5lZ290aWF0aW9uIEdyZWFzaW5n DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9mb250PjwvZGl2Pg0KMjAxOeW5tDTmnIgxMOaXpSjmsLQp IDEzOjEzIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZn dDs6IDxicj4NCiZndDsgPGJyPg0KJmd0OyBXaHkgbm90IGp1c3QgZHVtcCB0aGUgdmVyc2lvbiYj NDM7c2FsdCBpbiBUUCBhcyBKYW5hIHN1Z2dlc3RzPyA8YnI+DQo8YnI+DQpJIHRoaW5rIFR3byBy ZWFzb25zIGhhdmUgYmVlbiBwb2ludGVkIG91dCBzbyBmYXI6IDxicj4NCiogU2VuZGluZyBpbiBU UCByZWR1Y2VzIHRoZSBhbW91bnQgb2YgdGhpbmdzIGEgc2VydmVyIGNhbiBzZW5kIGluIHRoZSA8 YnI+DQpmaXJzdCBmbGlnaHQgKHdlIGFyZSB0cnlpbmcgaGFyZCB0byBmaXQgdGhlIGNlcnRpZmlj YXRlIGNoYWluIGluIDMgPGJyPg0KcGFja2V0czsgcG9pbnRlZCBvdXQgYnkgTWFydGVuKS4gPGJy Pg0KKiBCaW5kaW5nIGFsaWFzZXMgdG8gdG9rZW4gbGV0J3Mgc2VydmVycyBpc3N1ZSBkaWZmZXJl bnQgYWxpYXNlcyBmb3IgPGJyPg0KZWFjaCBjb25uZWN0aW9uLiBTZW5kaW5nIHRoZSBhbGlhc2Vz IGluIFRQIHdvdWxkIGltcGx5IHRoYXQgdGhleSBjYW4gPGJyPg0KYmUgdXNlZCB3aXRob3V0IGEg bWF0Y2hpbmcgdG9rZW4uIEluIHN1Y2ggYSBkZXNpZ24sIGl0IGlzIGltcG9zc2libGUgPGJyPg0K dG8gaGF2ZSBkaWZmZXJlbnQgYWxpYXNlcyBmb3IgZXZlcnkgY29ubmVjdGlvbiAocG9pbnRlZCBv dXQgYnkgTVQpLiA8YnI+DQo8YnI+DQomZ3Q7IEEgbmV3IGZyYW1lIHdhcyBhcmd1ZWQgdnMgbW9k aWZ5aW5nIGFub3RoZXIgZnJhbWUsIGJ1dCBpZiB5b3UgY2FuIGRvIGl0IGFsbCBpbiBUUCwgdGhh dCBpcyBhIHZvaWQgYXJndW1lbnQuIFNpZ25hbGxpbmcgaW4gVFAgc291bmRzIG92ZXItY29tcGxp Y2F0ZWQuIFVubGlrZSBORVdfVE9LRU4sIHlvdSBkb27igJl0IGhhdmUgdG8gd2FpdCBmb3IgVExT IHRvIGVtaXQgc29tZXRoaW5nLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gPGJyPg0KJmd0OyBGcmE6IFFVSUMgJmx0O3F1 aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgcMOlIHZlZ25lIGFmIEthenVobyBPa3UgJmx0O2thenVo b29rdUBnbWFpbC5jb20mZ3Q7IDxicj4NCiZndDsgU2VuZHQ6IG9uc2RhZywgYXByaWwgMTAsIDIw MTkgNToxNiBBTSA8YnI+DQomZ3Q7IFRpbDogTWFydGluIFRob21zb24gPGJyPg0KJmd0OyBDYzog SUVURiBRVUlDIFdHIDxicj4NCiZndDsgRW1uZTogUmU6IFZlcnNpb24gTmVnb3RpYXRpb24gR3Jl YXNpbmcgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIwMTnlubQ05pyIMTDml6Uo5rC0KSAxMTozNSBN YXJ0aW4gVGhvbXNvbiAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7OiA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IE9uIFdlZCwgQXByIDEwLCAyMDE5LCBhdCAwNTowOSwgSmFuYSBJeWVu Z2FyIHdyb3RlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBIbSwgcGVyaGFwcyBJJ20gbWlzc2luZyBz b21ldGhpbmcuIEFzIGFuIGV4dGVuc2lvbiwgdGhlIHNlcnZlciB3b3VsZCA8YnI+DQomZ3Q7ICZn dDsgJmd0OyBzaW1wbHkgYWR2ZXJ0aXNlIHRoZSBhbGlhcyBpbiBhIHRyYW5zcG9ydCBwYXJhbWV0 ZXIuIEEgY2xpZW50IHRoYXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdW5kZXJzdGFuZHMgdGhpcyB0 cmFuc3BvcnQgcGFyYW1ldGVyIGNvdWxkIHVzZSBpdCwgb3RoZXJzIHdvdWxkIG5vdC4gPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgV2h5IGRvZXMgdGhlIHNlcnZlciBuZWVkIHRvIGtub3cgdGhhdCB0aGUg Y2xpZW50IHVuZGVyc3RhbmRzIGFuZCB3aWxsIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHVzZSB0aGUg bmV3IGFsaWFzPyBUaGVyZSBuZWVkIG5vdCBiZSBhIHJlcXVpcmVtZW50IG9uIGEgY2xpZW50IHRv IGRvIGl0Li4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGVyZSBzZWVtcyB0byBi ZSByZWFzb25hYmxlIGFtb3VudHMgb2YgZGVtYW5kIGZvciBhIG5ldyBmcmFtZSwgd2hpY2ggd291 bGQgcmVxdWlyZSB0aGF0IHRoZSBjbGllbnQgc2lnbmFsIHRoYXQgaXQgaXMgd2lsbGluZyB0byBh Y2NlcHQgb25lLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFncmVlZC4gVGhvdWdoIGFzc3VtaW5n IHRoYXQgd2UnZCB1c2UgYSBmcmFtZSBmb3Igc2VuZGluZyB2ZXJzaW9uIDxicj4NCiZndDsgYWxp YXNlcywgdGhlIHRyYWRlLW9mZiBpcyBiZXR3ZWVuOiA8YnI+DQomZ3Q7ICogYSkgZGVmaW5lIHRo ZSBmcmFtZSBpbiB2MSA8YnI+DQomZ3Q7ICogYikgZGVmaW5lIGFuIGV4dGVuc2lvbiwgdGhhdCBz dWdnZXN0cyBhIGNsaWVudCB0byB1c2UgYSBUUCB0byBzaWduYWwgPGJyPg0KJmd0OyBpdCdzIHN1 cHBvcnQgZm9yIHRoZSBleHRlbnNpb24gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHdoZXJlLCBhIGhh cyB0aGUgKHBvdGVudGlhbCkgcmlzayBvZiBkZWxheWluZyB0aGUgc3RhbmRhcmRpemF0aW9uIDxi cj4NCiZndDsgcHJvY2VzcywgYiBoYXMgdGhlIHJpc2sgb2YgbWlkZGxlYm94ZXMgZGV0ZWN0aW5n IGFuZCBkcm9wcGluZyA8YnI+DQomZ3Q7IGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCBhdHRlbXB0 cyB1c2luZyB0aGUgZXh0ZW5zaW9uLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBkbyBub3QgdGhp bmsgdGhlIGRvd25zaWRlIG9mIGIgaXMgdGhhdCBpbXBvcnRhbnQgKGJlY2F1c2UgYSA8YnI+DQom Z3Q7IG1pZGRsZWJveCBjYW4gc2ltcGx5IGJsb2NrIGFsbCB0aGUgUVVJQyBjb25uZWN0aW9ucyks IGJ1dCB0aGUgcmlzayBpbiA8YnI+DQomZ3Q7IGEgaXMgYWxzbyBzbWFsbC4gQWxsIGluIGFsbCwg SSB0aGluayBhdm9pZGluZyBoYXZpbmcgYW4gZXh0ZW5zaW9uIHRoYXQgPGJyPg0KJmd0OyBjaGFu Z2VzIHRoZSBiZWhhdmlvciBvZiBRVUlDIHN0YWNrcyBvdXR3ZWlnaHMgdGhlIHJpc2tzLiA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgQW5kIEZXSVcsIEkgcHJlZmVyIGV4dGVuZGluZyB0aGUgdG9rZW4g Zm9yIGNhcnJ5aW5nIHRoZSB2ZXJzaW9uIGFsaWFzIDxicj4NCiZndDsgYXMgTVQgc3VnZ2VzdHMu IEJlY2F1c2UgdGhhdCB3b3VsZCBhbGxvdyB0aGUgc2VydmVyIHRvIGRlY2lwaGVyIHRoZSA8YnI+ DQomZ3Q7IGNvcnJlY3QgdmVyc2lvbiBudW1iZXIgZnJvbSB0aGUgY29udGVudHMgb2YgdGhlIHRv a2VuLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyBLYXp1aG8gT2t1IDxicj4N CiZndDsgPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KS2F6dWhvIE9rdSA8YnI+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB6PR10MB1766EE0620E3C5FD4AA67BBEAC2E0DB6PR10MB1766EURP_-- From nobody Tue Apr 9 21:38:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9F31200FB for ; Tue, 9 Apr 2019 21:38: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=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 RlHumfVr3NHP for ; Tue, 9 Apr 2019 21:38:32 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D047A12002E for ; Tue, 9 Apr 2019 21:38:31 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id g7so667700lfh.10 for ; Tue, 09 Apr 2019 21:38:31 -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=5YZgNHikHGcDRk152e+3Lr90O44P7gw9/qBQrlfgRO0=; b=uB6YZdfjxy7UWK1DZdOVJYZ6Mmr/dgaXQysE3JOuJ+CJh3maiIMBOQsBCukpUon0Cc u0dueC6wlMfHHqWsDZijnVnnLs1cWJIqvfdc0geep+34UiX8Ity366vTHHKLtMq3sEbw mdvHfCR+D3se/PzPDlVD4oYt8t9I9CLldVs6/gWK/zfjDGW50luwvAvDfwgdxTvHq3uo K3N09qrhRtZ086yZlQqCebziszAC/hUTurUPH33Ky6DwalZNbt/O4eLL7iEFfkPt5K6h rbR3lI7wAE8FukO6OTj5SkiSQqf45QCb7FHgfhEE3oDcmvpLCXzT9Ln6HG95UYvobZ7+ 0aYA== 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=5YZgNHikHGcDRk152e+3Lr90O44P7gw9/qBQrlfgRO0=; b=fN+h82xUYw+5BqNT/FTuzghRdmrL7QjdTdBYyJV+5wd4Jb54kZGrml5yI3FtNAw3Jw k8EbRJjWK7883Yn+mfWVh2qLtYSUJ+gg1fir40qM0x3eznxfbzizOyGOQw2QDMcQ2iPy o/Kkxj3C9Kbghe6c6AAf0TjEHoVKhzgM5nOiuLPbpr+YbnuMxBCFok8bwqZqv5GTbksO awy9V+ZLQGAnUhTyE9z1iDXuOYvOnCk06qNkeLF3k1GlMwXM9FnUJn3mYwYSoG3OMFLG Kl24iwlvRiwH3wrHMORdwRhieFqXUbEyER3P4RzIl8l/GvKaRPOhc31gxZLc/WHRbCG9 nP+g== X-Gm-Message-State: APjAAAXXsc/uunfEF1HdWqtpxBvCtoPmTx3zecpDPJk7gr5Xrupk7Qy8 800t84VMsC7le8SiNia1lB2bDn5i4aKe+aeqGW4= X-Google-Smtp-Source: APXvYqw+ttGIl/aKjOjokGUB3y2xWatq+EgwnFcmD0imHQ/NbdyjPirwKxnG75DE7X4nO57T2+nOxgD9EzxVw2Vy3cY= X-Received: by 2002:ac2:420b:: with SMTP id y11mr22401328lfh.104.1554871110079; Tue, 09 Apr 2019 21:38:30 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.com> In-Reply-To: From: Kazuho Oku Date: Wed, 10 Apr 2019 13:38:18 +0900 Message-ID: Subject: Re: Version Negotiation Greasing To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 04:38:34 -0000 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 13:34 Mikkel Fahn=C3=B8e J=C3= =B8rgensen : > > Fair points. What if the connection goes down between new token and new v= ersion alias? Yeah. That's why I like MT's proposal to send a version alias as part of a token. > Is the token usable in its own? My understanding is that version alias is proposed as an option, and nobody is arguing against that. Assuming that is true, a token would always be usable by its own. > > > ________________________________ > Fra: Kazuho Oku > Sendt: onsdag, april 10, 2019 6:30 AM > Til: Mikkel Fahn=C3=B8e J=C3=B8rgensen > Cc: Martin Thomson; IETF QUIC WG > Emne: Re: Version Negotiation Greasing > > 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 13:13 Mikkel Fahn=C3=B8e J= =C3=B8rgensen : > > > > Why not just dump the version+salt in TP as Jana suggests? > > I think Two reasons have been pointed out so far: > * Sending in TP reduces the amount of things a server can send in the > first flight (we are trying hard to fit the certificate chain in 3 > packets; pointed out by Marten). > * Binding aliases to token let's servers issue different aliases for > each connection. Sending the aliases in TP would imply that they can > be used without a matching token. In such a design, it is impossible > to have different aliases for every connection (pointed out by MT). > > > A new frame was argued vs modifying another frame, but if you can do it= all in TP, that is a void argument. Signalling in TP sounds over-complicat= ed. Unlike NEW_TOKEN, you don=E2=80=99t have to wait for TLS to emit someth= ing. > > > > > > ________________________________ > > Fra: QUIC p=C3=A5 vegne af Kazuho Oku > > Sendt: onsdag, april 10, 2019 5:16 AM > > Til: Martin Thomson > > Cc: IETF QUIC WG > > Emne: Re: Version Negotiation Greasing > > > > 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 11:35 Martin Thomson : > > > > > > On Wed, Apr 10, 2019, at 05:09, Jana Iyengar wrote: > > > > Hm, perhaps I'm missing something. As an extension, the server woul= d > > > > simply advertise the alias in a transport parameter. A client that > > > > understands this transport parameter could use it, others would not= . > > > > Why does the server need to know that the client understands and wi= ll > > > > use the new alias? There need not be a requirement on a client to d= o it.. > > > > > > There seems to be reasonable amounts of demand for a new frame, which= would require that the client signal that it is willing to accept one. > > > > Agreed. Though assuming that we'd use a frame for sending version > > aliases, the trade-off is between: > > * a) define the frame in v1 > > * b) define an extension, that suggests a client to use a TP to signal > > it's support for the extension > > > > where, a has the (potential) risk of delaying the standardization > > process, b has the risk of middleboxes detecting and dropping > > connection establishment attempts using the extension. > > > > I do not think the downside of b is that important (because a > > middlebox can simply block all the QUIC connections), but the risk in > > a is also small. All in all, I think avoiding having an extension that > > changes the behavior of QUIC stacks outweighs the risks. > > > > And FWIW, I prefer extending the token for carrying the version alias > > as MT suggests. Because that would allow the server to decipher the > > correct version number from the contents of the token. > > > > -- > > Kazuho Oku > > > > > -- > Kazuho Oku --=20 Kazuho Oku From nobody Tue Apr 9 22:21:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1FB12015B for ; Tue, 9 Apr 2019 22:21:05 -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 U2H-ekFvsVjO for ; Tue, 9 Apr 2019 22:21:03 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6776120155 for ; Tue, 9 Apr 2019 22:21:02 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id c4so985359ioh.9 for ; Tue, 09 Apr 2019 22:21: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=txjpK7RLORhg4IJfZ60lADtKpA+FIzbk4R49oTjW17I=; b=arHWJBI1hOa1nITqnbS5tTEBUIjrcN+aiFlVAFjZi7JKNlvRmrq08TS0yULVEXWLHD XUJPM5WiiRiIdk/BHMLfDUBYg02ff/u17O1XatTf7Jl14lrTsgrbMFiO+XgK6NsgI3dt In38aduIlxRXFpDutfDmBksjX9iUqnabnd7igvMkSkpHCjR7kCS/4d6Yc3ENCH5fIJKk 9JrBrhOIJ2qmkd9I469gGcyvlCe2FmaQD1xru6NEhlusSqmjrft+NU52nhTB2N8l4hhh e1RwwO9blNA/uYOFvIUQKqv6/EoBSZ03YXmFpsmwZChmZbV/E4uCttPh2qHWxfQ3izmb beog== 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=txjpK7RLORhg4IJfZ60lADtKpA+FIzbk4R49oTjW17I=; b=RKPKPg+Gqw3mhf6dD5xxcXlFDfpxZ2WIeRb2N1pMyeLwHgxh+qkY2CoWRsiM8YxXtN EEVQM3lo7DO6dV0bhuIyi3YayygorlCJ/CJ8sFR/UT7wFhu4VWwcUPlGzyjtybEGr+AL A84jPE4g3WJaKuCEOgVlzPUt380hKTIrk3Dl4ueePj6uditOlGrB+kWzK7jHF21+4EQK +1uHpbKJ9iFt2kCBcBpDRjEcy/3GXcCqajla7P5iOsr1p86mCPghMOzAc+qIT2G+wE7f 7p7jIO/0HseWZiSPDB/rPZ2PwHBlr3VdoFBjeaT6LoJIYulr2j4o6kYmyRVj1jw5ybVv UiTA== X-Gm-Message-State: APjAAAUxq8ywgPDW/6koKBWEDpHtaDfAKlTYsEdWUzb0LUAuax4e+uAu RyavirDMhUEzELoskpLPuYjYRqEQRr/+6k/9pHc= X-Google-Smtp-Source: APXvYqyt3KFa1LZ6I66aUC4S2oeWiGG+xpcMeX/BeUgy3pE9ygTDZFnwnPn7MTHCEldKtAqyHUIKnqNxGXyK8La+v3g= X-Received: by 2002:a5d:8902:: with SMTP id b2mr26548476ion.267.1554873662204; Tue, 09 Apr 2019 22:21:02 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Apr 2019 22:21:01 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 9 Apr 2019 22:21:01 -0700 Message-ID: Subject: Re: Version Negotiation Greasing To: Kazuho Oku Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004e70430586263c6b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 05:21:05 -0000 --0000000000004e70430586263c6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is an argument floating that iff a client accepts the alias extension, the alias must be used without the client attempting fallback to the original version. I=E2=80=99m not entirely sure what I think about this. It discourages middl= eboxes from blocking anything but v1 but if a server park is not able to honor it, or the client looses context, there is a problem. This problem can be solved by tying the context to the token. But this means the token cannot be used without the alias version. This in turn means that the token cannot be valid until the alias has also been received. This in turn introduces race conditions that could have been avoided if the alias were in the same frame as the token, or at least in the same packet (which is a complication). Mikkel On 10 April 2019 at 06.38.30, Kazuho Oku (kazuhooku@gmail.com) wrote: 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 13:34 Mikkel Fahn=C3=B8e J=C3= =B8rgensen : > > Fair points. What if the connection goes down between new token and new version alias? Yeah. That's why I like MT's proposal to send a version alias as part of a token. > Is the token usable in its own? My understanding is that version alias is proposed as an option, and nobody is arguing against that. Assuming that is true, a token would always be usable by its own. > > > ________________________________ > Fra: Kazuho Oku > Sendt: onsdag, april 10, 2019 6:30 AM > Til: Mikkel Fahn=C3=B8e J=C3=B8rgensen > Cc: Martin Thomson; IETF QUIC WG > Emne: Re: Version Negotiation Greasing > > 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 13:13 Mikkel Fahn=C3=B8e J= =C3=B8rgensen : > > > > Why not just dump the version+salt in TP as Jana suggests? > > I think Two reasons have been pointed out so far: > * Sending in TP reduces the amount of things a server can send in the > first flight (we are trying hard to fit the certificate chain in 3 > packets; pointed out by Marten). > * Binding aliases to token let's servers issue different aliases for > each connection. Sending the aliases in TP would imply that they can > be used without a matching token. In such a design, it is impossible > to have different aliases for every connection (pointed out by MT). > > > A new frame was argued vs modifying another frame, but if you can do it all in TP, that is a void argument. Signalling in TP sounds over-complicated. Unlike NEW_TOKEN, you don=E2=80=99t have to wait for TLS = to emit something. > > > > > > ________________________________ > > Fra: QUIC p=C3=A5 vegne af Kazuho Oku < kazuhooku@gmail.com> > > Sendt: onsdag, april 10, 2019 5:16 AM > > Til: Martin Thomson > > Cc: IETF QUIC WG > > Emne: Re: Version Negotiation Greasing > > > > 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 11:35 Martin Thomson : > > > > > > On Wed, Apr 10, 2019, at 05:09, Jana Iyengar wrote: > > > > Hm, perhaps I'm missing something. As an extension, the server would > > > > simply advertise the alias in a transport parameter. A client that > > > > understands this transport parameter could use it, others would not. > > > > Why does the server need to know that the client understands and will > > > > use the new alias? There need not be a requirement on a client to do it.. > > > > > > There seems to be reasonable amounts of demand for a new frame, which would require that the client signal that it is willing to accept one. > > > > Agreed. Though assuming that we'd use a frame for sending version > > aliases, the trade-off is between: > > * a) define the frame in v1 > > * b) define an extension, that suggests a client to use a TP to signal > > it's support for the extension > > > > where, a has the (potential) risk of delaying the standardization > > process, b has the risk of middleboxes detecting and dropping > > connection establishment attempts using the extension. > > > > I do not think the downside of b is that important (because a > > middlebox can simply block all the QUIC connections), but the risk in > > a is also small. All in all, I think avoiding having an extension that > > changes the behavior of QUIC stacks outweighs the risks. > > > > And FWIW, I prefer extending the token for carrying the version alias > > as MT suggests. Because that would allow the server to decipher the > > correct version number from the contents of the token. > > > > -- > > Kazuho Oku > > > > > -- > Kazuho Oku --=20 Kazuho Oku --0000000000004e70430586263c6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = There is an argument= floating that iff a client accepts the alias extension, the alias must be = used without the client attempting fallback to the original version.
<= 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">
I=E2=80=99m not entirely = sure what I think about this. It discourages middleboxes from blocking anyt= hing but v1 but if a server park is not able to honor it, or the client loo= ses context, there is a problem. This problem can be solved by tying the co= ntext to the token. But this means the token cannot be used without the ali= as version. This in turn means that the token cannot be valid until the ali= as has also been received. This =C2=A0in turn introduces race conditions th= at could have been avoided if the alias were in the same frame as the token= , or at least in the same packet (which is a complication).

Mikkel

On 10 April 2019 at 06.38.30, Kazuho Oku (kazuhooku@gmail.com) wrote:

2019=E5=B9=B44=E6=9C=8810=E6=97= =A5(=E6=B0=B4) 13:34 Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>:
>
> Fair points. What if the connection goes down between new token an= d new version alias?

Yeah. That's why I like MT's proposal to send a version alias a= s part
of a token.

> Is the token usable in its own?

My understanding is that version alias is proposed as an option, and
nobody is arguing against that. Assuming that is true, a token would
always be usable by its own.

>
>
> ________________________________
> Fra: Kazuho Oku <kazuhoo= ku@gmail.com>
> Sendt: onsdag, april 10, 2019 6:30 AM
> Til: Mikkel Fahn=C3=B8e J=C3=B8rgensen
> Cc: Martin Thomson; IETF QUIC WG
> Emne: Re: Version Negotiation Greasing
>
> 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 13:13 Mikkel Fahn=C3= =B8e J=C3=B8rgensen <mikkelfj@gmai= l.com>:
> >
> > Why not just dump the version+salt in TP as Jana suggests?
>
> I think Two reasons have been pointed out so far:
> * Sending in TP reduces the amount of things a server can send in = the
> first flight (we are trying hard to fit the certificate chain in 3
> packets; pointed out by Marten).
> * Binding aliases to token let's servers issue different alias= es for
> each connection. Sending the aliases in TP would imply that they c= an
> be used without a matching token. In such a design, it is impossib= le
> to have different aliases for every connection (pointed out by MT)= .
>
> > A new frame was argued vs modifying another frame, but if you= can do it all in TP, that is a void argument. Signalling in TP sounds over= -complicated. Unlike NEW_TOKEN, you don=E2=80=99t have to wait for TLS to e= mit something.
> >
> >
> > ________________________________
> > Fra: QUIC <quic-b= ounces@ietf.org> p=C3=A5 vegne af Kazuho Oku <kazuhooku@gmail.com>
> > Sendt: onsdag, april 10, 2019 5:16 AM
> > Til: Martin Thomson
> > Cc: IETF QUIC WG
> > Emne: Re: Version Negotiation Greasing
> >
> > 2019=E5=B9=B44=E6=9C=8810=E6=97=A5(=E6=B0=B4) 11:35 Martin Th= omson <mt@lowentropy.net>:
> > >
> > > On Wed, Apr 10, 2019, at 05:09, Jana Iyengar wrote:
> > > > Hm, perhaps I'm missing something. As an extens= ion, the server would
> > > > simply advertise the alias in a transport parameter= . A client that
> > > > understands this transport parameter could use it, = others would not.
> > > > Why does the server need to know that the client un= derstands and will
> > > > use the new alias? There need not be a requirement = on a client to do it..
> > >
> > > There seems to be reasonable amounts of demand for a new= frame, which would require that the client signal that it is willing to ac= cept one.
> >
> > Agreed. Though assuming that we'd use a frame for sending= version
> > aliases, the trade-off is between:
> > * a) define the frame in v1
> > * b) define an extension, that suggests a client to use a TP = to signal
> > it's support for the extension
> >
> > where, a has the (potential) risk of delaying the standardiza= tion
> > process, b has the risk of middleboxes detecting and dropping
> > connection establishment attempts using the extension.
> >
> > I do not think the downside of b is that important (because a
> > middlebox can simply block all the QUIC connections), but the= risk in
> > a is also small. All in all, I think avoiding having an exten= sion that
> > changes the behavior of QUIC stacks outweighs the risks.
> >
> > And FWIW, I prefer extending the token for carrying the versi= on alias
> > as MT suggests. Because that would allow the server to deciph= er the
> > correct version number from the contents of the token.
> >
> > --
> > Kazuho Oku
> >
>
>
> --
> Kazuho Oku



-- =20
Kazuho Oku
--0000000000004e70430586263c6b-- From nobody Wed Apr 10 01:48:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1C91201B2 for ; Wed, 10 Apr 2019 01:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaRsAIz83ira for ; Wed, 10 Apr 2019 01:48:30 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 58F7A1202BB for ; Wed, 10 Apr 2019 01:48:30 -0700 (PDT) Received: from G-MacBook.local (unknown [152.71.207.141]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 84DC61B002A1 for ; Wed, 10 Apr 2019 09:48:27 +0100 (BST) Message-ID: <5CADADDD.7010005@erg.abdn.ac.uk> Date: Wed, 10 Apr 2019 09:48:29 +0100 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: quic@ietf.org Subject: Is "Version Greasing" a new benfit or a new obstacle? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 08:48:33 -0000 Obscuring the version of a protocol seems like a major design design decision for wider use cases. So, I'm trying to understand the motivation for version greasing. (1) I know there were instances where some early versions of QUIC were blocked due to an uninitentional matching of the header. Is there evidence of intentional attempts to block updates to protocols? (2) Thinking about operating a network that cares about user support and protection from unwanted traffic, I would expect that there would be cases where traffic pattern anomolies are found and the appropriate thing would be to try to determine if a new protocol had been deployed and monitor it, if not, then the next most obvious thing could be to block all unexpected traffic, that seems like a decision to hide the version could increase ossification for new versions in these cases. (3) Similarly, if a threat is known to impact only a specific (older) version, it would seem to motivate a drop of that traffic that seeks to use that version, while still permitting other traffic. Forcing version detection to use pattern matching/ML will lead to less predictable outcomes, or blocking based on address, etc. (4) This obfusticates the most basic piece of reporting information used for support. It hides the extent of deployment of the current protocol version and prevlance of old implementations. (5) On the support, if a problem only emerges when a particular version is used with a particular address, then this helps pinpoint the issues. Matching client versions to servers is much more of an issue if the user community uses a wide range of servers (less so, I expect for major providers: google, facebook, etc, etc), but significant when there is a use of a diverse set of external sites and sites with their own load balancers, etc and a need to manage interactions with L2 services. I am intersted in knowing if this is likely to benefit or be a new obstacle? Gorry From nobody Wed Apr 10 06:04:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F79120378 for ; Wed, 10 Apr 2019 06:04:37 -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, DKIMWL_WL_HIGH=-0.001, 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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtrUgDn0f2qB for ; Wed, 10 Apr 2019 06:04:34 -0700 (PDT) Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90053.outbound.protection.outlook.com [40.107.9.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD7D1202DB for ; Wed, 10 Apr 2019 06:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6WAp2lIJcC3hF94+iNWk/s0a1GqPcqgDb9bM7jGyk48=; b=d+q0NiFFAAeAXnCJpNbC5lPuHpmuPyLCdMJKDJ4fK9yMTlYH2iyYqrNacZaGVyxAiqa2ExP5tYs8ZC9vWns3H+uyb7TybOcvJvNQrWBPKTwGggMeCssd9IRGGQDxuPZQfC9T1AYGpR9Eq01lCScLDnTJsevhx4TkDYBm7tTte+M= Received: from PR1PR07MB5898.eurprd07.prod.outlook.com (20.177.212.19) by PR1PR07MB5884.eurprd07.prod.outlook.com (20.177.212.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Wed, 10 Apr 2019 13:04:20 +0000 Received: from PR1PR07MB5898.eurprd07.prod.outlook.com ([fe80::9d5b:fab9:4cc2:2f0d]) by PR1PR07MB5898.eurprd07.prod.outlook.com ([fe80::9d5b:fab9:4cc2:2f0d%5]) with mapi id 15.20.1792.009; Wed, 10 Apr 2019 13:04:20 +0000 From: Mirja Kuehlewind To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Kazuho Oku CC: IETF QUIC WG , Martin Thomson Subject: Re: Version Negotiation Greasing Thread-Topic: Version Negotiation Greasing Thread-Index: AQHU7a/hRs5u0XcsyUeTcK1gYCUzN6YzLLAAgAAFEICAAAOxAIAAFYQAgAAFqQCAAAXlAIAAAz4AgADaWQCAAHx5AIAAC4MAgAAQD4CAAATJAIAAAS4AgAAA9ACAAAvvgIAAovmA Date: Wed, 10 Apr 2019 13:04:20 +0000 Message-ID: References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.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=mirja.kuehlewind@ericsson.com; x-originating-ip: [192.176.1.97] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ee5716b6-7da0-4054-5c06-08d6bdb50bcf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:PR1PR07MB5884; x-ms-traffictypediagnostic: PR1PR07MB5884: x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(346002)(136003)(376002)(53754006)(189003)(199004)(81156014)(229853002)(82746002)(8936002)(2906002)(68736007)(14444005)(305945005)(7736002)(6246003)(256004)(93886005)(3846002)(81166006)(446003)(476003)(25786009)(2616005)(11346002)(486006)(8676002)(6116002)(7116003)(4326008)(110136005)(44832011)(86362001)(53936002)(6512007)(6486002)(6436002)(83716004)(186003)(105586002)(33656002)(3480700005)(36756003)(97736004)(26005)(66066001)(76176011)(316002)(106356001)(478600001)(66574012)(4744005)(102836004)(71200400001)(54906003)(71190400001)(14454004)(99286004)(5660300002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:PR1PR07MB5884; H:PR1PR07MB5898.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QTyX1YotZydknbB+Rni6wo2oedWuivRktVR+MHqyGz4+KI8wiwejQaf3zqVRYWKEyMmAghgf27gC1L7nq7ThCD/w4RK7Zp868Hw75/vEzSu5L4OFFAeRXzfAYDhwWiDOkzCLI0rfl8GY3YtQR2yyUg9S6UdETDL5j9wrkV1vKdjznsvkhFLT/LMdIjxHTLRb0zQC+rpFjLhfXY/AgFjnl5sc2RQ8QW//Uvz0pvrnlnqzwXjEsUCHpXmZWd9cHw6iXIGXJRV1zPa8xqwPWHCuWfFb7xbf/C147Uwkbynzf2Wn1b9Tkyrz2ZcRmN3Flw9Mt14SWq0DgIQ7ZKCjepizxxB1Yy5SE+kmmCrsnutw9jsrYKCi4mjiE6NfO0MCG2uuRpqKOUDnYFfsAgKVRvxaob1q1ZvT17XiTFJr9mBT//Q= Content-Type: text/plain; charset="utf-8" Content-ID: <6383D347F008A44B8BF62AD9268AD619@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee5716b6-7da0-4054-5c06-08d6bdb50bcf X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 13:04:20.3352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5884 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 13:04:37 -0000 SEkgYWxsLA0KDQpwbGVhc2Ugc2VlIGJlbG93Lg0KDQrvu79PbiAxMC4wNC4xOSwgMDc6MjIsICJR VUlDIG9uIGJlaGFsZiBvZiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIiA8cXVpYy1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBtaWtrZWxmakBnbWFpbC5jb20+IHdyb3RlOg0KDQogPiAg IFRoZXJlIGlzIGFuIGFyZ3VtZW50IGZsb2F0aW5nIHRoYXQgaWZmIGEgY2xpZW50IGFjY2VwdHMg dGhlIGFsaWFzIGV4dGVuc2lvbiwgdGhlIGFsaWFzIG11c3QgYmUgdXNlZCB3aXRob3V0IHRoZSBj bGllbnQgYXR0ZW1wdGluZyBmYWxsYmFjayB0byB0aGUgb3JpZ2luYWwgdmVyc2lvbi4NCg0KRnVy dGhlciB0aGlua2luZyBhYm91dCB0aGlzLiBJIGRvIHVuZGVyc3RhbmQgdGhhdCB0aGlzIHJlcXVp cmVtZW50IGlzIG5lZWRlZCB0byBhY3R1YWxseSBhdm9pZCBibG9ja2luZyBvZiBhbHQtdmVyc2lv biwgaG93ZXZlciwgd291bGQgYW55Ym9keSBhY3R1YWxseSBiZSBldmVyIHdpbGxpbmcgdG8gaW1w bGVtZW50IHRoaXM/IElmIHlvdSBzZXJ2aWNlIGRvZXMgbm90IGdldCBjb25uZWN0aXZpdHkgd2l0 aCB0aGUgYWx0LXZlcnNpb24sIGlzIGl0IG5vdCB2ZXJ5IHRlbXB0aW5nIHRvIGFsc28gdHJ5IHRo ZSBhY3R1YWwgdmVyc2lvbiBpbiBvcmRlciB0byBzZXJ2ZSB5b3VyIHVzZXIvY3VzdG9tZXIgYXQg YWxsPw0KDQpNaXJqYQ0KDQoNCg0KDQo= From nobody Wed Apr 10 09:53:35 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6088B1203E2 for ; Wed, 10 Apr 2019 09:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.363, 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 (1024-bit key) header.d=fb.com header.b=nwqq/Dp/; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=cn0DxrJH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6DaSREs6VJP for ; Wed, 10 Apr 2019 09:53:31 -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 B60EE1203DE for ; Wed, 10 Apr 2019 09:53:31 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3AGmre7025960; Wed, 10 Apr 2019 09:53:27 -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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=6BB6jOyn2Xb3LKKtnEQ6MW2kvK9rZxZC3C45KXg+qCE=; b=nwqq/Dp/alb3ebsEaBwlre9H4x6EYGM2XIY6ax9MMsQmEZ0jJBC35KLHYKFAD7V9JZaz FZRb9U4Nf7EFLJ1mTyUv8z16WF/sq37Q/2L4PdtJGAfsw6xsRkC7eCVpRYCIN1gpzSYE 5tTKAajY/EYrCXNhvQv5+KWgH9S4ClGWfAU= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2rsm5tgcbd-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 Apr 2019 09:53:26 -0700 Received: from frc-mbx05.TheFacebook.com (2620:10d:c0a1:f82::29) by frc-hub03.TheFacebook.com (2620:10d:c021:18::173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 10 Apr 2019 09:51:41 -0700 Received: from frc-hub04.TheFacebook.com (2620:10d:c021:18::174) by frc-mbx05.TheFacebook.com (2620:10d:c0a1:f82::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 10 Apr 2019 09:51:41 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5 via Frontend Transport; Wed, 10 Apr 2019 09:51:41 -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:X-MS-Exchange-SenderADCheck; bh=6BB6jOyn2Xb3LKKtnEQ6MW2kvK9rZxZC3C45KXg+qCE=; b=cn0DxrJHeomqLaeFy5AGRnbg459d9WOQed68pqd6YOgaKxMXDdZ2lgb3pXbPsR0KpUtA7+isFnhknlc/FGsQxq0pKwO+vXLPkiohvuYl5DU/slB+YAB718gG1KY06z+TuMVNXfvSr3s7HOe+Uwkeb70QddnTpF4iO2365g0eG68= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB3429.namprd15.prod.outlook.com (20.179.59.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15; Wed, 10 Apr 2019 16:51:39 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7%2]) with mapi id 15.20.1771.021; Wed, 10 Apr 2019 16:51:39 +0000 From: Roberto Peon To: G Fairhurst , "quic@ietf.org" Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o3xTufubPn9E2URSuto2uLa6Y1JwYA Date: Wed, 10 Apr 2019 16:51:39 +0000 Message-ID: References: <5CADADDD.7010005@erg.abdn.ac.uk> In-Reply-To: <5CADADDD.7010005@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 x-originating-ip: [2620:10d:c090:200::1ab6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cef81c3a-1439-4e6f-8c8e-08d6bdd4cd9f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR15MB3429; x-ms-traffictypediagnostic: BYAPR15MB3429: x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(366004)(376002)(396003)(346002)(199004)(189003)(256004)(478600001)(71190400001)(81166006)(2906002)(71200400001)(229853002)(14454004)(25786009)(14444005)(86362001)(5660300002)(97736004)(83716004)(106356001)(105586002)(53936002)(186003)(82746002)(7736002)(446003)(46003)(6436002)(486006)(6116002)(33656002)(6246003)(2501003)(6512007)(305945005)(6486002)(68736007)(110136005)(296002)(102836004)(8936002)(36756003)(316002)(58126008)(2616005)(81156014)(6506007)(8676002)(76176011)(99286004)(476003)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB3429; H:BYAPR15MB2312.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ABVgVx8Zc8HkyQtE8PejowdhQIYcTr0Y5yBoKlMhFMAxDcjpYsoRL6XERkzRG2RsBKVCp5yYt35TNl1niRnuFjr8K8EVIsGagoe3FdvzYWmH1OVnAwWdoX45qZ8Uk2FQBu94EmabijM5XyiiWhBAbBxMnY0ZhtkfMSUQtxljmIfKP+6r+tLdH38LL100m/jkBvBX6Kd6FQZygWVVT5iknIypBoXMz5yZ5b5JW71URhdGqzPOSzPwVca7jJ8SgbE7qMmS6eg0LerHzuiI0qeZ2Xi9k+WVY5rTqkp7HK7Sxmpyl7ITKuoRD4YicRsv7tBSIlvMaQqorN8zpDAIBRFCnw/bQ9YYjxPpiuFcFPDH5mzIRrG8Nis+qQkgy1ngX8PXnDtJtdo/9nBKUeSTe/xgbiw1DY0ECLPajhTRVSGafYg= Content-Type: text/plain; charset="utf-8" Content-ID: <2FD387570BE464428EF8EA46735349E2@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cef81c3a-1439-4e6f-8c8e-08d6bdd4cd9f X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 16:51:39.8054 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3429 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-10_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 16:53:33 -0000 WW91J3JlIGtpbmRhIGJldHdlZW4gYSByb2NrLWFuZC1hLWhhcmQtcGxhY2UgZWl0aGVyIHdheToN Cg0KICAtIFdlJ3ZlIHNlZW4gaG93IG11Y2ggZnVuIG9zc2lmaWNhdGlvbiBpcyBpbiBUQ1AgYW5k IEhUVFAuIElmIHRoZSB0aGluZyBpcyBvYnNlcnZhYmxlLCBpdCB3aWxsIGJlIG9zc2lmaWVkIHNl ZW1zIHRvIGJlIHRoZSBsZXNzb24uIEEgbG90IG9mIHRoZSByZWFzb24gd2h5IFFVSUMgd2FzIHN0 YXJ0ZWQgaW4gdGhlIGZpcnN0IHBsYWNlIHdhcyBiZWNhdXNlIG9mIHRoZSBpbmFiaWxpdHkgdG8g aW1wcm92ZSBUQ1AgZHVlIHRvIHRoaXMgb3NzaWZpY2F0aW9uLg0KICAtIE9UT0gsIHRoZXJlIGlz IHRoZSBmZWFyIG9mIHVua25vd24vdW5vYnNlcnZhYmxlIHdoaWNoIG1pZ2h0IGNhdXNlIG9wZXJh dG9ycyB0byBibG9jayB0aGluZ3MsIHdoZXRoZXIgcHJlZGljdGFibHkgb3Igbm90Lg0KDQpNeSBv cGluaW9uIGlzIHRoYXQgaXQgaXMgYmV0dGVyIHRvIHN0YXJ0IHdpdGggcHJldmVudGluZyBvc3Np ZmljYXRpb24sIGFuZCB0aGVuIGlmIHRoYXQgcmVzdWx0cyBpbiB0b28gbGFyZ2UgYSBwZXJjZW50 YWdlIG9mIG9wZXJhdG9ycyBibG9ja2luZyB0aGluZ3MsIHRvIHJlLWV2YWx1YXRlLiANCg0KTXkg Z3Vlc3NlczoNCklQK3BvcnQgdHVwbGVzIGFuZCB0cmFmZmljIHBhdHRlcm5zIGFyZSBzdGlsbCBv YnNlcnZhYmxlIChmb3IgYmV0dGVyIGFuZCB3b3JzZSksIHdoaWNoIGltcGxpZXMgb3BlcmF0b3Jz IHdpbGwgc3RpbGwgaGF2ZSBzaWduaWZpY2FudCB0b29scyBmb3IgbWFuYWdpbmcgdHJhZmZpYy4g SSBiZWxpZXZlIHRoYXQgdGhlc2UgYXJlIGFjdGVkIG9uL21hdGNoZWQgKE1MIG9yIG5vdCkgcmVn YXJkbGVzcyBvZiBhbnkgb3RoZXIgZGF0YSBwcmVzZW50ZWQuIEluIG90aGVyIHdvcmRzLCBJIGhh dmUgYSBkb3VidCB0aGF0IHN0YXRpbmcgdGhlIHZlcnNpb24gaW4gYW4gb2JzZXJ2YWJsZSB3YXkg d2lsbCBwcmV2ZW50IHRoZSB1c2Ugb2Ygc3VjaCB0b29scy4NCg0KTW9zdCBwcm9ibGVtcyBJJ3Zl IHNlZW4gYXNzb2NpYXRlZCB3aXRoIGltcGxlbWVudGF0aW9ucyByYXRoZXIgdGhhbiBwcm90b2Nv bCB2ZXJzaW9ucyAodGhvdWdoIHdoZW4gdGhlIGxhdHRlciBoYXBwZW5zIGl0IGlzIHByZXR0eSBz ZXZlcmUpLiBJZiB5b3UgYmVsaWV2ZSB0aGlzIGFzc2VydGlvbiwgdGhlbiBhY3Rpbmcgb24gcHJv dG9jb2wgdmVyc2lvbiBpcyBsZXNzIGludGVyZXN0aW5nIHRoYW4gYXR0ZW1wdGluZyB0byBhY3Qg YmFzZWQgb24gaW1wbGVtZW50YXRpb24gZmluZ2VycHJpbnRzLg0KLT1SDQoNCg0K77u/T24gNC8x MC8xOSwgMTo0OCBBTSwgIlFVSUMgb24gYmVoYWxmIG9mIEcgRmFpcmh1cnN0IiA8cXVpYy1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBnb3JyeUBlcmcuYWJkbi5hYy51az4gd3JvdGU6DQoN CiAgICBPYnNjdXJpbmcgdGhlIHZlcnNpb24gb2YgYSBwcm90b2NvbCBzZWVtcyBsaWtlIGEgbWFq b3IgZGVzaWduIGRlc2lnbiANCiAgICBkZWNpc2lvbiBmb3Igd2lkZXIgdXNlIGNhc2VzLiBTbywg SSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSANCiAgICBtb3RpdmF0aW9uIGZvciB2ZXJzaW9u IGdyZWFzaW5nLg0KICAgIA0KICAgICgxKSBJIGtub3cgdGhlcmUgd2VyZSBpbnN0YW5jZXMgd2hl cmUgc29tZSBlYXJseSB2ZXJzaW9ucyBvZiBRVUlDIHdlcmUgDQogICAgYmxvY2tlZCBkdWUgdG8g YW4gdW5pbml0ZW50aW9uYWwgbWF0Y2hpbmcgb2YgdGhlIGhlYWRlci4gSXMgdGhlcmUgDQogICAg ZXZpZGVuY2Ugb2YgaW50ZW50aW9uYWwgYXR0ZW1wdHMgdG8gYmxvY2sgdXBkYXRlcyB0byBwcm90 b2NvbHM/DQogICAgDQogICAgKDIpIFRoaW5raW5nIGFib3V0IG9wZXJhdGluZyBhIG5ldHdvcmsg dGhhdCBjYXJlcyBhYm91dCB1c2VyIHN1cHBvcnQgYW5kIA0KICAgIHByb3RlY3Rpb24gZnJvbSB1 bndhbnRlZCB0cmFmZmljLCBJIHdvdWxkIGV4cGVjdCB0aGF0IHRoZXJlIHdvdWxkIGJlIA0KICAg IGNhc2VzIHdoZXJlIHRyYWZmaWMgcGF0dGVybiBhbm9tb2xpZXMgYXJlIGZvdW5kIGFuZCB0aGUg YXBwcm9wcmlhdGUgDQogICAgdGhpbmcgd291bGQgYmUgdG8gdHJ5IHRvIGRldGVybWluZSBpZiBh IG5ldyBwcm90b2NvbCBoYWQgYmVlbiBkZXBsb3llZCANCiAgICBhbmQgbW9uaXRvciBpdCwgaWYg bm90LCB0aGVuIHRoZSBuZXh0IG1vc3Qgb2J2aW91cyB0aGluZyBjb3VsZCBiZSB0byANCiAgICBi bG9jayBhbGwgdW5leHBlY3RlZCB0cmFmZmljLCB0aGF0IHNlZW1zIGxpa2UgYSBkZWNpc2lvbiB0 byBoaWRlIHRoZSANCiAgICB2ZXJzaW9uIGNvdWxkIGluY3JlYXNlIG9zc2lmaWNhdGlvbiBmb3Ig bmV3IHZlcnNpb25zIGluIHRoZXNlIGNhc2VzLg0KICAgIA0KICAgICgzKSBTaW1pbGFybHksIGlm IGEgdGhyZWF0IGlzIGtub3duIHRvIGltcGFjdCBvbmx5IGEgc3BlY2lmaWMgKG9sZGVyKSANCiAg ICB2ZXJzaW9uLCBpdCB3b3VsZCBzZWVtIHRvIG1vdGl2YXRlIGEgZHJvcCBvZiB0aGF0IHRyYWZm aWMgdGhhdCBzZWVrcyB0byANCiAgICB1c2UgdGhhdCB2ZXJzaW9uLCB3aGlsZSBzdGlsbCBwZXJt aXR0aW5nIG90aGVyIHRyYWZmaWMuIEZvcmNpbmcgdmVyc2lvbiANCiAgICBkZXRlY3Rpb24gdG8g dXNlIHBhdHRlcm4gbWF0Y2hpbmcvTUwgd2lsbCBsZWFkIHRvIGxlc3MgcHJlZGljdGFibGUgDQog ICAgb3V0Y29tZXMsIG9yIGJsb2NraW5nIGJhc2VkIG9uIGFkZHJlc3MsIGV0Yy4NCiAgICANCiAg ICAoNCkgVGhpcyBvYmZ1c3RpY2F0ZXMgdGhlIG1vc3QgYmFzaWMgcGllY2Ugb2YgcmVwb3J0aW5n IGluZm9ybWF0aW9uIHVzZWQgDQogICAgZm9yIHN1cHBvcnQuIEl0IGhpZGVzIHRoZSBleHRlbnQg b2YgZGVwbG95bWVudCBvZiB0aGUgY3VycmVudCBwcm90b2NvbCANCiAgICB2ZXJzaW9uIGFuZCBw cmV2bGFuY2Ugb2Ygb2xkIGltcGxlbWVudGF0aW9ucy4NCiAgICANCiAgICAoNSkgT24gdGhlIHN1 cHBvcnQsIGlmIGEgcHJvYmxlbSBvbmx5IGVtZXJnZXMgd2hlbiBhIHBhcnRpY3VsYXIgdmVyc2lv biANCiAgICBpcyB1c2VkIHdpdGggYSBwYXJ0aWN1bGFyIGFkZHJlc3MsIHRoZW4gdGhpcyBoZWxw cyBwaW5wb2ludCB0aGUgaXNzdWVzLiANCiAgICBNYXRjaGluZyBjbGllbnQgdmVyc2lvbnMgdG8g c2VydmVycyBpcyBtdWNoIG1vcmUgb2YgYW4gaXNzdWUgaWYgdGhlIHVzZXIgDQogICAgY29tbXVu aXR5IHVzZXMgYSB3aWRlIHJhbmdlIG9mIHNlcnZlcnMgKGxlc3Mgc28sIEkgZXhwZWN0IGZvciBt YWpvciANCiAgICBwcm92aWRlcnM6IGdvb2dsZSwgZmFjZWJvb2ssIGV0YywgZXRjKSwgYnV0IHNp Z25pZmljYW50IHdoZW4gdGhlcmUgaXMgYSANCiAgICB1c2Ugb2YgYSBkaXZlcnNlIHNldCBvZiBl eHRlcm5hbCBzaXRlcyBhbmQgc2l0ZXMgd2l0aCB0aGVpciBvd24gbG9hZCANCiAgICBiYWxhbmNl cnMsIGV0YyBhbmQgYSBuZWVkIHRvIG1hbmFnZSBpbnRlcmFjdGlvbnMgd2l0aCBMMiBzZXJ2aWNl cy4NCiAgICANCiAgICBJIGFtIGludGVyc3RlZCBpbiBrbm93aW5nIGlmIHRoaXMgaXMgbGlrZWx5 IHRvIGJlbmVmaXQgb3IgYmUgYSBuZXcgb2JzdGFjbGU/DQogICAgDQogICAgR29ycnkNCiAgICAN CiAgICANCg0K From nobody Wed Apr 10 09:59:04 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5781203E2 for ; Wed, 10 Apr 2019 09:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.363, 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=hughes.com header.b=N8bsdjBj; dkim=pass (1024-bit key) header.d=hughes.com header.b=LYPongOc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkCKB8Ehnshg for ; Wed, 10 Apr 2019 09:59:00 -0700 (PDT) Received: from mx0a-00115402.pphosted.com (mx0a-00115402.pphosted.com [148.163.150.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 838581203DE for ; Wed, 10 Apr 2019 09:59:00 -0700 (PDT) Received: from pps.filterd (m0118426.ppops.net [127.0.0.1]) by mx0a-00115402.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3AGqHg7023466; Wed, 10 Apr 2019 16:58:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=3152018; bh=9SuBwA7wUpsgNS/foITRCqQ/7j0Ocn8WGKKgRyzaQsc=; b=N8bsdjBj0p3MRp6qaN0AgG3FVLlKOvWIwGZG0pxPFIT1uHPMdCHnEwQdgzNVbWx1RiMn hojbERS2IZO57ulbMjrHXNov4Ix48x1NvCFK069sY89pa/ym2fMiIHRozNEMu3i+7M/0 QEA5KSTNmC76E58BV0O8hsqZojlE32g8TPQLcVtTtrxW0IdRKlT4kdHsraSjlJ8rhpHX igbFdEYcRVzdYbNrIL8ptMm8uSUJ3LEldQ62wRU+C/Fx4I0WRk9jXIEJ0SKSWlH7Uol5 6rba3dDT+JyzqHt077hDwX9ql2mWlFG6VgwIiiPcswXAwM7B0qw9dTFr3cJE+nIg2XJS Xw== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2050.outbound.protection.outlook.com [104.47.38.50]) by mx0a-00115402.pphosted.com with ESMTP id 2rsm1xr5sp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 Apr 2019 16:58:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9SuBwA7wUpsgNS/foITRCqQ/7j0Ocn8WGKKgRyzaQsc=; b=LYPongOcKz5ZK1L6qVHT4YDnV0JXVW68n71Rnj4g5117GgvB/H7ilUBVNUyRi2bNnLy+BHGHYglkGLe+5xzv8gZJwdAfGg4WtGpd0yNNTQzIjhNmsgR+FPR0k/PJ95y3dt57pDbiqMdtB+LXLerKSPejXc+sTv7m6q0MtpFOKtQ= Received: from BL0PR11MB3394.namprd11.prod.outlook.com (10.167.240.87) by BL0PR11MB3346.namprd11.prod.outlook.com (10.167.235.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Wed, 10 Apr 2019 16:58:49 +0000 Received: from BL0PR11MB3394.namprd11.prod.outlook.com ([fe80::4c34:8995:92f3:5e3]) by BL0PR11MB3394.namprd11.prod.outlook.com ([fe80::4c34:8995:92f3:5e3%3]) with mapi id 15.20.1771.016; Wed, 10 Apr 2019 16:58:49 +0000 From: "Border, John" To: Roberto Peon , G Fairhurst , "quic@ietf.org" Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o1HANarzJfIkWJiL5ZcFMTo6Y1nGCAgAABHIA= Date: Wed, 10 Apr 2019 16:58:49 +0000 Message-ID: References: <5CADADDD.7010005@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.85.223.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0775a791-d588-42b8-77fe-08d6bdd5cdc8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BL0PR11MB3346; x-ms-traffictypediagnostic: BL0PR11MB3346: x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(136003)(376002)(366004)(13464003)(199004)(189003)(5024004)(305945005)(14444005)(5660300002)(476003)(52536014)(14454004)(74316002)(229853002)(66066001)(256004)(72206003)(6506007)(6436002)(53546011)(97736004)(86362001)(102836004)(478600001)(25786009)(486006)(6246003)(7696005)(8936002)(33656002)(110136005)(6116002)(99286004)(9686003)(3846002)(55016002)(2906002)(316002)(26005)(8676002)(446003)(11346002)(71190400001)(76176011)(71200400001)(7736002)(105586002)(106356001)(53936002)(186003)(81166006)(81156014)(68736007)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR11MB3346; H:BL0PR11MB3394.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: hughes.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AIkufeRUL93c1bgpp/RP5Q0NEDJCpL0ZNyECIKoIaNzOB11iJRFM311Pqv48qOGQpuuPixZcZQZGX9gKxo1+iod97A/sTf2TbjiG8nOjJKXBf5oJj+wcD+HAZa0tZaj/0+66tBsQKF0tMGtkl+0jSA4k65AYa1Ua7neiU3AGSTilhWlQM0fgyHjVeq0jopVMUZkG4aQxOLLpGE+HAvDgNcdOETvvDmpNpeSsj8D7wDnopViWhGdhc26wu6LKtrK54rO82l+bwRkxP7oNXpN7UZXa/9gwmUSXZdV2/2m2i11ctZ2esmdawnt0WSIeUzOFJrWBUvRVaR7AdKqa9cWMr54WjNaH9F2IpbxrJMko6Yt2wofOsOYvXFvY8EGru376ARimrYPlJCxeNy2qjLtvV4EI9Msfv1eu5W9hs/GBZ7U= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: hughes.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0775a791-d588-42b8-77fe-08d6bdd5cdc8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 16:58:49.6574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0e1f3187-4610-4ce2-bad1-b92f4ba36ab3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3346 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-10_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-1810050000 definitions=main-1904100114 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 16:59:03 -0000 DQpJIHVuZGVyc3RhbmQgd2h5IHBlb3BsZSB3YW50IHRvIGNvbWUgZG93biBvbiB0aGUgc2lkZSBv ZiBwcmV2ZW50aW5nIG9zc2lmaWNhdGlvbi4gIEJ1dCwgdGhpbmdzIGhhdmUgY2hhbmdlZC4gIFRo ZXJlIGFyZSBhIGxvdCBvZiBtb3JlIG5lZ2F0aXZlIGNvbnNlcXVlbmNlcyBub3cgd2hlbiBwZW9w bGUgdW5uZWNlc3NhcmlseSBibG9jayB0aGluZ3MuICBJIHRoaW5rIG9wZXJhdG9ycyB3b3VsZCBw dXQgYSBsb3Qgb2YgcHJlc3N1cmUgb24gdmVuZG9ycyB0byBub3QgZG8gaXQgbm93IGFuZCB0byBm aXggaXQgaWYgdGhleSBkaWQgImJ5IGFjY2lkZW50Ii4gIE9mIGNvdXJzZSwgSSBhbSBvbmx5IG9u ZSBvcGVyYXRvci4gIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGVhciBmcm9tIG90aGVycy4uLg0KDQoN Cg0KSm9obg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIDxxdWlj LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb2JlcnRvIFBlb24NClNlbnQ6IFdlZG5l c2RheSwgQXByaWwgMTAsIDIwMTkgMTI6NTIgUE0NClRvOiBHIEZhaXJodXJzdCA8Z29ycnlAZXJn LmFiZG4uYWMudWs+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogSXMgIlZlcnNpb24gR3Jl YXNpbmciIGEgbmV3IGJlbmZpdCBvciBhIG5ldyBvYnN0YWNsZT8NCg0KV0FSTklORzogVGhlIHNl bmRlciBvZiB0aGlzIGVtYWlsIGNvdWxkIG5vdCBiZSB2YWxpZGF0ZWQgYW5kIG1heSBub3QgbWF0 Y2ggdGhlIHBlcnNvbiBpbiB0aGUgIkZyb20iIGZpZWxkLg0KDQpDQVVUSU9OOiBUaGlzIGVtYWls IG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGlj ayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5k ZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0KDQpZb3UncmUga2luZGEgYmV0d2Vl biBhIHJvY2stYW5kLWEtaGFyZC1wbGFjZSBlaXRoZXIgd2F5Og0KDQogIC0gV2UndmUgc2VlbiBo b3cgbXVjaCBmdW4gb3NzaWZpY2F0aW9uIGlzIGluIFRDUCBhbmQgSFRUUC4gSWYgdGhlIHRoaW5n IGlzIG9ic2VydmFibGUsIGl0IHdpbGwgYmUgb3NzaWZpZWQgc2VlbXMgdG8gYmUgdGhlIGxlc3Nv bi4gQSBsb3Qgb2YgdGhlIHJlYXNvbiB3aHkgUVVJQyB3YXMgc3RhcnRlZCBpbiB0aGUgZmlyc3Qg cGxhY2Ugd2FzIGJlY2F1c2Ugb2YgdGhlIGluYWJpbGl0eSB0byBpbXByb3ZlIFRDUCBkdWUgdG8g dGhpcyBvc3NpZmljYXRpb24uDQogIC0gT1RPSCwgdGhlcmUgaXMgdGhlIGZlYXIgb2YgdW5rbm93 bi91bm9ic2VydmFibGUgd2hpY2ggbWlnaHQgY2F1c2Ugb3BlcmF0b3JzIHRvIGJsb2NrIHRoaW5n cywgd2hldGhlciBwcmVkaWN0YWJseSBvciBub3QuDQoNCk15IG9waW5pb24gaXMgdGhhdCBpdCBp cyBiZXR0ZXIgdG8gc3RhcnQgd2l0aCBwcmV2ZW50aW5nIG9zc2lmaWNhdGlvbiwgYW5kIHRoZW4g aWYgdGhhdCByZXN1bHRzIGluIHRvbyBsYXJnZSBhIHBlcmNlbnRhZ2Ugb2Ygb3BlcmF0b3JzIGJs b2NraW5nIHRoaW5ncywgdG8gcmUtZXZhbHVhdGUuDQoNCk15IGd1ZXNzZXM6DQpJUCtwb3J0IHR1 cGxlcyBhbmQgdHJhZmZpYyBwYXR0ZXJucyBhcmUgc3RpbGwgb2JzZXJ2YWJsZSAoZm9yIGJldHRl ciBhbmQgd29yc2UpLCB3aGljaCBpbXBsaWVzIG9wZXJhdG9ycyB3aWxsIHN0aWxsIGhhdmUgc2ln bmlmaWNhbnQgdG9vbHMgZm9yIG1hbmFnaW5nIHRyYWZmaWMuIEkgYmVsaWV2ZSB0aGF0IHRoZXNl IGFyZSBhY3RlZCBvbi9tYXRjaGVkIChNTCBvciBub3QpIHJlZ2FyZGxlc3Mgb2YgYW55IG90aGVy IGRhdGEgcHJlc2VudGVkLiBJbiBvdGhlciB3b3JkcywgSSBoYXZlIGEgZG91YnQgdGhhdCBzdGF0 aW5nIHRoZSB2ZXJzaW9uIGluIGFuIG9ic2VydmFibGUgd2F5IHdpbGwgcHJldmVudCB0aGUgdXNl IG9mIHN1Y2ggdG9vbHMuDQoNCk1vc3QgcHJvYmxlbXMgSSd2ZSBzZWVuIGFzc29jaWF0ZWQgd2l0 aCBpbXBsZW1lbnRhdGlvbnMgcmF0aGVyIHRoYW4gcHJvdG9jb2wgdmVyc2lvbnMgKHRob3VnaCB3 aGVuIHRoZSBsYXR0ZXIgaGFwcGVucyBpdCBpcyBwcmV0dHkgc2V2ZXJlKS4gSWYgeW91IGJlbGll dmUgdGhpcyBhc3NlcnRpb24sIHRoZW4gYWN0aW5nIG9uIHByb3RvY29sIHZlcnNpb24gaXMgbGVz cyBpbnRlcmVzdGluZyB0aGFuIGF0dGVtcHRpbmcgdG8gYWN0IGJhc2VkIG9uIGltcGxlbWVudGF0 aW9uIGZpbmdlcnByaW50cy4NCi09Ug0KDQoNCu+7v09uIDQvMTAvMTksIDE6NDggQU0sICJRVUlD IG9uIGJlaGFsZiBvZiBHIEZhaXJodXJzdCIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgZ29ycnlAZXJnLmFiZG4uYWMudWs+IHdyb3RlOg0KDQogICAgT2JzY3VyaW5nIHRoZSB2 ZXJzaW9uIG9mIGEgcHJvdG9jb2wgc2VlbXMgbGlrZSBhIG1ham9yIGRlc2lnbiBkZXNpZ24NCiAg ICBkZWNpc2lvbiBmb3Igd2lkZXIgdXNlIGNhc2VzLiBTbywgSSdtIHRyeWluZyB0byB1bmRlcnN0 YW5kIHRoZQ0KICAgIG1vdGl2YXRpb24gZm9yIHZlcnNpb24gZ3JlYXNpbmcuDQoNCiAgICAoMSkg SSBrbm93IHRoZXJlIHdlcmUgaW5zdGFuY2VzIHdoZXJlIHNvbWUgZWFybHkgdmVyc2lvbnMgb2Yg UVVJQyB3ZXJlDQogICAgYmxvY2tlZCBkdWUgdG8gYW4gdW5pbml0ZW50aW9uYWwgbWF0Y2hpbmcg b2YgdGhlIGhlYWRlci4gSXMgdGhlcmUNCiAgICBldmlkZW5jZSBvZiBpbnRlbnRpb25hbCBhdHRl bXB0cyB0byBibG9jayB1cGRhdGVzIHRvIHByb3RvY29scz8NCg0KICAgICgyKSBUaGlua2luZyBh Ym91dCBvcGVyYXRpbmcgYSBuZXR3b3JrIHRoYXQgY2FyZXMgYWJvdXQgdXNlciBzdXBwb3J0IGFu ZA0KICAgIHByb3RlY3Rpb24gZnJvbSB1bndhbnRlZCB0cmFmZmljLCBJIHdvdWxkIGV4cGVjdCB0 aGF0IHRoZXJlIHdvdWxkIGJlDQogICAgY2FzZXMgd2hlcmUgdHJhZmZpYyBwYXR0ZXJuIGFub21v bGllcyBhcmUgZm91bmQgYW5kIHRoZSBhcHByb3ByaWF0ZQ0KICAgIHRoaW5nIHdvdWxkIGJlIHRv IHRyeSB0byBkZXRlcm1pbmUgaWYgYSBuZXcgcHJvdG9jb2wgaGFkIGJlZW4gZGVwbG95ZWQNCiAg ICBhbmQgbW9uaXRvciBpdCwgaWYgbm90LCB0aGVuIHRoZSBuZXh0IG1vc3Qgb2J2aW91cyB0aGlu ZyBjb3VsZCBiZSB0bw0KICAgIGJsb2NrIGFsbCB1bmV4cGVjdGVkIHRyYWZmaWMsIHRoYXQgc2Vl bXMgbGlrZSBhIGRlY2lzaW9uIHRvIGhpZGUgdGhlDQogICAgdmVyc2lvbiBjb3VsZCBpbmNyZWFz ZSBvc3NpZmljYXRpb24gZm9yIG5ldyB2ZXJzaW9ucyBpbiB0aGVzZSBjYXNlcy4NCg0KICAgICgz KSBTaW1pbGFybHksIGlmIGEgdGhyZWF0IGlzIGtub3duIHRvIGltcGFjdCBvbmx5IGEgc3BlY2lm aWMgKG9sZGVyKQ0KICAgIHZlcnNpb24sIGl0IHdvdWxkIHNlZW0gdG8gbW90aXZhdGUgYSBkcm9w IG9mIHRoYXQgdHJhZmZpYyB0aGF0IHNlZWtzIHRvDQogICAgdXNlIHRoYXQgdmVyc2lvbiwgd2hp bGUgc3RpbGwgcGVybWl0dGluZyBvdGhlciB0cmFmZmljLiBGb3JjaW5nIHZlcnNpb24NCiAgICBk ZXRlY3Rpb24gdG8gdXNlIHBhdHRlcm4gbWF0Y2hpbmcvTUwgd2lsbCBsZWFkIHRvIGxlc3MgcHJl ZGljdGFibGUNCiAgICBvdXRjb21lcywgb3IgYmxvY2tpbmcgYmFzZWQgb24gYWRkcmVzcywgZXRj Lg0KDQogICAgKDQpIFRoaXMgb2JmdXN0aWNhdGVzIHRoZSBtb3N0IGJhc2ljIHBpZWNlIG9mIHJl cG9ydGluZyBpbmZvcm1hdGlvbiB1c2VkDQogICAgZm9yIHN1cHBvcnQuIEl0IGhpZGVzIHRoZSBl eHRlbnQgb2YgZGVwbG95bWVudCBvZiB0aGUgY3VycmVudCBwcm90b2NvbA0KICAgIHZlcnNpb24g YW5kIHByZXZsYW5jZSBvZiBvbGQgaW1wbGVtZW50YXRpb25zLg0KDQogICAgKDUpIE9uIHRoZSBz dXBwb3J0LCBpZiBhIHByb2JsZW0gb25seSBlbWVyZ2VzIHdoZW4gYSBwYXJ0aWN1bGFyIHZlcnNp b24NCiAgICBpcyB1c2VkIHdpdGggYSBwYXJ0aWN1bGFyIGFkZHJlc3MsIHRoZW4gdGhpcyBoZWxw cyBwaW5wb2ludCB0aGUgaXNzdWVzLg0KICAgIE1hdGNoaW5nIGNsaWVudCB2ZXJzaW9ucyB0byBz ZXJ2ZXJzIGlzIG11Y2ggbW9yZSBvZiBhbiBpc3N1ZSBpZiB0aGUgdXNlcg0KICAgIGNvbW11bml0 eSB1c2VzIGEgd2lkZSByYW5nZSBvZiBzZXJ2ZXJzIChsZXNzIHNvLCBJIGV4cGVjdCBmb3IgbWFq b3INCiAgICBwcm92aWRlcnM6IGdvb2dsZSwgZmFjZWJvb2ssIGV0YywgZXRjKSwgYnV0IHNpZ25p ZmljYW50IHdoZW4gdGhlcmUgaXMgYQ0KICAgIHVzZSBvZiBhIGRpdmVyc2Ugc2V0IG9mIGV4dGVy bmFsIHNpdGVzIGFuZCBzaXRlcyB3aXRoIHRoZWlyIG93biBsb2FkDQogICAgYmFsYW5jZXJzLCBl dGMgYW5kIGEgbmVlZCB0byBtYW5hZ2UgaW50ZXJhY3Rpb25zIHdpdGggTDIgc2VydmljZXMuDQoN CiAgICBJIGFtIGludGVyc3RlZCBpbiBrbm93aW5nIGlmIHRoaXMgaXMgbGlrZWx5IHRvIGJlbmVm aXQgb3IgYmUgYSBuZXcgb2JzdGFjbGU/DQoNCiAgICBHb3JyeQ0KDQoNCg0K From nobody Wed Apr 10 10:25:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE26F120086 for ; Wed, 10 Apr 2019 10:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu7z6yIBtUpo for ; Wed, 10 Apr 2019 10:25:26 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4611205D0 for ; Wed, 10 Apr 2019 10:25:25 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id w15so4776033itc.0 for ; Wed, 10 Apr 2019 10:25: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=ub0lQYmoUXJuLw9H6y+q/Xvak/P1G51i17GhzJ/meS0=; b=lnWSSYqQ8t43wiYrXJ0UGrT4HR3bFU8LYIfNLfZ+eqw/dxHFC38x68krKtrIATm5uG Hv2qifbaNUzvWroIsvMn/+phhUeuYMeIRYJR0ftx+5GRBiImOR3IJwIr2+N20Y3qZc8x C+f8d3g4RO/TAQ22/XdKngnmQuqaKlyw/EhX3R50Vl+ROHz/FqbW6xLyGSx3qxQzqjjK WRNSag+AbL9Jn/Cf80UMRnsNSlOZZik1j7A+H4DnHWLQjHrGbBOnJaVUgIiX0C27pW1Q NnMYsoXq7fQMbfgVzHts3LTY0SUuWixKmTNocrnn2yd6PY7UeylABe4iCS/9a/SgDIUl +yIw== 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=ub0lQYmoUXJuLw9H6y+q/Xvak/P1G51i17GhzJ/meS0=; b=IIiuzyWhmubaH96g7GOCZwtlpfm5YAccJsZdrROC03hkFnT4NYPGd4WyCcZIHijei9 t2qaP6oVQZwYCV6UYMMYmPjr+3YUQzSrjw+hffOY2oJ3bIk1IRGMCkJF9JF73JlcPh7p gkTqNsr9JqaXcLFXOUdaXPHxf4hnlykjvyIO9nfsJMhgGdWej5srgwKftWsCXNhCsUqz CvWMaFQs1KrwudOoBSFcFKX0PPHPjTTKxEPpENNacj8mWdznHk9BRLyv5CqQr5NHaBF8 GqLIM+WJGK25uTR5JewrfOepW47l+WjMJn5A4qQxK12fWX7joZ2IuE2a8voPVyWt836Y Z0AQ== X-Gm-Message-State: APjAAAVjgNjWie7Jq8X5g6oKSbKFCAL+MJelZo1seNejEVWobizKthvc lEdEJjQYsJ9/UfVCpFgq2tHVOF75h7nG7Es+Aco= X-Google-Smtp-Source: APXvYqz8zm8tJ+GH0xD1ucuH51/5y96h+2aHXHKGNti4rPximg0ipNdo3B4MfdYpKXR5JyK3qzqxvHbday6AQq/KS+c= X-Received: by 2002:a02:ab90:: with SMTP id t16mr32243584jan.119.1554917124597; Wed, 10 Apr 2019 10:25:24 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Apr 2019 10:25:23 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5CADADDD.7010005@erg.abdn.ac.uk> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 10 Apr 2019 10:25:23 -0700 Message-ID: Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? To: G Fairhurst , "Border, John" , Roberto Peon , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ddec270586305a0f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:25:30 -0000 --000000000000ddec270586305a0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable China blocks as a rule. Russia is running an experiment to block the rest of the internet. USA blocks net neutrality. EU blocks cookies. GB blocks itself. So blocking is not limited to what an operator considers best for business. On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote: I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others... John -----Original Message----- From: QUIC On Behalf Of Roberto Peon Sent: Wednesday, April 10, 2019 12:52 PM To: G Fairhurst ; quic@ietf.org Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? WARNING: The sender of this email could not be validated and may not match the person in the "From" field. CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. You're kinda between a rock-and-a-hard-place either way: - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification. - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not. My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate. My guesses: IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In other words, I have a doubt that stating the version in an observable way will prevent the use of such tools. Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe). If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation fingerprints. -=3DR =EF=BB=BFOn 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" wrote: Obscuring the version of a protocol seems like a major design design decision for wider use cases. So, I'm trying to understand the motivation for version greasing. (1) I know there were instances where some early versions of QUIC were blocked due to an uninitentional matching of the header. Is there evidence of intentional attempts to block updates to protocols? (2) Thinking about operating a network that cares about user support and protection from unwanted traffic, I would expect that there would be cases where traffic pattern anomolies are found and the appropriate thing would be to try to determine if a new protocol had been deployed and monitor it, if not, then the next most obvious thing could be to block all unexpected traffic, that seems like a decision to hide the version could increase ossification for new versions in these cases. (3) Similarly, if a threat is known to impact only a specific (older) version, it would seem to motivate a drop of that traffic that seeks to use that version, while still permitting other traffic. Forcing version detection to use pattern matching/ML will lead to less predictable outcomes, or blocking based on address, etc. (4) This obfusticates the most basic piece of reporting information used for support. It hides the extent of deployment of the current protocol version and prevlance of old implementations. (5) On the support, if a problem only emerges when a particular version is used with a particular address, then this helps pinpoint the issues. Matching client versions to servers is much more of an issue if the user community uses a wide range of servers (less so, I expect for major providers: google, facebook, etc, etc), but significant when there is a use of a diverse set of external sites and sites with their own load balancers, etc and a need to manage interactions with L2 services. I am intersted in knowing if this is likely to benefit or be a new obstacle? Gorry --000000000000ddec270586305a0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = China blocks as a ru= le.
Russia is= running an experiment to block the rest of the internet.
USA blocks net neutrality.
EU blocks cookie= s.
GB blocks = itself.

<= /div>
So blocking i= s not limited to what an operator considers best for business.


On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote:


I understand why people want to come down on the side of preventing oss= ification. But, things have changed. There are a lot of more negative con= sequences now when people unnecessarily block things. I think operators wo= uld put a lot of pressure on vendors to not do it now and to fix it if they= did "by accident". Of course, I am only one operator. It would= be nice to hear from others...



John


-----Original Message-----
From: QUIC <quic-bounces@ie= tf.org> On Behalf Of Roberto Peon
Sent: Wednesday, April 10, 2019 12:52 PM
To: G Fairhurst <gorry@erg.a= bdn.ac.uk>; quic@ietf.org
Subject: Re: Is "Version Greasing" a new benfit or a new obst= acle?

WARNING: The sender of this email could not be validated and may not ma= tch the person in the "From" field.

CAUTION: This email originated from outside of the organization. Do not= click links or open attachments unless you recognize the sender and know t= he content is safe.


You're kinda between a rock-and-a-hard-place either way:

- We've seen how much fun ossification is in TCP and HTTP. If the= thing is observable, it will be ossified seems to be the lesson. A lot of = the reason why QUIC was started in the first place was because of the inabi= lity to improve TCP due to this ossification.
- OTOH, there is the fear of unknown/unobservable which might cause o= perators to block things, whether predictably or not.

My opinion is that it is better to start with preventing ossification, = and then if that results in too large a percentage of operators blocking th= ings, to re-evaluate.

My guesses:
IP+port tuples and traffic patterns are still observable (for better an= d worse), which implies operators will still have significant tools for man= aging traffic. I believe that these are acted on/matched (ML or not) regard= less of any other data presented. In other words, I have a doubt that stati= ng the version in an observable way will prevent the use of such tools.

Most problems I've seen associated with implementations rather than= protocol versions (though when the latter happens it is pretty severe). If= you believe this assertion, then acting on protocol version is less intere= sting than attempting to act based on implementation fingerprints.
-=3DR


=EF=BB=BFOn 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst"= <quic-bounces@ietf.org on = behalf of gorry@erg.abdn.ac.uk&= gt; wrote:

Obscuring the version of a protocol seems like a major design desig= n
decision for wider use cases. So, I'm trying to understand the
motivation for version greasing.

(1) I know there were instances where some early versions of QUIC w= ere
blocked due to an uninitentional matching of the header. Is there
evidence of intentional attempts to block updates to protocols?

(2) Thinking about operating a network that cares about user suppor= t and
protection from unwanted traffic, I would expect that there would b= e
cases where traffic pattern anomolies are found and the appropriate
thing would be to try to determine if a new protocol had been deplo= yed
and monitor it, if not, then the next most obvious thing could be t= o
block all unexpected traffic, that seems like a decision to hide th= e
version could increase ossification for new versions in these cases= .

(3) Similarly, if a threat is known to impact only a specific (olde= r)
version, it would seem to motivate a drop of that traffic that seek= s to
use that version, while still permitting other traffic. Forcing ver= sion
detection to use pattern matching/ML will lead to less predictable
outcomes, or blocking based on address, etc.

(4) This obfusticates the most basic piece of reporting information= used
for support. It hides the extent of deployment of the current proto= col
version and prevlance of old implementations.

(5) On the support, if a problem only emerges when a particular ver= sion
is used with a particular address, then this helps pinpoint the iss= ues.
Matching client versions to servers is much more of an issue if the= user
community uses a wide range of servers (less so, I expect for major
providers: google, facebook, etc, etc), but significant when there = is a
use of a diverse set of external sites and sites with their own loa= d
balancers, etc and a need to manage interactions with L2 services.

I am intersted in knowing if this is likely to benefit or be a new = obstacle?

Gorry



--000000000000ddec270586305a0f-- From nobody Wed Apr 10 10:33:11 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB087120404 for ; Wed, 10 Apr 2019 10:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, 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=hughes.com header.b=bpx9t7h1; dkim=pass (1024-bit key) header.d=hughes.com header.b=2lVHsK0+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8AAdyjv7zuo for ; Wed, 10 Apr 2019 10:33:08 -0700 (PDT) Received: from mx0a-00115402.pphosted.com (mx0a-00115402.pphosted.com [148.163.150.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 1F6B912040C for ; Wed, 10 Apr 2019 10:33:08 -0700 (PDT) Received: from pps.filterd (m0118426.ppops.net [127.0.0.1]) by mx0a-00115402.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3AHWNu2026685; Wed, 10 Apr 2019 17:33:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=3152018; bh=FdnQ0Q/A8PNnuZEqUK6Xf0T3mNk3XvJ7u+eeYt0NY44=; b=bpx9t7h14zcUCQjmAvxRG2VIzt2V++a+kUS5u6ZLHok+jJOZIgcSJAbNazRXIriGYple jxb4ERKK+azTdqKcvnNO/PAOH/+lDTEMSBhgnFTNtf+FN5jpRPsoFxCrTGXsfSm6Q3xc fRp9/uWg/mo1aR/hj+ghtyrxyfwd8qzsd2IHTx2TjneOAbycKi6G7KJwJMbSwZkS82I3 48Ef0z2J0IcTCajIXU5ccOnbedbi4pZiKaH/jMu+1SxlTfalGbTiNFmm/GcIR5c9HZ7I 2xFVA9jA1ZafHvCQrmIAHthyOVQvciXnhQwsh15yF3p+rmUHAf415SkHl+QwmNNHMBpP ow== Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp2053.outbound.protection.outlook.com [104.47.33.53]) by mx0a-00115402.pphosted.com with ESMTP id 2rsm1xrd6c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 Apr 2019 17:32:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FdnQ0Q/A8PNnuZEqUK6Xf0T3mNk3XvJ7u+eeYt0NY44=; b=2lVHsK0+B68+EKM3bw/VBoQ7ZnV10mFcVAyVgC4hVBzvYpWyATpZ0253xFg0teOJAg1yznUwjeFaJHp0fLZ7TJx9VPccMY/LISmJaKaaP6JeIimlfdI7wk3GtYC0pEjMpPtQZPzHw6EFRH4io6H4tPhfy+wVA6V1Jik/GWDPDWM= Received: from BL0PR11MB3394.namprd11.prod.outlook.com (10.167.240.87) by BL0PR11MB3347.namprd11.prod.outlook.com (10.167.235.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Wed, 10 Apr 2019 17:32:55 +0000 Received: from BL0PR11MB3394.namprd11.prod.outlook.com ([fe80::4c34:8995:92f3:5e3]) by BL0PR11MB3394.namprd11.prod.outlook.com ([fe80::4c34:8995:92f3:5e3%3]) with mapi id 15.20.1771.016; Wed, 10 Apr 2019 17:32:55 +0000 From: "Border, John" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , G Fairhurst , Roberto Peon , "quic@ietf.org" Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o1HANarzJfIkWJiL5ZcFMTo6Y1nGCAgAABHICAAAhRgIAAAfeg Date: Wed, 10 Apr 2019 17:32:55 +0000 Message-ID: References: <5CADADDD.7010005@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.85.223.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29d94559-9ebb-45b0-6744-08d6bdda9152 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BL0PR11MB3347; x-ms-traffictypediagnostic: BL0PR11MB3347: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(346002)(136003)(396003)(13464003)(189003)(199004)(478600001)(26005)(6436002)(486006)(186003)(105586002)(106356001)(236005)(66066001)(2501003)(256004)(102836004)(5024004)(9686003)(6506007)(54896002)(33656002)(6306002)(53546011)(11346002)(14454004)(14444005)(476003)(53936002)(446003)(7696005)(81156014)(81166006)(71190400001)(229853002)(97736004)(72206003)(74316002)(2906002)(76176011)(71200400001)(86362001)(25786009)(52536014)(66574012)(8676002)(6246003)(6116002)(110136005)(316002)(68736007)(3846002)(790700001)(7736002)(55016002)(99286004)(8936002)(93886005)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR11MB3347; H:BL0PR11MB3394.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: hughes.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: oaSqHumH8PJxRomZSejpmz3Tu3Rw2Zfc1IxgQU2s3mc0XtZUEPv/2yMhdvVJU9rn2eDlUXsMNUeMn5sI/Xo8Nna8OyUoNBdKpWpIyjTBlTPKwUvDJ+m7hXpNxQK8f0kmupYENb8zNcnPyMwX5LHZmgtcZPwZUzkP0atqKNJCoyOLIwljOL44hsUzuaD/mBupl4eyuNnU4BcRO7LcWVQolwmBTrosZxegY5E1O8vQUaSkH+XfXnQv+j1ge/7Unjvzj1Y++Zw4DUsT1Ws5e+NizpNwYxNxNqQAGM7Yw0dmQSgdR7ysTN/8QE0RvIbDLo/DSeKGULTYP+ZUZAaJILMi0oKn24f7GbalNfS4z69V0nr5x9JRkxwk85pZLMn1Lu18uG2ej/px+t86kHc65YCURFeFhoSpyG3ozlM/FOzl+qo= Content-Type: multipart/alternative; boundary="_000_BL0PR11MB339439D6DE80D2C69BD05A61902E0BL0PR11MB3394namp_" MIME-Version: 1.0 X-OriginatorOrg: hughes.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29d94559-9ebb-45b0-6744-08d6bdda9152 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 17:32:55.6999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0e1f3187-4610-4ce2-bad1-b92f4ba36ab3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3347 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-10_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-1810050000 definitions=main-1904100117 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:33:11 -0000 --_000_BL0PR11MB339439D6DE80D2C69BD05A61902E0BL0PR11MB3394namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpUaGF0IGlzIG5vdCBvc3NpZmljYXRpb24uICBCdXQsIGl0IGlzIGEgdmFsaWQgcG9pbnQuDQoN Cg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPg0K U2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMCwgMjAxOSAxOjI1IFBNDQpUbzogRyBGYWlyaHVyc3Qg PGdvcnJ5QGVyZy5hYmRuLmFjLnVrPjsgQm9yZGVyLCBKb2huIDxKb2huLkJvcmRlckBodWdoZXMu Y29tPjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0 OiBSRTogSXMgIlZlcnNpb24gR3JlYXNpbmciIGEgbmV3IGJlbmZpdCBvciBhIG5ldyBvYnN0YWNs ZT8NCg0KQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUg b3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxl c3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUu DQoNCkNoaW5hIGJsb2NrcyBhcyBhIHJ1bGUuDQpSdXNzaWEgaXMgcnVubmluZyBhbiBleHBlcmlt ZW50IHRvIGJsb2NrIHRoZSByZXN0IG9mIHRoZSBpbnRlcm5ldC4NClVTQSBibG9ja3MgbmV0IG5l dXRyYWxpdHkuDQpFVSBibG9ja3MgY29va2llcy4NCkdCIGJsb2NrcyBpdHNlbGYuDQoNClNvIGJs b2NraW5nIGlzIG5vdCBsaW1pdGVkIHRvIHdoYXQgYW4gb3BlcmF0b3IgY29uc2lkZXJzIGJlc3Qg Zm9yIGJ1c2luZXNzLg0KDQoNCg0KT24gMTAgQXByaWwgMjAxOSBhdCAxOC41OS4xNSwgQm9yZGVy LCBKb2huIChqb2huLmJvcmRlckBodWdoZXMuY29tPG1haWx0bzpqb2huLmJvcmRlckBodWdoZXMu Y29tPikgd3JvdGU6DQoNCkkgdW5kZXJzdGFuZCB3aHkgcGVvcGxlIHdhbnQgdG8gY29tZSBkb3du IG9uIHRoZSBzaWRlIG9mIHByZXZlbnRpbmcgb3NzaWZpY2F0aW9uLiBCdXQsIHRoaW5ncyBoYXZl IGNoYW5nZWQuIFRoZXJlIGFyZSBhIGxvdCBvZiBtb3JlIG5lZ2F0aXZlIGNvbnNlcXVlbmNlcyBu b3cgd2hlbiBwZW9wbGUgdW5uZWNlc3NhcmlseSBibG9jayB0aGluZ3MuIEkgdGhpbmsgb3BlcmF0 b3JzIHdvdWxkIHB1dCBhIGxvdCBvZiBwcmVzc3VyZSBvbiB2ZW5kb3JzIHRvIG5vdCBkbyBpdCBu b3cgYW5kIHRvIGZpeCBpdCBpZiB0aGV5IGRpZCAiYnkgYWNjaWRlbnQiLiBPZiBjb3Vyc2UsIEkg YW0gb25seSBvbmUgb3BlcmF0b3IuIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGVhciBmcm9tIG90aGVy cy4uLg0KDQoNCg0KSm9obg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBR VUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+ IE9uIEJlaGFsZiBPZiBSb2JlcnRvIFBlb24NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTAsIDIw MTkgMTI6NTIgUE0NClRvOiBHIEZhaXJodXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRv OmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogSXMgIlZlcnNpb24gR3JlYXNpbmciIGEgbmV3IGJlbmZpdCBvciBh IG5ldyBvYnN0YWNsZT8NCg0KV0FSTklORzogVGhlIHNlbmRlciBvZiB0aGlzIGVtYWlsIGNvdWxk IG5vdCBiZSB2YWxpZGF0ZWQgYW5kIG1heSBub3QgbWF0Y2ggdGhlIHBlcnNvbiBpbiB0aGUgIkZy b20iIGZpZWxkLg0KDQpDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRl IG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1l bnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQg aXMgc2FmZS4NCg0KDQpZb3UncmUga2luZGEgYmV0d2VlbiBhIHJvY2stYW5kLWEtaGFyZC1wbGFj ZSBlaXRoZXIgd2F5Og0KDQotIFdlJ3ZlIHNlZW4gaG93IG11Y2ggZnVuIG9zc2lmaWNhdGlvbiBp cyBpbiBUQ1AgYW5kIEhUVFAuIElmIHRoZSB0aGluZyBpcyBvYnNlcnZhYmxlLCBpdCB3aWxsIGJl IG9zc2lmaWVkIHNlZW1zIHRvIGJlIHRoZSBsZXNzb24uIEEgbG90IG9mIHRoZSByZWFzb24gd2h5 IFFVSUMgd2FzIHN0YXJ0ZWQgaW4gdGhlIGZpcnN0IHBsYWNlIHdhcyBiZWNhdXNlIG9mIHRoZSBp bmFiaWxpdHkgdG8gaW1wcm92ZSBUQ1AgZHVlIHRvIHRoaXMgb3NzaWZpY2F0aW9uLg0KLSBPVE9I LCB0aGVyZSBpcyB0aGUgZmVhciBvZiB1bmtub3duL3Vub2JzZXJ2YWJsZSB3aGljaCBtaWdodCBj YXVzZSBvcGVyYXRvcnMgdG8gYmxvY2sgdGhpbmdzLCB3aGV0aGVyIHByZWRpY3RhYmx5IG9yIG5v dC4NCg0KTXkgb3BpbmlvbiBpcyB0aGF0IGl0IGlzIGJldHRlciB0byBzdGFydCB3aXRoIHByZXZl bnRpbmcgb3NzaWZpY2F0aW9uLCBhbmQgdGhlbiBpZiB0aGF0IHJlc3VsdHMgaW4gdG9vIGxhcmdl IGEgcGVyY2VudGFnZSBvZiBvcGVyYXRvcnMgYmxvY2tpbmcgdGhpbmdzLCB0byByZS1ldmFsdWF0 ZS4NCg0KTXkgZ3Vlc3NlczoNCklQK3BvcnQgdHVwbGVzIGFuZCB0cmFmZmljIHBhdHRlcm5zIGFy ZSBzdGlsbCBvYnNlcnZhYmxlIChmb3IgYmV0dGVyIGFuZCB3b3JzZSksIHdoaWNoIGltcGxpZXMg b3BlcmF0b3JzIHdpbGwgc3RpbGwgaGF2ZSBzaWduaWZpY2FudCB0b29scyBmb3IgbWFuYWdpbmcg dHJhZmZpYy4gSSBiZWxpZXZlIHRoYXQgdGhlc2UgYXJlIGFjdGVkIG9uL21hdGNoZWQgKE1MIG9y IG5vdCkgcmVnYXJkbGVzcyBvZiBhbnkgb3RoZXIgZGF0YSBwcmVzZW50ZWQuIEluIG90aGVyIHdv cmRzLCBJIGhhdmUgYSBkb3VidCB0aGF0IHN0YXRpbmcgdGhlIHZlcnNpb24gaW4gYW4gb2JzZXJ2 YWJsZSB3YXkgd2lsbCBwcmV2ZW50IHRoZSB1c2Ugb2Ygc3VjaCB0b29scy4NCg0KTW9zdCBwcm9i bGVtcyBJJ3ZlIHNlZW4gYXNzb2NpYXRlZCB3aXRoIGltcGxlbWVudGF0aW9ucyByYXRoZXIgdGhh biBwcm90b2NvbCB2ZXJzaW9ucyAodGhvdWdoIHdoZW4gdGhlIGxhdHRlciBoYXBwZW5zIGl0IGlz IHByZXR0eSBzZXZlcmUpLiBJZiB5b3UgYmVsaWV2ZSB0aGlzIGFzc2VydGlvbiwgdGhlbiBhY3Rp bmcgb24gcHJvdG9jb2wgdmVyc2lvbiBpcyBsZXNzIGludGVyZXN0aW5nIHRoYW4gYXR0ZW1wdGlu ZyB0byBhY3QgYmFzZWQgb24gaW1wbGVtZW50YXRpb24gZmluZ2VycHJpbnRzLg0KLT1SDQoNCg0K 77u/T24gNC8xMC8xOSwgMTo0OCBBTSwgIlFVSUMgb24gYmVoYWxmIG9mIEcgRmFpcmh1cnN0IiA8 cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiBnb3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+ PiB3cm90ZToNCg0KT2JzY3VyaW5nIHRoZSB2ZXJzaW9uIG9mIGEgcHJvdG9jb2wgc2VlbXMgbGlr ZSBhIG1ham9yIGRlc2lnbiBkZXNpZ24NCmRlY2lzaW9uIGZvciB3aWRlciB1c2UgY2FzZXMuIFNv LCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlDQptb3RpdmF0aW9uIGZvciB2ZXJzaW9uIGdy ZWFzaW5nLg0KDQooMSkgSSBrbm93IHRoZXJlIHdlcmUgaW5zdGFuY2VzIHdoZXJlIHNvbWUgZWFy bHkgdmVyc2lvbnMgb2YgUVVJQyB3ZXJlDQpibG9ja2VkIGR1ZSB0byBhbiB1bmluaXRlbnRpb25h bCBtYXRjaGluZyBvZiB0aGUgaGVhZGVyLiBJcyB0aGVyZQ0KZXZpZGVuY2Ugb2YgaW50ZW50aW9u YWwgYXR0ZW1wdHMgdG8gYmxvY2sgdXBkYXRlcyB0byBwcm90b2NvbHM/DQoNCigyKSBUaGlua2lu ZyBhYm91dCBvcGVyYXRpbmcgYSBuZXR3b3JrIHRoYXQgY2FyZXMgYWJvdXQgdXNlciBzdXBwb3J0 IGFuZA0KcHJvdGVjdGlvbiBmcm9tIHVud2FudGVkIHRyYWZmaWMsIEkgd291bGQgZXhwZWN0IHRo YXQgdGhlcmUgd291bGQgYmUNCmNhc2VzIHdoZXJlIHRyYWZmaWMgcGF0dGVybiBhbm9tb2xpZXMg YXJlIGZvdW5kIGFuZCB0aGUgYXBwcm9wcmlhdGUNCnRoaW5nIHdvdWxkIGJlIHRvIHRyeSB0byBk ZXRlcm1pbmUgaWYgYSBuZXcgcHJvdG9jb2wgaGFkIGJlZW4gZGVwbG95ZWQNCmFuZCBtb25pdG9y IGl0LCBpZiBub3QsIHRoZW4gdGhlIG5leHQgbW9zdCBvYnZpb3VzIHRoaW5nIGNvdWxkIGJlIHRv DQpibG9jayBhbGwgdW5leHBlY3RlZCB0cmFmZmljLCB0aGF0IHNlZW1zIGxpa2UgYSBkZWNpc2lv biB0byBoaWRlIHRoZQ0KdmVyc2lvbiBjb3VsZCBpbmNyZWFzZSBvc3NpZmljYXRpb24gZm9yIG5l dyB2ZXJzaW9ucyBpbiB0aGVzZSBjYXNlcy4NCg0KKDMpIFNpbWlsYXJseSwgaWYgYSB0aHJlYXQg aXMga25vd24gdG8gaW1wYWN0IG9ubHkgYSBzcGVjaWZpYyAob2xkZXIpDQp2ZXJzaW9uLCBpdCB3 b3VsZCBzZWVtIHRvIG1vdGl2YXRlIGEgZHJvcCBvZiB0aGF0IHRyYWZmaWMgdGhhdCBzZWVrcyB0 bw0KdXNlIHRoYXQgdmVyc2lvbiwgd2hpbGUgc3RpbGwgcGVybWl0dGluZyBvdGhlciB0cmFmZmlj LiBGb3JjaW5nIHZlcnNpb24NCmRldGVjdGlvbiB0byB1c2UgcGF0dGVybiBtYXRjaGluZy9NTCB3 aWxsIGxlYWQgdG8gbGVzcyBwcmVkaWN0YWJsZQ0Kb3V0Y29tZXMsIG9yIGJsb2NraW5nIGJhc2Vk IG9uIGFkZHJlc3MsIGV0Yy4NCg0KKDQpIFRoaXMgb2JmdXN0aWNhdGVzIHRoZSBtb3N0IGJhc2lj IHBpZWNlIG9mIHJlcG9ydGluZyBpbmZvcm1hdGlvbiB1c2VkDQpmb3Igc3VwcG9ydC4gSXQgaGlk ZXMgdGhlIGV4dGVudCBvZiBkZXBsb3ltZW50IG9mIHRoZSBjdXJyZW50IHByb3RvY29sDQp2ZXJz aW9uIGFuZCBwcmV2bGFuY2Ugb2Ygb2xkIGltcGxlbWVudGF0aW9ucy4NCg0KKDUpIE9uIHRoZSBz dXBwb3J0LCBpZiBhIHByb2JsZW0gb25seSBlbWVyZ2VzIHdoZW4gYSBwYXJ0aWN1bGFyIHZlcnNp b24NCmlzIHVzZWQgd2l0aCBhIHBhcnRpY3VsYXIgYWRkcmVzcywgdGhlbiB0aGlzIGhlbHBzIHBp bnBvaW50IHRoZSBpc3N1ZXMuDQpNYXRjaGluZyBjbGllbnQgdmVyc2lvbnMgdG8gc2VydmVycyBp cyBtdWNoIG1vcmUgb2YgYW4gaXNzdWUgaWYgdGhlIHVzZXINCmNvbW11bml0eSB1c2VzIGEgd2lk ZSByYW5nZSBvZiBzZXJ2ZXJzIChsZXNzIHNvLCBJIGV4cGVjdCBmb3IgbWFqb3INCnByb3ZpZGVy czogZ29vZ2xlLCBmYWNlYm9vaywgZXRjLCBldGMpLCBidXQgc2lnbmlmaWNhbnQgd2hlbiB0aGVy ZSBpcyBhDQp1c2Ugb2YgYSBkaXZlcnNlIHNldCBvZiBleHRlcm5hbCBzaXRlcyBhbmQgc2l0ZXMg d2l0aCB0aGVpciBvd24gbG9hZA0KYmFsYW5jZXJzLCBldGMgYW5kIGEgbmVlZCB0byBtYW5hZ2Ug aW50ZXJhY3Rpb25zIHdpdGggTDIgc2VydmljZXMuDQoNCkkgYW0gaW50ZXJzdGVkIGluIGtub3dp bmcgaWYgdGhpcyBpcyBsaWtlbHkgdG8gYmVuZWZpdCBvciBiZSBhIG5ldyBvYnN0YWNsZT8NCg0K R29ycnkNCg0KDQo= --_000_BL0PR11MB339439D6DE80D2C69BD05A61902E0BL0PR11MB3394namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGlj YTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmFpcm1haWxvbiwgbGku YWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmFpcm1haWxfb247DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGF0IGlzIG5vdCBvc3NpZmljYXRpb24uJm5ic3A7IEJ1dCwgaXQgaXMgYSB2 YWxpZCBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+RnJvbTo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWls LmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTAsIDIwMTkgMToy NSBQTTxicj4NCjxiPlRvOjwvYj4gRyBGYWlyaHVyc3QgJmx0O2dvcnJ5QGVyZy5hYmRuLmFjLnVr Jmd0OzsgQm9yZGVyLCBKb2huICZsdDtKb2huLkJvcmRlckBodWdoZXMuY29tJmd0OzsgUm9iZXJ0 byBQZW9uICZsdDtmZW5peEBmYi5jb20mZ3Q7OyBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBJcyAmcXVvdDtWZXJzaW9uIEdyZWFzaW5nJnF1b3Q7IGEgbmV3IGJlbmZpdCBv ciBhIG5ldyBvYnN0YWNsZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpz b2xpZCAjOUM2NTAwIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwLjBwdDtiYWNrZ3JvdW5kOiNG RkVCOUMiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6IzlDNjUwMCI+Q0FV VElPTjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6YmxhY2si PiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24u IERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuDQogYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNv Z25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGlkPSJibG9vcF9j dXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DaGlu YSBibG9ja3MgYXMgYSBydWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+UnVzc2lhIGlzIHJ1bm5pbmcgYW4gZXhwZXJpbWVudCB0byBibG9jayB0aGUgcmVzdCBv ZiB0aGUgaW50ZXJuZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJi bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5VU0EgYmxvY2tzIG5ldCBuZXV0cmFsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+RVUgYmxvY2tzIGNvb2tpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5HQiBibG9ja3MgaXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5TbyBibG9ja2luZyBpcyBub3QgbGltaXRlZCB0byB3aGF0IGFuIG9w ZXJhdG9yIGNvbnNpZGVycyBiZXN0IGZvciBidXNpbmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5P biAxMCBBcHJpbCAyMDE5IGF0IDE4LjU5LjE1LCBCb3JkZXIsIEpvaG4gKDxhIGhyZWY9Im1haWx0 bzpqb2huLmJvcmRlckBodWdoZXMuY29tIj5qb2huLmJvcmRlckBodWdoZXMuY29tPC9hPikgd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxi cj4NCkkgdW5kZXJzdGFuZCB3aHkgcGVvcGxlIHdhbnQgdG8gY29tZSBkb3duIG9uIHRoZSBzaWRl IG9mIHByZXZlbnRpbmcgb3NzaWZpY2F0aW9uLiBCdXQsIHRoaW5ncyBoYXZlIGNoYW5nZWQuIFRo ZXJlIGFyZSBhIGxvdCBvZiBtb3JlIG5lZ2F0aXZlIGNvbnNlcXVlbmNlcyBub3cgd2hlbiBwZW9w bGUgdW5uZWNlc3NhcmlseSBibG9jayB0aGluZ3MuIEkgdGhpbmsgb3BlcmF0b3JzIHdvdWxkIHB1 dCBhIGxvdCBvZiBwcmVzc3VyZSBvbiB2ZW5kb3JzIHRvDQogbm90IGRvIGl0IG5vdyBhbmQgdG8g Zml4IGl0IGlmIHRoZXkgZGlkICZxdW90O2J5IGFjY2lkZW50JnF1b3Q7LiBPZiBjb3Vyc2UsIEkg YW0gb25seSBvbmUgb3BlcmF0b3IuIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGVhciBmcm9tIG90aGVy cy4uLg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KSm9obiA8YnI+DQo8YnI+DQo8YnI+DQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8YnI+DQpGcm9tOiBRVUlDICZsdDs8YSBocmVmPSJtYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBP biBCZWhhbGYgT2YgUm9iZXJ0byBQZW9uDQo8YnI+DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEw LCAyMDE5IDEyOjUyIFBNIDxicj4NClRvOiBHIEZhaXJodXJzdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj5nb3JyeUBlcmcuYWJkbi5hYy51azwvYT4mZ3Q7Ow0KPGEg aHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+IDxicj4NClN1Ympl Y3Q6IFJlOiBJcyAmcXVvdDtWZXJzaW9uIEdyZWFzaW5nJnF1b3Q7IGEgbmV3IGJlbmZpdCBvciBh IG5ldyBvYnN0YWNsZT8gPGJyPg0KPGJyPg0KV0FSTklORzogVGhlIHNlbmRlciBvZiB0aGlzIGVt YWlsIGNvdWxkIG5vdCBiZSB2YWxpZGF0ZWQgYW5kIG1heSBub3QgbWF0Y2ggdGhlIHBlcnNvbiBp biB0aGUgJnF1b3Q7RnJvbSZxdW90OyBmaWVsZC4NCjxicj4NCjxicj4NCkNBVVRJT046IFRoaXMg ZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90 IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhl IHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPGJyPg0KPGJyPg0KPGJyPg0K WW91J3JlIGtpbmRhIGJldHdlZW4gYSByb2NrLWFuZC1hLWhhcmQtcGxhY2UgZWl0aGVyIHdheTog PGJyPg0KPGJyPg0KLSBXZSd2ZSBzZWVuIGhvdyBtdWNoIGZ1biBvc3NpZmljYXRpb24gaXMgaW4g VENQIGFuZCBIVFRQLiBJZiB0aGUgdGhpbmcgaXMgb2JzZXJ2YWJsZSwgaXQgd2lsbCBiZSBvc3Np ZmllZCBzZWVtcyB0byBiZSB0aGUgbGVzc29uLiBBIGxvdCBvZiB0aGUgcmVhc29uIHdoeSBRVUlD IHdhcyBzdGFydGVkIGluIHRoZSBmaXJzdCBwbGFjZSB3YXMgYmVjYXVzZSBvZiB0aGUgaW5hYmls aXR5IHRvIGltcHJvdmUgVENQIGR1ZSB0byB0aGlzIG9zc2lmaWNhdGlvbi4NCjxicj4NCi0gT1RP SCwgdGhlcmUgaXMgdGhlIGZlYXIgb2YgdW5rbm93bi91bm9ic2VydmFibGUgd2hpY2ggbWlnaHQg Y2F1c2Ugb3BlcmF0b3JzIHRvIGJsb2NrIHRoaW5ncywgd2hldGhlciBwcmVkaWN0YWJseSBvciBu b3QuDQo8YnI+DQo8YnI+DQpNeSBvcGluaW9uIGlzIHRoYXQgaXQgaXMgYmV0dGVyIHRvIHN0YXJ0 IHdpdGggcHJldmVudGluZyBvc3NpZmljYXRpb24sIGFuZCB0aGVuIGlmIHRoYXQgcmVzdWx0cyBp biB0b28gbGFyZ2UgYSBwZXJjZW50YWdlIG9mIG9wZXJhdG9ycyBibG9ja2luZyB0aGluZ3MsIHRv IHJlLWV2YWx1YXRlLg0KPGJyPg0KPGJyPg0KTXkgZ3Vlc3NlczogPGJyPg0KSVAmIzQzO3BvcnQg dHVwbGVzIGFuZCB0cmFmZmljIHBhdHRlcm5zIGFyZSBzdGlsbCBvYnNlcnZhYmxlIChmb3IgYmV0 dGVyIGFuZCB3b3JzZSksIHdoaWNoIGltcGxpZXMgb3BlcmF0b3JzIHdpbGwgc3RpbGwgaGF2ZSBz aWduaWZpY2FudCB0b29scyBmb3IgbWFuYWdpbmcgdHJhZmZpYy4gSSBiZWxpZXZlIHRoYXQgdGhl c2UgYXJlIGFjdGVkIG9uL21hdGNoZWQgKE1MIG9yIG5vdCkgcmVnYXJkbGVzcyBvZiBhbnkgb3Ro ZXIgZGF0YSBwcmVzZW50ZWQuIEluDQogb3RoZXIgd29yZHMsIEkgaGF2ZSBhIGRvdWJ0IHRoYXQg c3RhdGluZyB0aGUgdmVyc2lvbiBpbiBhbiBvYnNlcnZhYmxlIHdheSB3aWxsIHByZXZlbnQgdGhl IHVzZSBvZiBzdWNoIHRvb2xzLg0KPGJyPg0KPGJyPg0KTW9zdCBwcm9ibGVtcyBJJ3ZlIHNlZW4g YXNzb2NpYXRlZCB3aXRoIGltcGxlbWVudGF0aW9ucyByYXRoZXIgdGhhbiBwcm90b2NvbCB2ZXJz aW9ucyAodGhvdWdoIHdoZW4gdGhlIGxhdHRlciBoYXBwZW5zIGl0IGlzIHByZXR0eSBzZXZlcmUp LiBJZiB5b3UgYmVsaWV2ZSB0aGlzIGFzc2VydGlvbiwgdGhlbiBhY3Rpbmcgb24gcHJvdG9jb2wg dmVyc2lvbiBpcyBsZXNzIGludGVyZXN0aW5nIHRoYW4gYXR0ZW1wdGluZyB0byBhY3QgYmFzZWQg b24gaW1wbGVtZW50YXRpb24NCiBmaW5nZXJwcmludHMuIDxicj4NCi09UiA8YnI+DQo8YnI+DQo8 YnI+DQrvu79PbiA0LzEwLzE5LCAxOjQ4IEFNLCAmcXVvdDtRVUlDIG9uIGJlaGFsZiBvZiBHIEZh aXJodXJzdCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+ cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpn b3JyeUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OyB3cm90ZTog PGJyPg0KPGJyPg0KT2JzY3VyaW5nIHRoZSB2ZXJzaW9uIG9mIGEgcHJvdG9jb2wgc2VlbXMgbGlr ZSBhIG1ham9yIGRlc2lnbiBkZXNpZ24gPGJyPg0KZGVjaXNpb24gZm9yIHdpZGVyIHVzZSBjYXNl cy4gU28sIEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgPGJyPg0KbW90aXZhdGlvbiBmb3Ig dmVyc2lvbiBncmVhc2luZy4gPGJyPg0KPGJyPg0KKDEpIEkga25vdyB0aGVyZSB3ZXJlIGluc3Rh bmNlcyB3aGVyZSBzb21lIGVhcmx5IHZlcnNpb25zIG9mIFFVSUMgd2VyZSA8YnI+DQpibG9ja2Vk IGR1ZSB0byBhbiB1bmluaXRlbnRpb25hbCBtYXRjaGluZyBvZiB0aGUgaGVhZGVyLiBJcyB0aGVy ZSA8YnI+DQpldmlkZW5jZSBvZiBpbnRlbnRpb25hbCBhdHRlbXB0cyB0byBibG9jayB1cGRhdGVz IHRvIHByb3RvY29scz8gPGJyPg0KPGJyPg0KKDIpIFRoaW5raW5nIGFib3V0IG9wZXJhdGluZyBh IG5ldHdvcmsgdGhhdCBjYXJlcyBhYm91dCB1c2VyIHN1cHBvcnQgYW5kIDxicj4NCnByb3RlY3Rp b24gZnJvbSB1bndhbnRlZCB0cmFmZmljLCBJIHdvdWxkIGV4cGVjdCB0aGF0IHRoZXJlIHdvdWxk IGJlIDxicj4NCmNhc2VzIHdoZXJlIHRyYWZmaWMgcGF0dGVybiBhbm9tb2xpZXMgYXJlIGZvdW5k IGFuZCB0aGUgYXBwcm9wcmlhdGUgPGJyPg0KdGhpbmcgd291bGQgYmUgdG8gdHJ5IHRvIGRldGVy bWluZSBpZiBhIG5ldyBwcm90b2NvbCBoYWQgYmVlbiBkZXBsb3llZCA8YnI+DQphbmQgbW9uaXRv ciBpdCwgaWYgbm90LCB0aGVuIHRoZSBuZXh0IG1vc3Qgb2J2aW91cyB0aGluZyBjb3VsZCBiZSB0 byA8YnI+DQpibG9jayBhbGwgdW5leHBlY3RlZCB0cmFmZmljLCB0aGF0IHNlZW1zIGxpa2UgYSBk ZWNpc2lvbiB0byBoaWRlIHRoZSA8YnI+DQp2ZXJzaW9uIGNvdWxkIGluY3JlYXNlIG9zc2lmaWNh dGlvbiBmb3IgbmV3IHZlcnNpb25zIGluIHRoZXNlIGNhc2VzLiA8YnI+DQo8YnI+DQooMykgU2lt aWxhcmx5LCBpZiBhIHRocmVhdCBpcyBrbm93biB0byBpbXBhY3Qgb25seSBhIHNwZWNpZmljIChv bGRlcikgPGJyPg0KdmVyc2lvbiwgaXQgd291bGQgc2VlbSB0byBtb3RpdmF0ZSBhIGRyb3Agb2Yg dGhhdCB0cmFmZmljIHRoYXQgc2Vla3MgdG8gPGJyPg0KdXNlIHRoYXQgdmVyc2lvbiwgd2hpbGUg c3RpbGwgcGVybWl0dGluZyBvdGhlciB0cmFmZmljLiBGb3JjaW5nIHZlcnNpb24gPGJyPg0KZGV0 ZWN0aW9uIHRvIHVzZSBwYXR0ZXJuIG1hdGNoaW5nL01MIHdpbGwgbGVhZCB0byBsZXNzIHByZWRp Y3RhYmxlIDxicj4NCm91dGNvbWVzLCBvciBibG9ja2luZyBiYXNlZCBvbiBhZGRyZXNzLCBldGMu IDxicj4NCjxicj4NCig0KSBUaGlzIG9iZnVzdGljYXRlcyB0aGUgbW9zdCBiYXNpYyBwaWVjZSBv ZiByZXBvcnRpbmcgaW5mb3JtYXRpb24gdXNlZCA8YnI+DQpmb3Igc3VwcG9ydC4gSXQgaGlkZXMg dGhlIGV4dGVudCBvZiBkZXBsb3ltZW50IG9mIHRoZSBjdXJyZW50IHByb3RvY29sIDxicj4NCnZl cnNpb24gYW5kIHByZXZsYW5jZSBvZiBvbGQgaW1wbGVtZW50YXRpb25zLiA8YnI+DQo8YnI+DQoo NSkgT24gdGhlIHN1cHBvcnQsIGlmIGEgcHJvYmxlbSBvbmx5IGVtZXJnZXMgd2hlbiBhIHBhcnRp Y3VsYXIgdmVyc2lvbiA8YnI+DQppcyB1c2VkIHdpdGggYSBwYXJ0aWN1bGFyIGFkZHJlc3MsIHRo ZW4gdGhpcyBoZWxwcyBwaW5wb2ludCB0aGUgaXNzdWVzLiA8YnI+DQpNYXRjaGluZyBjbGllbnQg dmVyc2lvbnMgdG8gc2VydmVycyBpcyBtdWNoIG1vcmUgb2YgYW4gaXNzdWUgaWYgdGhlIHVzZXIg PGJyPg0KY29tbXVuaXR5IHVzZXMgYSB3aWRlIHJhbmdlIG9mIHNlcnZlcnMgKGxlc3Mgc28sIEkg ZXhwZWN0IGZvciBtYWpvciA8YnI+DQpwcm92aWRlcnM6IGdvb2dsZSwgZmFjZWJvb2ssIGV0Yywg ZXRjKSwgYnV0IHNpZ25pZmljYW50IHdoZW4gdGhlcmUgaXMgYSA8YnI+DQp1c2Ugb2YgYSBkaXZl cnNlIHNldCBvZiBleHRlcm5hbCBzaXRlcyBhbmQgc2l0ZXMgd2l0aCB0aGVpciBvd24gbG9hZCA8 YnI+DQpiYWxhbmNlcnMsIGV0YyBhbmQgYSBuZWVkIHRvIG1hbmFnZSBpbnRlcmFjdGlvbnMgd2l0 aCBMMiBzZXJ2aWNlcy4gPGJyPg0KPGJyPg0KSSBhbSBpbnRlcnN0ZWQgaW4ga25vd2luZyBpZiB0 aGlzIGlzIGxpa2VseSB0byBiZW5lZml0IG9yIGJlIGEgbmV3IG9ic3RhY2xlPyA8YnI+DQo8YnI+ DQpHb3JyeSA8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_BL0PR11MB339439D6DE80D2C69BD05A61902E0BL0PR11MB3394namp_-- From nobody Wed Apr 10 11:14:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365DA12030E for ; Wed, 10 Apr 2019 11:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 poTQZUnhS0-2 for ; Wed, 10 Apr 2019 11:14:01 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id AFB2E12004E for ; Wed, 10 Apr 2019 11:14:00 -0700 (PDT) Received: from [172.21.29.146] (unknown [152.71.207.141]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6F21D1B001BF; Wed, 10 Apr 2019 19:13:54 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-04D40974-1936-4AF3-BF1C-FBA4C2B4A6FE Mime-Version: 1.0 (1.0) Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? From: "Gorry (erg)" X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Wed, 10 Apr 2019 19:13:52 +0100 Cc: "Border, John" , Roberto Peon , "quic@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> References: <5CADADDD.7010005@erg.abdn.ac.uk> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 18:14:04 -0000 --Apple-Mail-04D40974-1936-4AF3-BF1C-FBA4C2B4A6FE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Mikkel, I do understand that various actors intentionally drop - but a= re you saying these actors would specifically choose to block a new version o= f QUIC ... I do not understand that assertion. Gorry > On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >=20 > China blocks as a rule. > Russia is running an experiment to block the rest of the internet. > USA blocks net neutrality. > EU blocks cookies. > GB blocks itself. >=20 > So blocking is not limited to what an operator considers best for business= . >=20 >=20 >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote= : >>=20 >>=20 >> I understand why people want to come down on the side of preventing ossif= ication. But, things have changed. There are a lot of more negative conseque= nces now when people unnecessarily block things. I think operators would put= a lot of pressure on vendors to not do it now and to fix it if they did "by= accident". Of course, I am only one operator. It would be nice to hear from= others...=20 >>=20 >>=20 >>=20 >> John=20 >>=20 >>=20 >> -----Original Message-----=20 >> From: QUIC On Behalf Of Roberto Peon=20 >> Sent: Wednesday, April 10, 2019 12:52 PM=20 >> To: G Fairhurst ; quic@ietf.org=20 >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?=20 >>=20 >> WARNING: The sender of this email could not be validated and may not matc= h the person in the "From" field.=20 >>=20 >> CAUTION: This email originated from outside of the organization. Do not c= lick links or open attachments unless you recognize the sender and know the c= ontent is safe.=20 >>=20 >>=20 >> You're kinda between a rock-and-a-hard-place either way:=20 >>=20 >> - We've seen how much fun ossification is in TCP and HTTP. If the thing i= s observable, it will be ossified seems to be the lesson. A lot of the reaso= n why QUIC was started in the first place was because of the inability to im= prove TCP due to this ossification.=20 >> - OTOH, there is the fear of unknown/unobservable which might cause opera= tors to block things, whether predictably or not.=20 >>=20 >> My opinion is that it is better to start with preventing ossification, an= d then if that results in too large a percentage of operators blocking thing= s, to re-evaluate.=20 >>=20 >> My guesses:=20 >> IP+port tuples and traffic patterns are still observable (for better and w= orse), which implies operators will still have significant tools for managin= g traffic. I believe that these are acted on/matched (ML or not) regardless o= f any other data presented. In other words, I have a doubt that stating the v= ersion in an observable way will prevent the use of such tools.=20 >>=20 >> Most problems I've seen associated with implementations rather than proto= col versions (though when the latter happens it is pretty severe). If you be= lieve this assertion, then acting on protocol version is less interesting th= an attempting to act based on implementation fingerprints.=20 >> -=3DR=20 >>=20 >>=20 >> =EF=BB=BFOn 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" wrote:=20 >>=20 >> Obscuring the version of a protocol seems like a major design design=20 >> decision for wider use cases. So, I'm trying to understand the=20 >> motivation for version greasing.=20 >>=20 >> (1) I know there were instances where some early versions of QUIC were=20= >> blocked due to an uninitentional matching of the header. Is there=20 >> evidence of intentional attempts to block updates to protocols?=20 >>=20 >> (2) Thinking about operating a network that cares about user support and=20= >> protection from unwanted traffic, I would expect that there would be=20 >> cases where traffic pattern anomolies are found and the appropriate=20 >> thing would be to try to determine if a new protocol had been deployed=20= >> and monitor it, if not, then the next most obvious thing could be to=20 >> block all unexpected traffic, that seems like a decision to hide the=20 >> version could increase ossification for new versions in these cases.=20 >>=20 >> (3) Similarly, if a threat is known to impact only a specific (older)=20 >> version, it would seem to motivate a drop of that traffic that seeks to=20= >> use that version, while still permitting other traffic. Forcing version=20= >> detection to use pattern matching/ML will lead to less predictable=20 >> outcomes, or blocking based on address, etc.=20 >>=20 >> (4) This obfusticates the most basic piece of reporting information used=20= >> for support. It hides the extent of deployment of the current protocol=20= >> version and prevlance of old implementations.=20 >>=20 >> (5) On the support, if a problem only emerges when a particular version=20= >> is used with a particular address, then this helps pinpoint the issues.=20= >> Matching client versions to servers is much more of an issue if the user=20= >> community uses a wide range of servers (less so, I expect for major=20 >> providers: google, facebook, etc, etc), but significant when there is a=20= >> use of a diverse set of external sites and sites with their own load=20 >> balancers, etc and a need to manage interactions with L2 services.=20 >>=20 >> I am intersted in knowing if this is likely to benefit or be a new obstac= le?=20 >>=20 >> Gorry=20 >>=20 >>=20 >>=20 --Apple-Mail-04D40974-1936-4AF3-BF1C-FBA4C2B4A6FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Tha= nks Mikkel, I do understand that various actors intentionally drop - but are= you saying these actors would specifically choose to block a new version of= QUIC ...  I do not understand that assertion.
Gorry

On 10 Apr 2019, at 1= 8:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

= Let=E2=80=99s say = =C2=A0China makes a deal with Google to allow their search engine (a not en= tirely unreasonably proposition).
The Great Firewall of China (GFC) is reconfigured to= accept traffic from a specific IP range for QUIC protocol v1.

Google later upgrades to v2. = GFC is updated. Later, out of ignorance, some other department within said = company decides that its browsers should all use forced version aliases as = a rule. GFC breaks. (Assuming Googles servers are not located within the de= militarised zone and users use Chrome).

Alternative 1: Google up front decides to deploy forced = version aliasing. China rejects the deal because they do not want to suppor= t random traffic through GFC.

Alternative 2: Google up front decides to deploy forced version al= iasing, and China does not reject the deal, out of ignorance. Later some de= partment in China GFC oversight realises the deal and forces Google to remo= ve forced version aliasing, or shut down its service.

Alternative 3: Google up front decides to = deploy forced version aliasing and China says, of course, we trust everythi= ng from Googles IP range.

Alternative 4: Google realises that forced version aliasing does not w= ork in the general case, and makes a special case for users within a certai= n geographical area.

= Disclaimer: I=E2=80=99m not affiliated with Google and this might not at al= l be how things would work, but it does highlight some of the challenges.

Of course, to be fair,= China is not the only government entity that might have a vested interest.= Let's take a fictional example of US a real estate investor with heavy= ties to the eastern european block who somehow finds himself elected as pr= esident needing to find leverage on trade negotiations without effectively = hurting personal finances. It turns out that blocking certain digital servi= ces from said eastern european block is the perfect tool in the trade negot= iations. Advisers point out that those services run heavily encrypted on th= e dark web with perpetual circulation of IP ranges so, ignoring any legal c= oncerns, it would not be practically possible. Eventually someone figures o= ut that these services all usually are at the forefront of technology and c= urrently use QUIC v3.2 and no-one else has deployed that version yet, so it= would suffice to ask NSA to tap into the backbone and disrupt specific pac= kets. Of course, this ends up taking down the Bavarian local government ele= ction process in Germany where they are the first to use a new digital elec= tion system. Not that the is an issue, since trade negotiations are also ru= nning hot in that area, so that is just an accidental bonus.

Or an endless number of other dev= elopments over the next few decades if the past few years is anything to go= by.



<= p class=3D"airmail_on">On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote:

=
Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ...=C2=A0 I do not understand that assertion.

Gorry

On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

China blocks as a rule.
Russia is running an experiment to block the rest of the internet.
USA blocks net neutrality.
EU blocks cookies.
GB blocks itself.

So blocking is not limited to what an operator considers best for business.


On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote:


I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others...



John


-----Original Message-----
From: QUIC <quic-bounces@ietf.o= rg> On Behalf Of Roberto Peon
Sent: Wednesday, April 10, 2019 12:52 PM
To: G Fairhurst <gorry@erg.abdn.= ac.uk>; quic@ietf.org
Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?

WARNING: The sender of this email could not be validated and may not match the person in the "From" field.

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


You're kinda between a rock-and-a-hard-place either way:

- We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification.
- OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not.

My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate.

My guesses:
IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In other words, I have a doubt that stating the version in an observable way will prevent the use of such tools.

Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe). If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation fingerprints.
-=3DR


=EF=BB=BFOn 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" <= ;quic-bounces@ietf.org on beha= lf of gorry@erg.abdn.ac.uk> wrote:

Obscuring the version of a protocol seems like a major design design
decision for wider use cases. So, I'm trying to understand the
motivation for version greasing.

(1) I know there were instances where some early versions of QUIC were
blocked due to an uninitentional matching of the header. Is there
evidence of intentional attempts to block updates to protocols?

(2) Thinking about operating a network that cares about user support and
protection from unwanted traffic, I would expect that there would be
cases where traffic pattern anomolies are found and the appropriate
thing would be to try to determine if a new protocol had been deployed
and monitor it, if not, then the next most obvious thing could be to
block all unexpected traffic, that seems like a decision to hide the
version could increase ossification for new versions in these cases.

(3) Similarly, if a threat is known to impact only a specific (older)
version, it would seem to motivate a drop of that traffic that seeks to
use that version, while still permitting other traffic. Forcing version
detection to use pattern matching/ML will lead to less predictable
outcomes, or blocking based on address, etc.

(4) This obfusticates the most basic piece of reporting information used
for support. It hides the extent of deployment of the current protocol
version and prevlance of old implementations.

(5) On the support, if a problem only emerges when a particular version
is used with a particular address, then this helps pinpoint the issues.
Matching client versions to servers is much more of an issue if the user
community uses a wide range of servers (less so, I expect for major
providers: google, facebook, etc, etc), but significant when there is a
use of a diverse set of external sites and sites with their own load
balancers, etc and a need to manage interactions with L2 services.

I am intersted in knowing if this is likely to benefit or be a new obstacle?

Gorry



 --00000000000076e4e60586327846-- From nobody Wed Apr 10 18:29:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AA2120125 for ; Wed, 10 Apr 2019 18:29:19 -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=lowentropy.net header.b=H1YH4U4j; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MYarvMW+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAvlCUgYLSBa for ; Wed, 10 Apr 2019 18:29:18 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DCA1120075 for ; Wed, 10 Apr 2019 18:29:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6EC0E214DB; Wed, 10 Apr 2019 21:29:17 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 10 Apr 2019 21:29:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=3ShgeMfy6ilMXLOOlCQn/wAprrKK VcWoFzWGi6LeiKQ=; b=H1YH4U4j3AwtCbiCmfOdpgg0+Z8SYfMtK8AmnYMa1wgS ycc3/yEXzgZV+YToSH7cBjsWDBVFu7QXcV3Fka67UsZX4fftwtZV7ZWVBbTDBtqx 94bkSw7XdcC22TjyqoQ11XkZpB5ZPlV+1TfuPEazjVjFFFzpEOTqpB5XbgMyx6HZ HpL1o9m2UldIS9bAKrKxKOrZVbKepHETpLBh46VXgKIz1dOUAqt0Od4nhl9WQjVW qK2RCqqPNX557VZe4iQMpg/y+kfFKD/F1LG5OEqetOrcc6AAnCPobCDL9r0lZhx6 /0BlbUY8g4cRrXjZ/n3tpcB9Q+LbId4v7AVUGkZvlw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3ShgeM fy6ilMXLOOlCQn/wAprrKKVcWoFzWGi6LeiKQ=; b=MYarvMW+5ThqzPqLljaqut 6C6FA/8c8u13nJ5tmuZSDuDaXJocJCuDuLeqmbNSpjJRgFUzZM010bH7M9qZAB7Y jKP05usjVZAOx1Fq1jnKTkXrsxeAToZnB9BLNlwbZ1KQg95iLC7VXms4YzOQ0BZu +c5/cptXqTcX8d+0AdFHUFBtjAjlZAernLgU0ja9Odet+VAPMqDzJtICtymbkOGr xUlqbEfAKz3NE8dxTwefNgguRDK1W28jdw0voELrFYxxUWSqS+lLRgb3e4+Y4Bxl AdQThseJs+dgWEKdqM2lZQdJ+ezl/Gp768iI/6DrEsvuL2u90XcP4bygDy+yC1gA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudekgdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F0D6C7C1B9; Wed, 10 Apr 2019 21:29:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <6fb2a0b7-c3cf-45a0-8824-0cae384be1cc@www.fastmail.com> In-Reply-To: References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.com> Date: Wed, 10 Apr 2019 21:29:20 -0400 From: "Martin Thomson" To: "Mirja Kuehlewind" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "Kazuho Oku" Cc: "IETF QUIC WG" Subject: Re: Version Negotiation Greasing Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 01:29:20 -0000 On Wed, Apr 10, 2019, at 23:04, Mirja Kuehlewind wrote: > Further thinking about this. I do understand that this requirement is > needed to actually avoid blocking of alt-version, however, would > anybody actually be ever willing to implement this? If you service does > not get connectivity with the alt-version, is it not very tempting to > also try the actual version in order to serve your user/customer at all? The number of layers of fallback-and-retry that we maintain is already fairly terrible[1], so I suspect that we'll skip that step and fall straight back to h2. [1] We don't want to add to happy eyeballs, alt-svc, network-level connection retries, the eventual parallel QUIC/h2 attempts, and HTTP request-level retries. From nobody Wed Apr 10 18:45:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A22120123 for ; Wed, 10 Apr 2019 18:45:13 -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=lowentropy.net header.b=VIOPAyhr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=35ldoxGt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-7A-oTfOp7h for ; Wed, 10 Apr 2019 18:45:11 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E311120142 for ; Wed, 10 Apr 2019 18:45:11 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 465F72013C for ; Wed, 10 Apr 2019 21:45:10 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 10 Apr 2019 21:45:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=SobN1iHvhFoPskiFsqtKz4rRIj2020X PHxH4D0fEjjc=; b=VIOPAyhrW9SNVmWPzLQc/DDyYeNK7EmVWI6ruqoiHtMPLHK jAYzinQAIx4jhgkwB6mAbofyIKRtE/CFYOHdLHdh8xCQvVOfO3i5E4FUp22FvKEq cQzcLvh8G1PJfrHDSAtw/IbX9IoxIW3sslXkHfn9ZrI/9gs4a9jJIjwB1x31n1/0 2GGHwdvstltkTXEpcwkOhmuy0B+lBsxeIaw9CwhUlWh6xx2cfAFDdgaK1J2y3if/ nnBJ88AK6osHfuhTaekzbJcYsRCn6z7DlxtS9NdghiKVsFVKU7vpHJQgFSC8GZzk zj/bLZhoiV1XOjx47/Wej41v8sOWZSXDQEhnl0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=SobN1i HvhFoPskiFsqtKz4rRIj2020XPHxH4D0fEjjc=; b=35ldoxGt+o3A5vn6yNtkes KcmFyXwSZVyqhfNOOy57mKJoWCk7Qni85b+kgw3GJmkugOecgd7yvU6URCGmdxey XXVETIMq3vOVmH4TOGvXcUj89VmWUhcjLrF5ZTsGO3pUuiX/NO/7uBFQVL4K8OOy XghNB8Cr/XMtCrE8LaU6zmQQYpABei7p49vuN9CAWrOJuK2yXjQDulP8+H+BSzYc NvZYFFH56QmMWE2s1HiUQ48nNv+eCoQzkQ7w0MSwV/+2jJvWIs52qp1yPoAYdTTK sIyDrdHFzizDJdxS9o5Hwsw1sOkZiCgv6XnRzqLkD3f1EKBUkYVY97q7lwLYw6Hw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudekgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B109B7C1B9; Wed, 10 Apr 2019 21:45:09 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: <5CADADDD.7010005@erg.abdn.ac.uk> References: <5CADADDD.7010005@erg.abdn.ac.uk> Date: Wed, 10 Apr 2019 21:45:13 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 01:45:14 -0000 It's always possible to come up with a scenario where the network helps here, but the cost of help is the risk of harm. I would cast this question differently: who has the right(?) to decide when a new version of the protocol is permitted? The motivation behind this is that it is considerably more likely if only endpoints are involved in that process. The architectural consequences of protecting a "clean" version negotiation process are what makes me positive about this change. It is always possible to invent a new version negotiation process that looks very much like QUIC v1, but enables the use of v2. That is what we ended up doing for the TLS 1.2 to 1.3 transition. For instance, you could learn that you can negotiate QUICv2 by changing the case of certain characters in the server_name extension. Or you could use the ordering of transport parameters to signal the support for an alternative version. If you are willing to tolerate a risk of downgrade, then you can even negotiate different versions in a way that can't be detected without access to session keys. I don't want to have to repeat the ugly hacks we had to add to TLS. If we can deploy aliasing, I have a little hope that we can use the versionin gmechanism we have designed. On Wed, Apr 10, 2019, at 18:48, G Fairhurst wrote: > Obscuring the version of a protocol seems like a major design design > decision for wider use cases. So, I'm trying to understand the > motivation for version greasing. > > (1) I know there were instances where some early versions of QUIC were > blocked due to an uninitentional matching of the header. Is there > evidence of intentional attempts to block updates to protocols? > > (2) Thinking about operating a network that cares about user support and > protection from unwanted traffic, I would expect that there would be > cases where traffic pattern anomolies are found and the appropriate > thing would be to try to determine if a new protocol had been deployed > and monitor it, if not, then the next most obvious thing could be to > block all unexpected traffic, that seems like a decision to hide the > version could increase ossification for new versions in these cases. > > (3) Similarly, if a threat is known to impact only a specific (older) > version, it would seem to motivate a drop of that traffic that seeks to > use that version, while still permitting other traffic. Forcing version > detection to use pattern matching/ML will lead to less predictable > outcomes, or blocking based on address, etc. > > (4) This obfusticates the most basic piece of reporting information used > for support. It hides the extent of deployment of the current protocol > version and prevlance of old implementations. > > (5) On the support, if a problem only emerges when a particular version > is used with a particular address, then this helps pinpoint the issues. > Matching client versions to servers is much more of an issue if the user > community uses a wide range of servers (less so, I expect for major > providers: google, facebook, etc, etc), but significant when there is a > use of a diverse set of external sites and sites with their own load > balancers, etc and a need to manage interactions with L2 services. > > I am intersted in knowing if this is likely to benefit or be a new obstacle? > > Gorry > > From nobody Thu Apr 11 01:03:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4B3120288 for ; Thu, 11 Apr 2019 01:03:18 -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, DKIMWL_WL_HIGH=-0.001, 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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kBGY91rz275 for ; Thu, 11 Apr 2019 01:03:16 -0700 (PDT) Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120073.outbound.protection.outlook.com [40.107.12.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7A612017D for ; Thu, 11 Apr 2019 01:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J9mm2s/D17tUSi+QFUctRCW3s8bGtmu4D46VRmHu7MI=; b=lfjgl1R4dipePRBewxu9OVObyY3Ggr34YCowk+KZP5xKELZ0zMtpShp1cRmSu4uh7q93qIYKnh5/Fer86jBcHhnWpSwWbb1NkHoZn1PbQx0La7wyS44GnAs8mp9TkCji2bLTm5ZeFsX+Wg+vUZxud770gMSgOef9MTF46Dgw4eg= Received: from PR1PR07MB5898.eurprd07.prod.outlook.com (20.177.212.19) by PR1PR07MB5739.eurprd07.prod.outlook.com (20.177.210.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.12; Thu, 11 Apr 2019 08:03:12 +0000 Received: from PR1PR07MB5898.eurprd07.prod.outlook.com ([fe80::9d5b:fab9:4cc2:2f0d]) by PR1PR07MB5898.eurprd07.prod.outlook.com ([fe80::9d5b:fab9:4cc2:2f0d%5]) with mapi id 15.20.1792.009; Thu, 11 Apr 2019 08:03:12 +0000 From: Mirja Kuehlewind To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Gorry (erg)" CC: "quic@ietf.org" , "Border, John" , Roberto Peon Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73pAMRMlXHrk8EeORXfrw42uF6Y1nGCAgAACAYCAAAdsgIAADYwAgAAcxACAAOx4gA== Date: Thu, 11 Apr 2019 08:03:12 +0000 Message-ID: <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> 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=mirja.kuehlewind@ericsson.com; x-originating-ip: [192.176.1.97] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8135a49c-458f-43de-24d8-08d6be542506 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:PR1PR07MB5739; x-ms-traffictypediagnostic: PR1PR07MB5739: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(39860400002)(396003)(346002)(189003)(13464003)(199004)(33656002)(6506007)(316002)(2906002)(44832011)(36756003)(14454004)(229853002)(53546011)(476003)(6116002)(486006)(4326008)(7736002)(26005)(81166006)(81156014)(6246003)(186003)(3846002)(8676002)(99286004)(102836004)(110136005)(71190400001)(2616005)(305945005)(5024004)(66574012)(8936002)(478600001)(25786009)(82746002)(11346002)(256004)(6512007)(14444005)(53936002)(83716004)(54906003)(93886005)(106356001)(446003)(97736004)(66066001)(105586002)(6436002)(76176011)(68736007)(5660300002)(86362001)(6486002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:PR1PR07MB5739; H:PR1PR07MB5898.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MX4W9R+QJi2Nv0pRUspAmCcClvm6kr+esVYyF7k378w09C1GMbhwqmFPnKEos+5lQMXpZ38eJBvXa9O7pVDk7i/AVuq6wrG3LleT6Wb1j45AT7e6xQfwZQ4BoLBv47tgCbbvAfUyXi7XNd3oKoer3zaVao6a2xq0JTMYJZBpvPNFs5LKAd7VucZ9I/S1KzeRGZf/Mdd2SlXv4WWdVMnbvNMKZ9J3b5kAZs5lGvrPM3+PDcUkGpPAiU7VA17q5MRfv/RttrEdfxV35qXlTOfh8yFE1cb3HOiO8apTUNh2ufbrtSnWVtAHXN+c0cHtsEu0JGDInRhoLSbtrdUu05MxQ9m16GKh+HnVL0yfXdk9Slwepc4rbQKVm1e/KXwBhmm3b9fqgKiHmVHy4Md1U6KT5TmzK+OUH5k4UOeq8iFyIGs= Content-Type: text/plain; charset="utf-8" Content-ID: <130A50493CB7384699A8F397013CC5F3@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8135a49c-458f-43de-24d8-08d6be542506 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 08:03:12.5602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5739 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 08:03:19 -0000 SGkgTWlra2VsLA0KDQpJIGd1ZXNzIGl0IGlzIG11Y2ggbW9yZSBsaWtlbHkgdGhhdCBhbnkgb2Yg dGhvc2UgYWN0b3JzIHdvdWxkIGp1c3QgYmxvY2sgUVVJQyBhbGwgdG9nZXRoZXIgKGFzIHRoZXJl IGlzIGFjdHVhbGx5IGEgZmFsbGJhY2sgdG8gVENQKS4NCg0KTWlyamENCg0KDQoNCu+7v09uIDEw LjA0LjE5LCAyMTo1NywgIlFVSUMgb24gYmVoYWxmIG9mIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5z ZW4iIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1pa2tlbGZqQGdtYWlsLmNv bT4gd3JvdGU6DQoNCiAgICANCiAgICBMZXTigJlzIHNheSAgQ2hpbmEgbWFrZXMgYSBkZWFsIHdp dGggR29vZ2xlIHRvIGFsbG93IHRoZWlyIHNlYXJjaCBlbmdpbmUgKGEgbm90IGVudGlyZWx5IHVu cmVhc29uYWJseSBwcm9wb3NpdGlvbikuDQogICAgVGhlIEdyZWF0IEZpcmV3YWxsIG9mIENoaW5h IChHRkMpIGlzIHJlY29uZmlndXJlZCB0byBhY2NlcHQgdHJhZmZpYyBmcm9tIGEgc3BlY2lmaWMg SVAgcmFuZ2UgZm9yIFFVSUMgcHJvdG9jb2wgdjEuDQogICAgDQogICAgDQogICAgDQogICAgR29v Z2xlIGxhdGVyIHVwZ3JhZGVzIHRvIHYyLiBHRkMgaXMgdXBkYXRlZC4gTGF0ZXIsIG91dCBvZiBp Z25vcmFuY2UsIHNvbWUgb3RoZXIgZGVwYXJ0bWVudCB3aXRoaW4gc2FpZCBjb21wYW55IGRlY2lk ZXMgdGhhdCBpdHMgYnJvd3NlcnMgc2hvdWxkIGFsbCB1c2UgZm9yY2VkIHZlcnNpb24gYWxpYXNl cyBhcyBhIHJ1bGUuIEdGQyBicmVha3MuIChBc3N1bWluZyBHb29nbGVzIHNlcnZlcnMgYXJlIG5v dCBsb2NhdGVkIHdpdGhpbiB0aGUgZGVtaWxpdGFyaXNlZA0KICAgICB6b25lIGFuZCB1c2VycyB1 c2UgQ2hyb21lKS4NCiAgICANCiAgICANCiAgICBBbHRlcm5hdGl2ZSAxOiBHb29nbGUgdXAgZnJv bnQgZGVjaWRlcyB0byBkZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcuIENoaW5hIHJlamVj dHMgdGhlIGRlYWwgYmVjYXVzZSB0aGV5IGRvIG5vdCB3YW50IHRvIHN1cHBvcnQgcmFuZG9tIHRy YWZmaWMgdGhyb3VnaCBHRkMuDQogICAgDQogICAgDQogICAgQWx0ZXJuYXRpdmUgMjogR29vZ2xl IHVwIGZyb250IGRlY2lkZXMgdG8gZGVwbG95IGZvcmNlZCB2ZXJzaW9uIGFsaWFzaW5nLCBhbmQg Q2hpbmEgZG9lcyBub3QgcmVqZWN0IHRoZSBkZWFsLCBvdXQgb2YgaWdub3JhbmNlLiBMYXRlciBz b21lIGRlcGFydG1lbnQgaW4gQ2hpbmEgR0ZDIG92ZXJzaWdodCByZWFsaXNlcyB0aGUgZGVhbCBh bmQgZm9yY2VzIEdvb2dsZSB0byByZW1vdmUgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcsIG9yIHNo dXQgZG93bg0KICAgICBpdHMgc2VydmljZS4NCiAgICANCiAgICANCiAgICBBbHRlcm5hdGl2ZSAz OiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0byBkZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNp bmcgYW5kIENoaW5hIHNheXMsIG9mIGNvdXJzZSwgd2UgdHJ1c3QgZXZlcnl0aGluZyBmcm9tIEdv b2dsZXMgSVAgcmFuZ2UuDQogICAgDQogICAgDQogICAgQWx0ZXJuYXRpdmUgNDogR29vZ2xlIHJl YWxpc2VzIHRoYXQgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcgZG9lcyBub3Qgd29yayBpbiB0aGUg Z2VuZXJhbCBjYXNlLCBhbmQgbWFrZXMgYSBzcGVjaWFsIGNhc2UgZm9yIHVzZXJzIHdpdGhpbiBh IGNlcnRhaW4gZ2VvZ3JhcGhpY2FsIGFyZWEuDQogICAgDQogICAgDQogICAgRGlzY2xhaW1lcjog SeKAmW0gbm90IGFmZmlsaWF0ZWQgd2l0aCBHb29nbGUgYW5kIHRoaXMgbWlnaHQgbm90IGF0IGFs bCBiZSBob3cgdGhpbmdzIHdvdWxkIHdvcmssIGJ1dCBpdCBkb2VzIGhpZ2hsaWdodCBzb21lIG9m IHRoZSBjaGFsbGVuZ2VzLg0KICAgIA0KICAgIA0KICAgIE9mIGNvdXJzZSwgdG8gYmUgZmFpciwg Q2hpbmEgaXMgbm90IHRoZSBvbmx5IGdvdmVybm1lbnQgZW50aXR5IHRoYXQgbWlnaHQgaGF2ZSBh IHZlc3RlZCBpbnRlcmVzdC4gTGV0J3MgdGFrZSBhIGZpY3Rpb25hbCBleGFtcGxlIG9mIFVTIGEg cmVhbCBlc3RhdGUgaW52ZXN0b3Igd2l0aCBoZWF2eSB0aWVzIHRvIHRoZSBlYXN0ZXJuIGV1cm9w ZWFuIGJsb2NrIHdobyBzb21laG93IGZpbmRzIGhpbXNlbGYgZWxlY3RlZCBhcyBwcmVzaWRlbnQg bmVlZGluZw0KICAgICB0byBmaW5kIGxldmVyYWdlIG9uIHRyYWRlIG5lZ290aWF0aW9ucyB3aXRo b3V0IGVmZmVjdGl2ZWx5IGh1cnRpbmcgcGVyc29uYWwgZmluYW5jZXMuIEl0IHR1cm5zIG91dCB0 aGF0IGJsb2NraW5nIGNlcnRhaW4gZGlnaXRhbCBzZXJ2aWNlcyBmcm9tIHNhaWQgZWFzdGVybiBl dXJvcGVhbiBibG9jayBpcyB0aGUgcGVyZmVjdCB0b29sIGluIHRoZSB0cmFkZSBuZWdvdGlhdGlv bnMuIEFkdmlzZXJzIHBvaW50IG91dCB0aGF0IHRob3NlIHNlcnZpY2VzDQogICAgIHJ1biBoZWF2 aWx5IGVuY3J5cHRlZCBvbiB0aGUgZGFyayB3ZWIgd2l0aCBwZXJwZXR1YWwgY2lyY3VsYXRpb24g b2YgSVAgcmFuZ2VzIHNvLCBpZ25vcmluZyBhbnkgbGVnYWwgY29uY2VybnMsIGl0IHdvdWxkIG5v dCBiZSBwcmFjdGljYWxseSBwb3NzaWJsZS4gRXZlbnR1YWxseSBzb21lb25lIGZpZ3VyZXMgb3V0 IHRoYXQgdGhlc2Ugc2VydmljZXMgYWxsIHVzdWFsbHkgYXJlIGF0IHRoZSBmb3JlZnJvbnQgb2Yg dGVjaG5vbG9neSBhbmQgY3VycmVudGx5DQogICAgIHVzZSBRVUlDIHYzLjIgYW5kIG5vLW9uZSBl bHNlIGhhcyBkZXBsb3llZCB0aGF0IHZlcnNpb24geWV0LCBzbyBpdCB3b3VsZCBzdWZmaWNlIHRv IGFzayBOU0EgdG8gdGFwIGludG8gdGhlIGJhY2tib25lIGFuZCBkaXNydXB0IHNwZWNpZmljIHBh Y2tldHMuIE9mIGNvdXJzZSwgdGhpcyBlbmRzIHVwIHRha2luZyBkb3duIHRoZSBCYXZhcmlhbiBs b2NhbCBnb3Zlcm5tZW50IGVsZWN0aW9uIHByb2Nlc3MgaW4gR2VybWFueSB3aGVyZSB0aGV5IGFy ZQ0KICAgICB0aGUgZmlyc3QgdG8gdXNlIGEgbmV3IGRpZ2l0YWwgZWxlY3Rpb24gc3lzdGVtLiBO b3QgdGhhdCB0aGUgaXMgYW4gaXNzdWUsIHNpbmNlIHRyYWRlIG5lZ290aWF0aW9ucyBhcmUgYWxz byBydW5uaW5nIGhvdCBpbiB0aGF0IGFyZWEsIHNvIHRoYXQgaXMganVzdCBhbiBhY2NpZGVudGFs IGJvbnVzLg0KICAgIA0KICAgIA0KICAgIE9yIGFuIGVuZGxlc3MgbnVtYmVyIG9mIG90aGVyIGRl dmVsb3BtZW50cyBvdmVyIHRoZSBuZXh0IGZldyBkZWNhZGVzIGlmIHRoZSBwYXN0IGZldyB5ZWFy cyBpcyBhbnl0aGluZyB0byBnbyBieS4NCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAg ICBPbiAxMCBBcHJpbCAyMDE5IGF0IDIwLjEzLjU5LCBHb3JyeSAoZXJnKSAoZ29ycnlAZXJnLmFi ZG4uYWMudWspIHdyb3RlOg0KICAgIA0KICAgIFRoYW5rcyBNaWtrZWwsIEkgZG8gdW5kZXJzdGFu ZCB0aGF0IHZhcmlvdXMgYWN0b3JzIGludGVudGlvbmFsbHkgZHJvcCAtIGJ1dCBhcmUgeW91IHNh eWluZyB0aGVzZSBhY3RvcnMgd291bGQgc3BlY2lmaWNhbGx5IGNob29zZSB0byBibG9jayBhIG5l dyB2ZXJzaW9uIG9mIFFVSUMgLi4uICBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoYXQgYXNzZXJ0aW9u Lg0KICAgIA0KICAgIA0KICAgIEdvcnJ5DQogICAgDQogICAgT24gMTAgQXByIDIwMTksIGF0IDE4 OjI1LCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+IHdyb3Rl Og0KICAgIA0KICAgIA0KICAgIA0KICAgIENoaW5hIGJsb2NrcyBhcyBhIHJ1bGUuDQogICAgUnVz c2lhIGlzIHJ1bm5pbmcgYW4gZXhwZXJpbWVudCB0byBibG9jayB0aGUgcmVzdCBvZiB0aGUgaW50 ZXJuZXQuDQogICAgVVNBIGJsb2NrcyBuZXQgbmV1dHJhbGl0eS4NCiAgICBFVSBibG9ja3MgY29v a2llcy4NCiAgICBHQiBibG9ja3MgaXRzZWxmLg0KICAgIA0KICAgIA0KICAgIFNvIGJsb2NraW5n IGlzIG5vdCBsaW1pdGVkIHRvIHdoYXQgYW4gb3BlcmF0b3IgY29uc2lkZXJzIGJlc3QgZm9yIGJ1 c2luZXNzLg0KICAgIA0KICAgIA0KICAgIA0KICAgIE9uIDEwIEFwcmlsIDIwMTkgYXQgMTguNTku MTUsIEJvcmRlciwgSm9obiAoam9obi5ib3JkZXJAaHVnaGVzLmNvbSkgd3JvdGU6DQogICAgDQog ICAgDQogICAgSSB1bmRlcnN0YW5kIHdoeSBwZW9wbGUgd2FudCB0byBjb21lIGRvd24gb24gdGhl IHNpZGUgb2YgcHJldmVudGluZyBvc3NpZmljYXRpb24uIEJ1dCwgdGhpbmdzIGhhdmUgY2hhbmdl ZC4gVGhlcmUgYXJlIGEgbG90IG9mIG1vcmUgbmVnYXRpdmUgY29uc2VxdWVuY2VzIG5vdyB3aGVu IHBlb3BsZSB1bm5lY2Vzc2FyaWx5IGJsb2NrIHRoaW5ncy4gSSB0aGluayBvcGVyYXRvcnMgd291 bGQgcHV0IGEgbG90IG9mIHByZXNzdXJlIG9uIHZlbmRvcnMgdG8NCiAgICAgbm90IGRvIGl0IG5v dyBhbmQgdG8gZml4IGl0IGlmIHRoZXkgZGlkICJieSBhY2NpZGVudCIuIE9mIGNvdXJzZSwgSSBh bSBvbmx5IG9uZSBvcGVyYXRvci4gSXQgd291bGQgYmUgbmljZSB0byBoZWFyIGZyb20gb3RoZXJz Li4uDQogICAgDQogICAgDQogICAgDQogICAgSm9obg0KICAgIA0KICAgIA0KICAgIC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgUm9iZXJ0byBQZW9uDQogICAgU2VudDogV2VkbmVzZGF5LCBBcHJpbCAx MCwgMjAxOSAxMjo1MiBQTQ0KICAgIFRvOiBHIEZhaXJodXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMu dWs+Ow0KICAgIHF1aWNAaWV0Zi5vcmcNCiAgICBTdWJqZWN0OiBSZTogSXMgIlZlcnNpb24gR3Jl YXNpbmciIGEgbmV3IGJlbmZpdCBvciBhIG5ldyBvYnN0YWNsZT8NCiAgICANCiAgICBXQVJOSU5H OiBUaGUgc2VuZGVyIG9mIHRoaXMgZW1haWwgY291bGQgbm90IGJlIHZhbGlkYXRlZCBhbmQgbWF5 IG5vdCBtYXRjaCB0aGUgcGVyc29uIGluIHRoZSAiRnJvbSIgZmllbGQuDQogICAgDQogICAgQ0FV VElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0 aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJl Y29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQogICAgDQog ICAgDQogICAgWW91J3JlIGtpbmRhIGJldHdlZW4gYSByb2NrLWFuZC1hLWhhcmQtcGxhY2UgZWl0 aGVyIHdheToNCiAgICANCiAgICAtIFdlJ3ZlIHNlZW4gaG93IG11Y2ggZnVuIG9zc2lmaWNhdGlv biBpcyBpbiBUQ1AgYW5kIEhUVFAuIElmIHRoZSB0aGluZyBpcyBvYnNlcnZhYmxlLCBpdCB3aWxs IGJlIG9zc2lmaWVkIHNlZW1zIHRvIGJlIHRoZSBsZXNzb24uIEEgbG90IG9mIHRoZSByZWFzb24g d2h5IFFVSUMgd2FzIHN0YXJ0ZWQgaW4gdGhlIGZpcnN0IHBsYWNlIHdhcyBiZWNhdXNlIG9mIHRo ZSBpbmFiaWxpdHkgdG8gaW1wcm92ZSBUQ1AgZHVlIHRvIHRoaXMgb3NzaWZpY2F0aW9uLg0KICAg IC0gT1RPSCwgdGhlcmUgaXMgdGhlIGZlYXIgb2YgdW5rbm93bi91bm9ic2VydmFibGUgd2hpY2gg bWlnaHQgY2F1c2Ugb3BlcmF0b3JzIHRvIGJsb2NrIHRoaW5ncywgd2hldGhlciBwcmVkaWN0YWJs eSBvciBub3QuDQogICAgDQogICAgTXkgb3BpbmlvbiBpcyB0aGF0IGl0IGlzIGJldHRlciB0byBz dGFydCB3aXRoIHByZXZlbnRpbmcgb3NzaWZpY2F0aW9uLCBhbmQgdGhlbiBpZiB0aGF0IHJlc3Vs dHMgaW4gdG9vIGxhcmdlIGEgcGVyY2VudGFnZSBvZiBvcGVyYXRvcnMgYmxvY2tpbmcgdGhpbmdz LCB0byByZS1ldmFsdWF0ZS4NCiAgICANCiAgICBNeSBndWVzc2VzOg0KICAgIElQK3BvcnQgdHVw bGVzIGFuZCB0cmFmZmljIHBhdHRlcm5zIGFyZSBzdGlsbCBvYnNlcnZhYmxlIChmb3IgYmV0dGVy IGFuZCB3b3JzZSksIHdoaWNoIGltcGxpZXMgb3BlcmF0b3JzIHdpbGwgc3RpbGwgaGF2ZSBzaWdu aWZpY2FudCB0b29scyBmb3IgbWFuYWdpbmcgdHJhZmZpYy4gSSBiZWxpZXZlIHRoYXQgdGhlc2Ug YXJlIGFjdGVkIG9uL21hdGNoZWQgKE1MIG9yIG5vdCkgcmVnYXJkbGVzcyBvZiBhbnkgb3RoZXIg ZGF0YSBwcmVzZW50ZWQuIEluDQogICAgIG90aGVyIHdvcmRzLCBJIGhhdmUgYSBkb3VidCB0aGF0 IHN0YXRpbmcgdGhlIHZlcnNpb24gaW4gYW4gb2JzZXJ2YWJsZSB3YXkgd2lsbCBwcmV2ZW50IHRo ZSB1c2Ugb2Ygc3VjaCB0b29scy4NCiAgICANCiAgICBNb3N0IHByb2JsZW1zIEkndmUgc2VlbiBh c3NvY2lhdGVkIHdpdGggaW1wbGVtZW50YXRpb25zIHJhdGhlciB0aGFuIHByb3RvY29sIHZlcnNp b25zICh0aG91Z2ggd2hlbiB0aGUgbGF0dGVyIGhhcHBlbnMgaXQgaXMgcHJldHR5IHNldmVyZSku IElmIHlvdSBiZWxpZXZlIHRoaXMgYXNzZXJ0aW9uLCB0aGVuIGFjdGluZyBvbiBwcm90b2NvbCB2 ZXJzaW9uIGlzIGxlc3MgaW50ZXJlc3RpbmcgdGhhbiBhdHRlbXB0aW5nIHRvIGFjdCBiYXNlZCBv biBpbXBsZW1lbnRhdGlvbg0KICAgICBmaW5nZXJwcmludHMuDQogICAgLT1SDQogICAgDQogICAg DQogICAgT24gNC8xMC8xOSwgMTo0OCBBTSwgIlFVSUMgb24gYmVoYWxmIG9mIEcgRmFpcmh1cnN0 IiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0KICAgIGdvcnJ5QGVyZy5hYmRu LmFjLnVrPiB3cm90ZToNCiAgICANCiAgICBPYnNjdXJpbmcgdGhlIHZlcnNpb24gb2YgYSBwcm90 b2NvbCBzZWVtcyBsaWtlIGEgbWFqb3IgZGVzaWduIGRlc2lnbg0KICAgIGRlY2lzaW9uIGZvciB3 aWRlciB1c2UgY2FzZXMuIFNvLCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlDQogICAgbW90 aXZhdGlvbiBmb3IgdmVyc2lvbiBncmVhc2luZy4NCiAgICANCiAgICAoMSkgSSBrbm93IHRoZXJl IHdlcmUgaW5zdGFuY2VzIHdoZXJlIHNvbWUgZWFybHkgdmVyc2lvbnMgb2YgUVVJQyB3ZXJlDQog ICAgYmxvY2tlZCBkdWUgdG8gYW4gdW5pbml0ZW50aW9uYWwgbWF0Y2hpbmcgb2YgdGhlIGhlYWRl ci4gSXMgdGhlcmUNCiAgICBldmlkZW5jZSBvZiBpbnRlbnRpb25hbCBhdHRlbXB0cyB0byBibG9j ayB1cGRhdGVzIHRvIHByb3RvY29scz8NCiAgICANCiAgICAoMikgVGhpbmtpbmcgYWJvdXQgb3Bl cmF0aW5nIGEgbmV0d29yayB0aGF0IGNhcmVzIGFib3V0IHVzZXIgc3VwcG9ydCBhbmQNCiAgICBw cm90ZWN0aW9uIGZyb20gdW53YW50ZWQgdHJhZmZpYywgSSB3b3VsZCBleHBlY3QgdGhhdCB0aGVy ZSB3b3VsZCBiZQ0KICAgIGNhc2VzIHdoZXJlIHRyYWZmaWMgcGF0dGVybiBhbm9tb2xpZXMgYXJl IGZvdW5kIGFuZCB0aGUgYXBwcm9wcmlhdGUNCiAgICB0aGluZyB3b3VsZCBiZSB0byB0cnkgdG8g ZGV0ZXJtaW5lIGlmIGEgbmV3IHByb3RvY29sIGhhZCBiZWVuIGRlcGxveWVkDQogICAgYW5kIG1v bml0b3IgaXQsIGlmIG5vdCwgdGhlbiB0aGUgbmV4dCBtb3N0IG9idmlvdXMgdGhpbmcgY291bGQg YmUgdG8NCiAgICBibG9jayBhbGwgdW5leHBlY3RlZCB0cmFmZmljLCB0aGF0IHNlZW1zIGxpa2Ug YSBkZWNpc2lvbiB0byBoaWRlIHRoZQ0KICAgIHZlcnNpb24gY291bGQgaW5jcmVhc2Ugb3NzaWZp Y2F0aW9uIGZvciBuZXcgdmVyc2lvbnMgaW4gdGhlc2UgY2FzZXMuDQogICAgDQogICAgKDMpIFNp bWlsYXJseSwgaWYgYSB0aHJlYXQgaXMga25vd24gdG8gaW1wYWN0IG9ubHkgYSBzcGVjaWZpYyAo b2xkZXIpDQogICAgdmVyc2lvbiwgaXQgd291bGQgc2VlbSB0byBtb3RpdmF0ZSBhIGRyb3Agb2Yg dGhhdCB0cmFmZmljIHRoYXQgc2Vla3MgdG8NCiAgICB1c2UgdGhhdCB2ZXJzaW9uLCB3aGlsZSBz dGlsbCBwZXJtaXR0aW5nIG90aGVyIHRyYWZmaWMuIEZvcmNpbmcgdmVyc2lvbg0KICAgIGRldGVj dGlvbiB0byB1c2UgcGF0dGVybiBtYXRjaGluZy9NTCB3aWxsIGxlYWQgdG8gbGVzcyBwcmVkaWN0 YWJsZQ0KICAgIG91dGNvbWVzLCBvciBibG9ja2luZyBiYXNlZCBvbiBhZGRyZXNzLCBldGMuDQog ICAgDQogICAgKDQpIFRoaXMgb2JmdXN0aWNhdGVzIHRoZSBtb3N0IGJhc2ljIHBpZWNlIG9mIHJl cG9ydGluZyBpbmZvcm1hdGlvbiB1c2VkDQogICAgZm9yIHN1cHBvcnQuIEl0IGhpZGVzIHRoZSBl eHRlbnQgb2YgZGVwbG95bWVudCBvZiB0aGUgY3VycmVudCBwcm90b2NvbA0KICAgIHZlcnNpb24g YW5kIHByZXZsYW5jZSBvZiBvbGQgaW1wbGVtZW50YXRpb25zLg0KICAgIA0KICAgICg1KSBPbiB0 aGUgc3VwcG9ydCwgaWYgYSBwcm9ibGVtIG9ubHkgZW1lcmdlcyB3aGVuIGEgcGFydGljdWxhciB2 ZXJzaW9uDQogICAgaXMgdXNlZCB3aXRoIGEgcGFydGljdWxhciBhZGRyZXNzLCB0aGVuIHRoaXMg aGVscHMgcGlucG9pbnQgdGhlIGlzc3Vlcy4NCiAgICBNYXRjaGluZyBjbGllbnQgdmVyc2lvbnMg dG8gc2VydmVycyBpcyBtdWNoIG1vcmUgb2YgYW4gaXNzdWUgaWYgdGhlIHVzZXINCiAgICBjb21t dW5pdHkgdXNlcyBhIHdpZGUgcmFuZ2Ugb2Ygc2VydmVycyAobGVzcyBzbywgSSBleHBlY3QgZm9y IG1ham9yDQogICAgcHJvdmlkZXJzOiBnb29nbGUsIGZhY2Vib29rLCBldGMsIGV0YyksIGJ1dCBz aWduaWZpY2FudCB3aGVuIHRoZXJlIGlzIGENCiAgICB1c2Ugb2YgYSBkaXZlcnNlIHNldCBvZiBl eHRlcm5hbCBzaXRlcyBhbmQgc2l0ZXMgd2l0aCB0aGVpciBvd24gbG9hZA0KICAgIGJhbGFuY2Vy cywgZXRjIGFuZCBhIG5lZWQgdG8gbWFuYWdlIGludGVyYWN0aW9ucyB3aXRoIEwyIHNlcnZpY2Vz Lg0KICAgIA0KICAgIEkgYW0gaW50ZXJzdGVkIGluIGtub3dpbmcgaWYgdGhpcyBpcyBsaWtlbHkg dG8gYmVuZWZpdCBvciBiZSBhIG5ldyBvYnN0YWNsZT8NCiAgICANCiAgICBHb3JyeQ0KICAgIA0K ICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAg IA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Thu Apr 11 01:11:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D215812011D for ; Thu, 11 Apr 2019 01:11:18 -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, DKIMWL_WL_HIGH=-0.001, 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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjuSQw199S-J for ; Thu, 11 Apr 2019 01:11:16 -0700 (PDT) Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120049.outbound.protection.outlook.com [40.107.12.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F191200F8 for ; Thu, 11 Apr 2019 01:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hOMsJq2aqg7v9tq4DvHqoszHAlOlzlTpCgNTh2NiR7c=; b=c/UQVFqcgwvfhLH21xUU3jHPITUtkch7MVKIafrgGsF41itZrQgKRjNYSqgY2sI7p9TsAL4HMndJWUZdcvCf0OzFKFjYfj2RxI4rtj1P82QrFrVoCJPZ+Wc/G8mycwZjioLH6Y7TBTqpIYCml4F/y4y60cYxdZuS3itcI+/Qw1Q= Received: from PR1PR07MB5898.eurprd07.prod.outlook.com (20.177.212.19) by PR1PR07MB5020.eurprd07.prod.outlook.com (20.177.209.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.12; Thu, 11 Apr 2019 08:11:12 +0000 Received: from PR1PR07MB5898.eurprd07.prod.outlook.com ([fe80::9d5b:fab9:4cc2:2f0d]) by PR1PR07MB5898.eurprd07.prod.outlook.com ([fe80::9d5b:fab9:4cc2:2f0d%5]) with mapi id 15.20.1792.009; Thu, 11 Apr 2019 08:11:12 +0000 From: Mirja Kuehlewind To: Martin Thomson , "quic@ietf.org" Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73pAMRMlXHrk8EeORXfrw42uF6Y2MXSAgACNXwA= Date: Thu, 11 Apr 2019 08:11:12 +0000 Message-ID: <0B91FC74-DDF4-4D9D-80E5-274C3956E85E@ericsson.com> References: <5CADADDD.7010005@erg.abdn.ac.uk> 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=mirja.kuehlewind@ericsson.com; x-originating-ip: [192.176.1.97] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe710863-37b5-4309-c27c-08d6be55431e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:PR1PR07MB5020; x-ms-traffictypediagnostic: PR1PR07MB5020: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(376002)(39860400002)(346002)(189003)(199004)(3846002)(110136005)(6512007)(44832011)(6506007)(256004)(5660300002)(6486002)(305945005)(8936002)(14444005)(7736002)(6436002)(66066001)(33656002)(229853002)(2616005)(8676002)(81166006)(11346002)(476003)(105586002)(446003)(186003)(76176011)(102836004)(106356001)(26005)(68736007)(81156014)(486006)(71200400001)(71190400001)(6246003)(83716004)(53936002)(478600001)(66574012)(36756003)(6116002)(14454004)(97736004)(2501003)(82746002)(86362001)(316002)(25786009)(2906002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:PR1PR07MB5020; H:PR1PR07MB5898.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vIAwJixuek5lQEFpp9tNAHXYq4xzrgIY6Ae3qNW0I79elk1O3maiJ76qf5QEjHv9gSdtiQl0/hVKwNtJSgJZctQh0s0iSvi4wgmYWvuP9KgRYPk9SeejkiFpPjE5rQKSa6W7cc4mJ9/pIRZXVo7EA4onv4OSs58drkkoGDDOcH8pzB9rUsHZte0j+UqRM828FGc5vuRF/BPU6JZXDrPy6HSP8l83I9uwdDvZ+eS8gGU0VUQkeZ+RlBDjAqv3R5NiuWVmKmubJ0mZxk11s0iUD2+fS+QsFOJC17z2nDKHowskFd8s8S8YZoLU8E1i7VP2vNDe1XzEZSFfsghnSaWRL9/mG3r7xc8klp83HTPQgiTWQt3+n9Sn0h91uEZM2ieQMBCHzkZMU61BNGtYSmUq6xqwepS939U5oxfo5Az7d6o= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe710863-37b5-4309-c27c-08d6be55431e X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 08:11:12.6370 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5020 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 08:11:19 -0000 SGkgTWFydGluLA0KDQpJJ20gc3RpbGwgdmVyeSB1bmRlY2lkZWQgd2hhdCBpcyB0aGUgYmV0dGVy IGNob2ljZSBub3c6IHBheWluZyB0aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5IGNvc3Qgc3RyYWln aHQgYXdheSBhbmQgZm9yIGV2ZXJ5Ym9keSAoYmFzaWNhbGx5IG91dCBvZiBmZWFyIGJhc2VkIG9u IHBhc3QgZXhwZXJpZW5jZSBidXQgd2l0aG91dCB0YWtpbmcgaW50byBhY2NvdW50IHRoYXQgdGhl IGNpcmN1bXN0YW5jZXMgbWF5IGhhdmUgY2hhbmdlZCBhcyBHb3JyeSBtZW50aW9uZWQpIG9yIGhh dmluZyB0byBhZGQgb25lIG9mIHRoZSB0aG9zZSwgZnJvbSBhIGRlc2lnbiBwb2ludCBvZiB2aWV3 LCB1Z2x5IGhhY2tzIHBvdGVudGlhbGx5IGxhdGVyICh3aGljaCBzdGlsbCBtYXkgYmUgbGVzcyBj b21wbGV4KS4gSXQgbWlnaHQgYmUgc2lsbHkgdG8gIm5vdCIgbGVhcm4gZnJvbSB0aGUgcGFzdCBi dXQgaXQgbWlnaHQgYWxzbyBiZSBhIGNoYW5jZS4gTWF5YmUgSSdtIGEgYml0IG5hw692ZSBoZXJl IGJ1dCBJIGRvbid0IHdhbnQgdG8gZ2l2ZSB1cCB5ZXQuIEJ1dCBJIGFsc28gdW5jZXJ0YWluIGJl Y2F1c2Ugd2UgYWxsIGNhbiBwcmVkaWN0IHRoZSBmdXR1cmUuIEhvd2V2ZXIsIEkgdGhpbmsgdGhl IGltcG9ydGFudCBwbGFuIGlzIHRvIGhhdmUgYSB1c2FibGUgcGF0aCBmb3IgdmVyc2lvbiB1cGRh dGVzIChldmVuIHRob3VnaHQgaXQgbWlnaHQgYmUgYSBoYWNrKS4NCg0KTWlyamENCg0KDQoNCu+7 v09uIDExLjA0LjE5LCAwMzo0NSwgIlFVSUMgb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uIiA8 cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtdEBsb3dlbnRyb3B5Lm5ldD4gd3Jv dGU6DQoNCiAgICBJdCdzIGFsd2F5cyBwb3NzaWJsZSB0byBjb21lIHVwIHdpdGggYSBzY2VuYXJp byB3aGVyZSB0aGUgbmV0d29yayBoZWxwcyBoZXJlLCBidXQgdGhlIGNvc3Qgb2YgaGVscCBpcyB0 aGUgcmlzayBvZiBoYXJtLg0KICAgIA0KICAgIEkgd291bGQgY2FzdCB0aGlzIHF1ZXN0aW9uIGRp ZmZlcmVudGx5OiB3aG8gaGFzIHRoZSByaWdodCg/KSB0byBkZWNpZGUgd2hlbiBhIG5ldyB2ZXJz aW9uIG9mIHRoZSBwcm90b2NvbCBpcyBwZXJtaXR0ZWQ/ICBUaGUgbW90aXZhdGlvbiBiZWhpbmQg dGhpcyBpcyB0aGF0IGl0IGlzIGNvbnNpZGVyYWJseSBtb3JlIGxpa2VseSBpZiBvbmx5IGVuZHBv aW50cyBhcmUgaW52b2x2ZWQgaW4gdGhhdCBwcm9jZXNzLg0KICAgIA0KICAgIFRoZSBhcmNoaXRl Y3R1cmFsIGNvbnNlcXVlbmNlcyBvZiBwcm90ZWN0aW5nIGEgImNsZWFuIiB2ZXJzaW9uIG5lZ290 aWF0aW9uIHByb2Nlc3MgYXJlIHdoYXQgbWFrZXMgbWUgcG9zaXRpdmUgYWJvdXQgdGhpcyBjaGFu Z2UuICBJdCBpcyBhbHdheXMgcG9zc2libGUgdG8gaW52ZW50IGEgbmV3IHZlcnNpb24gbmVnb3Rp YXRpb24gcHJvY2VzcyB0aGF0IGxvb2tzIHZlcnkgbXVjaCBsaWtlIFFVSUMgdjEsIGJ1dCBlbmFi bGVzIHRoZSB1c2Ugb2YgdjIuICBUaGF0IGlzIHdoYXQgd2UgZW5kZWQgdXAgZG9pbmcgZm9yIHRo ZSBUTFMgMS4yIHRvIDEuMyB0cmFuc2l0aW9uLiAgRm9yIGluc3RhbmNlLCB5b3UgY291bGQgbGVh cm4gdGhhdCB5b3UgY2FuIG5lZ290aWF0ZSBRVUlDdjIgYnkgY2hhbmdpbmcgdGhlIGNhc2Ugb2Yg Y2VydGFpbiBjaGFyYWN0ZXJzIGluIHRoZSBzZXJ2ZXJfbmFtZSBleHRlbnNpb24uICBPciB5b3Ug Y291bGQgdXNlIHRoZSBvcmRlcmluZyBvZiB0cmFuc3BvcnQgcGFyYW1ldGVycyB0byBzaWduYWwg dGhlIHN1cHBvcnQgZm9yIGFuIGFsdGVybmF0aXZlIHZlcnNpb24uICBJZiB5b3UgYXJlIHdpbGxp bmcgdG8gdG9sZXJhdGUgYSByaXNrIG9mIGRvd25ncmFkZSwgdGhlbiB5b3UgY2FuIGV2ZW4gbmVn b3RpYXRlIGRpZmZlcmVudCB2ZXJzaW9ucyBpbiBhIHdheSB0aGF0IGNhbid0IGJlIGRldGVjdGVk IHdpdGhvdXQgYWNjZXNzIHRvIHNlc3Npb24ga2V5cy4NCiAgICANCiAgICBJIGRvbid0IHdhbnQg dG8gaGF2ZSB0byByZXBlYXQgdGhlIHVnbHkgaGFja3Mgd2UgaGFkIHRvIGFkZCB0byBUTFMuICBJ ZiB3ZSBjYW4gZGVwbG95IGFsaWFzaW5nLCBJIGhhdmUgYSBsaXR0bGUgaG9wZSB0aGF0IHdlIGNh biB1c2UgdGhlIHZlcnNpb25pbiBnbWVjaGFuaXNtIHdlIGhhdmUgZGVzaWduZWQuDQogICAgDQog ICAgT24gV2VkLCBBcHIgMTAsIDIwMTksIGF0IDE4OjQ4LCBHIEZhaXJodXJzdCB3cm90ZToNCiAg ICA+IE9ic2N1cmluZyB0aGUgdmVyc2lvbiBvZiBhIHByb3RvY29sIHNlZW1zIGxpa2UgYSBtYWpv ciBkZXNpZ24gZGVzaWduIA0KICAgID4gZGVjaXNpb24gZm9yIHdpZGVyIHVzZSBjYXNlcy4gU28s IEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgDQogICAgPiBtb3RpdmF0aW9uIGZvciB2ZXJz aW9uIGdyZWFzaW5nLg0KICAgID4gDQogICAgPiAoMSkgSSBrbm93IHRoZXJlIHdlcmUgaW5zdGFu Y2VzIHdoZXJlIHNvbWUgZWFybHkgdmVyc2lvbnMgb2YgUVVJQyB3ZXJlIA0KICAgID4gYmxvY2tl ZCBkdWUgdG8gYW4gdW5pbml0ZW50aW9uYWwgbWF0Y2hpbmcgb2YgdGhlIGhlYWRlci4gSXMgdGhl cmUgDQogICAgPiBldmlkZW5jZSBvZiBpbnRlbnRpb25hbCBhdHRlbXB0cyB0byBibG9jayB1cGRh dGVzIHRvIHByb3RvY29scz8NCiAgICA+IA0KICAgID4gKDIpIFRoaW5raW5nIGFib3V0IG9wZXJh dGluZyBhIG5ldHdvcmsgdGhhdCBjYXJlcyBhYm91dCB1c2VyIHN1cHBvcnQgYW5kIA0KICAgID4g cHJvdGVjdGlvbiBmcm9tIHVud2FudGVkIHRyYWZmaWMsIEkgd291bGQgZXhwZWN0IHRoYXQgdGhl cmUgd291bGQgYmUgDQogICAgPiBjYXNlcyB3aGVyZSB0cmFmZmljIHBhdHRlcm4gYW5vbW9saWVz IGFyZSBmb3VuZCBhbmQgdGhlIGFwcHJvcHJpYXRlIA0KICAgID4gdGhpbmcgd291bGQgYmUgdG8g dHJ5IHRvIGRldGVybWluZSBpZiBhIG5ldyBwcm90b2NvbCBoYWQgYmVlbiBkZXBsb3llZCANCiAg ICA+IGFuZCBtb25pdG9yIGl0LCBpZiBub3QsIHRoZW4gdGhlIG5leHQgbW9zdCBvYnZpb3VzIHRo aW5nIGNvdWxkIGJlIHRvIA0KICAgID4gYmxvY2sgYWxsIHVuZXhwZWN0ZWQgdHJhZmZpYywgdGhh dCBzZWVtcyBsaWtlIGEgZGVjaXNpb24gdG8gaGlkZSB0aGUgDQogICAgPiB2ZXJzaW9uIGNvdWxk IGluY3JlYXNlIG9zc2lmaWNhdGlvbiBmb3IgbmV3IHZlcnNpb25zIGluIHRoZXNlIGNhc2VzLg0K ICAgID4gDQogICAgPiAoMykgU2ltaWxhcmx5LCBpZiBhIHRocmVhdCBpcyBrbm93biB0byBpbXBh Y3Qgb25seSBhIHNwZWNpZmljIChvbGRlcikgDQogICAgPiB2ZXJzaW9uLCBpdCB3b3VsZCBzZWVt IHRvIG1vdGl2YXRlIGEgZHJvcCBvZiB0aGF0IHRyYWZmaWMgdGhhdCBzZWVrcyB0byANCiAgICA+ IHVzZSB0aGF0IHZlcnNpb24sIHdoaWxlIHN0aWxsIHBlcm1pdHRpbmcgb3RoZXIgdHJhZmZpYy4g Rm9yY2luZyB2ZXJzaW9uIA0KICAgID4gZGV0ZWN0aW9uIHRvIHVzZSBwYXR0ZXJuIG1hdGNoaW5n L01MIHdpbGwgbGVhZCB0byBsZXNzIHByZWRpY3RhYmxlIA0KICAgID4gb3V0Y29tZXMsIG9yIGJs b2NraW5nIGJhc2VkIG9uIGFkZHJlc3MsIGV0Yy4NCiAgICA+IA0KICAgID4gKDQpIFRoaXMgb2Jm dXN0aWNhdGVzIHRoZSBtb3N0IGJhc2ljIHBpZWNlIG9mIHJlcG9ydGluZyBpbmZvcm1hdGlvbiB1 c2VkIA0KICAgID4gZm9yIHN1cHBvcnQuIEl0IGhpZGVzIHRoZSBleHRlbnQgb2YgZGVwbG95bWVu dCBvZiB0aGUgY3VycmVudCBwcm90b2NvbCANCiAgICA+IHZlcnNpb24gYW5kIHByZXZsYW5jZSBv ZiBvbGQgaW1wbGVtZW50YXRpb25zLg0KICAgID4gDQogICAgPiAoNSkgT24gdGhlIHN1cHBvcnQs IGlmIGEgcHJvYmxlbSBvbmx5IGVtZXJnZXMgd2hlbiBhIHBhcnRpY3VsYXIgdmVyc2lvbiANCiAg ICA+IGlzIHVzZWQgd2l0aCBhIHBhcnRpY3VsYXIgYWRkcmVzcywgdGhlbiB0aGlzIGhlbHBzIHBp bnBvaW50IHRoZSBpc3N1ZXMuIA0KICAgID4gTWF0Y2hpbmcgY2xpZW50IHZlcnNpb25zIHRvIHNl cnZlcnMgaXMgbXVjaCBtb3JlIG9mIGFuIGlzc3VlIGlmIHRoZSB1c2VyIA0KICAgID4gY29tbXVu aXR5IHVzZXMgYSB3aWRlIHJhbmdlIG9mIHNlcnZlcnMgKGxlc3Mgc28sIEkgZXhwZWN0IGZvciBt YWpvciANCiAgICA+IHByb3ZpZGVyczogZ29vZ2xlLCBmYWNlYm9vaywgZXRjLCBldGMpLCBidXQg c2lnbmlmaWNhbnQgd2hlbiB0aGVyZSBpcyBhIA0KICAgID4gdXNlIG9mIGEgZGl2ZXJzZSBzZXQg b2YgZXh0ZXJuYWwgc2l0ZXMgYW5kIHNpdGVzIHdpdGggdGhlaXIgb3duIGxvYWQgDQogICAgPiBi YWxhbmNlcnMsIGV0YyBhbmQgYSBuZWVkIHRvIG1hbmFnZSBpbnRlcmFjdGlvbnMgd2l0aCBMMiBz ZXJ2aWNlcy4NCiAgICA+IA0KICAgID4gSSBhbSBpbnRlcnN0ZWQgaW4ga25vd2luZyBpZiB0aGlz IGlzIGxpa2VseSB0byBiZW5lZml0IG9yIGJlIGEgbmV3IG9ic3RhY2xlPw0KICAgID4gDQogICAg PiBHb3JyeQ0KICAgID4gDQogICAgPg0KICAgIA0KICAgIA0KDQo= From nobody Thu Apr 11 01:20:35 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F38912017D for ; Thu, 11 Apr 2019 01:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A7NcY8yuh3m for ; Thu, 11 Apr 2019 01:20:31 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B4E12011D for ; Thu, 11 Apr 2019 01:20:30 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id v10so4601092iom.8 for ; Thu, 11 Apr 2019 01:20:30 -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=KqOTUi0P2BiRtdjCHJBmCQRHSlHrIKwybLQK/SO8glM=; b=EhggmS3W/hTVZkPaFr8xf6Nz/zyuHohDjb3xRlbMZsVyBZxwfLk540zqsX64ZT++Sf B5imcJ7ypdOz71AFU8YVLGKEBKmF7zOvKN0FlTzTWO2TC44f9ykRq7k3R3/E1yb3KVqp o6TTsVYgKok4hlGNpZ2Gr7azBoPt4OeqjFM2Ra/+txz0BLwzyEL4IGq8X59U3/BUYmOy s4UdP4kWO8aBbFnCMsMZrJxX8cGTV5oZr+txZzhVn+kf/4iAjFyfmi+d93YXqdzDwLFG e1sKjrKk95ZOUSV1RA+x7cGQhHPUj+OPKDZrC2rU7XSbUqOULbwwLXfl8SBQ8jPGs48J fFCg== 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=KqOTUi0P2BiRtdjCHJBmCQRHSlHrIKwybLQK/SO8glM=; b=DkmyrE1qiHxCxhZuIx+53M3HaADbzBZwI6WnFIycnTtYry+cyUCntdgYL262oQkrGv mVXNrQ6tPASbmrNfu3dOtIUdkecnyq4vbgpLbxz4HVo94ZPIQrbWuWN5LvariotUpVVJ OCBUL7l3lHGtR+1eTBdu89xw8PYC4VK4DWMsAG75ImyxFLx8ALiVkqh5FzOuuu6xf7WO hbfL/KxNZzrgEeT6c1IaBkM+iYE+27Xo5BO2YziX9fPIAcC70WWgbtWTpqlU5j9f5Ofm 1EPw5aHIHjZ1UU8Cu5LsDAn/N6xvGipXeh49eQCiTNKDo0QNXGgnUZsIUFvkaRqYIZa8 EoWg== X-Gm-Message-State: APjAAAV7VYQJjxTynDZxILTMUOsT1N28gJkQEdDM4LKGqzLr38G5mzUf VU4NFjPVhpIBrmJXRBXYtQTEbn8qIEpMBannQ08= X-Google-Smtp-Source: APXvYqy5Sc58+DykjZKMaAnXsB0DesHwy1JfNqdnvkTa90qeh0Yq2nJ7BNkTAi+PL2Wnd+VWvHk31RO/eFzRYhUjgtU= X-Received: by 2002:a5d:8902:: with SMTP id b2mr31483801ion.267.1554970830205; Thu, 11 Apr 2019 01:20:30 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Apr 2019 01:20:29 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 11 Apr 2019 01:20:29 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: "Gorry (erg)" , Mirja Kuehlewind Cc: "Border, John" , Roberto Peon , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f8797b05863cdbbd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 08:20:34 -0000 --000000000000f8797b05863cdbbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In a not so distant future, a fallback to TCP would not be a viable alternative for a number of services. Think WebRTC. If QUIC and other encrypted protocols become dominant, just blocking everything would literally block everything. Of course, http(s) as we know it, it will continue to live on, but many mobile apps would not. On 11 April 2019 at 10.03.14, Mirja Kuehlewind ( mirja.kuehlewind@ericsson.com) wrote: Hi Mikkel, I guess it is much more likely that any of those actors would just block QUIC all together (as there is actually a fallback to TCP). Mirja =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e J=C3=B8r= gensen" < quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: Let=E2=80=99s say China makes a deal with Google to allow their search engi= ne (a not entirely unreasonably proposition). The Great Firewall of China (GFC) is reconfigured to accept traffic from a specific IP range for QUIC protocol v1. Google later upgrades to v2. GFC is updated. Later, out of ignorance, some other department within said company decides that its browsers should all use forced version aliases as a rule. GFC breaks. (Assuming Googles servers are not located within the demilitarised zone and users use Chrome). Alternative 1: Google up front decides to deploy forced version aliasing. China rejects the deal because they do not want to support random traffic through GFC. Alternative 2: Google up front decides to deploy forced version aliasing, and China does not reject the deal, out of ignorance. Later some department in China GFC oversight realises the deal and forces Google to remove forced version aliasing, or shut down its service. Alternative 3: Google up front decides to deploy forced version aliasing and China says, of course, we trust everything from Googles IP range. Alternative 4: Google realises that forced version aliasing does not work in the general case, and makes a special case for users within a certain geographical area. Disclaimer: I=E2=80=99m not affiliated with Google and this might not at al= l be how things would work, but it does highlight some of the challenges. Of course, to be fair, China is not the only government entity that might have a vested interest. Let's take a fictional example of US a real estate investor with heavy ties to the eastern european block who somehow finds himself elected as president needing to find leverage on trade negotiations without effectively hurting personal finances. It turns out that blocking certain digital services from said eastern european block is the perfect tool in the trade negotiations. Advisers point out that those services run heavily encrypted on the dark web with perpetual circulation of IP ranges so, ignoring any legal concerns, it would not be practically possible. Eventually someone figures out that these services all usually are at the forefront of technology and currently use QUIC v3.2 and no-one else has deployed that version yet, so it would suffice to ask NSA to tap into the backbone and disrupt specific packets. Of course, this ends up taking down the Bavarian local government election process in Germany where they are the first to use a new digital election system. Not that the is an issue, since trade negotiations are also running hot in that area, so that is just an accidental bonus. Or an endless number of other developments over the next few decades if the past few years is anything to go by. On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote: Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ... I do not understand that assertion. Gorry On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: China blocks as a rule. Russia is running an experiment to block the rest of the internet. USA blocks net neutrality. EU blocks cookies. GB blocks itself. So blocking is not limited to what an operator considers best for business. On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote: I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others... John -----Original Message----- From: QUIC On Behalf Of Roberto Peon Sent: Wednesday, April 10, 2019 12:52 PM To: G Fairhurst ; quic@ietf.org Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? WARNING: The sender of this email could not be validated and may not match the person in the "From" field. CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. You're kinda between a rock-and-a-hard-place either way: - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification. - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not. My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate. My guesses: IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In other words, I have a doubt that stating the version in an observable way will prevent the use of such tools. Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe). If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation fingerprints. -=3DR On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" wrote: Obscuring the version of a protocol seems like a major design design decision for wider use cases. So, I'm trying to understand the motivation for version greasing. (1) I know there were instances where some early versions of QUIC were blocked due to an uninitentional matching of the header. Is there evidence of intentional attempts to block updates to protocols? (2) Thinking about operating a network that cares about user support and protection from unwanted traffic, I would expect that there would be cases where traffic pattern anomolies are found and the appropriate thing would be to try to determine if a new protocol had been deployed and monitor it, if not, then the next most obvious thing could be to block all unexpected traffic, that seems like a decision to hide the version could increase ossification for new versions in these cases. (3) Similarly, if a threat is known to impact only a specific (older) version, it would seem to motivate a drop of that traffic that seeks to use that version, while still permitting other traffic. Forcing version detection to use pattern matching/ML will lead to less predictable outcomes, or blocking based on address, etc. (4) This obfusticates the most basic piece of reporting information used for support. It hides the extent of deployment of the current protocol version and prevlance of old implementations. (5) On the support, if a problem only emerges when a particular version is used with a particular address, then this helps pinpoint the issues. Matching client versions to servers is much more of an issue if the user community uses a wide range of servers (less so, I expect for major providers: google, facebook, etc, etc), but significant when there is a use of a diverse set of external sites and sites with their own load balancers, etc and a need to manage interactions with L2 services. I am intersted in knowing if this is likely to benefit or be a new obstacle? Gorry --000000000000f8797b05863cdbbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = In a not so distant = future, a fallback to TCP would not be a viable alternative for a number of= services. Think WebRTC.
If QUIC and other encrypted protocols become dominant, just blo= cking everything would literally block everything.
Of course, http(s) as we know it, it = will continue to live on, but many mobile apps would not.


On 11 April 2019 at 10.03.14, Mirja Kuehlewind (mirja.kuehlewind@ericsson.com) wrote:

<= blockquote type=3D"cite" class=3D"clean_bq">
Hi M= ikkel,

I guess it is much more likely that any of those actors would just bloc= k QUIC all together (as there is actually a fallback to TCP).

Mirja



=EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e= J=C3=B8rgensen" <quic-bou= nces@ietf.org on behalf of mikkel= fj@gmail.com> wrote:

=20
Let=E2=80=99s say China makes a deal with Google to allow their se= arch engine (a not entirely unreasonably proposition).
The Great Firewall of China (GFC) is reconfigured to accept traffic= from a specific IP range for QUIC protocol v1.
=20
=20
=20
Google later upgrades to v2. GFC is updated. Later, out of ignoranc= e, some other department within said company decides that its browsers shou= ld all use forced version aliases as a rule. GFC breaks. (Assuming Googles = servers are not located within the demilitarised
zone and users use Chrome).
=20
=20
Alternative 1: Google up front decides to deploy forced version ali= asing. China rejects the deal because they do not want to support random tr= affic through GFC.
=20
=20
Alternative 2: Google up front decides to deploy forced version ali= asing, and China does not reject the deal, out of ignorance. Later some dep= artment in China GFC oversight realises the deal and forces Google to remov= e forced version aliasing, or shut down
its service.
=20
=20
Alternative 3: Google up front decides to deploy forced version ali= asing and China says, of course, we trust everything from Googles IP range.
=20
=20
Alternative 4: Google realises that forced version aliasing does no= t work in the general case, and makes a special case for users within a cer= tain geographical area.
=20
=20
Disclaimer: I=E2=80=99m not affiliated with Google and this might n= ot at all be how things would work, but it does highlight some of the chall= enges.
=20
=20
Of course, to be fair, China is not the only government entity that= might have a vested interest. Let's take a fictional example of US a r= eal estate investor with heavy ties to the eastern european block who someh= ow finds himself elected as president needing
to find leverage on trade negotiations without effectively hurting= personal finances. It turns out that blocking certain digital services fro= m said eastern european block is the perfect tool in the trade negotiations= . Advisers point out that those services
run heavily encrypted on the dark web with perpetual circulation o= f IP ranges so, ignoring any legal concerns, it would not be practically po= ssible. Eventually someone figures out that these services all usually are = at the forefront of technology and currently
use QUIC v3.2 and no-one else has deployed that version yet, so it= would suffice to ask NSA to tap into the backbone and disrupt specific pac= kets. Of course, this ends up taking down the Bavarian local government ele= ction process in Germany where they are
the first to use a new digital election system. Not that the is an= issue, since trade negotiations are also running hot in that area, so that= is just an accidental bonus.
=20
=20
Or an endless number of other developments over the next few decade= s if the past few years is anything to go by.
=20
=20
=20
=20
=20
On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote:
=20
Thanks Mikkel, I do understand that various actors intentionally dr= op - but are you saying these actors would specifically choose to block a n= ew version of QUIC ... I do not understand that assertion.
=20
=20
Gorry
=20
On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
=20
=20
=20
China blocks as a rule.
Russia is running an experiment to block the rest of the internet.
USA blocks net neutrality.
EU blocks cookies.
GB blocks itself.
=20
=20
So blocking is not limited to what an operator considers best for b= usiness.
=20
=20
=20
On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote:
=20
=20
I understand why people want to come down on the side of preventing= ossification. But, things have changed. There are a lot of more negative c= onsequences now when people unnecessarily block things. I think operators w= ould put a lot of pressure on vendors to
not do it now and to fix it if they did "by accident". O= f course, I am only one operator. It would be nice to hear from others...
=20
=20
=20
John
=20
=20
-----Original Message-----
From: QUIC <quic-bounce= s@ietf.org> On Behalf Of Roberto Peon
Sent: Wednesday, April 10, 2019 12:52 PM
To: G Fairhurst <gorry@e= rg.abdn.ac.uk>;
quic@ietf.org
Subject: Re: Is "Version Greasing" a new benfit or a new = obstacle?
=20
WARNING: The sender of this email could not be validated and may no= t match the person in the "From" field.
=20
CAUTION: This email originated from outside of the organization. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe.
=20
=20
You're kinda between a rock-and-a-hard-place either way:
=20
- We've seen how much fun ossification is in TCP and HTTP. If t= he thing is observable, it will be ossified seems to be the lesson. A lot o= f the reason why QUIC was started in the first place was because of the ina= bility to improve TCP due to this ossification.
- OTOH, there is the fear of unknown/unobservable which might cause= operators to block things, whether predictably or not.
=20
My opinion is that it is better to start with preventing ossificati= on, and then if that results in too large a percentage of operators blockin= g things, to re-evaluate.
=20
My guesses:
IP+port tuples and traffic patterns are still observable (for bette= r and worse), which implies operators will still have significant tools for= managing traffic. I believe that these are acted on/matched (ML or not) re= gardless of any other data presented. In
other words, I have a doubt that stating the version in an observa= ble way will prevent the use of such tools.
=20
Most problems I've seen associated with implementations rather = than protocol versions (though when the latter happens it is pretty severe)= . If you believe this assertion, then acting on protocol version is less in= teresting than attempting to act based on implementation
fingerprints.
-=3DR
=20
=20
On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" <= quic-bounces@ietf.org on behal= f of
gorry@erg.abdn.ac.uk>= ; wrote:
=20
Obscuring the version of a protocol seems like a major design desig= n
decision for wider use cases. So, I'm trying to understand the
motivation for version greasing.
=20
(1) I know there were instances where some early versions of QUIC w= ere
blocked due to an uninitentional matching of the header. Is there
evidence of intentional attempts to block updates to protocols?
=20
(2) Thinking about operating a network that cares about user suppor= t and
protection from unwanted traffic, I would expect that there would b= e
cases where traffic pattern anomolies are found and the appropriate
thing would be to try to determine if a new protocol had been deplo= yed
and monitor it, if not, then the next most obvious thing could be t= o
block all unexpected traffic, that seems like a decision to hide th= e
version could increase ossification for new versions in these cases= .
=20
(3) Similarly, if a threat is known to impact only a specific (olde= r)
version, it would seem to motivate a drop of that traffic that seek= s to
use that version, while still permitting other traffic. Forcing ver= sion
detection to use pattern matching/ML will lead to less predictable
outcomes, or blocking based on address, etc.
=20
(4) This obfusticates the most basic piece of reporting information= used
for support. It hides the extent of deployment of the current proto= col
version and prevlance of old implementations.
=20
(5) On the support, if a problem only emerges when a particular ver= sion
is used with a particular address, then this helps pinpoint the iss= ues.
Matching client versions to servers is much more of an issue if the= user
community uses a wide range of servers (less so, I expect for major
providers: google, facebook, etc, etc), but significant when there = is a
use of a diverse set of external sites and sites with their own loa= d
balancers, etc and a need to manage interactions with L2 services.
=20
I am intersted in knowing if this is likely to benefit or be a new = obstacle?
=20
Gorry
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20

--000000000000f8797b05863cdbbd-- From nobody Fri Apr 12 07:18:05 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E00F120393 for ; Fri, 12 Apr 2019 07:18:04 -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 h_DRQLGATXw2 for ; Fri, 12 Apr 2019 07:18:01 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 B3A29120364 for ; Fri, 12 Apr 2019 07:18:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id E565FBA7 for ; Fri, 12 Apr 2019 16:17:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Z+MLxneY1kpz for ; Fri, 12 Apr 2019 16:17:58 +0200 (CEST) Received: from users-MacBook-Pro.local (svsawb.informatik.uni-hamburg.de [134.100.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 451DBBA6 for ; Fri, 12 Apr 2019 16:17:57 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de From: Erik Sy Subject: QUICker connection establishment with out-of-band validation tokens Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== To: QUIC WG Message-ID: Date: Fri, 12 Apr 2019 16:17:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 14:18:04 -0000 Hi folks, I suggest introducing out-of-band validation tokens to save a round-trip time during QUIC's connection establishment. These tokens can be distributed via DNS resolvers or other QUIC servers and can avoid up to 100% of stateless retries during connection establishments. Below is a detailed description and evaluation on performance, security, privacy and scalability of this proposal:        https://svs.informatik.uni-hamburg.de/publications/2019/2019-04-12-Sy-preprint-QUICker_connection_establishment_with_out-of-band_validation_tokens.pdf Best, Erik From nobody Fri Apr 12 08:53:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263E9120305 for ; Fri, 12 Apr 2019 08:53:32 -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, DKIMWL_WL_HIGH=-0.001, 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 xoTbzMbB6clt for ; Fri, 12 Apr 2019 08:53:28 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680117.outbound.protection.outlook.com [40.107.68.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 8BA7B1200F6 for ; Fri, 12 Apr 2019 08:53: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:X-MS-Exchange-SenderADCheck; bh=+eFd8AqMzI5Ab4tvUr+khHAYu0ExKn7leq11/8m6TCQ=; b=dR/6WYKpXIImfUQffLVKwxvrv+icpKAG5VMZFj03/yOslp+D4kMmpcL7ZlaWa/GDHquc5/kN5g012SPhf30cr8DOwfzX7R8UhQeu2HiK6DLUWrbt0qTz3tVy2JM++Ds5UOWG5RitzkyIY9WTh29WXdYAg2dHrOE1ionzhjNNVT0= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1083.namprd21.prod.outlook.com (52.132.149.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.5; Fri, 12 Apr 2019 15:53:24 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c999:100b:9952:f8f6]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c999:100b:9952:f8f6%5]) with mapi id 15.20.1813.000; Fri, 12 Apr 2019 15:53:24 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Gorry (erg)" , Mirja Kuehlewind CC: "quic@ietf.org" , "Border, John" , Roberto Peon Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o0AOSUW1ZVWEa1WA8MStgy7KY1nGCAgAACAYCAAAdsgIAADYwAgAAcxQCAAMrxAIAABNWAgAIQK4A= Date: Fri, 12 Apr 2019 15:53:24 +0000 Message-ID: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.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=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:0:21b3:7b4b:b4a3:c3bf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e48b51a-13b3-4415-91d2-08d6bf5eff3c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB1083; x-ms-traffictypediagnostic: MW2PR2101MB1083: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(346002)(396003)(366004)(199004)(189003)(13464003)(8990500004)(33656002)(55016002)(99286004)(6436002)(486006)(68736007)(446003)(11346002)(22452003)(316002)(110136005)(6246003)(54906003)(81156014)(25786009)(478600001)(10290500003)(81166006)(8676002)(2906002)(5660300002)(790700001)(6116002)(97736004)(46003)(52536014)(4326008)(7736002)(74316002)(229853002)(9686003)(54896002)(6306002)(106356001)(8936002)(476003)(105586002)(236005)(186003)(6506007)(14454004)(53546011)(5024004)(7696005)(53936002)(102836004)(71190400001)(66574012)(71200400001)(93886005)(86362001)(14444005)(76176011)(256004)(10090500001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1083; H:MW2PR2101MB1049.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Yq7QejndctAt16R3Jk8TMblLdBVFilGGPwelRztK7GrX6Q/zuzmwcXuDc6y/THh7Fjx9ZneYVDLmJlk+SfiBEAExWAZJJ08E6KU6zSH5UMXzY6mHjDRKNuZGMK0eTfCqxWtQAa6WTK1W4Vq0KpysXC0jF3xTZKlGBYlFh88od2tsX+gCJiOvVdtFYbea7Z3BlArWLuJsyOevvw79UZx+XFnux0CLftIlyw43k6QMCNbY3Qy0bENySQT+d7KFpDBxVZ5S04QTimWKDhH9eLTM2ycojHzLQ8sIQSREDtoomjCkiksnV1Sa1HyFYhePkIWS4CFs6bOlIQcFEv2/IuErPcq/JNZCV6ZIhstckRkS2yH6DMPPcQNDNaT/gKjwU+jygYbNMGxXUUOhdllQfTzmtH16xGHjBmisimYyKn8ZYRw= Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB104902B6BC7C67D8688EA852B6280MW2PR2101MB1049_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e48b51a-13b3-4415-91d2-08d6bf5eff3c X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 15:53:24.8275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1083 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 15:53:32 -0000 --_000_MW2PR2101MB104902B6BC7C67D8688EA852B6280MW2PR2101MB1049_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmVyc2lvbiBncmVhc2luZyB3aWxsIGNyZWF0ZSBwcm9ibGVtcyBmb3IgRERvUyBwcm90ZWN0aW9u LiBUaGUgRERvUyBwcm90ZWN0aW9uIG1pZGRsZWJveCB3aWxsIGhhdmUgdG8gdHJlYXQgYWxsIHRy YWZmaWMgd2l0aCB1bmtub3duIHZlcnNpb24gbnVtYmVycyBhcyBwbGFpbiBvbGQgUVVJQyBhbmQg cmF0ZSBsaW1pdCBpdC4gQW55IHNvbHV0aW9uIHRoYXQgcmVxdWlyZXMgcGVyIGNvbm5lY3Rpb24g c3RhdGUgdG8gdHJhY2sgdmVyc2lvbiBudW1iZXJzIGRvZXNu4oCZdCBzY2FsZS4gRXNwZWNpYWxs eSBpbiB0aGUgY2xvdWQgc2NlbmFyaW8gY3VzdG9tZXJzIGJyaW5nIHRoZWlyIG93biB3ZWIgc2Vy dmVycyBzbyB0aGlzIG1ha2VzIGFueSBvcHQtb3V0IHNvbHV0aW9uIG5vdCBnb29kIGVub3VnaC4g U28gSSBkbyB0aGluayB0aGlzIGlzIGFuIG9ic3RhY2xlIGZvciBtYW55IGRlcGxveW1lbnRzLg0K DQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTEsIDIwMTkgMToyMCBB TQ0KVG86IEdvcnJ5IChlcmcpIDxnb3JyeUBlcmcuYWJkbi5hYy51az47IE1pcmphIEt1ZWhsZXdp bmQgPG1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPg0KQ2M6IHF1aWNAaWV0Zi5vcmc7IEJv cmRlciwgSm9obiA8am9obi5ib3JkZXJAaHVnaGVzLmNvbT47IFJvYmVydG8gUGVvbiA8ZmVuaXhA ZmIuY29tPg0KU3ViamVjdDogUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBiZW5maXQg b3IgYSBuZXcgb2JzdGFjbGU/DQoNCkluIGEgbm90IHNvIGRpc3RhbnQgZnV0dXJlLCBhIGZhbGxi YWNrIHRvIFRDUCB3b3VsZCBub3QgYmUgYSB2aWFibGUgYWx0ZXJuYXRpdmUgZm9yIGEgbnVtYmVy IG9mIHNlcnZpY2VzLiBUaGluayBXZWJSVEMuDQpJZiBRVUlDIGFuZCBvdGhlciBlbmNyeXB0ZWQg cHJvdG9jb2xzIGJlY29tZSBkb21pbmFudCwganVzdCBibG9ja2luZyBldmVyeXRoaW5nIHdvdWxk IGxpdGVyYWxseSBibG9jayBldmVyeXRoaW5nLg0KT2YgY291cnNlLCBodHRwKHMpIGFzIHdlIGtu b3cgaXQsIGl0IHdpbGwgY29udGludWUgdG8gbGl2ZSBvbiwgYnV0IG1hbnkgbW9iaWxlIGFwcHMg d291bGQgbm90Lg0KDQoNCg0KT24gMTEgQXByaWwgMjAxOSBhdCAxMC4wMy4xNCwgTWlyamEgS3Vl aGxld2luZCAobWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb208bWFpbHRvOm1pcmphLmt1ZWhs ZXdpbmRAZXJpY3Nzb24uY29tPikgd3JvdGU6DQpIaSBNaWtrZWwsDQoNCkkgZ3Vlc3MgaXQgaXMg bXVjaCBtb3JlIGxpa2VseSB0aGF0IGFueSBvZiB0aG9zZSBhY3RvcnMgd291bGQganVzdCBibG9j ayBRVUlDIGFsbCB0b2dldGhlciAoYXMgdGhlcmUgaXMgYWN0dWFsbHkgYSBmYWxsYmFjayB0byBU Q1ApLg0KDQpNaXJqYQ0KDQoNCg0K77u/T24gMTAuMDQuMTksIDIxOjU3LCAiUVVJQyBvbiBiZWhh bGYgb2YgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgbWlra2VsZmpAZ21haWwu Y29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQpMZXTigJlzIHNheSBD aGluYSBtYWtlcyBhIGRlYWwgd2l0aCBHb29nbGUgdG8gYWxsb3cgdGhlaXIgc2VhcmNoIGVuZ2lu ZSAoYSBub3QgZW50aXJlbHkgdW5yZWFzb25hYmx5IHByb3Bvc2l0aW9uKS4NClRoZSBHcmVhdCBG aXJld2FsbCBvZiBDaGluYSAoR0ZDKSBpcyByZWNvbmZpZ3VyZWQgdG8gYWNjZXB0IHRyYWZmaWMg ZnJvbSBhIHNwZWNpZmljIElQIHJhbmdlIGZvciBRVUlDIHByb3RvY29sIHYxLg0KDQoNCg0KR29v Z2xlIGxhdGVyIHVwZ3JhZGVzIHRvIHYyLiBHRkMgaXMgdXBkYXRlZC4gTGF0ZXIsIG91dCBvZiBp Z25vcmFuY2UsIHNvbWUgb3RoZXIgZGVwYXJ0bWVudCB3aXRoaW4gc2FpZCBjb21wYW55IGRlY2lk ZXMgdGhhdCBpdHMgYnJvd3NlcnMgc2hvdWxkIGFsbCB1c2UgZm9yY2VkIHZlcnNpb24gYWxpYXNl cyBhcyBhIHJ1bGUuIEdGQyBicmVha3MuIChBc3N1bWluZyBHb29nbGVzIHNlcnZlcnMgYXJlIG5v dCBsb2NhdGVkIHdpdGhpbiB0aGUgZGVtaWxpdGFyaXNlZA0Kem9uZSBhbmQgdXNlcnMgdXNlIENo cm9tZSkuDQoNCg0KQWx0ZXJuYXRpdmUgMTogR29vZ2xlIHVwIGZyb250IGRlY2lkZXMgdG8gZGVw bG95IGZvcmNlZCB2ZXJzaW9uIGFsaWFzaW5nLiBDaGluYSByZWplY3RzIHRoZSBkZWFsIGJlY2F1 c2UgdGhleSBkbyBub3Qgd2FudCB0byBzdXBwb3J0IHJhbmRvbSB0cmFmZmljIHRocm91Z2ggR0ZD Lg0KDQoNCkFsdGVybmF0aXZlIDI6IEdvb2dsZSB1cCBmcm9udCBkZWNpZGVzIHRvIGRlcGxveSBm b3JjZWQgdmVyc2lvbiBhbGlhc2luZywgYW5kIENoaW5hIGRvZXMgbm90IHJlamVjdCB0aGUgZGVh bCwgb3V0IG9mIGlnbm9yYW5jZS4gTGF0ZXIgc29tZSBkZXBhcnRtZW50IGluIENoaW5hIEdGQyBv dmVyc2lnaHQgcmVhbGlzZXMgdGhlIGRlYWwgYW5kIGZvcmNlcyBHb29nbGUgdG8gcmVtb3ZlIGZv cmNlZCB2ZXJzaW9uIGFsaWFzaW5nLCBvciBzaHV0IGRvd24NCml0cyBzZXJ2aWNlLg0KDQoNCkFs dGVybmF0aXZlIDM6IEdvb2dsZSB1cCBmcm9udCBkZWNpZGVzIHRvIGRlcGxveSBmb3JjZWQgdmVy c2lvbiBhbGlhc2luZyBhbmQgQ2hpbmEgc2F5cywgb2YgY291cnNlLCB3ZSB0cnVzdCBldmVyeXRo aW5nIGZyb20gR29vZ2xlcyBJUCByYW5nZS4NCg0KDQpBbHRlcm5hdGl2ZSA0OiBHb29nbGUgcmVh bGlzZXMgdGhhdCBmb3JjZWQgdmVyc2lvbiBhbGlhc2luZyBkb2VzIG5vdCB3b3JrIGluIHRoZSBn ZW5lcmFsIGNhc2UsIGFuZCBtYWtlcyBhIHNwZWNpYWwgY2FzZSBmb3IgdXNlcnMgd2l0aGluIGEg Y2VydGFpbiBnZW9ncmFwaGljYWwgYXJlYS4NCg0KDQpEaXNjbGFpbWVyOiBJ4oCZbSBub3QgYWZm aWxpYXRlZCB3aXRoIEdvb2dsZSBhbmQgdGhpcyBtaWdodCBub3QgYXQgYWxsIGJlIGhvdyB0aGlu Z3Mgd291bGQgd29yaywgYnV0IGl0IGRvZXMgaGlnaGxpZ2h0IHNvbWUgb2YgdGhlIGNoYWxsZW5n ZXMuDQoNCg0KT2YgY291cnNlLCB0byBiZSBmYWlyLCBDaGluYSBpcyBub3QgdGhlIG9ubHkgZ292 ZXJubWVudCBlbnRpdHkgdGhhdCBtaWdodCBoYXZlIGEgdmVzdGVkIGludGVyZXN0LiBMZXQncyB0 YWtlIGEgZmljdGlvbmFsIGV4YW1wbGUgb2YgVVMgYSByZWFsIGVzdGF0ZSBpbnZlc3RvciB3aXRo IGhlYXZ5IHRpZXMgdG8gdGhlIGVhc3Rlcm4gZXVyb3BlYW4gYmxvY2sgd2hvIHNvbWVob3cgZmlu ZHMgaGltc2VsZiBlbGVjdGVkIGFzIHByZXNpZGVudCBuZWVkaW5nDQp0byBmaW5kIGxldmVyYWdl IG9uIHRyYWRlIG5lZ290aWF0aW9ucyB3aXRob3V0IGVmZmVjdGl2ZWx5IGh1cnRpbmcgcGVyc29u YWwgZmluYW5jZXMuIEl0IHR1cm5zIG91dCB0aGF0IGJsb2NraW5nIGNlcnRhaW4gZGlnaXRhbCBz ZXJ2aWNlcyBmcm9tIHNhaWQgZWFzdGVybiBldXJvcGVhbiBibG9jayBpcyB0aGUgcGVyZmVjdCB0 b29sIGluIHRoZSB0cmFkZSBuZWdvdGlhdGlvbnMuLiBBZHZpc2VycyBwb2ludCBvdXQgdGhhdCB0 aG9zZSBzZXJ2aWNlcw0KcnVuIGhlYXZpbHkgZW5jcnlwdGVkIG9uIHRoZSBkYXJrIHdlYiB3aXRo IHBlcnBldHVhbCBjaXJjdWxhdGlvbiBvZiBJUCByYW5nZXMgc28sIGlnbm9yaW5nIGFueSBsZWdh bCBjb25jZXJucywgaXQgd291bGQgbm90IGJlIHByYWN0aWNhbGx5IHBvc3NpYmxlLiBFdmVudHVh bGx5IHNvbWVvbmUgZmlndXJlcyBvdXQgdGhhdCB0aGVzZSBzZXJ2aWNlcyBhbGwgdXN1YWxseSBh cmUgYXQgdGhlIGZvcmVmcm9udCBvZiB0ZWNobm9sb2d5IGFuZCBjdXJyZW50bHkNCnVzZSBRVUlD IHYzLjIgYW5kIG5vLW9uZSBlbHNlIGhhcyBkZXBsb3llZCB0aGF0IHZlcnNpb24geWV0LCBzbyBp dCB3b3VsZCBzdWZmaWNlIHRvIGFzayBOU0EgdG8gdGFwIGludG8gdGhlIGJhY2tib25lIGFuZCBk aXNydXB0IHNwZWNpZmljIHBhY2tldHMuIE9mIGNvdXJzZSwgdGhpcyBlbmRzIHVwIHRha2luZyBk b3duIHRoZSBCYXZhcmlhbiBsb2NhbCBnb3Zlcm5tZW50IGVsZWN0aW9uIHByb2Nlc3MgaW4gR2Vy bWFueSB3aGVyZSB0aGV5IGFyZQ0KdGhlIGZpcnN0IHRvIHVzZSBhIG5ldyBkaWdpdGFsIGVsZWN0 aW9uIHN5c3RlbS4gTm90IHRoYXQgdGhlIGlzIGFuIGlzc3VlLCBzaW5jZSB0cmFkZSBuZWdvdGlh dGlvbnMgYXJlIGFsc28gcnVubmluZyBob3QgaW4gdGhhdCBhcmVhLCBzbyB0aGF0IGlzIGp1c3Qg YW4gYWNjaWRlbnRhbCBib251cy4NCg0KDQpPciBhbiBlbmRsZXNzIG51bWJlciBvZiBvdGhlciBk ZXZlbG9wbWVudHMgb3ZlciB0aGUgbmV4dCBmZXcgZGVjYWRlcyBpZiB0aGUgcGFzdCBmZXcgeWVh cnMgaXMgYW55dGhpbmcgdG8gZ28gYnkuDQoNCg0KDQoNCg0KT24gMTAgQXByaWwgMjAxOSBhdCAy MC4xMy41OSwgR29ycnkgKGVyZykgKGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBl cmcuYWJkbi5hYy51az4pIHdyb3RlOg0KDQpUaGFua3MgTWlra2VsLCBJIGRvIHVuZGVyc3RhbmQg dGhhdCB2YXJpb3VzIGFjdG9ycyBpbnRlbnRpb25hbGx5IGRyb3AgLSBidXQgYXJlIHlvdSBzYXlp bmcgdGhlc2UgYWN0b3JzIHdvdWxkIHNwZWNpZmljYWxseSBjaG9vc2UgdG8gYmxvY2sgYSBuZXcg dmVyc2lvbiBvZiBRVUlDIC4uLiBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoYXQgYXNzZXJ0aW9uLg0K DQoNCkdvcnJ5DQoNCk9uIDEwIEFwciAyMDE5LCBhdCAxODoyNSwgTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PiB3 cm90ZToNCg0KDQoNCkNoaW5hIGJsb2NrcyBhcyBhIHJ1bGUuDQpSdXNzaWEgaXMgcnVubmluZyBh biBleHBlcmltZW50IHRvIGJsb2NrIHRoZSByZXN0IG9mIHRoZSBpbnRlcm5ldC4NClVTQSBibG9j a3MgbmV0IG5ldXRyYWxpdHkuDQpFVSBibG9ja3MgY29va2llcy4NCkdCIGJsb2NrcyBpdHNlbGYu DQoNCg0KU28gYmxvY2tpbmcgaXMgbm90IGxpbWl0ZWQgdG8gd2hhdCBhbiBvcGVyYXRvciBjb25z aWRlcnMgYmVzdCBmb3IgYnVzaW5lc3MuDQoNCg0KDQpPbiAxMCBBcHJpbCAyMDE5IGF0IDE4LjU5 LjE1LCBCb3JkZXIsIEpvaG4gKGpvaG4uYm9yZGVyQGh1Z2hlcy5jb208bWFpbHRvOmpvaG4uYm9y ZGVyQGh1Z2hlcy5jb20+KSB3cm90ZToNCg0KDQpJIHVuZGVyc3RhbmQgd2h5IHBlb3BsZSB3YW50 IHRvIGNvbWUgZG93biBvbiB0aGUgc2lkZSBvZiBwcmV2ZW50aW5nIG9zc2lmaWNhdGlvbi4gQnV0 LCB0aGluZ3MgaGF2ZSBjaGFuZ2VkLiBUaGVyZSBhcmUgYSBsb3Qgb2YgbW9yZSBuZWdhdGl2ZSBj b25zZXF1ZW5jZXMgbm93IHdoZW4gcGVvcGxlIHVubmVjZXNzYXJpbHkgYmxvY2sgdGhpbmdzLiBJ IHRoaW5rIG9wZXJhdG9ycyB3b3VsZCBwdXQgYSBsb3Qgb2YgcHJlc3N1cmUgb24gdmVuZG9ycyB0 bw0Kbm90IGRvIGl0IG5vdyBhbmQgdG8gZml4IGl0IGlmIHRoZXkgZGlkICJieSBhY2NpZGVudCIu IE9mIGNvdXJzZSwgSSBhbSBvbmx5IG9uZSBvcGVyYXRvci4gSXQgd291bGQgYmUgbmljZSB0byBo ZWFyIGZyb20gb3RoZXJzLi4uDQoNCg0KDQpKb2huDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIFJvYmVydG8gUGVvbg0KU2VudDogV2VkbmVzZGF5 LCBBcHJpbCAxMCwgMjAxOSAxMjo1MiBQTQ0KVG86IEcgRmFpcmh1cnN0IDxnb3JyeUBlcmcuYWJk bi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+PjsNCnF1aWNAaWV0Zi5vcmc8bWFp bHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogSXMgIlZlcnNpb24gR3JlYXNpbmciIGEg bmV3IGJlbmZpdCBvciBhIG5ldyBvYnN0YWNsZT8NCg0KV0FSTklORzogVGhlIHNlbmRlciBvZiB0 aGlzIGVtYWlsIGNvdWxkIG5vdCBiZSB2YWxpZGF0ZWQgYW5kIG1heSBub3QgbWF0Y2ggdGhlIHBl cnNvbiBpbiB0aGUgIkZyb20iIGZpZWxkLg0KDQpDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0 ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBv ciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtu b3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0KDQpZb3UncmUga2luZGEgYmV0d2VlbiBhIHJvY2st YW5kLWEtaGFyZC1wbGFjZSBlaXRoZXIgd2F5Og0KDQotIFdlJ3ZlIHNlZW4gaG93IG11Y2ggZnVu IG9zc2lmaWNhdGlvbiBpcyBpbiBUQ1AgYW5kIEhUVFAuIElmIHRoZSB0aGluZyBpcyBvYnNlcnZh YmxlLCBpdCB3aWxsIGJlIG9zc2lmaWVkIHNlZW1zIHRvIGJlIHRoZSBsZXNzb24uIEEgbG90IG9m IHRoZSByZWFzb24gd2h5IFFVSUMgd2FzIHN0YXJ0ZWQgaW4gdGhlIGZpcnN0IHBsYWNlIHdhcyBi ZWNhdXNlIG9mIHRoZSBpbmFiaWxpdHkgdG8gaW1wcm92ZSBUQ1AgZHVlIHRvIHRoaXMgb3NzaWZp Y2F0aW9uLg0KLSBPVE9ILCB0aGVyZSBpcyB0aGUgZmVhciBvZiB1bmtub3duL3Vub2JzZXJ2YWJs ZSB3aGljaCBtaWdodCBjYXVzZSBvcGVyYXRvcnMgdG8gYmxvY2sgdGhpbmdzLCB3aGV0aGVyIHBy ZWRpY3RhYmx5IG9yIG5vdC4NCg0KTXkgb3BpbmlvbiBpcyB0aGF0IGl0IGlzIGJldHRlciB0byBz dGFydCB3aXRoIHByZXZlbnRpbmcgb3NzaWZpY2F0aW9uLCBhbmQgdGhlbiBpZiB0aGF0IHJlc3Vs dHMgaW4gdG9vIGxhcmdlIGEgcGVyY2VudGFnZSBvZiBvcGVyYXRvcnMgYmxvY2tpbmcgdGhpbmdz LCB0byByZS1ldmFsdWF0ZS4NCg0KTXkgZ3Vlc3NlczoNCklQK3BvcnQgdHVwbGVzIGFuZCB0cmFm ZmljIHBhdHRlcm5zIGFyZSBzdGlsbCBvYnNlcnZhYmxlIChmb3IgYmV0dGVyIGFuZCB3b3JzZSks IHdoaWNoIGltcGxpZXMgb3BlcmF0b3JzIHdpbGwgc3RpbGwgaGF2ZSBzaWduaWZpY2FudCB0b29s cyBmb3IgbWFuYWdpbmcgdHJhZmZpYy4gSSBiZWxpZXZlIHRoYXQgdGhlc2UgYXJlIGFjdGVkIG9u L21hdGNoZWQgKE1MIG9yIG5vdCkgcmVnYXJkbGVzcyBvZiBhbnkgb3RoZXIgZGF0YSBwcmVzZW50 ZWQuIEluDQpvdGhlciB3b3JkcywgSSBoYXZlIGEgZG91YnQgdGhhdCBzdGF0aW5nIHRoZSB2ZXJz aW9uIGluIGFuIG9ic2VydmFibGUgd2F5IHdpbGwgcHJldmVudCB0aGUgdXNlIG9mIHN1Y2ggdG9v bHMuDQoNCk1vc3QgcHJvYmxlbXMgSSd2ZSBzZWVuIGFzc29jaWF0ZWQgd2l0aCBpbXBsZW1lbnRh dGlvbnMgcmF0aGVyIHRoYW4gcHJvdG9jb2wgdmVyc2lvbnMgKHRob3VnaCB3aGVuIHRoZSBsYXR0 ZXIgaGFwcGVucyBpdCBpcyBwcmV0dHkgc2V2ZXJlKS4uIElmIHlvdSBiZWxpZXZlIHRoaXMgYXNz ZXJ0aW9uLCB0aGVuIGFjdGluZyBvbiBwcm90b2NvbCB2ZXJzaW9uIGlzIGxlc3MgaW50ZXJlc3Rp bmcgdGhhbiBhdHRlbXB0aW5nIHRvIGFjdCBiYXNlZCBvbiBpbXBsZW1lbnRhdGlvbg0KZmluZ2Vy cHJpbnRzLg0KLT1SDQoNCg0KT24gNC8xMC8xOSwgMTo0OCBBTSwgIlFVSUMgb24gYmVoYWxmIG9m IEcgRmFpcmh1cnN0IiA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZg0KZ29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5 QGVyZy5hYmRuLmFjLnVrPj4gd3JvdGU6DQoNCk9ic2N1cmluZyB0aGUgdmVyc2lvbiBvZiBhIHBy b3RvY29sIHNlZW1zIGxpa2UgYSBtYWpvciBkZXNpZ24gZGVzaWduDQpkZWNpc2lvbiBmb3Igd2lk ZXIgdXNlIGNhc2VzLiBTbywgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZQ0KbW90aXZhdGlv biBmb3IgdmVyc2lvbiBncmVhc2luZy4NCg0KKDEpIEkga25vdyB0aGVyZSB3ZXJlIGluc3RhbmNl cyB3aGVyZSBzb21lIGVhcmx5IHZlcnNpb25zIG9mIFFVSUMgd2VyZQ0KYmxvY2tlZCBkdWUgdG8g YW4gdW5pbml0ZW50aW9uYWwgbWF0Y2hpbmcgb2YgdGhlIGhlYWRlci4gSXMgdGhlcmUNCmV2aWRl bmNlIG9mIGludGVudGlvbmFsIGF0dGVtcHRzIHRvIGJsb2NrIHVwZGF0ZXMgdG8gcHJvdG9jb2xz Pw0KDQooMikgVGhpbmtpbmcgYWJvdXQgb3BlcmF0aW5nIGEgbmV0d29yayB0aGF0IGNhcmVzIGFi b3V0IHVzZXIgc3VwcG9ydCBhbmQNCnByb3RlY3Rpb24gZnJvbSB1bndhbnRlZCB0cmFmZmljLCBJ IHdvdWxkIGV4cGVjdCB0aGF0IHRoZXJlIHdvdWxkIGJlDQpjYXNlcyB3aGVyZSB0cmFmZmljIHBh dHRlcm4gYW5vbW9saWVzIGFyZSBmb3VuZCBhbmQgdGhlIGFwcHJvcHJpYXRlDQp0aGluZyB3b3Vs ZCBiZSB0byB0cnkgdG8gZGV0ZXJtaW5lIGlmIGEgbmV3IHByb3RvY29sIGhhZCBiZWVuIGRlcGxv eWVkDQphbmQgbW9uaXRvciBpdCwgaWYgbm90LCB0aGVuIHRoZSBuZXh0IG1vc3Qgb2J2aW91cyB0 aGluZyBjb3VsZCBiZSB0bw0KYmxvY2sgYWxsIHVuZXhwZWN0ZWQgdHJhZmZpYywgdGhhdCBzZWVt cyBsaWtlIGEgZGVjaXNpb24gdG8gaGlkZSB0aGUNCnZlcnNpb24gY291bGQgaW5jcmVhc2Ugb3Nz aWZpY2F0aW9uIGZvciBuZXcgdmVyc2lvbnMgaW4gdGhlc2UgY2FzZXMuLg0KDQooMykgU2ltaWxh cmx5LCBpZiBhIHRocmVhdCBpcyBrbm93biB0byBpbXBhY3Qgb25seSBhIHNwZWNpZmljIChvbGRl cikNCnZlcnNpb24sIGl0IHdvdWxkIHNlZW0gdG8gbW90aXZhdGUgYSBkcm9wIG9mIHRoYXQgdHJh ZmZpYyB0aGF0IHNlZWtzIHRvDQp1c2UgdGhhdCB2ZXJzaW9uLCB3aGlsZSBzdGlsbCBwZXJtaXR0 aW5nIG90aGVyIHRyYWZmaWMuIEZvcmNpbmcgdmVyc2lvbg0KZGV0ZWN0aW9uIHRvIHVzZSBwYXR0 ZXJuIG1hdGNoaW5nL01MIHdpbGwgbGVhZCB0byBsZXNzIHByZWRpY3RhYmxlDQpvdXRjb21lcywg b3IgYmxvY2tpbmcgYmFzZWQgb24gYWRkcmVzcywgZXRjLg0KDQooNCkgVGhpcyBvYmZ1c3RpY2F0 ZXMgdGhlIG1vc3QgYmFzaWMgcGllY2Ugb2YgcmVwb3J0aW5nIGluZm9ybWF0aW9uIHVzZWQNCmZv ciBzdXBwb3J0LiBJdCBoaWRlcyB0aGUgZXh0ZW50IG9mIGRlcGxveW1lbnQgb2YgdGhlIGN1cnJl bnQgcHJvdG9jb2wNCnZlcnNpb24gYW5kIHByZXZsYW5jZSBvZiBvbGQgaW1wbGVtZW50YXRpb25z Lg0KDQooNSkgT24gdGhlIHN1cHBvcnQsIGlmIGEgcHJvYmxlbSBvbmx5IGVtZXJnZXMgd2hlbiBh IHBhcnRpY3VsYXIgdmVyc2lvbg0KaXMgdXNlZCB3aXRoIGEgcGFydGljdWxhciBhZGRyZXNzLCB0 aGVuIHRoaXMgaGVscHMgcGlucG9pbnQgdGhlIGlzc3Vlcy4NCk1hdGNoaW5nIGNsaWVudCB2ZXJz aW9ucyB0byBzZXJ2ZXJzIGlzIG11Y2ggbW9yZSBvZiBhbiBpc3N1ZSBpZiB0aGUgdXNlcg0KY29t bXVuaXR5IHVzZXMgYSB3aWRlIHJhbmdlIG9mIHNlcnZlcnMgKGxlc3Mgc28sIEkgZXhwZWN0IGZv ciBtYWpvcg0KcHJvdmlkZXJzOiBnb29nbGUsIGZhY2Vib29rLCBldGMsIGV0YyksIGJ1dCBzaWdu aWZpY2FudCB3aGVuIHRoZXJlIGlzIGENCnVzZSBvZiBhIGRpdmVyc2Ugc2V0IG9mIGV4dGVybmFs IHNpdGVzIGFuZCBzaXRlcyB3aXRoIHRoZWlyIG93biBsb2FkDQpiYWxhbmNlcnMsIGV0YyBhbmQg YSBuZWVkIHRvIG1hbmFnZSBpbnRlcmFjdGlvbnMgd2l0aCBMMiBzZXJ2aWNlcy4NCg0KSSBhbSBp bnRlcnN0ZWQgaW4ga25vd2luZyBpZiB0aGlzIGlzIGxpa2VseSB0byBiZW5lZml0IG9yIGJlIGEg bmV3IG9ic3RhY2xlPw0KDQpHb3JyeQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K --_000_MW2PR2101MB104902B6BC7C67D8688EA852B6280MW2PR2101MB1049_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxl LW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlZlcnNpb24gZ3JlYXNpbmcgd2lsbCBjcmVhdGUgcHJvYmxlbXMgZm9yIEREb1MgcHJv dGVjdGlvbi4gVGhlIEREb1MgcHJvdGVjdGlvbiBtaWRkbGVib3ggd2lsbCBoYXZlIHRvIHRyZWF0 IGFsbCB0cmFmZmljIHdpdGggdW5rbm93biB2ZXJzaW9uIG51bWJlcnMgYXMgcGxhaW4gb2xkIFFV SUMgYW5kIHJhdGUgbGltaXQgaXQuIEFueSBzb2x1dGlvbiB0aGF0IHJlcXVpcmVzIHBlciBjb25u ZWN0aW9uIHN0YXRlIHRvDQogdHJhY2sgdmVyc2lvbiBudW1iZXJzIGRvZXNu4oCZdCBzY2FsZS4g RXNwZWNpYWxseSBpbiB0aGUgY2xvdWQgc2NlbmFyaW8gY3VzdG9tZXJzIGJyaW5nIHRoZWlyIG93 biB3ZWIgc2VydmVycyBzbyB0aGlzIG1ha2VzIGFueSBvcHQtb3V0IHNvbHV0aW9uIG5vdCBnb29k IGVub3VnaC4gU28gSSBkbyB0aGluayB0aGlzIGlzIGFuIG9ic3RhY2xlIGZvciBtYW55IGRlcGxv eW1lbnRzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0 OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTEsIDIwMTkgMToyMCBBTTxicj4NCjxiPlRvOjwv Yj4gR29ycnkgKGVyZykgJmx0O2dvcnJ5QGVyZy5hYmRuLmFjLnVrJmd0OzsgTWlyamEgS3VlaGxl d2luZCAmbHQ7bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBxdWljQGlldGYub3JnOyBCb3JkZXIsIEpvaG4gJmx0O2pvaG4uYm9yZGVyQGh1Z2hlcy5jb20m Z3Q7OyBSb2JlcnRvIFBlb24gJmx0O2Zlbml4QGZiLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IElzICZxdW90O1ZlcnNpb24gR3JlYXNpbmcmcXVvdDsgYSBuZXcgYmVuZml0IG9yIGEg bmV3IG9ic3RhY2xlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gYSBub3Qgc28g ZGlzdGFudCBmdXR1cmUsIGEgZmFsbGJhY2sgdG8gVENQIHdvdWxkIG5vdCBiZSBhIHZpYWJsZSBh bHRlcm5hdGl2ZSBmb3IgYSBudW1iZXIgb2Ygc2VydmljZXMuIFRoaW5rIFdlYlJUQy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIFFVSUMgYW5kIG90aGVyIGVu Y3J5cHRlZCBwcm90b2NvbHMgYmVjb21lIGRvbWluYW50LCBqdXN0IGJsb2NraW5nIGV2ZXJ5dGhp bmcgd291bGQgbGl0ZXJhbGx5IGJsb2NrIGV2ZXJ5dGhpbmcuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5PZiBjb3Vyc2UsIGh0dHAocykgYXMgd2Uga25vdyBpdCwg aXQgd2lsbCBjb250aW51ZSB0byBsaXZlIG9uLCBidXQgbWFueSBtb2JpbGUgYXBwcyB3b3VsZCBu b3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE1 NTQ5NzA2OTgzMDAyODIxMTIiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiAx MSBBcHJpbCAyMDE5IGF0IDEwLjAzLjE0LCBNaXJqYSBLdWVobGV3aW5kICg8YSBocmVmPSJtYWls dG86bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20iPm1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nz b24uY29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkhpIE1pa2tlbCwNCjxicj4NCjxicj4NCkkgZ3Vlc3MgaXQgaXMgbXVjaCBt b3JlIGxpa2VseSB0aGF0IGFueSBvZiB0aG9zZSBhY3RvcnMgd291bGQganVzdCBibG9jayBRVUlD IGFsbCB0b2dldGhlciAoYXMgdGhlcmUgaXMgYWN0dWFsbHkgYSBmYWxsYmFjayB0byBUQ1ApLg0K PGJyPg0KPGJyPg0KTWlyamEgPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj7vu788L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDEwLjA0LjE5LCAyMTo1Nywg JnF1b3Q7UVVJQyBvbiBiZWhhbGYgb2YgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGll dGYub3JnPC9hPg0KIG9uIGJlaGFsZiBvZiA8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwu Y29tIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTogPGJyPg0KPGJyPg0KPGJyPg0K TGV04oCZcyBzYXkgQ2hpbmEgbWFrZXMgYSBkZWFsIHdpdGggR29vZ2xlIHRvIGFsbG93IHRoZWly IHNlYXJjaCBlbmdpbmUgKGEgbm90IGVudGlyZWx5IHVucmVhc29uYWJseSBwcm9wb3NpdGlvbiku DQo8YnI+DQpUaGUgR3JlYXQgRmlyZXdhbGwgb2YgQ2hpbmEgKEdGQykgaXMgcmVjb25maWd1cmVk IHRvIGFjY2VwdCB0cmFmZmljIGZyb20gYSBzcGVjaWZpYyBJUCByYW5nZSBmb3IgUVVJQyBwcm90 b2NvbCB2MS4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCkdvb2dsZSBsYXRlciB1cGdyYWRlcyB0 byB2Mi4gR0ZDIGlzIHVwZGF0ZWQuIExhdGVyLCBvdXQgb2YgaWdub3JhbmNlLCBzb21lIG90aGVy IGRlcGFydG1lbnQgd2l0aGluIHNhaWQgY29tcGFueSBkZWNpZGVzIHRoYXQgaXRzIGJyb3dzZXJz IHNob3VsZCBhbGwgdXNlIGZvcmNlZCB2ZXJzaW9uIGFsaWFzZXMgYXMgYSBydWxlLiBHRkMgYnJl YWtzLiAoQXNzdW1pbmcgR29vZ2xlcyBzZXJ2ZXJzIGFyZSBub3QgbG9jYXRlZCB3aXRoaW4gdGhl IGRlbWlsaXRhcmlzZWQNCjxicj4NCnpvbmUgYW5kIHVzZXJzIHVzZSBDaHJvbWUpLiA8YnI+DQo8 YnI+DQo8YnI+DQpBbHRlcm5hdGl2ZSAxOiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0byBkZXBs b3kgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcuIENoaW5hIHJlamVjdHMgdGhlIGRlYWwgYmVjYXVz ZSB0aGV5IGRvIG5vdCB3YW50IHRvIHN1cHBvcnQgcmFuZG9tIHRyYWZmaWMgdGhyb3VnaCBHRkMu DQo8YnI+DQo8YnI+DQo8YnI+DQpBbHRlcm5hdGl2ZSAyOiBHb29nbGUgdXAgZnJvbnQgZGVjaWRl cyB0byBkZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcsIGFuZCBDaGluYSBkb2VzIG5vdCBy ZWplY3QgdGhlIGRlYWwsIG91dCBvZiBpZ25vcmFuY2UuIExhdGVyIHNvbWUgZGVwYXJ0bWVudCBp biBDaGluYSBHRkMgb3ZlcnNpZ2h0IHJlYWxpc2VzIHRoZSBkZWFsIGFuZCBmb3JjZXMgR29vZ2xl IHRvIHJlbW92ZSBmb3JjZWQgdmVyc2lvbiBhbGlhc2luZywgb3Igc2h1dCBkb3duDQo8YnI+DQpp dHMgc2VydmljZS4gPGJyPg0KPGJyPg0KPGJyPg0KQWx0ZXJuYXRpdmUgMzogR29vZ2xlIHVwIGZy b250IGRlY2lkZXMgdG8gZGVwbG95IGZvcmNlZCB2ZXJzaW9uIGFsaWFzaW5nIGFuZCBDaGluYSBz YXlzLCBvZiBjb3Vyc2UsIHdlIHRydXN0IGV2ZXJ5dGhpbmcgZnJvbSBHb29nbGVzIElQIHJhbmdl Lg0KPGJyPg0KPGJyPg0KPGJyPg0KQWx0ZXJuYXRpdmUgNDogR29vZ2xlIHJlYWxpc2VzIHRoYXQg Zm9yY2VkIHZlcnNpb24gYWxpYXNpbmcgZG9lcyBub3Qgd29yayBpbiB0aGUgZ2VuZXJhbCBjYXNl LCBhbmQgbWFrZXMgYSBzcGVjaWFsIGNhc2UgZm9yIHVzZXJzIHdpdGhpbiBhIGNlcnRhaW4gZ2Vv Z3JhcGhpY2FsIGFyZWEuDQo8YnI+DQo8YnI+DQo8YnI+DQpEaXNjbGFpbWVyOiBJ4oCZbSBub3Qg YWZmaWxpYXRlZCB3aXRoIEdvb2dsZSBhbmQgdGhpcyBtaWdodCBub3QgYXQgYWxsIGJlIGhvdyB0 aGluZ3Mgd291bGQgd29yaywgYnV0IGl0IGRvZXMgaGlnaGxpZ2h0IHNvbWUgb2YgdGhlIGNoYWxs ZW5nZXMuDQo8YnI+DQo8YnI+DQo8YnI+DQpPZiBjb3Vyc2UsIHRvIGJlIGZhaXIsIENoaW5hIGlz IG5vdCB0aGUgb25seSBnb3Zlcm5tZW50IGVudGl0eSB0aGF0IG1pZ2h0IGhhdmUgYSB2ZXN0ZWQg aW50ZXJlc3QuIExldCdzIHRha2UgYSBmaWN0aW9uYWwgZXhhbXBsZSBvZiBVUyBhIHJlYWwgZXN0 YXRlIGludmVzdG9yIHdpdGggaGVhdnkgdGllcyB0byB0aGUgZWFzdGVybiBldXJvcGVhbiBibG9j ayB3aG8gc29tZWhvdyBmaW5kcyBoaW1zZWxmIGVsZWN0ZWQgYXMgcHJlc2lkZW50IG5lZWRpbmcN Cjxicj4NCnRvIGZpbmQgbGV2ZXJhZ2Ugb24gdHJhZGUgbmVnb3RpYXRpb25zIHdpdGhvdXQgZWZm ZWN0aXZlbHkgaHVydGluZyBwZXJzb25hbCBmaW5hbmNlcy4gSXQgdHVybnMgb3V0IHRoYXQgYmxv Y2tpbmcgY2VydGFpbiBkaWdpdGFsIHNlcnZpY2VzIGZyb20gc2FpZCBlYXN0ZXJuIGV1cm9wZWFu IGJsb2NrIGlzIHRoZSBwZXJmZWN0IHRvb2wgaW4gdGhlIHRyYWRlIG5lZ290aWF0aW9ucy4uIEFk dmlzZXJzIHBvaW50IG91dCB0aGF0IHRob3NlIHNlcnZpY2VzDQo8YnI+DQpydW4gaGVhdmlseSBl bmNyeXB0ZWQgb24gdGhlIGRhcmsgd2ViIHdpdGggcGVycGV0dWFsIGNpcmN1bGF0aW9uIG9mIElQ IHJhbmdlcyBzbywgaWdub3JpbmcgYW55IGxlZ2FsIGNvbmNlcm5zLCBpdCB3b3VsZCBub3QgYmUg cHJhY3RpY2FsbHkgcG9zc2libGUuIEV2ZW50dWFsbHkgc29tZW9uZSBmaWd1cmVzIG91dCB0aGF0 IHRoZXNlIHNlcnZpY2VzIGFsbCB1c3VhbGx5IGFyZSBhdCB0aGUgZm9yZWZyb250IG9mIHRlY2hu b2xvZ3kgYW5kIGN1cnJlbnRseQ0KPGJyPg0KdXNlIFFVSUMgdjMuMiBhbmQgbm8tb25lIGVsc2Ug aGFzIGRlcGxveWVkIHRoYXQgdmVyc2lvbiB5ZXQsIHNvIGl0IHdvdWxkIHN1ZmZpY2UgdG8gYXNr IE5TQSB0byB0YXAgaW50byB0aGUgYmFja2JvbmUgYW5kIGRpc3J1cHQgc3BlY2lmaWMgcGFja2V0 cy4gT2YgY291cnNlLCB0aGlzIGVuZHMgdXAgdGFraW5nIGRvd24gdGhlIEJhdmFyaWFuIGxvY2Fs IGdvdmVybm1lbnQgZWxlY3Rpb24gcHJvY2VzcyBpbiBHZXJtYW55IHdoZXJlIHRoZXkgYXJlDQo8 YnI+DQp0aGUgZmlyc3QgdG8gdXNlIGEgbmV3IGRpZ2l0YWwgZWxlY3Rpb24gc3lzdGVtLiBOb3Qg dGhhdCB0aGUgaXMgYW4gaXNzdWUsIHNpbmNlIHRyYWRlIG5lZ290aWF0aW9ucyBhcmUgYWxzbyBy dW5uaW5nIGhvdCBpbiB0aGF0IGFyZWEsIHNvIHRoYXQgaXMganVzdCBhbiBhY2NpZGVudGFsIGJv bnVzLg0KPGJyPg0KPGJyPg0KPGJyPg0KT3IgYW4gZW5kbGVzcyBudW1iZXIgb2Ygb3RoZXIgZGV2 ZWxvcG1lbnRzIG92ZXIgdGhlIG5leHQgZmV3IGRlY2FkZXMgaWYgdGhlIHBhc3QgZmV3IHllYXJz IGlzIGFueXRoaW5nIHRvIGdvIGJ5Lg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KT24gMTAgQXByaWwgMjAxOSBhdCAyMC4xMy41OSwgR29ycnkgKGVyZykgKDxhIGhyZWY9Im1h aWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+KSB3cm90 ZToNCjxicj4NCjxicj4NClRoYW5rcyBNaWtrZWwsIEkgZG8gdW5kZXJzdGFuZCB0aGF0IHZhcmlv dXMgYWN0b3JzIGludGVudGlvbmFsbHkgZHJvcCAtIGJ1dCBhcmUgeW91IHNheWluZyB0aGVzZSBh Y3RvcnMgd291bGQgc3BlY2lmaWNhbGx5IGNob29zZSB0byBibG9jayBhIG5ldyB2ZXJzaW9uIG9m IFFVSUMgLi4uIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhhdCBhc3NlcnRpb24uDQo8YnI+DQo8YnI+ DQo8YnI+DQpHb3JyeSA8YnI+DQo8YnI+DQpPbiAxMCBBcHIgMjAxOSwgYXQgMTg6MjUsIE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5j b20iPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KQ2hpbmEgYmxvY2tzIGFzIGEgcnVsZS4gPGJyPg0KUnVzc2lhIGlzIHJ1bm5pbmcgYW4g ZXhwZXJpbWVudCB0byBibG9jayB0aGUgcmVzdCBvZiB0aGUgaW50ZXJuZXQuIDxicj4NClVTQSBi bG9ja3MgbmV0IG5ldXRyYWxpdHkuIDxicj4NCkVVIGJsb2NrcyBjb29raWVzLiA8YnI+DQpHQiBi bG9ja3MgaXRzZWxmLiA8YnI+DQo8YnI+DQo8YnI+DQpTbyBibG9ja2luZyBpcyBub3QgbGltaXRl ZCB0byB3aGF0IGFuIG9wZXJhdG9yIGNvbnNpZGVycyBiZXN0IGZvciBidXNpbmVzcy4gPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KT24gMTAgQXByaWwgMjAxOSBhdCAxOC41OS4xNSwgQm9yZGVyLCBK b2huICg8YSBocmVmPSJtYWlsdG86am9obi5ib3JkZXJAaHVnaGVzLmNvbSI+am9obi5ib3JkZXJA aHVnaGVzLmNvbTwvYT4pIHdyb3RlOg0KPGJyPg0KPGJyPg0KPGJyPg0KSSB1bmRlcnN0YW5kIHdo eSBwZW9wbGUgd2FudCB0byBjb21lIGRvd24gb24gdGhlIHNpZGUgb2YgcHJldmVudGluZyBvc3Np ZmljYXRpb24uIEJ1dCwgdGhpbmdzIGhhdmUgY2hhbmdlZC4gVGhlcmUgYXJlIGEgbG90IG9mIG1v cmUgbmVnYXRpdmUgY29uc2VxdWVuY2VzIG5vdyB3aGVuIHBlb3BsZSB1bm5lY2Vzc2FyaWx5IGJs b2NrIHRoaW5ncy4gSSB0aGluayBvcGVyYXRvcnMgd291bGQgcHV0IGEgbG90IG9mIHByZXNzdXJl IG9uIHZlbmRvcnMgdG8NCjxicj4NCm5vdCBkbyBpdCBub3cgYW5kIHRvIGZpeCBpdCBpZiB0aGV5 IGRpZCAmcXVvdDtieSBhY2NpZGVudCZxdW90Oy4gT2YgY291cnNlLCBJIGFtIG9ubHkgb25lIG9w ZXJhdG9yLiBJdCB3b3VsZCBiZSBuaWNlIHRvIGhlYXIgZnJvbSBvdGhlcnMuLi4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCkpvaG4gPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0gPGJyPg0KRnJvbTogUVVJQyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIFJv YmVydG8gUGVvbg0KPGJyPg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMCwgMjAxOSAxMjo1MiBQ TSA8YnI+DQpUbzogRyBGYWlyaHVyc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJk bi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OzsNCjxicj4NCjxhIGhyZWY9Im1h aWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiA8YnI+DQpTdWJqZWN0OiBSZTog SXMgJnF1b3Q7VmVyc2lvbiBHcmVhc2luZyZxdW90OyBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2Jz dGFjbGU/IDxicj4NCjxicj4NCldBUk5JTkc6IFRoZSBzZW5kZXIgb2YgdGhpcyBlbWFpbCBjb3Vs ZCBub3QgYmUgdmFsaWRhdGVkIGFuZCBtYXkgbm90IG1hdGNoIHRoZSBwZXJzb24gaW4gdGhlICZx dW90O0Zyb20mcXVvdDsgZmllbGQuDQo8YnI+DQo8YnI+DQpDQVVUSU9OOiBUaGlzIGVtYWlsIG9y aWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBs aW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIg YW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCjxicj4NCjxicj4NCjxicj4NCllvdSdyZSBr aW5kYSBiZXR3ZWVuIGEgcm9jay1hbmQtYS1oYXJkLXBsYWNlIGVpdGhlciB3YXk6IDxicj4NCjxi cj4NCi0gV2UndmUgc2VlbiBob3cgbXVjaCBmdW4gb3NzaWZpY2F0aW9uIGlzIGluIFRDUCBhbmQg SFRUUC4gSWYgdGhlIHRoaW5nIGlzIG9ic2VydmFibGUsIGl0IHdpbGwgYmUgb3NzaWZpZWQgc2Vl bXMgdG8gYmUgdGhlIGxlc3Nvbi4gQSBsb3Qgb2YgdGhlIHJlYXNvbiB3aHkgUVVJQyB3YXMgc3Rh cnRlZCBpbiB0aGUgZmlyc3QgcGxhY2Ugd2FzIGJlY2F1c2Ugb2YgdGhlIGluYWJpbGl0eSB0byBp bXByb3ZlIFRDUCBkdWUgdG8gdGhpcyBvc3NpZmljYXRpb24uDQo8YnI+DQotIE9UT0gsIHRoZXJl IGlzIHRoZSBmZWFyIG9mIHVua25vd24vdW5vYnNlcnZhYmxlIHdoaWNoIG1pZ2h0IGNhdXNlIG9w ZXJhdG9ycyB0byBibG9jayB0aGluZ3MsIHdoZXRoZXIgcHJlZGljdGFibHkgb3Igbm90Lg0KPGJy Pg0KPGJyPg0KTXkgb3BpbmlvbiBpcyB0aGF0IGl0IGlzIGJldHRlciB0byBzdGFydCB3aXRoIHBy ZXZlbnRpbmcgb3NzaWZpY2F0aW9uLCBhbmQgdGhlbiBpZiB0aGF0IHJlc3VsdHMgaW4gdG9vIGxh cmdlIGEgcGVyY2VudGFnZSBvZiBvcGVyYXRvcnMgYmxvY2tpbmcgdGhpbmdzLCB0byByZS1ldmFs dWF0ZS4NCjxicj4NCjxicj4NCk15IGd1ZXNzZXM6IDxicj4NCklQJiM0Mztwb3J0IHR1cGxlcyBh bmQgdHJhZmZpYyBwYXR0ZXJucyBhcmUgc3RpbGwgb2JzZXJ2YWJsZSAoZm9yIGJldHRlciBhbmQg d29yc2UpLCB3aGljaCBpbXBsaWVzIG9wZXJhdG9ycyB3aWxsIHN0aWxsIGhhdmUgc2lnbmlmaWNh bnQgdG9vbHMgZm9yIG1hbmFnaW5nIHRyYWZmaWMuIEkgYmVsaWV2ZSB0aGF0IHRoZXNlIGFyZSBh Y3RlZCBvbi9tYXRjaGVkIChNTCBvciBub3QpIHJlZ2FyZGxlc3Mgb2YgYW55IG90aGVyIGRhdGEg cHJlc2VudGVkLiBJbg0KPGJyPg0Kb3RoZXIgd29yZHMsIEkgaGF2ZSBhIGRvdWJ0IHRoYXQgc3Rh dGluZyB0aGUgdmVyc2lvbiBpbiBhbiBvYnNlcnZhYmxlIHdheSB3aWxsIHByZXZlbnQgdGhlIHVz ZSBvZiBzdWNoIHRvb2xzLg0KPGJyPg0KPGJyPg0KTW9zdCBwcm9ibGVtcyBJJ3ZlIHNlZW4gYXNz b2NpYXRlZCB3aXRoIGltcGxlbWVudGF0aW9ucyByYXRoZXIgdGhhbiBwcm90b2NvbCB2ZXJzaW9u cyAodGhvdWdoIHdoZW4gdGhlIGxhdHRlciBoYXBwZW5zIGl0IGlzIHByZXR0eSBzZXZlcmUpLi4g SWYgeW91IGJlbGlldmUgdGhpcyBhc3NlcnRpb24sIHRoZW4gYWN0aW5nIG9uIHByb3RvY29sIHZl cnNpb24gaXMgbGVzcyBpbnRlcmVzdGluZyB0aGFuIGF0dGVtcHRpbmcgdG8gYWN0IGJhc2VkIG9u IGltcGxlbWVudGF0aW9uDQo8YnI+DQpmaW5nZXJwcmludHMuIDxicj4NCi09UiA8YnI+DQo8YnI+ DQo8YnI+DQpPbiA0LzEwLzE5LCAxOjQ4IEFNLCAmcXVvdDtRVUlDIG9uIGJlaGFsZiBvZiBHIEZh aXJodXJzdCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+ cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxicj4NCjxhIGhyZWY9Im1h aWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OyB3 cm90ZTogPGJyPg0KPGJyPg0KT2JzY3VyaW5nIHRoZSB2ZXJzaW9uIG9mIGEgcHJvdG9jb2wgc2Vl bXMgbGlrZSBhIG1ham9yIGRlc2lnbiBkZXNpZ24gPGJyPg0KZGVjaXNpb24gZm9yIHdpZGVyIHVz ZSBjYXNlcy4gU28sIEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgPGJyPg0KbW90aXZhdGlv biBmb3IgdmVyc2lvbiBncmVhc2luZy4gPGJyPg0KPGJyPg0KKDEpIEkga25vdyB0aGVyZSB3ZXJl IGluc3RhbmNlcyB3aGVyZSBzb21lIGVhcmx5IHZlcnNpb25zIG9mIFFVSUMgd2VyZSA8YnI+DQpi bG9ja2VkIGR1ZSB0byBhbiB1bmluaXRlbnRpb25hbCBtYXRjaGluZyBvZiB0aGUgaGVhZGVyLiBJ cyB0aGVyZSA8YnI+DQpldmlkZW5jZSBvZiBpbnRlbnRpb25hbCBhdHRlbXB0cyB0byBibG9jayB1 cGRhdGVzIHRvIHByb3RvY29scz8gPGJyPg0KPGJyPg0KKDIpIFRoaW5raW5nIGFib3V0IG9wZXJh dGluZyBhIG5ldHdvcmsgdGhhdCBjYXJlcyBhYm91dCB1c2VyIHN1cHBvcnQgYW5kIDxicj4NCnBy b3RlY3Rpb24gZnJvbSB1bndhbnRlZCB0cmFmZmljLCBJIHdvdWxkIGV4cGVjdCB0aGF0IHRoZXJl IHdvdWxkIGJlIDxicj4NCmNhc2VzIHdoZXJlIHRyYWZmaWMgcGF0dGVybiBhbm9tb2xpZXMgYXJl IGZvdW5kIGFuZCB0aGUgYXBwcm9wcmlhdGUgPGJyPg0KdGhpbmcgd291bGQgYmUgdG8gdHJ5IHRv IGRldGVybWluZSBpZiBhIG5ldyBwcm90b2NvbCBoYWQgYmVlbiBkZXBsb3llZCA8YnI+DQphbmQg bW9uaXRvciBpdCwgaWYgbm90LCB0aGVuIHRoZSBuZXh0IG1vc3Qgb2J2aW91cyB0aGluZyBjb3Vs ZCBiZSB0byA8YnI+DQpibG9jayBhbGwgdW5leHBlY3RlZCB0cmFmZmljLCB0aGF0IHNlZW1zIGxp a2UgYSBkZWNpc2lvbiB0byBoaWRlIHRoZSA8YnI+DQp2ZXJzaW9uIGNvdWxkIGluY3JlYXNlIG9z c2lmaWNhdGlvbiBmb3IgbmV3IHZlcnNpb25zIGluIHRoZXNlIGNhc2VzLi4gPGJyPg0KPGJyPg0K KDMpIFNpbWlsYXJseSwgaWYgYSB0aHJlYXQgaXMga25vd24gdG8gaW1wYWN0IG9ubHkgYSBzcGVj aWZpYyAob2xkZXIpIDxicj4NCnZlcnNpb24sIGl0IHdvdWxkIHNlZW0gdG8gbW90aXZhdGUgYSBk cm9wIG9mIHRoYXQgdHJhZmZpYyB0aGF0IHNlZWtzIHRvIDxicj4NCnVzZSB0aGF0IHZlcnNpb24s IHdoaWxlIHN0aWxsIHBlcm1pdHRpbmcgb3RoZXIgdHJhZmZpYy4gRm9yY2luZyB2ZXJzaW9uIDxi cj4NCmRldGVjdGlvbiB0byB1c2UgcGF0dGVybiBtYXRjaGluZy9NTCB3aWxsIGxlYWQgdG8gbGVz cyBwcmVkaWN0YWJsZSA8YnI+DQpvdXRjb21lcywgb3IgYmxvY2tpbmcgYmFzZWQgb24gYWRkcmVz cywgZXRjLiA8YnI+DQo8YnI+DQooNCkgVGhpcyBvYmZ1c3RpY2F0ZXMgdGhlIG1vc3QgYmFzaWMg cGllY2Ugb2YgcmVwb3J0aW5nIGluZm9ybWF0aW9uIHVzZWQgPGJyPg0KZm9yIHN1cHBvcnQuIEl0 IGhpZGVzIHRoZSBleHRlbnQgb2YgZGVwbG95bWVudCBvZiB0aGUgY3VycmVudCBwcm90b2NvbCA8 YnI+DQp2ZXJzaW9uIGFuZCBwcmV2bGFuY2Ugb2Ygb2xkIGltcGxlbWVudGF0aW9ucy4gPGJyPg0K PGJyPg0KKDUpIE9uIHRoZSBzdXBwb3J0LCBpZiBhIHByb2JsZW0gb25seSBlbWVyZ2VzIHdoZW4g YSBwYXJ0aWN1bGFyIHZlcnNpb24gPGJyPg0KaXMgdXNlZCB3aXRoIGEgcGFydGljdWxhciBhZGRy ZXNzLCB0aGVuIHRoaXMgaGVscHMgcGlucG9pbnQgdGhlIGlzc3Vlcy4gPGJyPg0KTWF0Y2hpbmcg Y2xpZW50IHZlcnNpb25zIHRvIHNlcnZlcnMgaXMgbXVjaCBtb3JlIG9mIGFuIGlzc3VlIGlmIHRo ZSB1c2VyIDxicj4NCmNvbW11bml0eSB1c2VzIGEgd2lkZSByYW5nZSBvZiBzZXJ2ZXJzIChsZXNz IHNvLCBJIGV4cGVjdCBmb3IgbWFqb3IgPGJyPg0KcHJvdmlkZXJzOiBnb29nbGUsIGZhY2Vib29r LCBldGMsIGV0YyksIGJ1dCBzaWduaWZpY2FudCB3aGVuIHRoZXJlIGlzIGEgPGJyPg0KdXNlIG9m IGEgZGl2ZXJzZSBzZXQgb2YgZXh0ZXJuYWwgc2l0ZXMgYW5kIHNpdGVzIHdpdGggdGhlaXIgb3du IGxvYWQgPGJyPg0KYmFsYW5jZXJzLCBldGMgYW5kIGEgbmVlZCB0byBtYW5hZ2UgaW50ZXJhY3Rp b25zIHdpdGggTDIgc2VydmljZXMuIDxicj4NCjxicj4NCkkgYW0gaW50ZXJzdGVkIGluIGtub3dp bmcgaWYgdGhpcyBpcyBsaWtlbHkgdG8gYmVuZWZpdCBvciBiZSBhIG5ldyBvYnN0YWNsZT8gPGJy Pg0KPGJyPg0KR29ycnkgPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MW2PR2101MB104902B6BC7C67D8688EA852B6280MW2PR2101MB1049_-- From nobody Fri Apr 12 08:55:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C546D1202BD for ; Fri, 12 Apr 2019 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 5VWb4OdAYT07 for ; Fri, 12 Apr 2019 08:55:33 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730118.outbound.protection.outlook.com [40.107.73.118]) (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 388DC1200F6 for ; Fri, 12 Apr 2019 08:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kajEvngB6bTdBNNgqa+upvilOUYjhPN2L9nSil6WxwA=; b=bGp8wcA+qwgFW8cQUgrx3v/j7bFKNzX8uiS+d73CYJ63ZgjD4OWzmLas4acdZXK9Zz1SF1OnuioT99oGp2jPNxA+7CugLQ3is+vdAKKcXzB5Ml5ymkUs+l5rrC37qCq9DBT7JroYDPafILv1vBaq/sTiJt4SQvmoggg595xXKMk= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1034.namprd21.prod.outlook.com (52.132.149.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.0; Fri, 12 Apr 2019 15:55:30 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c999:100b:9952:f8f6]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c999:100b:9952:f8f6%5]) with mapi id 15.20.1813.000; Fri, 12 Apr 2019 15:55:30 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Gorry (erg)" , Mirja Kuehlewind CC: "quic@ietf.org" , "Border, John" , Roberto Peon Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o0AOSUW1ZVWEa1WA8MStgy7KY1nGCAgAACAYCAAAdsgIAADYwAgAAcxQCAAMrxAIAABNWAgAIQK4CAAADVYA== Date: Fri, 12 Apr 2019 15:55:30 +0000 Message-ID: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.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=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:0:21b3:7b4b:b4a3:c3bf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8cedfbcf-98d9-49f6-7174-08d6bf5f4a1e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(4534185)(4627221)(201703031133081)(201702281549075)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB1034; x-ms-traffictypediagnostic: MW2PR2101MB1034: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(136003)(39860400002)(346002)(189003)(199004)(13464003)(54906003)(81156014)(256004)(5024004)(71190400001)(8676002)(71200400001)(316002)(2906002)(74316002)(14444005)(110136005)(790700001)(6116002)(81166006)(8990500004)(22452003)(93156006)(486006)(105586002)(66574012)(106356001)(446003)(97736004)(7696005)(68736007)(6506007)(476003)(99286004)(76176011)(53546011)(46003)(8936002)(11346002)(102836004)(10290500003)(33656002)(93886005)(14454004)(186003)(53936002)(86612001)(5660300002)(478600001)(6306002)(54896002)(55016002)(86362001)(236005)(2940100002)(9686003)(52536014)(6436002)(7736002)(6246003)(25786009)(229853002)(10090500001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1034; H:MW2PR2101MB1049.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5VXj/KLkG6Zah42XH39Or/e4vtZ48TEkAe1SDrO8xEvVngZjX3LQJJ4bX5VOO3rZ9pHrEL5tzOGIZQqbVvB6wgzjnaNI/puobjtOGJmxfjTh43LhXdQiNGKmsEUvTpLfSczla8Rn3kooNmKw0+N3pgqNj7++QCD7LQkvdczq1MmH3U73wva4T+Txp829K6ElaeeW3pMbB/3wzbJB5atn77M+mq3+/YftSJUtHlTljZhL71lhyXcSPPf+RcGx93+NdYS9+MkhUI3vFmUllGX/X01gGyvDz4vhsx3RSwc/rNl3ZKzL9F9iqmdG1ImLGLo3GN7kqvQHtSXJV63g0OFXC4qs26Y6ldjmPv+KS3J6uUpiy9uoYzsQFrTPRStWrz+z+kmlEOi5MW+6i2Xpg//ZNXMtfeV82KWIqanmbOpGj6o= Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB104996C29680DF7B79230C8CB6280MW2PR2101MB1049_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8cedfbcf-98d9-49f6-7174-08d6bf5f4a1e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 15:55:30.5461 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1034 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 15:55:38 -0000 --_000_MW2PR2101MB104996C29680DF7B79230C8CB6280MW2PR2101MB1049_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIGEgdHlwby4gUGxhaW4gb2xkIFVEUCBub3QgUVVJQy4NCg0KRnJvbTogUHJhdmVl biBCYWxhc3VicmFtYW5pYW4NClNlbnQ6IEZyaWRheSwgQXByaWwgMTIsIDIwMTkgODo1MyBBTQ0K VG86IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47IEdvcnJ5 IChlcmcpIDxnb3JyeUBlcmcuYWJkbi5hYy51az47IE1pcmphIEt1ZWhsZXdpbmQgPG1pcmphLmt1 ZWhsZXdpbmRAZXJpY3Nzb24uY29tPg0KQ2M6IHF1aWNAaWV0Zi5vcmc7IEJvcmRlciwgSm9obiA8 am9obi5ib3JkZXJAaHVnaGVzLmNvbT47IFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPg0KU3Vi amVjdDogUkU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2Jz dGFjbGU/DQoNClZlcnNpb24gZ3JlYXNpbmcgd2lsbCBjcmVhdGUgcHJvYmxlbXMgZm9yIEREb1Mg cHJvdGVjdGlvbi4gVGhlIEREb1MgcHJvdGVjdGlvbiBtaWRkbGVib3ggd2lsbCBoYXZlIHRvIHRy ZWF0IGFsbCB0cmFmZmljIHdpdGggdW5rbm93biB2ZXJzaW9uIG51bWJlcnMgYXMgcGxhaW4gb2xk IFFVSUMgYW5kIHJhdGUgbGltaXQgaXQuIEFueSBzb2x1dGlvbiB0aGF0IHJlcXVpcmVzIHBlciBj b25uZWN0aW9uIHN0YXRlIHRvIHRyYWNrIHZlcnNpb24gbnVtYmVycyBkb2VzbuKAmXQgc2NhbGUu IEVzcGVjaWFsbHkgaW4gdGhlIGNsb3VkIHNjZW5hcmlvIGN1c3RvbWVycyBicmluZyB0aGVpciBv d24gd2ViIHNlcnZlcnMgc28gdGhpcyBtYWtlcyBhbnkgb3B0LW91dCBzb2x1dGlvbiBub3QgZ29v ZCBlbm91Z2guIFNvIEkgZG8gdGhpbmsgdGhpcyBpcyBhbiBvYnN0YWNsZSBmb3IgbWFueSBkZXBs b3ltZW50cy4NCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNl bg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDExLCAyMDE5IDE6MjAgQU0NClRvOiBHb3JyeSAoZXJn KSA8Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj47IE1p cmphIEt1ZWhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPG1haWx0bzptaXJq YS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbT4+DQpDYzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVp Y0BpZXRmLm9yZz47IEJvcmRlciwgSm9obiA8am9obi5ib3JkZXJAaHVnaGVzLmNvbTxtYWlsdG86 am9obi5ib3JkZXJAaHVnaGVzLmNvbT4+OyBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbTxtYWls dG86ZmVuaXhAZmIuY29tPj4NClN1YmplY3Q6IFJlOiBJcyAiVmVyc2lvbiBHcmVhc2luZyIgYSBu ZXcgYmVuZml0IG9yIGEgbmV3IG9ic3RhY2xlPw0KDQpJbiBhIG5vdCBzbyBkaXN0YW50IGZ1dHVy ZSwgYSBmYWxsYmFjayB0byBUQ1Agd291bGQgbm90IGJlIGEgdmlhYmxlIGFsdGVybmF0aXZlIGZv ciBhIG51bWJlciBvZiBzZXJ2aWNlcy4gVGhpbmsgV2ViUlRDLg0KSWYgUVVJQyBhbmQgb3RoZXIg ZW5jcnlwdGVkIHByb3RvY29scyBiZWNvbWUgZG9taW5hbnQsIGp1c3QgYmxvY2tpbmcgZXZlcnl0 aGluZyB3b3VsZCBsaXRlcmFsbHkgYmxvY2sgZXZlcnl0aGluZy4NCk9mIGNvdXJzZSwgaHR0cChz KSBhcyB3ZSBrbm93IGl0LCBpdCB3aWxsIGNvbnRpbnVlIHRvIGxpdmUgb24sIGJ1dCBtYW55IG1v YmlsZSBhcHBzIHdvdWxkIG5vdC4NCg0KDQoNCk9uIDExIEFwcmlsIDIwMTkgYXQgMTAuMDMuMTQs IE1pcmphIEt1ZWhsZXdpbmQgKG1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPG1haWx0bzpt aXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbT4pIHdyb3RlOg0KSGkgTWlra2VsLA0KDQpJIGd1 ZXNzIGl0IGlzIG11Y2ggbW9yZSBsaWtlbHkgdGhhdCBhbnkgb2YgdGhvc2UgYWN0b3JzIHdvdWxk IGp1c3QgYmxvY2sgUVVJQyBhbGwgdG9nZXRoZXIgKGFzIHRoZXJlIGlzIGFjdHVhbGx5IGEgZmFs bGJhY2sgdG8gVENQKS4NCg0KTWlyamENCg0KDQoNCu+7v09uIDEwLjA0LjE5LCAyMTo1NywgIlFV SUMgb24gYmVoYWxmIG9mIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4iIDxxdWljLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIG1pa2tl bGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KTGV0 4oCZcyBzYXkgQ2hpbmEgbWFrZXMgYSBkZWFsIHdpdGggR29vZ2xlIHRvIGFsbG93IHRoZWlyIHNl YXJjaCBlbmdpbmUgKGEgbm90IGVudGlyZWx5IHVucmVhc29uYWJseSBwcm9wb3NpdGlvbikuDQpU aGUgR3JlYXQgRmlyZXdhbGwgb2YgQ2hpbmEgKEdGQykgaXMgcmVjb25maWd1cmVkIHRvIGFjY2Vw dCB0cmFmZmljIGZyb20gYSBzcGVjaWZpYyBJUCByYW5nZSBmb3IgUVVJQyBwcm90b2NvbCB2MS4N Cg0KDQoNCkdvb2dsZSBsYXRlciB1cGdyYWRlcyB0byB2Mi4gR0ZDIGlzIHVwZGF0ZWQuIExhdGVy LCBvdXQgb2YgaWdub3JhbmNlLCBzb21lIG90aGVyIGRlcGFydG1lbnQgd2l0aGluIHNhaWQgY29t cGFueSBkZWNpZGVzIHRoYXQgaXRzIGJyb3dzZXJzIHNob3VsZCBhbGwgdXNlIGZvcmNlZCB2ZXJz aW9uIGFsaWFzZXMgYXMgYSBydWxlLiBHRkMgYnJlYWtzLiAoQXNzdW1pbmcgR29vZ2xlcyBzZXJ2 ZXJzIGFyZSBub3QgbG9jYXRlZCB3aXRoaW4gdGhlIGRlbWlsaXRhcmlzZWQNCnpvbmUgYW5kIHVz ZXJzIHVzZSBDaHJvbWUpLg0KDQoNCkFsdGVybmF0aXZlIDE6IEdvb2dsZSB1cCBmcm9udCBkZWNp ZGVzIHRvIGRlcGxveSBmb3JjZWQgdmVyc2lvbiBhbGlhc2luZy4gQ2hpbmEgcmVqZWN0cyB0aGUg ZGVhbCBiZWNhdXNlIHRoZXkgZG8gbm90IHdhbnQgdG8gc3VwcG9ydCByYW5kb20gdHJhZmZpYyB0 aHJvdWdoIEdGQy4NCg0KDQpBbHRlcm5hdGl2ZSAyOiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0 byBkZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcsIGFuZCBDaGluYSBkb2VzIG5vdCByZWpl Y3QgdGhlIGRlYWwsIG91dCBvZiBpZ25vcmFuY2UuIExhdGVyIHNvbWUgZGVwYXJ0bWVudCBpbiBD aGluYSBHRkMgb3ZlcnNpZ2h0IHJlYWxpc2VzIHRoZSBkZWFsIGFuZCBmb3JjZXMgR29vZ2xlIHRv IHJlbW92ZSBmb3JjZWQgdmVyc2lvbiBhbGlhc2luZywgb3Igc2h1dCBkb3duDQppdHMgc2Vydmlj ZS4NCg0KDQpBbHRlcm5hdGl2ZSAzOiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0byBkZXBsb3kg Zm9yY2VkIHZlcnNpb24gYWxpYXNpbmcgYW5kIENoaW5hIHNheXMsIG9mIGNvdXJzZSwgd2UgdHJ1 c3QgZXZlcnl0aGluZyBmcm9tIEdvb2dsZXMgSVAgcmFuZ2UuDQoNCg0KQWx0ZXJuYXRpdmUgNDog R29vZ2xlIHJlYWxpc2VzIHRoYXQgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcgZG9lcyBub3Qgd29y ayBpbiB0aGUgZ2VuZXJhbCBjYXNlLCBhbmQgbWFrZXMgYSBzcGVjaWFsIGNhc2UgZm9yIHVzZXJz IHdpdGhpbiBhIGNlcnRhaW4gZ2VvZ3JhcGhpY2FsIGFyZWEuDQoNCg0KRGlzY2xhaW1lcjogSeKA mW0gbm90IGFmZmlsaWF0ZWQgd2l0aCBHb29nbGUgYW5kIHRoaXMgbWlnaHQgbm90IGF0IGFsbCBi ZSBob3cgdGhpbmdzIHdvdWxkIHdvcmssIGJ1dCBpdCBkb2VzIGhpZ2hsaWdodCBzb21lIG9mIHRo ZSBjaGFsbGVuZ2VzLg0KDQoNCk9mIGNvdXJzZSwgdG8gYmUgZmFpciwgQ2hpbmEgaXMgbm90IHRo ZSBvbmx5IGdvdmVybm1lbnQgZW50aXR5IHRoYXQgbWlnaHQgaGF2ZSBhIHZlc3RlZCBpbnRlcmVz dC4gTGV0J3MgdGFrZSBhIGZpY3Rpb25hbCBleGFtcGxlIG9mIFVTIGEgcmVhbCBlc3RhdGUgaW52 ZXN0b3Igd2l0aCBoZWF2eSB0aWVzIHRvIHRoZSBlYXN0ZXJuIGV1cm9wZWFuIGJsb2NrIHdobyBz b21laG93IGZpbmRzIGhpbXNlbGYgZWxlY3RlZCBhcyBwcmVzaWRlbnQgbmVlZGluZw0KdG8gZmlu ZCBsZXZlcmFnZSBvbiB0cmFkZSBuZWdvdGlhdGlvbnMgd2l0aG91dCBlZmZlY3RpdmVseSBodXJ0 aW5nIHBlcnNvbmFsIGZpbmFuY2VzLiBJdCB0dXJucyBvdXQgdGhhdCBibG9ja2luZyBjZXJ0YWlu IGRpZ2l0YWwgc2VydmljZXMgZnJvbSBzYWlkIGVhc3Rlcm4gZXVyb3BlYW4gYmxvY2sgaXMgdGhl IHBlcmZlY3QgdG9vbCBpbiB0aGUgdHJhZGUgbmVnb3RpYXRpb25zLi4gQWR2aXNlcnMgcG9pbnQg b3V0IHRoYXQgdGhvc2Ugc2VydmljZXMNCnJ1biBoZWF2aWx5IGVuY3J5cHRlZCBvbiB0aGUgZGFy ayB3ZWIgd2l0aCBwZXJwZXR1YWwgY2lyY3VsYXRpb24gb2YgSVAgcmFuZ2VzIHNvLCBpZ25vcmlu ZyBhbnkgbGVnYWwgY29uY2VybnMsIGl0IHdvdWxkIG5vdCBiZSBwcmFjdGljYWxseSBwb3NzaWJs ZS4gRXZlbnR1YWxseSBzb21lb25lIGZpZ3VyZXMgb3V0IHRoYXQgdGhlc2Ugc2VydmljZXMgYWxs IHVzdWFsbHkgYXJlIGF0IHRoZSBmb3JlZnJvbnQgb2YgdGVjaG5vbG9neSBhbmQgY3VycmVudGx5 DQp1c2UgUVVJQyB2My4yIGFuZCBuby1vbmUgZWxzZSBoYXMgZGVwbG95ZWQgdGhhdCB2ZXJzaW9u IHlldCwgc28gaXQgd291bGQgc3VmZmljZSB0byBhc2sgTlNBIHRvIHRhcCBpbnRvIHRoZSBiYWNr Ym9uZSBhbmQgZGlzcnVwdCBzcGVjaWZpYyBwYWNrZXRzLiBPZiBjb3Vyc2UsIHRoaXMgZW5kcyB1 cCB0YWtpbmcgZG93biB0aGUgQmF2YXJpYW4gbG9jYWwgZ292ZXJubWVudCBlbGVjdGlvbiBwcm9j ZXNzIGluIEdlcm1hbnkgd2hlcmUgdGhleSBhcmUNCnRoZSBmaXJzdCB0byB1c2UgYSBuZXcgZGln aXRhbCBlbGVjdGlvbiBzeXN0ZW0uIE5vdCB0aGF0IHRoZSBpcyBhbiBpc3N1ZSwgc2luY2UgdHJh ZGUgbmVnb3RpYXRpb25zIGFyZSBhbHNvIHJ1bm5pbmcgaG90IGluIHRoYXQgYXJlYSwgc28gdGhh dCBpcyBqdXN0IGFuIGFjY2lkZW50YWwgYm9udXMuDQoNCg0KT3IgYW4gZW5kbGVzcyBudW1iZXIg b2Ygb3RoZXIgZGV2ZWxvcG1lbnRzIG92ZXIgdGhlIG5leHQgZmV3IGRlY2FkZXMgaWYgdGhlIHBh c3QgZmV3IHllYXJzIGlzIGFueXRoaW5nIHRvIGdvIGJ5Lg0KDQoNCg0KDQoNCk9uIDEwIEFwcmls IDIwMTkgYXQgMjAuMTMuNTksIEdvcnJ5IChlcmcpIChnb3JyeUBlcmcuYWJkbi5hYy51azxtYWls dG86Z29ycnlAZXJnLmFiZG4uYWMudWs+KSB3cm90ZToNCg0KVGhhbmtzIE1pa2tlbCwgSSBkbyB1 bmRlcnN0YW5kIHRoYXQgdmFyaW91cyBhY3RvcnMgaW50ZW50aW9uYWxseSBkcm9wIC0gYnV0IGFy ZSB5b3Ugc2F5aW5nIHRoZXNlIGFjdG9ycyB3b3VsZCBzcGVjaWZpY2FsbHkgY2hvb3NlIHRvIGJs b2NrIGEgbmV3IHZlcnNpb24gb2YgUVVJQyAuLi4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGF0IGFz c2VydGlvbi4NCg0KDQpHb3JyeQ0KDQpPbiAxMCBBcHIgMjAxOSwgYXQgMTg6MjUsIE1pa2tlbCBG YWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21h aWwuY29tPj4gd3JvdGU6DQoNCg0KDQpDaGluYSBibG9ja3MgYXMgYSBydWxlLg0KUnVzc2lhIGlz IHJ1bm5pbmcgYW4gZXhwZXJpbWVudCB0byBibG9jayB0aGUgcmVzdCBvZiB0aGUgaW50ZXJuZXQu DQpVU0EgYmxvY2tzIG5ldCBuZXV0cmFsaXR5Lg0KRVUgYmxvY2tzIGNvb2tpZXMuDQpHQiBibG9j a3MgaXRzZWxmLg0KDQoNClNvIGJsb2NraW5nIGlzIG5vdCBsaW1pdGVkIHRvIHdoYXQgYW4gb3Bl cmF0b3IgY29uc2lkZXJzIGJlc3QgZm9yIGJ1c2luZXNzLg0KDQoNCg0KT24gMTAgQXByaWwgMjAx OSBhdCAxOC41OS4xNSwgQm9yZGVyLCBKb2huIChqb2huLmJvcmRlckBodWdoZXMuY29tPG1haWx0 bzpqb2huLmJvcmRlckBodWdoZXMuY29tPikgd3JvdGU6DQoNCg0KSSB1bmRlcnN0YW5kIHdoeSBw ZW9wbGUgd2FudCB0byBjb21lIGRvd24gb24gdGhlIHNpZGUgb2YgcHJldmVudGluZyBvc3NpZmlj YXRpb24uIEJ1dCwgdGhpbmdzIGhhdmUgY2hhbmdlZC4gVGhlcmUgYXJlIGEgbG90IG9mIG1vcmUg bmVnYXRpdmUgY29uc2VxdWVuY2VzIG5vdyB3aGVuIHBlb3BsZSB1bm5lY2Vzc2FyaWx5IGJsb2Nr IHRoaW5ncy4gSSB0aGluayBvcGVyYXRvcnMgd291bGQgcHV0IGEgbG90IG9mIHByZXNzdXJlIG9u IHZlbmRvcnMgdG8NCm5vdCBkbyBpdCBub3cgYW5kIHRvIGZpeCBpdCBpZiB0aGV5IGRpZCAiYnkg YWNjaWRlbnQiLiBPZiBjb3Vyc2UsIEkgYW0gb25seSBvbmUgb3BlcmF0b3IuIEl0IHdvdWxkIGJl IG5pY2UgdG8gaGVhciBmcm9tIG90aGVycy4uLg0KDQoNCg0KSm9obg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBSb2JlcnRvIFBlb24NClNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMTAsIDIwMTkgMTI6NTIgUE0NClRvOiBHIEZhaXJodXJzdCA8Z29y cnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj47DQpxdWljQGll dGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IElzICJWZXJzaW9uIEdy ZWFzaW5nIiBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/DQoNCldBUk5JTkc6IFRoZSBz ZW5kZXIgb2YgdGhpcyBlbWFpbCBjb3VsZCBub3QgYmUgdmFsaWRhdGVkIGFuZCBtYXkgbm90IG1h dGNoIHRoZSBwZXJzb24gaW4gdGhlICJGcm9tIiBmaWVsZC4NCg0KQ0FVVElPTjogVGhpcyBlbWFp bCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xp Y2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2Vu ZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQoNCg0KWW91J3JlIGtpbmRhIGJldHdl ZW4gYSByb2NrLWFuZC1hLWhhcmQtcGxhY2UgZWl0aGVyIHdheToNCg0KLSBXZSd2ZSBzZWVuIGhv dyBtdWNoIGZ1biBvc3NpZmljYXRpb24gaXMgaW4gVENQIGFuZCBIVFRQLiBJZiB0aGUgdGhpbmcg aXMgb2JzZXJ2YWJsZSwgaXQgd2lsbCBiZSBvc3NpZmllZCBzZWVtcyB0byBiZSB0aGUgbGVzc29u LiBBIGxvdCBvZiB0aGUgcmVhc29uIHdoeSBRVUlDIHdhcyBzdGFydGVkIGluIHRoZSBmaXJzdCBw bGFjZSB3YXMgYmVjYXVzZSBvZiB0aGUgaW5hYmlsaXR5IHRvIGltcHJvdmUgVENQIGR1ZSB0byB0 aGlzIG9zc2lmaWNhdGlvbi4NCi0gT1RPSCwgdGhlcmUgaXMgdGhlIGZlYXIgb2YgdW5rbm93bi91 bm9ic2VydmFibGUgd2hpY2ggbWlnaHQgY2F1c2Ugb3BlcmF0b3JzIHRvIGJsb2NrIHRoaW5ncywg d2hldGhlciBwcmVkaWN0YWJseSBvciBub3QuDQoNCk15IG9waW5pb24gaXMgdGhhdCBpdCBpcyBi ZXR0ZXIgdG8gc3RhcnQgd2l0aCBwcmV2ZW50aW5nIG9zc2lmaWNhdGlvbiwgYW5kIHRoZW4gaWYg dGhhdCByZXN1bHRzIGluIHRvbyBsYXJnZSBhIHBlcmNlbnRhZ2Ugb2Ygb3BlcmF0b3JzIGJsb2Nr aW5nIHRoaW5ncywgdG8gcmUtZXZhbHVhdGUuDQoNCk15IGd1ZXNzZXM6DQpJUCtwb3J0IHR1cGxl cyBhbmQgdHJhZmZpYyBwYXR0ZXJucyBhcmUgc3RpbGwgb2JzZXJ2YWJsZSAoZm9yIGJldHRlciBh bmQgd29yc2UpLCB3aGljaCBpbXBsaWVzIG9wZXJhdG9ycyB3aWxsIHN0aWxsIGhhdmUgc2lnbmlm aWNhbnQgdG9vbHMgZm9yIG1hbmFnaW5nIHRyYWZmaWMuIEkgYmVsaWV2ZSB0aGF0IHRoZXNlIGFy ZSBhY3RlZCBvbi9tYXRjaGVkIChNTCBvciBub3QpIHJlZ2FyZGxlc3Mgb2YgYW55IG90aGVyIGRh dGEgcHJlc2VudGVkLiBJbg0Kb3RoZXIgd29yZHMsIEkgaGF2ZSBhIGRvdWJ0IHRoYXQgc3RhdGlu ZyB0aGUgdmVyc2lvbiBpbiBhbiBvYnNlcnZhYmxlIHdheSB3aWxsIHByZXZlbnQgdGhlIHVzZSBv ZiBzdWNoIHRvb2xzLg0KDQpNb3N0IHByb2JsZW1zIEkndmUgc2VlbiBhc3NvY2lhdGVkIHdpdGgg aW1wbGVtZW50YXRpb25zIHJhdGhlciB0aGFuIHByb3RvY29sIHZlcnNpb25zICh0aG91Z2ggd2hl biB0aGUgbGF0dGVyIGhhcHBlbnMgaXQgaXMgcHJldHR5IHNldmVyZSkuLiBJZiB5b3UgYmVsaWV2 ZSB0aGlzIGFzc2VydGlvbiwgdGhlbiBhY3Rpbmcgb24gcHJvdG9jb2wgdmVyc2lvbiBpcyBsZXNz IGludGVyZXN0aW5nIHRoYW4gYXR0ZW1wdGluZyB0byBhY3QgYmFzZWQgb24gaW1wbGVtZW50YXRp b24NCmZpbmdlcnByaW50cy4NCi09Ug0KDQoNCk9uIDQvMTAvMTksIDE6NDggQU0sICJRVUlDIG9u IGJlaGFsZiBvZiBHIEZhaXJodXJzdCIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YNCmdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1h aWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+IHdyb3RlOg0KDQpPYnNjdXJpbmcgdGhlIHZlcnNp b24gb2YgYSBwcm90b2NvbCBzZWVtcyBsaWtlIGEgbWFqb3IgZGVzaWduIGRlc2lnbg0KZGVjaXNp b24gZm9yIHdpZGVyIHVzZSBjYXNlcy4gU28sIEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUN Cm1vdGl2YXRpb24gZm9yIHZlcnNpb24gZ3JlYXNpbmcuDQoNCigxKSBJIGtub3cgdGhlcmUgd2Vy ZSBpbnN0YW5jZXMgd2hlcmUgc29tZSBlYXJseSB2ZXJzaW9ucyBvZiBRVUlDIHdlcmUNCmJsb2Nr ZWQgZHVlIHRvIGFuIHVuaW5pdGVudGlvbmFsIG1hdGNoaW5nIG9mIHRoZSBoZWFkZXIuIElzIHRo ZXJlDQpldmlkZW5jZSBvZiBpbnRlbnRpb25hbCBhdHRlbXB0cyB0byBibG9jayB1cGRhdGVzIHRv IHByb3RvY29scz8NCg0KKDIpIFRoaW5raW5nIGFib3V0IG9wZXJhdGluZyBhIG5ldHdvcmsgdGhh dCBjYXJlcyBhYm91dCB1c2VyIHN1cHBvcnQgYW5kDQpwcm90ZWN0aW9uIGZyb20gdW53YW50ZWQg dHJhZmZpYywgSSB3b3VsZCBleHBlY3QgdGhhdCB0aGVyZSB3b3VsZCBiZQ0KY2FzZXMgd2hlcmUg dHJhZmZpYyBwYXR0ZXJuIGFub21vbGllcyBhcmUgZm91bmQgYW5kIHRoZSBhcHByb3ByaWF0ZQ0K dGhpbmcgd291bGQgYmUgdG8gdHJ5IHRvIGRldGVybWluZSBpZiBhIG5ldyBwcm90b2NvbCBoYWQg YmVlbiBkZXBsb3llZA0KYW5kIG1vbml0b3IgaXQsIGlmIG5vdCwgdGhlbiB0aGUgbmV4dCBtb3N0 IG9idmlvdXMgdGhpbmcgY291bGQgYmUgdG8NCmJsb2NrIGFsbCB1bmV4cGVjdGVkIHRyYWZmaWMs IHRoYXQgc2VlbXMgbGlrZSBhIGRlY2lzaW9uIHRvIGhpZGUgdGhlDQp2ZXJzaW9uIGNvdWxkIGlu Y3JlYXNlIG9zc2lmaWNhdGlvbiBmb3IgbmV3IHZlcnNpb25zIGluIHRoZXNlIGNhc2VzLi4NCg0K KDMpIFNpbWlsYXJseSwgaWYgYSB0aHJlYXQgaXMga25vd24gdG8gaW1wYWN0IG9ubHkgYSBzcGVj aWZpYyAob2xkZXIpDQp2ZXJzaW9uLCBpdCB3b3VsZCBzZWVtIHRvIG1vdGl2YXRlIGEgZHJvcCBv ZiB0aGF0IHRyYWZmaWMgdGhhdCBzZWVrcyB0bw0KdXNlIHRoYXQgdmVyc2lvbiwgd2hpbGUgc3Rp bGwgcGVybWl0dGluZyBvdGhlciB0cmFmZmljLiBGb3JjaW5nIHZlcnNpb24NCmRldGVjdGlvbiB0 byB1c2UgcGF0dGVybiBtYXRjaGluZy9NTCB3aWxsIGxlYWQgdG8gbGVzcyBwcmVkaWN0YWJsZQ0K b3V0Y29tZXMsIG9yIGJsb2NraW5nIGJhc2VkIG9uIGFkZHJlc3MsIGV0Yy4NCg0KKDQpIFRoaXMg b2JmdXN0aWNhdGVzIHRoZSBtb3N0IGJhc2ljIHBpZWNlIG9mIHJlcG9ydGluZyBpbmZvcm1hdGlv biB1c2VkDQpmb3Igc3VwcG9ydC4gSXQgaGlkZXMgdGhlIGV4dGVudCBvZiBkZXBsb3ltZW50IG9m IHRoZSBjdXJyZW50IHByb3RvY29sDQp2ZXJzaW9uIGFuZCBwcmV2bGFuY2Ugb2Ygb2xkIGltcGxl bWVudGF0aW9ucy4NCg0KKDUpIE9uIHRoZSBzdXBwb3J0LCBpZiBhIHByb2JsZW0gb25seSBlbWVy Z2VzIHdoZW4gYSBwYXJ0aWN1bGFyIHZlcnNpb24NCmlzIHVzZWQgd2l0aCBhIHBhcnRpY3VsYXIg YWRkcmVzcywgdGhlbiB0aGlzIGhlbHBzIHBpbnBvaW50IHRoZSBpc3N1ZXMuDQpNYXRjaGluZyBj bGllbnQgdmVyc2lvbnMgdG8gc2VydmVycyBpcyBtdWNoIG1vcmUgb2YgYW4gaXNzdWUgaWYgdGhl IHVzZXINCmNvbW11bml0eSB1c2VzIGEgd2lkZSByYW5nZSBvZiBzZXJ2ZXJzIChsZXNzIHNvLCBJ IGV4cGVjdCBmb3IgbWFqb3INCnByb3ZpZGVyczogZ29vZ2xlLCBmYWNlYm9vaywgZXRjLCBldGMp LCBidXQgc2lnbmlmaWNhbnQgd2hlbiB0aGVyZSBpcyBhDQp1c2Ugb2YgYSBkaXZlcnNlIHNldCBv ZiBleHRlcm5hbCBzaXRlcyBhbmQgc2l0ZXMgd2l0aCB0aGVpciBvd24gbG9hZA0KYmFsYW5jZXJz LCBldGMgYW5kIGEgbmVlZCB0byBtYW5hZ2UgaW50ZXJhY3Rpb25zIHdpdGggTDIgc2VydmljZXMu DQoNCkkgYW0gaW50ZXJzdGVkIGluIGtub3dpbmcgaWYgdGhpcyBpcyBsaWtlbHkgdG8gYmVuZWZp dCBvciBiZSBhIG5ldyBvYnN0YWNsZT8NCg0KR29ycnkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQo= --_000_MW2PR2101MB104996C29680DF7B79230C8CB6280MW2PR2101MB1049_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxl LW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29y cnkgZm9yIGEgdHlwby4gUGxhaW4gb2xkIFVEUCBub3QgUVVJQy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiA8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxMiwg MjAxOSA4OjUzIEFNPGJyPg0KPGI+VG86PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZs dDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBHb3JyeSAoZXJnKSAmbHQ7Z29ycnlAZXJnLmFiZG4u YWMudWsmZ3Q7OyBNaXJqYSBLdWVobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5kQGVyaWNzc29u LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHF1aWNAaWV0Zi5vcmc7IEJvcmRlciwgSm9obiAmbHQ7 am9obi5ib3JkZXJAaHVnaGVzLmNvbSZndDs7IFJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29t Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogSXMgJnF1b3Q7VmVyc2lvbiBHcmVhc2luZyZx dW90OyBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5WZXJzaW9uIGdyZWFzaW5nIHdpbGwgY3JlYXRlIHByb2JsZW1z IGZvciBERG9TIHByb3RlY3Rpb24uIFRoZSBERG9TIHByb3RlY3Rpb24gbWlkZGxlYm94IHdpbGwg aGF2ZSB0byB0cmVhdCBhbGwgdHJhZmZpYyB3aXRoIHVua25vd24gdmVyc2lvbiBudW1iZXJzIGFz IHBsYWluIG9sZCBRVUlDIGFuZCByYXRlIGxpbWl0IGl0LiBBbnkgc29sdXRpb24gdGhhdCByZXF1 aXJlcyBwZXIgY29ubmVjdGlvbiBzdGF0ZSB0bw0KIHRyYWNrIHZlcnNpb24gbnVtYmVycyBkb2Vz buKAmXQgc2NhbGUuIEVzcGVjaWFsbHkgaW4gdGhlIGNsb3VkIHNjZW5hcmlvIGN1c3RvbWVycyBi cmluZyB0aGVpciBvd24gd2ViIHNlcnZlcnMgc28gdGhpcyBtYWtlcyBhbnkgb3B0LW91dCBzb2x1 dGlvbiBub3QgZ29vZCBlbm91Z2guIFNvIEkgZG8gdGhpbmsgdGhpcyBpcyBhbiBvYnN0YWNsZSBm b3IgbWFueSBkZXBsb3ltZW50cy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgJmx0OzxhIGhyZWY9Im1h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5T ZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDExLCAyMDE5IDE6MjAgQU08YnI+DQo8Yj5Ubzo8L2I+ IEdvcnJ5IChlcmcpICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiPmdv cnJ5QGVyZy5hYmRuLmFjLnVrPC9hPiZndDs7IE1pcmphIEt1ZWhsZXdpbmQgJmx0OzxhIGhyZWY9 Im1haWx0bzptaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbSI+bWlyamEua3VlaGxld2luZEBl cmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNA aWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+OyBCb3JkZXIsIEpvaG4gJmx0OzxhIGhyZWY9Im1h aWx0bzpqb2huLmJvcmRlckBodWdoZXMuY29tIj5qb2huLmJvcmRlckBodWdoZXMuY29tPC9hPiZn dDs7IFJvYmVydG8gUGVvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZlbml4QGZiLmNvbSI+ZmVuaXhA ZmIuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IElzICZxdW90O1ZlcnNpb24g R3JlYXNpbmcmcXVvdDsgYSBuZXcgYmVuZml0IG9yIGEgbmV3IG9ic3RhY2xlPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gYSBub3Qgc28gZGlzdGFudCBmdXR1cmUsIGEgZmFsbGJh Y2sgdG8gVENQIHdvdWxkIG5vdCBiZSBhIHZpYWJsZSBhbHRlcm5hdGl2ZSBmb3IgYSBudW1iZXIg b2Ygc2VydmljZXMuIFRoaW5rIFdlYlJUQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPklmIFFVSUMgYW5kIG90aGVyIGVuY3J5cHRlZCBwcm90b2NvbHMgYmVjb21l IGRvbWluYW50LCBqdXN0IGJsb2NraW5nIGV2ZXJ5dGhpbmcgd291bGQgbGl0ZXJhbGx5IGJsb2Nr IGV2ZXJ5dGhpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9v cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5P ZiBjb3Vyc2UsIGh0dHAocykgYXMgd2Uga25vdyBpdCwgaXQgd2lsbCBjb250aW51ZSB0byBsaXZl IG9uLCBidXQgbWFueSBtb2JpbGUgYXBwcyB3b3VsZCBub3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE1NTQ5NzA2OTgzMDAyODIxMTIiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJh aXJtYWlsb24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiAxMSBBcHJpbCAyMDE5IGF0IDEwLjAzLjE0 LCBNaXJqYSBLdWVobGV3aW5kICg8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEBlcmlj c3Nvbi5jb20iPm1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPC9hPikgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIE1pa2tlbCwN Cjxicj4NCjxicj4NCkkgZ3Vlc3MgaXQgaXMgbXVjaCBtb3JlIGxpa2VseSB0aGF0IGFueSBvZiB0 aG9zZSBhY3RvcnMgd291bGQganVzdCBibG9jayBRVUlDIGFsbCB0b2dldGhlciAoYXMgdGhlcmUg aXMgYWN0dWFsbHkgYSBmYWxsYmFjayB0byBUQ1ApLg0KPGJyPg0KPGJyPg0KTWlyamEgPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj7vu788L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPk9uIDEwLjA0LjE5LCAyMTo1NywgJnF1b3Q7UVVJQyBvbiBiZWhhbGYgb2Yg TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPg0KIG9uIGJlaGFsZiBv ZiA8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIj5taWtrZWxmakBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTogPGJyPg0KPGJyPg0KPGJyPg0KTGV04oCZcyBzYXkgQ2hpbmEgbWFrZXMg YSBkZWFsIHdpdGggR29vZ2xlIHRvIGFsbG93IHRoZWlyIHNlYXJjaCBlbmdpbmUgKGEgbm90IGVu dGlyZWx5IHVucmVhc29uYWJseSBwcm9wb3NpdGlvbikuDQo8YnI+DQpUaGUgR3JlYXQgRmlyZXdh bGwgb2YgQ2hpbmEgKEdGQykgaXMgcmVjb25maWd1cmVkIHRvIGFjY2VwdCB0cmFmZmljIGZyb20g YSBzcGVjaWZpYyBJUCByYW5nZSBmb3IgUVVJQyBwcm90b2NvbCB2MS4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCkdvb2dsZSBsYXRlciB1cGdyYWRlcyB0byB2Mi4gR0ZDIGlzIHVwZGF0ZWQuIExh dGVyLCBvdXQgb2YgaWdub3JhbmNlLCBzb21lIG90aGVyIGRlcGFydG1lbnQgd2l0aGluIHNhaWQg Y29tcGFueSBkZWNpZGVzIHRoYXQgaXRzIGJyb3dzZXJzIHNob3VsZCBhbGwgdXNlIGZvcmNlZCB2 ZXJzaW9uIGFsaWFzZXMgYXMgYSBydWxlLiBHRkMgYnJlYWtzLiAoQXNzdW1pbmcgR29vZ2xlcyBz ZXJ2ZXJzIGFyZSBub3QgbG9jYXRlZCB3aXRoaW4gdGhlIGRlbWlsaXRhcmlzZWQNCjxicj4NCnpv bmUgYW5kIHVzZXJzIHVzZSBDaHJvbWUpLiA8YnI+DQo8YnI+DQo8YnI+DQpBbHRlcm5hdGl2ZSAx OiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0byBkZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNp bmcuIENoaW5hIHJlamVjdHMgdGhlIGRlYWwgYmVjYXVzZSB0aGV5IGRvIG5vdCB3YW50IHRvIHN1 cHBvcnQgcmFuZG9tIHRyYWZmaWMgdGhyb3VnaCBHRkMuDQo8YnI+DQo8YnI+DQo8YnI+DQpBbHRl cm5hdGl2ZSAyOiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0byBkZXBsb3kgZm9yY2VkIHZlcnNp b24gYWxpYXNpbmcsIGFuZCBDaGluYSBkb2VzIG5vdCByZWplY3QgdGhlIGRlYWwsIG91dCBvZiBp Z25vcmFuY2UuIExhdGVyIHNvbWUgZGVwYXJ0bWVudCBpbiBDaGluYSBHRkMgb3ZlcnNpZ2h0IHJl YWxpc2VzIHRoZSBkZWFsIGFuZCBmb3JjZXMgR29vZ2xlIHRvIHJlbW92ZSBmb3JjZWQgdmVyc2lv biBhbGlhc2luZywgb3Igc2h1dCBkb3duDQo8YnI+DQppdHMgc2VydmljZS4gPGJyPg0KPGJyPg0K PGJyPg0KQWx0ZXJuYXRpdmUgMzogR29vZ2xlIHVwIGZyb250IGRlY2lkZXMgdG8gZGVwbG95IGZv cmNlZCB2ZXJzaW9uIGFsaWFzaW5nIGFuZCBDaGluYSBzYXlzLCBvZiBjb3Vyc2UsIHdlIHRydXN0 IGV2ZXJ5dGhpbmcgZnJvbSBHb29nbGVzIElQIHJhbmdlLg0KPGJyPg0KPGJyPg0KPGJyPg0KQWx0 ZXJuYXRpdmUgNDogR29vZ2xlIHJlYWxpc2VzIHRoYXQgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcg ZG9lcyBub3Qgd29yayBpbiB0aGUgZ2VuZXJhbCBjYXNlLCBhbmQgbWFrZXMgYSBzcGVjaWFsIGNh c2UgZm9yIHVzZXJzIHdpdGhpbiBhIGNlcnRhaW4gZ2VvZ3JhcGhpY2FsIGFyZWEuDQo8YnI+DQo8 YnI+DQo8YnI+DQpEaXNjbGFpbWVyOiBJ4oCZbSBub3QgYWZmaWxpYXRlZCB3aXRoIEdvb2dsZSBh bmQgdGhpcyBtaWdodCBub3QgYXQgYWxsIGJlIGhvdyB0aGluZ3Mgd291bGQgd29yaywgYnV0IGl0 IGRvZXMgaGlnaGxpZ2h0IHNvbWUgb2YgdGhlIGNoYWxsZW5nZXMuDQo8YnI+DQo8YnI+DQo8YnI+ DQpPZiBjb3Vyc2UsIHRvIGJlIGZhaXIsIENoaW5hIGlzIG5vdCB0aGUgb25seSBnb3Zlcm5tZW50 IGVudGl0eSB0aGF0IG1pZ2h0IGhhdmUgYSB2ZXN0ZWQgaW50ZXJlc3QuIExldCdzIHRha2UgYSBm aWN0aW9uYWwgZXhhbXBsZSBvZiBVUyBhIHJlYWwgZXN0YXRlIGludmVzdG9yIHdpdGggaGVhdnkg dGllcyB0byB0aGUgZWFzdGVybiBldXJvcGVhbiBibG9jayB3aG8gc29tZWhvdyBmaW5kcyBoaW1z ZWxmIGVsZWN0ZWQgYXMgcHJlc2lkZW50IG5lZWRpbmcNCjxicj4NCnRvIGZpbmQgbGV2ZXJhZ2Ug b24gdHJhZGUgbmVnb3RpYXRpb25zIHdpdGhvdXQgZWZmZWN0aXZlbHkgaHVydGluZyBwZXJzb25h bCBmaW5hbmNlcy4gSXQgdHVybnMgb3V0IHRoYXQgYmxvY2tpbmcgY2VydGFpbiBkaWdpdGFsIHNl cnZpY2VzIGZyb20gc2FpZCBlYXN0ZXJuIGV1cm9wZWFuIGJsb2NrIGlzIHRoZSBwZXJmZWN0IHRv b2wgaW4gdGhlIHRyYWRlIG5lZ290aWF0aW9ucy4uIEFkdmlzZXJzIHBvaW50IG91dCB0aGF0IHRo b3NlIHNlcnZpY2VzDQo8YnI+DQpydW4gaGVhdmlseSBlbmNyeXB0ZWQgb24gdGhlIGRhcmsgd2Vi IHdpdGggcGVycGV0dWFsIGNpcmN1bGF0aW9uIG9mIElQIHJhbmdlcyBzbywgaWdub3JpbmcgYW55 IGxlZ2FsIGNvbmNlcm5zLCBpdCB3b3VsZCBub3QgYmUgcHJhY3RpY2FsbHkgcG9zc2libGUuIEV2 ZW50dWFsbHkgc29tZW9uZSBmaWd1cmVzIG91dCB0aGF0IHRoZXNlIHNlcnZpY2VzIGFsbCB1c3Vh bGx5IGFyZSBhdCB0aGUgZm9yZWZyb250IG9mIHRlY2hub2xvZ3kgYW5kIGN1cnJlbnRseQ0KPGJy Pg0KdXNlIFFVSUMgdjMuMiBhbmQgbm8tb25lIGVsc2UgaGFzIGRlcGxveWVkIHRoYXQgdmVyc2lv biB5ZXQsIHNvIGl0IHdvdWxkIHN1ZmZpY2UgdG8gYXNrIE5TQSB0byB0YXAgaW50byB0aGUgYmFj a2JvbmUgYW5kIGRpc3J1cHQgc3BlY2lmaWMgcGFja2V0cy4gT2YgY291cnNlLCB0aGlzIGVuZHMg dXAgdGFraW5nIGRvd24gdGhlIEJhdmFyaWFuIGxvY2FsIGdvdmVybm1lbnQgZWxlY3Rpb24gcHJv Y2VzcyBpbiBHZXJtYW55IHdoZXJlIHRoZXkgYXJlDQo8YnI+DQp0aGUgZmlyc3QgdG8gdXNlIGEg bmV3IGRpZ2l0YWwgZWxlY3Rpb24gc3lzdGVtLiBOb3QgdGhhdCB0aGUgaXMgYW4gaXNzdWUsIHNp bmNlIHRyYWRlIG5lZ290aWF0aW9ucyBhcmUgYWxzbyBydW5uaW5nIGhvdCBpbiB0aGF0IGFyZWEs IHNvIHRoYXQgaXMganVzdCBhbiBhY2NpZGVudGFsIGJvbnVzLg0KPGJyPg0KPGJyPg0KPGJyPg0K T3IgYW4gZW5kbGVzcyBudW1iZXIgb2Ygb3RoZXIgZGV2ZWxvcG1lbnRzIG92ZXIgdGhlIG5leHQg ZmV3IGRlY2FkZXMgaWYgdGhlIHBhc3QgZmV3IHllYXJzIGlzIGFueXRoaW5nIHRvIGdvIGJ5Lg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMTAgQXByaWwgMjAxOSBhdCAy MC4xMy41OSwgR29ycnkgKGVyZykgKDxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+KSB3cm90ZToNCjxicj4NCjxicj4NClRoYW5rcyBN aWtrZWwsIEkgZG8gdW5kZXJzdGFuZCB0aGF0IHZhcmlvdXMgYWN0b3JzIGludGVudGlvbmFsbHkg ZHJvcCAtIGJ1dCBhcmUgeW91IHNheWluZyB0aGVzZSBhY3RvcnMgd291bGQgc3BlY2lmaWNhbGx5 IGNob29zZSB0byBibG9jayBhIG5ldyB2ZXJzaW9uIG9mIFFVSUMgLi4uIEkgZG8gbm90IHVuZGVy c3RhbmQgdGhhdCBhc3NlcnRpb24uDQo8YnI+DQo8YnI+DQo8YnI+DQpHb3JyeSA8YnI+DQo8YnI+ DQpPbiAxMCBBcHIgMjAxOSwgYXQgMTg6MjUsIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0 OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iPm1pa2tlbGZqQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQ2hpbmEgYmxvY2tzIGFzIGEg cnVsZS4gPGJyPg0KUnVzc2lhIGlzIHJ1bm5pbmcgYW4gZXhwZXJpbWVudCB0byBibG9jayB0aGUg cmVzdCBvZiB0aGUgaW50ZXJuZXQuIDxicj4NClVTQSBibG9ja3MgbmV0IG5ldXRyYWxpdHkuIDxi cj4NCkVVIGJsb2NrcyBjb29raWVzLiA8YnI+DQpHQiBibG9ja3MgaXRzZWxmLiA8YnI+DQo8YnI+ DQo8YnI+DQpTbyBibG9ja2luZyBpcyBub3QgbGltaXRlZCB0byB3aGF0IGFuIG9wZXJhdG9yIGNv bnNpZGVycyBiZXN0IGZvciBidXNpbmVzcy4gPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMTAg QXByaWwgMjAxOSBhdCAxOC41OS4xNSwgQm9yZGVyLCBKb2huICg8YSBocmVmPSJtYWlsdG86am9o bi5ib3JkZXJAaHVnaGVzLmNvbSI+am9obi5ib3JkZXJAaHVnaGVzLmNvbTwvYT4pIHdyb3RlOg0K PGJyPg0KPGJyPg0KPGJyPg0KSSB1bmRlcnN0YW5kIHdoeSBwZW9wbGUgd2FudCB0byBjb21lIGRv d24gb24gdGhlIHNpZGUgb2YgcHJldmVudGluZyBvc3NpZmljYXRpb24uIEJ1dCwgdGhpbmdzIGhh dmUgY2hhbmdlZC4gVGhlcmUgYXJlIGEgbG90IG9mIG1vcmUgbmVnYXRpdmUgY29uc2VxdWVuY2Vz IG5vdyB3aGVuIHBlb3BsZSB1bm5lY2Vzc2FyaWx5IGJsb2NrIHRoaW5ncy4gSSB0aGluayBvcGVy YXRvcnMgd291bGQgcHV0IGEgbG90IG9mIHByZXNzdXJlIG9uIHZlbmRvcnMgdG8NCjxicj4NCm5v dCBkbyBpdCBub3cgYW5kIHRvIGZpeCBpdCBpZiB0aGV5IGRpZCAmcXVvdDtieSBhY2NpZGVudCZx dW90Oy4gT2YgY291cnNlLCBJIGFtIG9ubHkgb25lIG9wZXJhdG9yLiBJdCB3b3VsZCBiZSBuaWNl IHRvIGhlYXIgZnJvbSBvdGhlcnMuLi4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCkpvaG4gPGJy Pg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gPGJyPg0KRnJvbTogUVVJ QyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIFJvYmVydG8gUGVvbg0KPGJyPg0KU2VudDog V2VkbmVzZGF5LCBBcHJpbCAxMCwgMjAxOSAxMjo1MiBQTSA8YnI+DQpUbzogRyBGYWlyaHVyc3Qg Jmx0OzxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4u YWMudWs8L2E+Jmd0OzsNCjxicj4NCjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWlj QGlldGYub3JnPC9hPiA8YnI+DQpTdWJqZWN0OiBSZTogSXMgJnF1b3Q7VmVyc2lvbiBHcmVhc2lu ZyZxdW90OyBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/IDxicj4NCjxicj4NCldBUk5J Tkc6IFRoZSBzZW5kZXIgb2YgdGhpcyBlbWFpbCBjb3VsZCBub3QgYmUgdmFsaWRhdGVkIGFuZCBt YXkgbm90IG1hdGNoIHRoZSBwZXJzb24gaW4gdGhlICZxdW90O0Zyb20mcXVvdDsgZmllbGQuDQo8 YnI+DQo8YnI+DQpDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9m IHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRz IHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMg c2FmZS4NCjxicj4NCjxicj4NCjxicj4NCllvdSdyZSBraW5kYSBiZXR3ZWVuIGEgcm9jay1hbmQt YS1oYXJkLXBsYWNlIGVpdGhlciB3YXk6IDxicj4NCjxicj4NCi0gV2UndmUgc2VlbiBob3cgbXVj aCBmdW4gb3NzaWZpY2F0aW9uIGlzIGluIFRDUCBhbmQgSFRUUC4gSWYgdGhlIHRoaW5nIGlzIG9i c2VydmFibGUsIGl0IHdpbGwgYmUgb3NzaWZpZWQgc2VlbXMgdG8gYmUgdGhlIGxlc3Nvbi4gQSBs b3Qgb2YgdGhlIHJlYXNvbiB3aHkgUVVJQyB3YXMgc3RhcnRlZCBpbiB0aGUgZmlyc3QgcGxhY2Ug d2FzIGJlY2F1c2Ugb2YgdGhlIGluYWJpbGl0eSB0byBpbXByb3ZlIFRDUCBkdWUgdG8gdGhpcyBv c3NpZmljYXRpb24uDQo8YnI+DQotIE9UT0gsIHRoZXJlIGlzIHRoZSBmZWFyIG9mIHVua25vd24v dW5vYnNlcnZhYmxlIHdoaWNoIG1pZ2h0IGNhdXNlIG9wZXJhdG9ycyB0byBibG9jayB0aGluZ3Ms IHdoZXRoZXIgcHJlZGljdGFibHkgb3Igbm90Lg0KPGJyPg0KPGJyPg0KTXkgb3BpbmlvbiBpcyB0 aGF0IGl0IGlzIGJldHRlciB0byBzdGFydCB3aXRoIHByZXZlbnRpbmcgb3NzaWZpY2F0aW9uLCBh bmQgdGhlbiBpZiB0aGF0IHJlc3VsdHMgaW4gdG9vIGxhcmdlIGEgcGVyY2VudGFnZSBvZiBvcGVy YXRvcnMgYmxvY2tpbmcgdGhpbmdzLCB0byByZS1ldmFsdWF0ZS4NCjxicj4NCjxicj4NCk15IGd1 ZXNzZXM6IDxicj4NCklQJiM0Mztwb3J0IHR1cGxlcyBhbmQgdHJhZmZpYyBwYXR0ZXJucyBhcmUg c3RpbGwgb2JzZXJ2YWJsZSAoZm9yIGJldHRlciBhbmQgd29yc2UpLCB3aGljaCBpbXBsaWVzIG9w ZXJhdG9ycyB3aWxsIHN0aWxsIGhhdmUgc2lnbmlmaWNhbnQgdG9vbHMgZm9yIG1hbmFnaW5nIHRy YWZmaWMuIEkgYmVsaWV2ZSB0aGF0IHRoZXNlIGFyZSBhY3RlZCBvbi9tYXRjaGVkIChNTCBvciBu b3QpIHJlZ2FyZGxlc3Mgb2YgYW55IG90aGVyIGRhdGEgcHJlc2VudGVkLiBJbg0KPGJyPg0Kb3Ro ZXIgd29yZHMsIEkgaGF2ZSBhIGRvdWJ0IHRoYXQgc3RhdGluZyB0aGUgdmVyc2lvbiBpbiBhbiBv YnNlcnZhYmxlIHdheSB3aWxsIHByZXZlbnQgdGhlIHVzZSBvZiBzdWNoIHRvb2xzLg0KPGJyPg0K PGJyPg0KTW9zdCBwcm9ibGVtcyBJJ3ZlIHNlZW4gYXNzb2NpYXRlZCB3aXRoIGltcGxlbWVudGF0 aW9ucyByYXRoZXIgdGhhbiBwcm90b2NvbCB2ZXJzaW9ucyAodGhvdWdoIHdoZW4gdGhlIGxhdHRl ciBoYXBwZW5zIGl0IGlzIHByZXR0eSBzZXZlcmUpLi4gSWYgeW91IGJlbGlldmUgdGhpcyBhc3Nl cnRpb24sIHRoZW4gYWN0aW5nIG9uIHByb3RvY29sIHZlcnNpb24gaXMgbGVzcyBpbnRlcmVzdGlu ZyB0aGFuIGF0dGVtcHRpbmcgdG8gYWN0IGJhc2VkIG9uIGltcGxlbWVudGF0aW9uDQo8YnI+DQpm aW5nZXJwcmludHMuIDxicj4NCi09UiA8YnI+DQo8YnI+DQo8YnI+DQpPbiA0LzEwLzE5LCAxOjQ4 IEFNLCAmcXVvdDtRVUlDIG9uIGJlaGFsZiBvZiBHIEZhaXJodXJzdCZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9h PiBvbiBiZWhhbGYgb2YNCjxicj4NCjxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OyB3cm90ZTogPGJyPg0KPGJyPg0KT2JzY3Vy aW5nIHRoZSB2ZXJzaW9uIG9mIGEgcHJvdG9jb2wgc2VlbXMgbGlrZSBhIG1ham9yIGRlc2lnbiBk ZXNpZ24gPGJyPg0KZGVjaXNpb24gZm9yIHdpZGVyIHVzZSBjYXNlcy4gU28sIEknbSB0cnlpbmcg dG8gdW5kZXJzdGFuZCB0aGUgPGJyPg0KbW90aXZhdGlvbiBmb3IgdmVyc2lvbiBncmVhc2luZy4g PGJyPg0KPGJyPg0KKDEpIEkga25vdyB0aGVyZSB3ZXJlIGluc3RhbmNlcyB3aGVyZSBzb21lIGVh cmx5IHZlcnNpb25zIG9mIFFVSUMgd2VyZSA8YnI+DQpibG9ja2VkIGR1ZSB0byBhbiB1bmluaXRl bnRpb25hbCBtYXRjaGluZyBvZiB0aGUgaGVhZGVyLiBJcyB0aGVyZSA8YnI+DQpldmlkZW5jZSBv ZiBpbnRlbnRpb25hbCBhdHRlbXB0cyB0byBibG9jayB1cGRhdGVzIHRvIHByb3RvY29scz8gPGJy Pg0KPGJyPg0KKDIpIFRoaW5raW5nIGFib3V0IG9wZXJhdGluZyBhIG5ldHdvcmsgdGhhdCBjYXJl cyBhYm91dCB1c2VyIHN1cHBvcnQgYW5kIDxicj4NCnByb3RlY3Rpb24gZnJvbSB1bndhbnRlZCB0 cmFmZmljLCBJIHdvdWxkIGV4cGVjdCB0aGF0IHRoZXJlIHdvdWxkIGJlIDxicj4NCmNhc2VzIHdo ZXJlIHRyYWZmaWMgcGF0dGVybiBhbm9tb2xpZXMgYXJlIGZvdW5kIGFuZCB0aGUgYXBwcm9wcmlh dGUgPGJyPg0KdGhpbmcgd291bGQgYmUgdG8gdHJ5IHRvIGRldGVybWluZSBpZiBhIG5ldyBwcm90 b2NvbCBoYWQgYmVlbiBkZXBsb3llZCA8YnI+DQphbmQgbW9uaXRvciBpdCwgaWYgbm90LCB0aGVu IHRoZSBuZXh0IG1vc3Qgb2J2aW91cyB0aGluZyBjb3VsZCBiZSB0byA8YnI+DQpibG9jayBhbGwg dW5leHBlY3RlZCB0cmFmZmljLCB0aGF0IHNlZW1zIGxpa2UgYSBkZWNpc2lvbiB0byBoaWRlIHRo ZSA8YnI+DQp2ZXJzaW9uIGNvdWxkIGluY3JlYXNlIG9zc2lmaWNhdGlvbiBmb3IgbmV3IHZlcnNp b25zIGluIHRoZXNlIGNhc2VzLi4gPGJyPg0KPGJyPg0KKDMpIFNpbWlsYXJseSwgaWYgYSB0aHJl YXQgaXMga25vd24gdG8gaW1wYWN0IG9ubHkgYSBzcGVjaWZpYyAob2xkZXIpIDxicj4NCnZlcnNp b24sIGl0IHdvdWxkIHNlZW0gdG8gbW90aXZhdGUgYSBkcm9wIG9mIHRoYXQgdHJhZmZpYyB0aGF0 IHNlZWtzIHRvIDxicj4NCnVzZSB0aGF0IHZlcnNpb24sIHdoaWxlIHN0aWxsIHBlcm1pdHRpbmcg b3RoZXIgdHJhZmZpYy4gRm9yY2luZyB2ZXJzaW9uIDxicj4NCmRldGVjdGlvbiB0byB1c2UgcGF0 dGVybiBtYXRjaGluZy9NTCB3aWxsIGxlYWQgdG8gbGVzcyBwcmVkaWN0YWJsZSA8YnI+DQpvdXRj b21lcywgb3IgYmxvY2tpbmcgYmFzZWQgb24gYWRkcmVzcywgZXRjLiA8YnI+DQo8YnI+DQooNCkg VGhpcyBvYmZ1c3RpY2F0ZXMgdGhlIG1vc3QgYmFzaWMgcGllY2Ugb2YgcmVwb3J0aW5nIGluZm9y bWF0aW9uIHVzZWQgPGJyPg0KZm9yIHN1cHBvcnQuIEl0IGhpZGVzIHRoZSBleHRlbnQgb2YgZGVw bG95bWVudCBvZiB0aGUgY3VycmVudCBwcm90b2NvbCA8YnI+DQp2ZXJzaW9uIGFuZCBwcmV2bGFu Y2Ugb2Ygb2xkIGltcGxlbWVudGF0aW9ucy4gPGJyPg0KPGJyPg0KKDUpIE9uIHRoZSBzdXBwb3J0 LCBpZiBhIHByb2JsZW0gb25seSBlbWVyZ2VzIHdoZW4gYSBwYXJ0aWN1bGFyIHZlcnNpb24gPGJy Pg0KaXMgdXNlZCB3aXRoIGEgcGFydGljdWxhciBhZGRyZXNzLCB0aGVuIHRoaXMgaGVscHMgcGlu cG9pbnQgdGhlIGlzc3Vlcy4gPGJyPg0KTWF0Y2hpbmcgY2xpZW50IHZlcnNpb25zIHRvIHNlcnZl cnMgaXMgbXVjaCBtb3JlIG9mIGFuIGlzc3VlIGlmIHRoZSB1c2VyIDxicj4NCmNvbW11bml0eSB1 c2VzIGEgd2lkZSByYW5nZSBvZiBzZXJ2ZXJzIChsZXNzIHNvLCBJIGV4cGVjdCBmb3IgbWFqb3Ig PGJyPg0KcHJvdmlkZXJzOiBnb29nbGUsIGZhY2Vib29rLCBldGMsIGV0YyksIGJ1dCBzaWduaWZp Y2FudCB3aGVuIHRoZXJlIGlzIGEgPGJyPg0KdXNlIG9mIGEgZGl2ZXJzZSBzZXQgb2YgZXh0ZXJu YWwgc2l0ZXMgYW5kIHNpdGVzIHdpdGggdGhlaXIgb3duIGxvYWQgPGJyPg0KYmFsYW5jZXJzLCBl dGMgYW5kIGEgbmVlZCB0byBtYW5hZ2UgaW50ZXJhY3Rpb25zIHdpdGggTDIgc2VydmljZXMuIDxi cj4NCjxicj4NCkkgYW0gaW50ZXJzdGVkIGluIGtub3dpbmcgaWYgdGhpcyBpcyBsaWtlbHkgdG8g YmVuZWZpdCBvciBiZSBhIG5ldyBvYnN0YWNsZT8gPGJyPg0KPGJyPg0KR29ycnkgPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MW2PR2101MB104996C29680DF7B79230C8CB6280MW2PR2101MB1049_-- From nobody Fri Apr 12 08:57:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235E5120372 for ; Fri, 12 Apr 2019 08:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 f1T4adf7ehe9 for ; Fri, 12 Apr 2019 08:57:38 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F28E1200F6 for ; Fri, 12 Apr 2019 08:57:38 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id z11so11940689wmi.0 for ; Fri, 12 Apr 2019 08:57:38 -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=i+OC+qFAcUupzUmPVIWL4T0W3BWtQp1gsZJjDEV7Njg=; b=bb4vtAGl5NLRzFUikQkOF9//dLByhFZsslQwM2fTqWRvc58S9L8e+VgzR56QAXajP9 xtsL2n31ltww/OofdYB7GHwD3vE+4p+CB8conHbX5kVnPA2qFGZg/qp0xmdiMiBTcGWi Qc/W6CTEnknHBcn4gA5u9oQqxsQfrCfCBvlsorTxxhBPPzeW1DEt/6gCgYhTQDF0tQb2 Do/CUM4g9CBMgPxBrnlnSUjYEV2us5IthiRawwiDcsmXeMNIGydWCmkh1zQSu83b/P1y 9hL9zzgPrbeB2BoASLMWc1SXqWhj2RwsoGCmW4Jk6tWcB4RFx42NXzhZfBG4YGHSZwhH E2OQ== 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=i+OC+qFAcUupzUmPVIWL4T0W3BWtQp1gsZJjDEV7Njg=; b=UUj4MIwuND4mwXNATSfRnQ31QRcTjs9kzFg3IbRWiA7zaSj5SD89p7Nfkj+hJSK7P7 RTe27lSWXol7y/4xj9ITbUU/PF/EK+aQBLEN1aIoOgRfjU//Yp3VJDguG9TJCTubWma7 khu5ke+8/HtZvFHEgOV0QJP0tEvOzJCrwtxtigvcX4fHBVhKmBOp38xcnLbvb+wDfcQt LnqrxeJMEV8wrqjDCIMVekU2rqyhen52fanOWfDrrdlwZTdr47DyaEkT2jTcRsSGCoSS Ycu7xCqbHf63gdgJd0rSAsXZ3bmwRvOi1jmUjioxF4XLYvlPw6aKNPIHwKCW9p0v/xhE q62w== X-Gm-Message-State: APjAAAWVFA+iRXLeQ+zvQhq7MAFyGZSBKGW6L9NyCSwQhv6E8iVpzbSQ jirlhuEhnK32hXnl3y444c7GIBNej060fPnHssjJdw== X-Google-Smtp-Source: APXvYqx/IxQzvqxsm8jNc5QvZGkwfIBJGw0dl/S9Aryz2l/ZZcHo7FGvf9prJoha1ZApijPfNLq87IItjDHHdRPEpkI= X-Received: by 2002:a1c:1f08:: with SMTP id f8mr10753240wmf.97.1555084656436; Fri, 12 Apr 2019 08:57:36 -0700 (PDT) MIME-Version: 1.0 References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> In-Reply-To: From: Ian Swett Date: Fri, 12 Apr 2019 11:57:23 -0400 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: Praveen Balasubramanian Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "Gorry (erg)" , Mirja Kuehlewind , "quic@ietf.org" , "Border, John" , Roberto Peon Content-Type: multipart/alternative; boundary="0000000000008b6d1d0586575ce4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 15:57:43 -0000 --0000000000008b6d1d0586575ce4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Possibly I'm missing something, but wouldn't version greasing be an optional extension? So if you wanted to do so you could, but those with load balancing that couldn't handle it would not? On Fri, Apr 12, 2019 at 11:55 AM Praveen Balasubramanian wrote: > Sorry for a typo. Plain old UDP not QUIC. > > > > *From:* Praveen Balasubramanian > *Sent:* Friday, April 12, 2019 8:53 AM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; Gorry (erg)= < > gorry@erg.abdn.ac.uk>; Mirja Kuehlewind > *Cc:* quic@ietf.org; Border, John ; Roberto Peon = < > fenix@fb.com> > *Subject:* RE: Is "Version Greasing" a new benfit or a new obstacle? > > > > Version greasing will create problems for DDoS protection. The DDoS > protection middlebox will have to treat all traffic with unknown version > numbers as plain old QUIC and rate limit it. Any solution that requires p= er > connection state to track version numbers doesn=E2=80=99t scale. Especial= ly in the > cloud scenario customers bring their own web servers so this makes any > opt-out solution not good enough. So I do think this is an obstacle for > many deployments. > > > > *From:* QUIC *On Behalf Of *Mikkel Fahn=C3=B8e > J=C3=B8rgensen > *Sent:* Thursday, April 11, 2019 1:20 AM > *To:* Gorry (erg) ; Mirja Kuehlewind < > mirja.kuehlewind@ericsson.com> > *Cc:* quic@ietf.org; Border, John ; Roberto Peon = < > fenix@fb.com> > *Subject:* Re: Is "Version Greasing" a new benfit or a new obstacle? > > > > In a not so distant future, a fallback to TCP would not be a viable > alternative for a number of services. Think WebRTC. > > If QUIC and other encrypted protocols become dominant, just blocking > everything would literally block everything. > > Of course, http(s) as we know it, it will continue to live on, but many > mobile apps would not. > > > > > > On 11 April 2019 at 10.03.14, Mirja Kuehlewind ( > mirja.kuehlewind@ericsson.com) wrote: > > Hi Mikkel, > > I guess it is much more likely that any of those actors would just block > QUIC all together (as there is actually a fallback to TCP). > > Mirja > > > > =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e J=C3= =B8rgensen" < > quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: > > > Let=E2=80=99s say China makes a deal with Google to allow their search en= gine (a > not entirely unreasonably proposition). > The Great Firewall of China (GFC) is reconfigured to accept traffic from = a > specific IP range for QUIC protocol v1. > > > > Google later upgrades to v2. GFC is updated. Later, out of ignorance, som= e > other department within said company decides that its browsers should all > use forced version aliases as a rule. GFC breaks. (Assuming Googles serve= rs > are not located within the demilitarised > zone and users use Chrome). > > > Alternative 1: Google up front decides to deploy forced version aliasing. > China rejects the deal because they do not want to support random traffic > through GFC. > > > Alternative 2: Google up front decides to deploy forced version aliasing, > and China does not reject the deal, out of ignorance. Later some departme= nt > in China GFC oversight realises the deal and forces Google to remove forc= ed > version aliasing, or shut down > its service. > > > Alternative 3: Google up front decides to deploy forced version aliasing > and China says, of course, we trust everything from Googles IP range. > > > Alternative 4: Google realises that forced version aliasing does not work > in the general case, and makes a special case for users within a certain > geographical area. > > > Disclaimer: I=E2=80=99m not affiliated with Google and this might not at = all be > how things would work, but it does highlight some of the challenges. > > > Of course, to be fair, China is not the only government entity that might > have a vested interest. Let's take a fictional example of US a real estat= e > investor with heavy ties to the eastern european block who somehow finds > himself elected as president needing > to find leverage on trade negotiations without effectively hurting > personal finances. It turns out that blocking certain digital services fr= om > said eastern european block is the perfect tool in the trade negotiations= .. > Advisers point out that those services > run heavily encrypted on the dark web with perpetual circulation of IP > ranges so, ignoring any legal concerns, it would not be practically > possible. Eventually someone figures out that these services all usually > are at the forefront of technology and currently > use QUIC v3.2 and no-one else has deployed that version yet, so it would > suffice to ask NSA to tap into the backbone and disrupt specific packets. > Of course, this ends up taking down the Bavarian local government electio= n > process in Germany where they are > the first to use a new digital election system. Not that the is an issue, > since trade negotiations are also running hot in that area, so that is ju= st > an accidental bonus. > > > Or an endless number of other developments over the next few decades if > the past few years is anything to go by. > > > > > > On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote: > > Thanks Mikkel, I do understand that various actors intentionally drop - > but are you saying these actors would specifically choose to block a new > version of QUIC ... I do not understand that assertion. > > > Gorry > > On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > > > > China blocks as a rule. > Russia is running an experiment to block the rest of the internet. > USA blocks net neutrality. > EU blocks cookies. > GB blocks itself. > > > So blocking is not limited to what an operator considers best for > business. > > > > On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) > wrote: > > > I understand why people want to come down on the side of preventing > ossification. But, things have changed. There are a lot of more negative > consequences now when people unnecessarily block things. I think operator= s > would put a lot of pressure on vendors to > not do it now and to fix it if they did "by accident". Of course, I am > only one operator. It would be nice to hear from others... > > > > John > > > -----Original Message----- > From: QUIC On Behalf Of Roberto Peon > Sent: Wednesday, April 10, 2019 12:52 PM > To: G Fairhurst ; > quic@ietf.org > Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? > > WARNING: The sender of this email could not be validated and may not matc= h > the person in the "From" field. > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > You're kinda between a rock-and-a-hard-place either way: > > - We've seen how much fun ossification is in TCP and HTTP. If the thing i= s > observable, it will be ossified seems to be the lesson. A lot of the reas= on > why QUIC was started in the first place was because of the inability to > improve TCP due to this ossification. > - OTOH, there is the fear of unknown/unobservable which might cause > operators to block things, whether predictably or not. > > My opinion is that it is better to start with preventing ossification, an= d > then if that results in too large a percentage of operators blocking > things, to re-evaluate. > > My guesses: > IP+port tuples and traffic patterns are still observable (for better and > worse), which implies operators will still have significant tools for > managing traffic. I believe that these are acted on/matched (ML or not) > regardless of any other data presented. In > other words, I have a doubt that stating the version in an observable way > will prevent the use of such tools. > > Most problems I've seen associated with implementations rather than > protocol versions (though when the latter happens it is pretty severe).. = If > you believe this assertion, then acting on protocol version is less > interesting than attempting to act based on implementation > fingerprints. > -=3DR > > > On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" < > quic-bounces@ietf.org on behalf of > gorry@erg.abdn.ac.uk> wrote: > > Obscuring the version of a protocol seems like a major design design > decision for wider use cases. So, I'm trying to understand the > motivation for version greasing. > > (1) I know there were instances where some early versions of QUIC were > blocked due to an uninitentional matching of the header. Is there > evidence of intentional attempts to block updates to protocols? > > (2) Thinking about operating a network that cares about user support and > protection from unwanted traffic, I would expect that there would be > cases where traffic pattern anomolies are found and the appropriate > thing would be to try to determine if a new protocol had been deployed > and monitor it, if not, then the next most obvious thing could be to > block all unexpected traffic, that seems like a decision to hide the > version could increase ossification for new versions in these cases.. > > (3) Similarly, if a threat is known to impact only a specific (older) > version, it would seem to motivate a drop of that traffic that seeks to > use that version, while still permitting other traffic. Forcing version > detection to use pattern matching/ML will lead to less predictable > outcomes, or blocking based on address, etc. > > (4) This obfusticates the most basic piece of reporting information used > for support. It hides the extent of deployment of the current protocol > version and prevlance of old implementations. > > (5) On the support, if a problem only emerges when a particular version > is used with a particular address, then this helps pinpoint the issues. > Matching client versions to servers is much more of an issue if the user > community uses a wide range of servers (less so, I expect for major > providers: google, facebook, etc, etc), but significant when there is a > use of a diverse set of external sites and sites with their own load > balancers, etc and a need to manage interactions with L2 services. > > I am intersted in knowing if this is likely to benefit or be a new > obstacle? > > Gorry > > > > > > > > > > > > > > > --0000000000008b6d1d0586575ce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Possibly I'm missing something, but wouldn't versi= on greasing be an optional extension?=C2=A0 So if you wanted to do so you c= ould, but those with load balancing that couldn't handle it would not?<= /div>
O= n Fri, Apr 12, 2019 at 11:55 AM Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

Sorry for a typo. Plain old UDP not QUIC.<= /u>

=C2=A0

From: Praveen Balasubramanian
Sent: Friday, April 12, 2019 8:53 AM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; Gorry (erg) <<= a href=3D"mailto:gorry@erg.abdn.ac.uk" target=3D"_blank">gorry@erg.abdn.ac.= uk>; Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: quic@ietf.org= ; Border, John <john.border@hughes.com>; Roberto Peon <fenix@fb.com>
Subject: RE: Is "Version Greasing" a new benfit or a new o= bstacle?

=C2=A0

Version greasing will create problems for DDoS prote= ction. The DDoS protection middlebox will have to treat all traffic with un= known version numbers as plain old QUIC and rate limit it. Any solution tha= t requires per connection state to track version numbers doesn=E2=80=99t scale. Especially in the cloud scena= rio customers bring their own web servers so this makes any opt-out solutio= n not good enough. So I do think this is an obstacle for many deployments.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Thursday, April 11, 2019 1:20 AM
To: Gorry (erg) <gorry@erg.abdn.ac.uk>; Mirja Kuehlewind <mirja.kuehlewind@eri= csson.com>
Cc: quic@ietf.org= ; Border, John <john.border@hughes.com>; Roberto Peon <fenix@fb.com>
Subject: Re: Is "Version Greasing" a new benfit or a new o= bstacle?

=C2=A0

In a not so distant future, a fallback to TCP would not be a vi= able alternative for a number of services. Think WebRTC.

If QUIC and other encrypted protocols become dominant, just blo= cking everything would literally block everything.

Of course, http(s) as we know it, it will continue to live on, = but many mobile apps would not.

=C2=A0

=C2=A0

On 11 April 2019 at 10.03.14, Mirja= Kuehlewind (mirja.kuehlewind@ericsson.com) wrote:

Hi Mikkel,

I guess it is much more likely that any of those actors would just block QU= IC all together (as there is actually a fallback to TCP).

Mirja



=EF=BB= =BFO= n 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e J=C3=B8rgense= n" <quic= -bounces@ietf.org on behalf of mikke= lfj@gmail.com> wrote:


Let=E2=80=99s say China makes a deal with Google to allow their search engi= ne (a not entirely unreasonably proposition).
The Great Firewall of China (GFC) is reconfigured to accept traffic from a = specific IP range for QUIC protocol v1.



Google later upgrades to v2. GFC is updated. Later, out of ignorance, some = other department within said company decides that its browsers should all u= se forced version aliases as a rule. GFC breaks. (Assuming Googles servers = are not located within the demilitarised
zone and users use Chrome).


Alternative 1: Google up front decides to deploy forced version aliasing. C= hina rejects the deal because they do not want to support random traffic th= rough GFC.


Alternative 2: Google up front decides to deploy forced version aliasing, a= nd China does not reject the deal, out of ignorance. Later some department = in China GFC oversight realises the deal and forces Google to remove forced= version aliasing, or shut down
its service.


Alternative 3: Google up front decides to deploy forced version aliasing an= d China says, of course, we trust everything from Googles IP range.


Alternative 4: Google realises that forced version aliasing does not work i= n the general case, and makes a special case for users within a certain geo= graphical area.


Disclaimer: I=E2=80=99m not affiliated with Google and this might not at al= l be how things would work, but it does highlight some of the challenges.


Of course, to be fair, China is not the only government entity that might h= ave a vested interest. Let's take a fictional example of US a real esta= te investor with heavy ties to the eastern european block who somehow finds= himself elected as president needing
to find leverage on trade negotiations without effectively hurting personal= finances. It turns out that blocking certain digital services from said ea= stern european block is the perfect tool in the trade negotiations.. Advise= rs point out that those services
run heavily encrypted on the dark web with perpetual circulation of IP rang= es so, ignoring any legal concerns, it would not be practically possible. E= ventually someone figures out that these services all usually are at the fo= refront of technology and currently
use QUIC v3.2 and no-one else has deployed that version yet, so it would su= ffice to ask NSA to tap into the backbone and disrupt specific packets. Of = course, this ends up taking down the Bavarian local government election pro= cess in Germany where they are
the first to use a new digital election system. Not that the is an issue, s= ince trade negotiations are also running hot in that area, so that is just = an accidental bonus.


Or an endless number of other developments over the next few decades if the= past few years is anything to go by.





On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote:

Thanks Mikkel, I do understand that various actors intentionally drop - but= are you saying these actors would specifically choose to block a new versi= on of QUIC ... I do not understand that assertion.


Gorry

On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wro= te:



China blocks as a rule.
Russia is running an experiment to block the rest of the internet.
USA blocks net neutrality.
EU blocks cookies.
GB blocks itself.


So blocking is not limited to what an operator considers best for business.=



On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote:


I understand why people want to come down on the side of preventing ossific= ation. But, things have changed. There are a lot of more negative consequen= ces now when people unnecessarily block things. I think operators would put= a lot of pressure on vendors to
not do it now and to fix it if they did "by accident". Of course,= I am only one operator. It would be nice to hear from others...



John


-----Original Message-----
From: QUIC <q= uic-bounces@ietf.org> On Behalf Of Roberto Peon
Sent: Wednesday, April 10, 2019 12:52 PM
To: G Fairhurst <gorry@erg.abdn.ac.uk>;
quic@ietf.org
Subject: Re: Is "Version Greasing" a new benfit or a new obstacle= ?

WARNING: The sender of this email could not be validated and may not match = the person in the "From" field.

CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you recognize the sender and know the c= ontent is safe.


You're kinda between a rock-and-a-hard-place either way:

- We've seen how much fun ossification is in TCP and HTTP. If the thing= is observable, it will be ossified seems to be the lesson. A lot of the re= ason why QUIC was started in the first place was because of the inability t= o improve TCP due to this ossification.
- OTOH, there is the fear of unknown/unobservable which might cause operato= rs to block things, whether predictably or not.

My opinion is that it is better to start with preventing ossification, and = then if that results in too large a percentage of operators blocking things= , to re-evaluate.

My guesses:
IP+port tuples and traffic patterns are still observable (for better and wo= rse), which implies operators will still have significant tools for managin= g traffic. I believe that these are acted on/matched (ML or not) regardless= of any other data presented. In
other words, I have a doubt that stating the version in an observable way w= ill prevent the use of such tools.

Most problems I've seen associated with implementations rather than pro= tocol versions (though when the latter happens it is pretty severe).. If yo= u believe this assertion, then acting on protocol version is less interesti= ng than attempting to act based on implementation
fingerprints.
-=3DR


On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" <quic-bounces@ietf.org on behalf of
gorry@erg.abdn.ac= .uk> wrote:

Obscuring the version of a protocol seems like a major design design
decision for wider use cases. So, I'm trying to understand the
motivation for version greasing.

(1) I know there were instances where some early versions of QUIC were
blocked due to an uninitentional matching of the header. Is there
evidence of intentional attempts to block updates to protocols?

(2) Thinking about operating a network that cares about user support and protection from unwanted traffic, I would expect that there would be
cases where traffic pattern anomolies are found and the appropriate
thing would be to try to determine if a new protocol had been deployed
and monitor it, if not, then the next most obvious thing could be to
block all unexpected traffic, that seems like a decision to hide the
version could increase ossification for new versions in these cases..

(3) Similarly, if a threat is known to impact only a specific (older)
version, it would seem to motivate a drop of that traffic that seeks to use that version, while still permitting other traffic. Forcing version detection to use pattern matching/ML will lead to less predictable
outcomes, or blocking based on address, etc.

(4) This obfusticates the most basic piece of reporting information used for support. It hides the extent of deployment of the current protocol
version and prevlance of old implementations.

(5) On the support, if a problem only emerges when a particular version is used with a particular address, then this helps pinpoint the issues. Matching client versions to servers is much more of an issue if the user community uses a wide range of servers (less so, I expect for major
providers: google, facebook, etc, etc), but significant when there is a use of a diverse set of external sites and sites with their own load
balancers, etc and a need to manage interactions with L2 services.

I am intersted in knowing if this is likely to benefit or be a new obstacle= ?

Gorry














--0000000000008b6d1d0586575ce4-- From nobody Fri Apr 12 09:08:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA0D12038E for ; Fri, 12 Apr 2019 09:08:17 -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, DKIMWL_WL_HIGH=-0.001, 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 f9X97Mo1Rhof for ; Fri, 12 Apr 2019 09:08:13 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690139.outbound.protection.outlook.com [40.107.69.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02C4120378 for ; Fri, 12 Apr 2019 09:08:09 -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:X-MS-Exchange-SenderADCheck; bh=hKsJLEaP2ECoBCnlgYW5QkwBBYwBvKEgsJn0obPsjF4=; b=JDj4soUYHGJe8ol6w0k0UqK7N6LR+2czbDigZtcTpgyNkoKqKSkDnSSg/IWBPaHBB9YGT/3fBhTgz2uipM4hU+Aa0Kpnackrdc2osw8J/VKYr4uxLwAynow7fc8D4V5U/RSnJkfabWMxw3CkrPWpz6C8V99yK8NkXxixPvM4/uI= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1100.namprd21.prod.outlook.com (52.132.149.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.0; Fri, 12 Apr 2019 16:08:08 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c999:100b:9952:f8f6]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c999:100b:9952:f8f6%5]) with mapi id 15.20.1813.000; Fri, 12 Apr 2019 16:08:07 +0000 From: Praveen Balasubramanian To: Ian Swett , Praveen Balasubramanian CC: "Gorry (erg)" , Roberto Peon , Mirja Kuehlewind , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , "Border, John" Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o0AOSUW1ZVWEa1WA8MStgy7KY1nGCAgAACAYCAAAdsgIAADYwAgAAcxQCAAMrxAIAABNWAgAIQK4CAAADVYIAAAPyAgAAAQ+A= Date: Fri, 12 Apr 2019 16:08:07 +0000 Message-ID: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.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=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:0:21b3:7b4b:b4a3:c3bf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a849cb5-e3af-49a1-bda0-08d6bf610d90 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB1100; x-ms-traffictypediagnostic: MW2PR2101MB1100: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(346002)(39860400002)(396003)(189003)(199004)(13464003)(97736004)(66574012)(6436002)(8936002)(81156014)(81166006)(106356001)(105586002)(22452003)(86362001)(316002)(86612001)(93886005)(5024004)(14444005)(478600001)(5070765005)(10290500003)(54906003)(10090500001)(14454004)(76176011)(30864003)(110136005)(53546011)(7696005)(6506007)(102836004)(256004)(440504004)(517774005)(486006)(53936002)(74316002)(11346002)(476003)(54896002)(6306002)(9686003)(236005)(229853002)(8990500004)(55016002)(186003)(446003)(46003)(52536014)(99286004)(6246003)(5660300002)(790700001)(4326008)(8676002)(71190400001)(71200400001)(25786009)(2906002)(33656002)(6116002)(7736002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1100; H:MW2PR2101MB1049.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0A4t5BHiiBO4IkO4+fVvgsycHC54MMs5FvKCZD9uwEKbycTvw63ottSr2KbV4GMQrah9ivM3Qm/6aRQyU8FnLO8flHg2aIwOPjPRLDNc8kwfK+5wayLPwNLB6olymKjRSTbEaRXYN47YJQKl1mKoujlYwLUCWkqwr54nOBW/ZagmrgYokwWK8T+VP4U06sSAM3Dh6XcDHToDqEYTvgs01mkLPKSdGMFPNlK5POMZhlsGKjNPkTSimLNGYrcIh8l6fXVjFNJXxfTO+Zhsy9+qhH4iWlE2DUepf3tPAaU/n5Hj9WcqOqmfJ0bhhTE7KfqzKGabvf84oIUtF71VjQkVqypGkauOS5E0YbzCBK7OdgK7FYVAR0tq0wPkRXqYyStLg7memdzibKt2Qy3dUyjFrIXY73p51kVwafNbBsJK2pI= Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB10496C89AF5523D20B753D6CB6280MW2PR2101MB1049_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a849cb5-e3af-49a1-bda0-08d6bf610d90 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 16:08:07.9116 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:08:18 -0000 --_000_MW2PR2101MB10496C89AF5523D20B753D6CB6280MW2PR2101MB1049_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgYmVpbmcgb3B0aW9uYWwgaGVscHMgaW4gY2FzZXMgd2hlcmUgdGhlIHNlcnZpY2UgYmVpbmcg ZGVwbG95ZWQgYW5kIHRoZSBEb1MgcHJvdGVjdGlvbiBzZXJ2aWNlIGFyZSB1bmRlciBzYW1lIGFk bWluaXN0cmF0aXZlIGRvbWFpbi4gU28gZGVwZW5kaW5nIG9uIGhvdyBEb1MgcHJvdGVjdGlvbiBp cyBkb25lIHRoZSBleHRlbnNpb24gY291bGQgYmUgdHVybmVkIG9uIG9yIG9mZi4gVGhlIHByb2Js ZW0gaXMgd2l0aCB0aGUgSWFhUyBzY2VuYXJpbyBpZiB0aGUgZXh0ZW5zaW9uIGlzIHR1cm5lZCBv biBieSBkZWZhdWx0IGluIHNvbWUgbWFqb3Igd2ViIHNlcnZlci4gTm93IEREb1MgcHJvdGVjdGlv biBjYW5ub3QgYmUgb2ZmZXJlZCBhcyBhIGNsb3VkIHNlcnZpY2Ugd2l0aG91dCBoYXJtaW5nIHNh aWQgdHJhZmZpYyBiZWNhdXNlIGl0IHdpbGwgYmUgcmF0ZSBsaW1pdGVkLiBBbmQgcmF0ZSBsaW1p dGluZyBpcyBzdHJpY3RseSB3b3JzZSB0aGFuIGJsb2NraW5nIFFVSUMgYmVjYXVzZSBwZXJmb3Jt YW5jZSB3aWxsIHN1ZmZlci4NCg0KV2Ugd2lsbCBsaWtlbHkgbmVlZCBzb21lIHRleHQgaW4gbWFu YWdlYWJpbGl0eSBkcmFmdCB3aGljaCBzYXlzIHRoYXQgdHVybmluZyBvbiB0aGlzIGV4dGVuc2lv biBtYXkgYnJlYWsgbmV0d29yayBmdW5jdGlvbnMgYW5kIGNhdXNlIHBlcmZvcm1hbmNlIGlzc3Vl cyBzbyBzZXJ2aWNlcyAvIGltcGxlbWVudGF0aW9ucyBzaG91bGQgb25seSB0dXJuIHRoaXMgb24g YWZ0ZXIgdGhlc2UgY29uc2lkZXJhdGlvbnMuDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIElhbiBTd2V0dA0KU2VudDogRnJpZGF5LCBBcHJpbCAxMiwg MjAxOSA4OjU3IEFNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9z b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBHb3JyeSAoZXJnKSA8Z29ycnlAZXJnLmFiZG4u YWMudWs+OyBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT47IE1pcmphIEt1ZWhsZXdpbmQgPG1p cmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPjsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8 bWlra2VsZmpAZ21haWwuY29tPjsgcXVpY0BpZXRmLm9yZzsgQm9yZGVyLCBKb2huIDxqb2huLmJv cmRlckBodWdoZXMuY29tPg0KU3ViamVjdDogUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5l dyBiZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/DQoNClBvc3NpYmx5IEknbSBtaXNzaW5nIHNvbWV0 aGluZywgYnV0IHdvdWxkbid0IHZlcnNpb24gZ3JlYXNpbmcgYmUgYW4gb3B0aW9uYWwgZXh0ZW5z aW9uPyAgU28gaWYgeW91IHdhbnRlZCB0byBkbyBzbyB5b3UgY291bGQsIGJ1dCB0aG9zZSB3aXRo IGxvYWQgYmFsYW5jaW5nIHRoYXQgY291bGRuJ3QgaGFuZGxlIGl0IHdvdWxkIG5vdD8NCg0KT24g RnJpLCBBcHIgMTIsIDIwMTkgYXQgMTE6NTUgQU0gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHBy YXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29t QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpTb3JyeSBmb3IgYSB0eXBvLiBQbGFpbiBvbGQgVURQ IG5vdCBRVUlDLg0KDQpGcm9tOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogRnJpZGF5 LCBBcHJpbCAxMiwgMjAxOSA4OjUzIEFNDQpUbzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8 bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PjsgR29ycnkgKGVy ZykgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+OyBN aXJqYSBLdWVobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbTxtYWlsdG86bWly amEua3VlaGxld2luZEBlcmljc3Nvbi5jb20+Pg0KQ2M6IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1 aWNAaWV0Zi5vcmc+OyBCb3JkZXIsIEpvaG4gPGpvaG4uYm9yZGVyQGh1Z2hlcy5jb208bWFpbHRv OmpvaG4uYm9yZGVyQGh1Z2hlcy5jb20+PjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb208bWFp bHRvOmZlbml4QGZiLmNvbT4+DQpTdWJqZWN0OiBSRTogSXMgIlZlcnNpb24gR3JlYXNpbmciIGEg bmV3IGJlbmZpdCBvciBhIG5ldyBvYnN0YWNsZT8NCg0KVmVyc2lvbiBncmVhc2luZyB3aWxsIGNy ZWF0ZSBwcm9ibGVtcyBmb3IgRERvUyBwcm90ZWN0aW9uLiBUaGUgRERvUyBwcm90ZWN0aW9uIG1p ZGRsZWJveCB3aWxsIGhhdmUgdG8gdHJlYXQgYWxsIHRyYWZmaWMgd2l0aCB1bmtub3duIHZlcnNp b24gbnVtYmVycyBhcyBwbGFpbiBvbGQgUVVJQyBhbmQgcmF0ZSBsaW1pdCBpdC4gQW55IHNvbHV0 aW9uIHRoYXQgcmVxdWlyZXMgcGVyIGNvbm5lY3Rpb24gc3RhdGUgdG8gdHJhY2sgdmVyc2lvbiBu dW1iZXJzIGRvZXNu4oCZdCBzY2FsZS4gRXNwZWNpYWxseSBpbiB0aGUgY2xvdWQgc2NlbmFyaW8g Y3VzdG9tZXJzIGJyaW5nIHRoZWlyIG93biB3ZWIgc2VydmVycyBzbyB0aGlzIG1ha2VzIGFueSBv cHQtb3V0IHNvbHV0aW9uIG5vdCBnb29kIGVub3VnaC4gU28gSSBkbyB0aGluayB0aGlzIGlzIGFu IG9ic3RhY2xlIGZvciBtYW55IGRlcGxveW1lbnRzLg0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTEsIDIwMTkg MToyMCBBTQ0KVG86IEdvcnJ5IChlcmcpIDxnb3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86Z29y cnlAZXJnLmFiZG4uYWMudWs+PjsgTWlyamEgS3VlaGxld2luZCA8bWlyamEua3VlaGxld2luZEBl cmljc3Nvbi5jb208bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPj4NCkNjOiBx dWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPjsgQm9yZGVyLCBKb2huIDxqb2huLmJv cmRlckBodWdoZXMuY29tPG1haWx0bzpqb2huLmJvcmRlckBodWdoZXMuY29tPj47IFJvYmVydG8g UGVvbiA8ZmVuaXhAZmIuY29tPG1haWx0bzpmZW5peEBmYi5jb20+Pg0KU3ViamVjdDogUmU6IElz ICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/DQoNCklu IGEgbm90IHNvIGRpc3RhbnQgZnV0dXJlLCBhIGZhbGxiYWNrIHRvIFRDUCB3b3VsZCBub3QgYmUg YSB2aWFibGUgYWx0ZXJuYXRpdmUgZm9yIGEgbnVtYmVyIG9mIHNlcnZpY2VzLiBUaGluayBXZWJS VEMuDQpJZiBRVUlDIGFuZCBvdGhlciBlbmNyeXB0ZWQgcHJvdG9jb2xzIGJlY29tZSBkb21pbmFu dCwganVzdCBibG9ja2luZyBldmVyeXRoaW5nIHdvdWxkIGxpdGVyYWxseSBibG9jayBldmVyeXRo aW5nLg0KT2YgY291cnNlLCBodHRwKHMpIGFzIHdlIGtub3cgaXQsIGl0IHdpbGwgY29udGludWUg dG8gbGl2ZSBvbiwgYnV0IG1hbnkgbW9iaWxlIGFwcHMgd291bGQgbm90Lg0KDQoNCg0KT24gMTEg QXByaWwgMjAxOSBhdCAxMC4wMy4xNCwgTWlyamEgS3VlaGxld2luZCAobWlyamEua3VlaGxld2lu ZEBlcmljc3Nvbi5jb208bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPikgd3Jv dGU6DQpIaSBNaWtrZWwsDQoNCkkgZ3Vlc3MgaXQgaXMgbXVjaCBtb3JlIGxpa2VseSB0aGF0IGFu eSBvZiB0aG9zZSBhY3RvcnMgd291bGQganVzdCBibG9jayBRVUlDIGFsbCB0b2dldGhlciAoYXMg dGhlcmUgaXMgYWN0dWFsbHkgYSBmYWxsYmFjayB0byBUQ1ApLg0KDQpNaXJqYQ0KDQoNCg0K77u/ T24gMTAuMDQuMTksIDIxOjU3LCAiUVVJQyBvbiBiZWhhbGYgb2YgTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgbWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFp bC5jb20+PiB3cm90ZToNCg0KDQpMZXTigJlzIHNheSBDaGluYSBtYWtlcyBhIGRlYWwgd2l0aCBH b29nbGUgdG8gYWxsb3cgdGhlaXIgc2VhcmNoIGVuZ2luZSAoYSBub3QgZW50aXJlbHkgdW5yZWFz b25hYmx5IHByb3Bvc2l0aW9uKS4NClRoZSBHcmVhdCBGaXJld2FsbCBvZiBDaGluYSAoR0ZDKSBp cyByZWNvbmZpZ3VyZWQgdG8gYWNjZXB0IHRyYWZmaWMgZnJvbSBhIHNwZWNpZmljIElQIHJhbmdl IGZvciBRVUlDIHByb3RvY29sIHYxLg0KDQoNCg0KR29vZ2xlIGxhdGVyIHVwZ3JhZGVzIHRvIHYy LiBHRkMgaXMgdXBkYXRlZC4gTGF0ZXIsIG91dCBvZiBpZ25vcmFuY2UsIHNvbWUgb3RoZXIgZGVw YXJ0bWVudCB3aXRoaW4gc2FpZCBjb21wYW55IGRlY2lkZXMgdGhhdCBpdHMgYnJvd3NlcnMgc2hv dWxkIGFsbCB1c2UgZm9yY2VkIHZlcnNpb24gYWxpYXNlcyBhcyBhIHJ1bGUuIEdGQyBicmVha3Mu IChBc3N1bWluZyBHb29nbGVzIHNlcnZlcnMgYXJlIG5vdCBsb2NhdGVkIHdpdGhpbiB0aGUgZGVt aWxpdGFyaXNlZA0Kem9uZSBhbmQgdXNlcnMgdXNlIENocm9tZSkuDQoNCg0KQWx0ZXJuYXRpdmUg MTogR29vZ2xlIHVwIGZyb250IGRlY2lkZXMgdG8gZGVwbG95IGZvcmNlZCB2ZXJzaW9uIGFsaWFz aW5nLiBDaGluYSByZWplY3RzIHRoZSBkZWFsIGJlY2F1c2UgdGhleSBkbyBub3Qgd2FudCB0byBz dXBwb3J0IHJhbmRvbSB0cmFmZmljIHRocm91Z2ggR0ZDLg0KDQoNCkFsdGVybmF0aXZlIDI6IEdv b2dsZSB1cCBmcm9udCBkZWNpZGVzIHRvIGRlcGxveSBmb3JjZWQgdmVyc2lvbiBhbGlhc2luZywg YW5kIENoaW5hIGRvZXMgbm90IHJlamVjdCB0aGUgZGVhbCwgb3V0IG9mIGlnbm9yYW5jZS4gTGF0 ZXIgc29tZSBkZXBhcnRtZW50IGluIENoaW5hIEdGQyBvdmVyc2lnaHQgcmVhbGlzZXMgdGhlIGRl YWwgYW5kIGZvcmNlcyBHb29nbGUgdG8gcmVtb3ZlIGZvcmNlZCB2ZXJzaW9uIGFsaWFzaW5nLCBv ciBzaHV0IGRvd24NCml0cyBzZXJ2aWNlLg0KDQoNCkFsdGVybmF0aXZlIDM6IEdvb2dsZSB1cCBm cm9udCBkZWNpZGVzIHRvIGRlcGxveSBmb3JjZWQgdmVyc2lvbiBhbGlhc2luZyBhbmQgQ2hpbmEg c2F5cywgb2YgY291cnNlLCB3ZSB0cnVzdCBldmVyeXRoaW5nIGZyb20gR29vZ2xlcyBJUCByYW5n ZS4NCg0KDQpBbHRlcm5hdGl2ZSA0OiBHb29nbGUgcmVhbGlzZXMgdGhhdCBmb3JjZWQgdmVyc2lv biBhbGlhc2luZyBkb2VzIG5vdCB3b3JrIGluIHRoZSBnZW5lcmFsIGNhc2UsIGFuZCBtYWtlcyBh IHNwZWNpYWwgY2FzZSBmb3IgdXNlcnMgd2l0aGluIGEgY2VydGFpbiBnZW9ncmFwaGljYWwgYXJl YS4NCg0KDQpEaXNjbGFpbWVyOiBJ4oCZbSBub3QgYWZmaWxpYXRlZCB3aXRoIEdvb2dsZSBhbmQg dGhpcyBtaWdodCBub3QgYXQgYWxsIGJlIGhvdyB0aGluZ3Mgd291bGQgd29yaywgYnV0IGl0IGRv ZXMgaGlnaGxpZ2h0IHNvbWUgb2YgdGhlIGNoYWxsZW5nZXMuDQoNCg0KT2YgY291cnNlLCB0byBi ZSBmYWlyLCBDaGluYSBpcyBub3QgdGhlIG9ubHkgZ292ZXJubWVudCBlbnRpdHkgdGhhdCBtaWdo dCBoYXZlIGEgdmVzdGVkIGludGVyZXN0LiBMZXQncyB0YWtlIGEgZmljdGlvbmFsIGV4YW1wbGUg b2YgVVMgYSByZWFsIGVzdGF0ZSBpbnZlc3RvciB3aXRoIGhlYXZ5IHRpZXMgdG8gdGhlIGVhc3Rl cm4gZXVyb3BlYW4gYmxvY2sgd2hvIHNvbWVob3cgZmluZHMgaGltc2VsZiBlbGVjdGVkIGFzIHBy ZXNpZGVudCBuZWVkaW5nDQp0byBmaW5kIGxldmVyYWdlIG9uIHRyYWRlIG5lZ290aWF0aW9ucyB3 aXRob3V0IGVmZmVjdGl2ZWx5IGh1cnRpbmcgcGVyc29uYWwgZmluYW5jZXMuIEl0IHR1cm5zIG91 dCB0aGF0IGJsb2NraW5nIGNlcnRhaW4gZGlnaXRhbCBzZXJ2aWNlcyBmcm9tIHNhaWQgZWFzdGVy biBldXJvcGVhbiBibG9jayBpcyB0aGUgcGVyZmVjdCB0b29sIGluIHRoZSB0cmFkZSBuZWdvdGlh dGlvbnMuLiBBZHZpc2VycyBwb2ludCBvdXQgdGhhdCB0aG9zZSBzZXJ2aWNlcw0KcnVuIGhlYXZp bHkgZW5jcnlwdGVkIG9uIHRoZSBkYXJrIHdlYiB3aXRoIHBlcnBldHVhbCBjaXJjdWxhdGlvbiBv ZiBJUCByYW5nZXMgc28sIGlnbm9yaW5nIGFueSBsZWdhbCBjb25jZXJucywgaXQgd291bGQgbm90 IGJlIHByYWN0aWNhbGx5IHBvc3NpYmxlLiBFdmVudHVhbGx5IHNvbWVvbmUgZmlndXJlcyBvdXQg dGhhdCB0aGVzZSBzZXJ2aWNlcyBhbGwgdXN1YWxseSBhcmUgYXQgdGhlIGZvcmVmcm9udCBvZiB0 ZWNobm9sb2d5IGFuZCBjdXJyZW50bHkNCnVzZSBRVUlDIHYzLjIgYW5kIG5vLW9uZSBlbHNlIGhh cyBkZXBsb3llZCB0aGF0IHZlcnNpb24geWV0LCBzbyBpdCB3b3VsZCBzdWZmaWNlIHRvIGFzayBO U0EgdG8gdGFwIGludG8gdGhlIGJhY2tib25lIGFuZCBkaXNydXB0IHNwZWNpZmljIHBhY2tldHMu IE9mIGNvdXJzZSwgdGhpcyBlbmRzIHVwIHRha2luZyBkb3duIHRoZSBCYXZhcmlhbiBsb2NhbCBn b3Zlcm5tZW50IGVsZWN0aW9uIHByb2Nlc3MgaW4gR2VybWFueSB3aGVyZSB0aGV5IGFyZQ0KdGhl IGZpcnN0IHRvIHVzZSBhIG5ldyBkaWdpdGFsIGVsZWN0aW9uIHN5c3RlbS4gTm90IHRoYXQgdGhl IGlzIGFuIGlzc3VlLCBzaW5jZSB0cmFkZSBuZWdvdGlhdGlvbnMgYXJlIGFsc28gcnVubmluZyBo b3QgaW4gdGhhdCBhcmVhLCBzbyB0aGF0IGlzIGp1c3QgYW4gYWNjaWRlbnRhbCBib251cy4NCg0K DQpPciBhbiBlbmRsZXNzIG51bWJlciBvZiBvdGhlciBkZXZlbG9wbWVudHMgb3ZlciB0aGUgbmV4 dCBmZXcgZGVjYWRlcyBpZiB0aGUgcGFzdCBmZXcgeWVhcnMgaXMgYW55dGhpbmcgdG8gZ28gYnku DQoNCg0KDQoNCg0KT24gMTAgQXByaWwgMjAxOSBhdCAyMC4xMy41OSwgR29ycnkgKGVyZykgKGdv cnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi4uYWMudWs+KSB3cm90ZToN Cg0KVGhhbmtzIE1pa2tlbCwgSSBkbyB1bmRlcnN0YW5kIHRoYXQgdmFyaW91cyBhY3RvcnMgaW50 ZW50aW9uYWxseSBkcm9wIC0gYnV0IGFyZSB5b3Ugc2F5aW5nIHRoZXNlIGFjdG9ycyB3b3VsZCBz cGVjaWZpY2FsbHkgY2hvb3NlIHRvIGJsb2NrIGEgbmV3IHZlcnNpb24gb2YgUVVJQyAuLi4gSSBk byBub3QgdW5kZXJzdGFuZCB0aGF0IGFzc2VydGlvbi4NCg0KDQpHb3JyeQ0KDQpPbiAxMCBBcHIg MjAxOSwgYXQgMTg6MjUsIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWls LmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KDQpDaGluYSBibG9j a3MgYXMgYSBydWxlLg0KUnVzc2lhIGlzIHJ1bm5pbmcgYW4gZXhwZXJpbWVudCB0byBibG9jayB0 aGUgcmVzdCBvZiB0aGUgaW50ZXJuZXQuDQpVU0EgYmxvY2tzIG5ldCBuZXV0cmFsaXR5Lg0KRVUg YmxvY2tzIGNvb2tpZXMuDQpHQiBibG9ja3MgaXRzZWxmLg0KDQoNClNvIGJsb2NraW5nIGlzIG5v dCBsaW1pdGVkIHRvIHdoYXQgYW4gb3BlcmF0b3IgY29uc2lkZXJzIGJlc3QgZm9yIGJ1c2luZXNz Lg0KDQoNCg0KT24gMTAgQXByaWwgMjAxOSBhdCAxOC41OS4xNSwgQm9yZGVyLCBKb2huIChqb2hu LmJvcmRlckBodWdoZXMuY29tPG1haWx0bzpqb2huLmJvcmRlckBodWdoZXMuY29tPikgd3JvdGU6 DQoNCg0KSSB1bmRlcnN0YW5kIHdoeSBwZW9wbGUgd2FudCB0byBjb21lIGRvd24gb24gdGhlIHNp ZGUgb2YgcHJldmVudGluZyBvc3NpZmljYXRpb24uIEJ1dCwgdGhpbmdzIGhhdmUgY2hhbmdlZC4g VGhlcmUgYXJlIGEgbG90IG9mIG1vcmUgbmVnYXRpdmUgY29uc2VxdWVuY2VzIG5vdyB3aGVuIHBl b3BsZSB1bm5lY2Vzc2FyaWx5IGJsb2NrIHRoaW5ncy4gSSB0aGluayBvcGVyYXRvcnMgd291bGQg cHV0IGEgbG90IG9mIHByZXNzdXJlIG9uIHZlbmRvcnMgdG8NCm5vdCBkbyBpdCBub3cgYW5kIHRv IGZpeCBpdCBpZiB0aGV5IGRpZCAiYnkgYWNjaWRlbnQiLiBPZiBjb3Vyc2UsIEkgYW0gb25seSBv bmUgb3BlcmF0b3IuIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGVhciBmcm9tIG90aGVycy4uLg0KDQoN Cg0KSm9obg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIDxxdWlj LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFs ZiBPZiBSb2JlcnRvIFBlb24NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTAsIDIwMTkgMTI6NTIg UE0NClRvOiBHIEZhaXJodXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVy Zy5hYmRuLmFjLnVrPj47DQpxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2Jz dGFjbGU/DQoNCldBUk5JTkc6IFRoZSBzZW5kZXIgb2YgdGhpcyBlbWFpbCBjb3VsZCBub3QgYmUg dmFsaWRhdGVkIGFuZCBtYXkgbm90IG1hdGNoIHRoZSBwZXJzb24gaW4gdGhlICJGcm9tIiBmaWVs ZC4NCg0KQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUg b3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxl c3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUu DQoNCg0KWW91J3JlIGtpbmRhIGJldHdlZW4gYSByb2NrLWFuZC1hLWhhcmQtcGxhY2UgZWl0aGVy IHdheToNCg0KLSBXZSd2ZSBzZWVuIGhvdyBtdWNoIGZ1biBvc3NpZmljYXRpb24gaXMgaW4gVENQ IGFuZCBIVFRQLiBJZiB0aGUgdGhpbmcgaXMgb2JzZXJ2YWJsZSwgaXQgd2lsbCBiZSBvc3NpZmll ZCBzZWVtcyB0byBiZSB0aGUgbGVzc29uLiBBIGxvdCBvZiB0aGUgcmVhc29uIHdoeSBRVUlDIHdh cyBzdGFydGVkIGluIHRoZSBmaXJzdCBwbGFjZSB3YXMgYmVjYXVzZSBvZiB0aGUgaW5hYmlsaXR5 IHRvIGltcHJvdmUgVENQIGR1ZSB0byB0aGlzIG9zc2lmaWNhdGlvbi4NCi0gT1RPSCwgdGhlcmUg aXMgdGhlIGZlYXIgb2YgdW5rbm93bi91bm9ic2VydmFibGUgd2hpY2ggbWlnaHQgY2F1c2Ugb3Bl cmF0b3JzIHRvIGJsb2NrIHRoaW5ncywgd2hldGhlciBwcmVkaWN0YWJseSBvciBub3QuDQoNCk15 IG9waW5pb24gaXMgdGhhdCBpdCBpcyBiZXR0ZXIgdG8gc3RhcnQgd2l0aCBwcmV2ZW50aW5nIG9z c2lmaWNhdGlvbiwgYW5kIHRoZW4gaWYgdGhhdCByZXN1bHRzIGluIHRvbyBsYXJnZSBhIHBlcmNl bnRhZ2Ugb2Ygb3BlcmF0b3JzIGJsb2NraW5nIHRoaW5ncywgdG8gcmUtZXZhbHVhdGUuDQoNCk15 IGd1ZXNzZXM6DQpJUCtwb3J0IHR1cGxlcyBhbmQgdHJhZmZpYyBwYXR0ZXJucyBhcmUgc3RpbGwg b2JzZXJ2YWJsZSAoZm9yIGJldHRlciBhbmQgd29yc2UpLCB3aGljaCBpbXBsaWVzIG9wZXJhdG9y cyB3aWxsIHN0aWxsIGhhdmUgc2lnbmlmaWNhbnQgdG9vbHMgZm9yIG1hbmFnaW5nIHRyYWZmaWMu IEkgYmVsaWV2ZSB0aGF0IHRoZXNlIGFyZSBhY3RlZCBvbi9tYXRjaGVkIChNTCBvciBub3QpIHJl Z2FyZGxlc3Mgb2YgYW55IG90aGVyIGRhdGEgcHJlc2VudGVkLiBJbg0Kb3RoZXIgd29yZHMsIEkg aGF2ZSBhIGRvdWJ0IHRoYXQgc3RhdGluZyB0aGUgdmVyc2lvbiBpbiBhbiBvYnNlcnZhYmxlIHdh eSB3aWxsIHByZXZlbnQgdGhlIHVzZSBvZiBzdWNoIHRvb2xzLg0KDQpNb3N0IHByb2JsZW1zIEkn dmUgc2VlbiBhc3NvY2lhdGVkIHdpdGggaW1wbGVtZW50YXRpb25zIHJhdGhlciB0aGFuIHByb3Rv Y29sIHZlcnNpb25zICh0aG91Z2ggd2hlbiB0aGUgbGF0dGVyIGhhcHBlbnMgaXQgaXMgcHJldHR5 IHNldmVyZSkuLiBJZiB5b3UgYmVsaWV2ZSB0aGlzIGFzc2VydGlvbiwgdGhlbiBhY3Rpbmcgb24g cHJvdG9jb2wgdmVyc2lvbiBpcyBsZXNzIGludGVyZXN0aW5nIHRoYW4gYXR0ZW1wdGluZyB0byBh Y3QgYmFzZWQgb24gaW1wbGVtZW50YXRpb24NCmZpbmdlcnByaW50cy4NCi09Ug0KDQoNCk9uIDQv MTAvMTksIDE6NDggQU0sICJRVUlDIG9uIGJlaGFsZiBvZiBHIEZhaXJodXJzdCIgPHF1aWMtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YN CmdvcnJ5QGVyZy5hYmRuLmFjLi51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+PiB3cm90 ZToNCg0KT2JzY3VyaW5nIHRoZSB2ZXJzaW9uIG9mIGEgcHJvdG9jb2wgc2VlbXMgbGlrZSBhIG1h am9yIGRlc2lnbiBkZXNpZ24NCmRlY2lzaW9uIGZvciB3aWRlciB1c2UgY2FzZXMuIFNvLCBJJ20g dHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlDQptb3RpdmF0aW9uIGZvciB2ZXJzaW9uIGdyZWFzaW5n Lg0KDQooMSkgSSBrbm93IHRoZXJlIHdlcmUgaW5zdGFuY2VzIHdoZXJlIHNvbWUgZWFybHkgdmVy c2lvbnMgb2YgUVVJQyB3ZXJlDQpibG9ja2VkIGR1ZSB0byBhbiB1bmluaXRlbnRpb25hbCBtYXRj aGluZyBvZiB0aGUgaGVhZGVyLiBJcyB0aGVyZQ0KZXZpZGVuY2Ugb2YgaW50ZW50aW9uYWwgYXR0 ZW1wdHMgdG8gYmxvY2sgdXBkYXRlcyB0byBwcm90b2NvbHM/DQoNCigyKSBUaGlua2luZyBhYm91 dCBvcGVyYXRpbmcgYSBuZXR3b3JrIHRoYXQgY2FyZXMgYWJvdXQgdXNlciBzdXBwb3J0IGFuZA0K cHJvdGVjdGlvbiBmcm9tIHVud2FudGVkIHRyYWZmaWMsIEkgd291bGQgZXhwZWN0IHRoYXQgdGhl cmUgd291bGQgYmUNCmNhc2VzIHdoZXJlIHRyYWZmaWMgcGF0dGVybiBhbm9tb2xpZXMgYXJlIGZv dW5kIGFuZCB0aGUgYXBwcm9wcmlhdGUNCnRoaW5nIHdvdWxkIGJlIHRvIHRyeSB0byBkZXRlcm1p bmUgaWYgYSBuZXcgcHJvdG9jb2wgaGFkIGJlZW4gZGVwbG95ZWQNCmFuZCBtb25pdG9yIGl0LCBp ZiBub3QsIHRoZW4gdGhlIG5leHQgbW9zdCBvYnZpb3VzIHRoaW5nIGNvdWxkIGJlIHRvDQpibG9j ayBhbGwgdW5leHBlY3RlZCB0cmFmZmljLCB0aGF0IHNlZW1zIGxpa2UgYSBkZWNpc2lvbiB0byBo aWRlIHRoZQ0KdmVyc2lvbiBjb3VsZCBpbmNyZWFzZSBvc3NpZmljYXRpb24gZm9yIG5ldyB2ZXJz aW9ucyBpbiB0aGVzZSBjYXNlcy4uDQoNCigzKSBTaW1pbGFybHksIGlmIGEgdGhyZWF0IGlzIGtu b3duIHRvIGltcGFjdCBvbmx5IGEgc3BlY2lmaWMgKG9sZGVyKQ0KdmVyc2lvbiwgaXQgd291bGQg c2VlbSB0byBtb3RpdmF0ZSBhIGRyb3Agb2YgdGhhdCB0cmFmZmljIHRoYXQgc2Vla3MgdG8NCnVz ZSB0aGF0IHZlcnNpb24sIHdoaWxlIHN0aWxsIHBlcm1pdHRpbmcgb3RoZXIgdHJhZmZpYy4gRm9y Y2luZyB2ZXJzaW9uDQpkZXRlY3Rpb24gdG8gdXNlIHBhdHRlcm4gbWF0Y2hpbmcvTUwgd2lsbCBs ZWFkIHRvIGxlc3MgcHJlZGljdGFibGUNCm91dGNvbWVzLCBvciBibG9ja2luZyBiYXNlZCBvbiBh ZGRyZXNzLCBldGMuDQoNCig0KSBUaGlzIG9iZnVzdGljYXRlcyB0aGUgbW9zdCBiYXNpYyBwaWVj ZSBvZiByZXBvcnRpbmcgaW5mb3JtYXRpb24gdXNlZA0KZm9yIHN1cHBvcnQuIEl0IGhpZGVzIHRo ZSBleHRlbnQgb2YgZGVwbG95bWVudCBvZiB0aGUgY3VycmVudCBwcm90b2NvbA0KdmVyc2lvbiBh bmQgcHJldmxhbmNlIG9mIG9sZCBpbXBsZW1lbnRhdGlvbnMuDQoNCig1KSBPbiB0aGUgc3VwcG9y dCwgaWYgYSBwcm9ibGVtIG9ubHkgZW1lcmdlcyB3aGVuIGEgcGFydGljdWxhciB2ZXJzaW9uDQpp cyB1c2VkIHdpdGggYSBwYXJ0aWN1bGFyIGFkZHJlc3MsIHRoZW4gdGhpcyBoZWxwcyBwaW5wb2lu dCB0aGUgaXNzdWVzLg0KTWF0Y2hpbmcgY2xpZW50IHZlcnNpb25zIHRvIHNlcnZlcnMgaXMgbXVj aCBtb3JlIG9mIGFuIGlzc3VlIGlmIHRoZSB1c2VyDQpjb21tdW5pdHkgdXNlcyBhIHdpZGUgcmFu Z2Ugb2Ygc2VydmVycyAobGVzcyBzbywgSSBleHBlY3QgZm9yIG1ham9yDQpwcm92aWRlcnM6IGdv b2dsZSwgZmFjZWJvb2ssIGV0YywgZXRjKSwgYnV0IHNpZ25pZmljYW50IHdoZW4gdGhlcmUgaXMg YQ0KdXNlIG9mIGEgZGl2ZXJzZSBzZXQgb2YgZXh0ZXJuYWwgc2l0ZXMgYW5kIHNpdGVzIHdpdGgg dGhlaXIgb3duIGxvYWQNCmJhbGFuY2VycywgZXRjIGFuZCBhIG5lZWQgdG8gbWFuYWdlIGludGVy YWN0aW9ucyB3aXRoIEwyIHNlcnZpY2VzLg0KDQpJIGFtIGludGVyc3RlZCBpbiBrbm93aW5nIGlm IHRoaXMgaXMgbGlrZWx5IHRvIGJlbmVmaXQgb3IgYmUgYSBuZXcgb2JzdGFjbGU/DQoNCkdvcnJ5 DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg== --_000_MW2PR2101MB10496C89AF5523D20B753D6CB6280MW2PR2101MB1049_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnAuZ21haWwtbS02NDUxMjc1MTE0OTc0ODI1MDY3YWlybWFpbG9uLCBsaS5nbWFpbC1tLTY0 NTEyNzUxMTQ5NzQ4MjUwNjdhaXJtYWlsb24sIGRpdi5nbWFpbC1tLTY0NTEyNzUxMTQ5NzQ4MjUw NjdhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tNjQ1MTI3NTExNDk3NDgyNTA2 N2Fpcm1haWxvbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JdCBiZWluZyBvcHRpb25hbCBoZWxwcyBpbiBjYXNlcyB3aGVyZSB0 aGUgc2VydmljZSBiZWluZyBkZXBsb3llZCBhbmQgdGhlIERvUyBwcm90ZWN0aW9uIHNlcnZpY2Ug YXJlIHVuZGVyIHNhbWUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLiBTbyBkZXBlbmRpbmcgb24gaG93 IERvUyBwcm90ZWN0aW9uIGlzIGRvbmUgdGhlIGV4dGVuc2lvbiBjb3VsZCBiZSB0dXJuZWQgb24g b3Igb2ZmLiBUaGUgcHJvYmxlbSBpcyB3aXRoDQogdGhlIElhYVMgc2NlbmFyaW8gaWYgdGhlIGV4 dGVuc2lvbiBpcyB0dXJuZWQgb24gYnkgZGVmYXVsdCBpbiBzb21lIG1ham9yIHdlYiBzZXJ2ZXIu IE5vdyBERG9TIHByb3RlY3Rpb24gY2Fubm90IGJlIG9mZmVyZWQgYXMgYSBjbG91ZCBzZXJ2aWNl IHdpdGhvdXQgaGFybWluZyBzYWlkIHRyYWZmaWMgYmVjYXVzZSBpdCB3aWxsIGJlIHJhdGUgbGlt aXRlZC4gQW5kIHJhdGUgbGltaXRpbmcgaXMgc3RyaWN0bHkgd29yc2UgdGhhbiBibG9ja2luZyBR VUlDDQogYmVjYXVzZSBwZXJmb3JtYW5jZSB3aWxsIHN1ZmZlci4gPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldlIHdpbGwgbGlrZWx5IG5lZWQgc29tZSB0ZXh0IGluIG1hbmFnZWFiaWxpdHkgZHJh ZnQgd2hpY2ggc2F5cyB0aGF0IHR1cm5pbmcgb24gdGhpcyBleHRlbnNpb24gbWF5IGJyZWFrIG5l dHdvcmsgZnVuY3Rpb25zIGFuZCBjYXVzZSBwZXJmb3JtYW5jZSBpc3N1ZXMgc28gc2VydmljZXMg LyBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIG9ubHkgdHVybiB0aGlzIG9uIGFmdGVyIHRoZXNlIGNv bnNpZGVyYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAm bHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KSWFuIFN3 ZXR0PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMTIsIDIwMTkgODo1NyBBTTxicj4N CjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTQwbWljcm9zb2Z0 LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IEdvcnJ5IChlcmcpICZsdDtn b3JyeUBlcmcuYWJkbi5hYy51ayZndDs7IFJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0 OzsgTWlyamEgS3VlaGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20mZ3Q7 OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBx dWljQGlldGYub3JnOyBCb3JkZXIsIEpvaG4gJmx0O2pvaG4uYm9yZGVyQGh1Z2hlcy5jb20mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJcyAmcXVvdDtWZXJzaW9uIEdyZWFzaW5nJnF1b3Q7 IGEgbmV3IGJlbmZpdCBvciBhIG5ldyBvYnN0YWNsZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlBvc3NpYmx5IEknbSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IHdvdWxkbid0IHZlcnNp b24gZ3JlYXNpbmcgYmUgYW4gb3B0aW9uYWwgZXh0ZW5zaW9uPyZuYnNwOyBTbyBpZiB5b3Ugd2Fu dGVkIHRvIGRvIHNvIHlvdSBjb3VsZCwgYnV0IHRob3NlIHdpdGggbG9hZCBiYWxhbmNpbmcgdGhh dCBjb3VsZG4ndCBoYW5kbGUgaXQgd291bGQgbm90PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgMTIsIDIwMTkgYXQgMTE6NTUgQU0gUHJh dmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmciPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvcnJ5IGZvciBhIHR5cG8uIFBsYWluIG9sZCBV RFAgbm90IFFVSUMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQo8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxMiwgMjAxOSA4OjUzIEFNPGJyPg0KPGI+ VG86PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlr a2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZn dDs7IEdvcnJ5IChlcmcpICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsi IHRhcmdldD0iX2JsYW5rIj5nb3JyeUBlcmcuYWJkbi5hYy51azwvYT4mZ3Q7OyBNaXJqYSBLdWVo bGV3aW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20i IHRhcmdldD0iX2JsYW5rIj5taXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnF1aWNAaWV0Zi5vcmc8L2E+OyBCb3JkZXIsIEpvaG4gJmx0OzxhIGhyZWY9Im1haWx0bzpq b2huLmJvcmRlckBodWdoZXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+am9obi5ib3JkZXJAaHVnaGVz LmNvbTwvYT4mZ3Q7OyBSb2JlcnRvIFBlb24gJmx0OzxhIGhyZWY9Im1haWx0bzpmZW5peEBmYi5j b20iIHRhcmdldD0iX2JsYW5rIj5mZW5peEBmYi5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogSXMgJnF1b3Q7VmVyc2lvbiBHcmVhc2luZyZxdW90OyBhIG5ldyBiZW5maXQgb3Ig YSBuZXcgb2JzdGFjbGU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+VmVyc2lvbiBncmVhc2luZyB3aWxsIGNyZWF0ZSBwcm9ibGVtcyBmb3IgRERvUyBwcm90ZWN0 aW9uLiBUaGUgRERvUyBwcm90ZWN0aW9uIG1pZGRsZWJveCB3aWxsIGhhdmUgdG8gdHJlYXQgYWxs IHRyYWZmaWMgd2l0aCB1bmtub3duIHZlcnNpb24gbnVtYmVycyBhcyBwbGFpbiBvbGQgUVVJQyBh bmQgcmF0ZSBsaW1pdA0KIGl0LiBBbnkgc29sdXRpb24gdGhhdCByZXF1aXJlcyBwZXIgY29ubmVj dGlvbiBzdGF0ZSB0byB0cmFjayB2ZXJzaW9uIG51bWJlcnMgZG9lc27igJl0IHNjYWxlLiBFc3Bl Y2lhbGx5IGluIHRoZSBjbG91ZCBzY2VuYXJpbyBjdXN0b21lcnMgYnJpbmcgdGhlaXIgb3duIHdl YiBzZXJ2ZXJzIHNvIHRoaXMgbWFrZXMgYW55IG9wdC1vdXQgc29sdXRpb24gbm90IGdvb2QgZW5v dWdoLiBTbyBJIGRvIHRoaW5rIHRoaXMgaXMgYW4gb2JzdGFjbGUgZm9yIG1hbnkNCiBkZXBsb3lt ZW50cy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFFVSUMgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAxMSwgMjAxOSAxOjIwIEFNPGJyPg0KPGI+VG86 PC9iPiBHb3JyeSAoZXJnKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVr IiB0YXJnZXQ9Il9ibGFuayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OzsgTWlyamEgS3Vl aGxld2luZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29t IiB0YXJnZXQ9Il9ibGFuayI+bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb208L2E+Jmd0Ozxi cj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5xdWljQGlldGYub3JnPC9hPjsgQm9yZGVyLCBKb2huICZsdDs8YSBocmVmPSJtYWlsdG86 am9obi5ib3JkZXJAaHVnaGVzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvaG4uYm9yZGVyQGh1Z2hl cy5jb208L2E+Jmd0OzsgUm9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIu Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZmVuaXhAZmIuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IElzICZxdW90O1ZlcnNpb24gR3JlYXNpbmcmcXVvdDsgYSBuZXcgYmVuZml0IG9y IGEgbmV3IG9ic3RhY2xlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJnbWFpbC1tXy02 NDUxMjc1MTE0OTc0ODI1MDY3Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiBhIG5vdCBzbyBkaXN0YW50IGZ1dHVyZSwgYSBmYWxs YmFjayB0byBUQ1Agd291bGQgbm90IGJlIGEgdmlhYmxlIGFsdGVybmF0aXZlIGZvciBhIG51bWJl ciBvZiBzZXJ2aWNlcy4gVGhpbmsNCiBXZWJSVEMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJnbWFpbC1tXy02NDUxMjc1MTE0OTc0ODI1MDY3Ymxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZiBRVUlDIGFu ZCBvdGhlciBlbmNyeXB0ZWQgcHJvdG9jb2xzIGJlY29tZSBkb21pbmFudCwganVzdCBibG9ja2lu ZyBldmVyeXRoaW5nIHdvdWxkIGxpdGVyYWxseSBibG9jayBldmVyeXRoaW5nLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8tNjQ1MTI3NTExNDk3NDgyNTA2 N2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+T2YgY291cnNlLCBodHRwKHMpIGFzIHdlIGtub3cgaXQsIGl0IHdpbGwgY29udGludWUg dG8gbGl2ZSBvbiwgYnV0IG1hbnkgbW9iaWxlIGFwcHMgd291bGQgbm90Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8tNjQ1MTI3NTExNDk3NDgyNTA2N2Js b29wX3NpZ25fMTU1NDk3MDY5ODMwMDI4MjExMiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTY0NTEyNzUxMTQ5 NzQ4MjUwNjdhaXJtYWlsb24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiAxMSBBcHJpbCAyMDE5IGF0 IDEwLjAzLjE0LCBNaXJqYSBLdWVobGV3aW5kICg8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxl d2luZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5taXJqYS5rdWVobGV3aW5kQGVyaWNz c29uLmNvbTwvYT4pDQogd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIE1pa2tlbCwNCjxicj4N Cjxicj4NCkkgZ3Vlc3MgaXQgaXMgbXVjaCBtb3JlIGxpa2VseSB0aGF0IGFueSBvZiB0aG9zZSBh Y3RvcnMgd291bGQganVzdCBibG9jayBRVUlDIGFsbCB0b2dldGhlciAoYXMgdGhlcmUgaXMgYWN0 dWFsbHkgYSBmYWxsYmFjayB0byBUQ1ApLg0KPGJyPg0KPGJyPg0KTWlyamEgPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj7vu788L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk9uIDEwLjA0LjE5LCAyMTo1NywgJnF1b3Q7UVVJQyBvbiBiZWhhbGYgb2YgTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4NCiBv biBiZWhhbGYgb2YgPGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPGJyPg0KPGJyPg0KPGJy Pg0KTGV04oCZcyBzYXkgQ2hpbmEgbWFrZXMgYSBkZWFsIHdpdGggR29vZ2xlIHRvIGFsbG93IHRo ZWlyIHNlYXJjaCBlbmdpbmUgKGEgbm90IGVudGlyZWx5IHVucmVhc29uYWJseSBwcm9wb3NpdGlv bikuDQo8YnI+DQpUaGUgR3JlYXQgRmlyZXdhbGwgb2YgQ2hpbmEgKEdGQykgaXMgcmVjb25maWd1 cmVkIHRvIGFjY2VwdCB0cmFmZmljIGZyb20gYSBzcGVjaWZpYyBJUCByYW5nZSBmb3IgUVVJQyBw cm90b2NvbCB2MS4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCkdvb2dsZSBsYXRlciB1cGdyYWRl cyB0byB2Mi4gR0ZDIGlzIHVwZGF0ZWQuIExhdGVyLCBvdXQgb2YgaWdub3JhbmNlLCBzb21lIG90 aGVyIGRlcGFydG1lbnQgd2l0aGluIHNhaWQgY29tcGFueSBkZWNpZGVzIHRoYXQgaXRzIGJyb3dz ZXJzIHNob3VsZCBhbGwgdXNlIGZvcmNlZCB2ZXJzaW9uIGFsaWFzZXMgYXMgYSBydWxlLiBHRkMg YnJlYWtzLiAoQXNzdW1pbmcgR29vZ2xlcyBzZXJ2ZXJzIGFyZSBub3QgbG9jYXRlZCB3aXRoaW4g dGhlIGRlbWlsaXRhcmlzZWQNCjxicj4NCnpvbmUgYW5kIHVzZXJzIHVzZSBDaHJvbWUpLiA8YnI+ DQo8YnI+DQo8YnI+DQpBbHRlcm5hdGl2ZSAxOiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0byBk ZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcuIENoaW5hIHJlamVjdHMgdGhlIGRlYWwgYmVj YXVzZSB0aGV5IGRvIG5vdCB3YW50IHRvIHN1cHBvcnQgcmFuZG9tIHRyYWZmaWMgdGhyb3VnaCBH RkMuDQo8YnI+DQo8YnI+DQo8YnI+DQpBbHRlcm5hdGl2ZSAyOiBHb29nbGUgdXAgZnJvbnQgZGVj aWRlcyB0byBkZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcsIGFuZCBDaGluYSBkb2VzIG5v dCByZWplY3QgdGhlIGRlYWwsIG91dCBvZiBpZ25vcmFuY2UuIExhdGVyIHNvbWUgZGVwYXJ0bWVu dCBpbiBDaGluYSBHRkMgb3ZlcnNpZ2h0IHJlYWxpc2VzIHRoZSBkZWFsIGFuZCBmb3JjZXMgR29v Z2xlIHRvIHJlbW92ZSBmb3JjZWQgdmVyc2lvbiBhbGlhc2luZywgb3Igc2h1dCBkb3duDQo8YnI+ DQppdHMgc2VydmljZS4gPGJyPg0KPGJyPg0KPGJyPg0KQWx0ZXJuYXRpdmUgMzogR29vZ2xlIHVw IGZyb250IGRlY2lkZXMgdG8gZGVwbG95IGZvcmNlZCB2ZXJzaW9uIGFsaWFzaW5nIGFuZCBDaGlu YSBzYXlzLCBvZiBjb3Vyc2UsIHdlIHRydXN0IGV2ZXJ5dGhpbmcgZnJvbSBHb29nbGVzIElQIHJh bmdlLg0KPGJyPg0KPGJyPg0KPGJyPg0KQWx0ZXJuYXRpdmUgNDogR29vZ2xlIHJlYWxpc2VzIHRo YXQgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcgZG9lcyBub3Qgd29yayBpbiB0aGUgZ2VuZXJhbCBj YXNlLCBhbmQgbWFrZXMgYSBzcGVjaWFsIGNhc2UgZm9yIHVzZXJzIHdpdGhpbiBhIGNlcnRhaW4g Z2VvZ3JhcGhpY2FsIGFyZWEuDQo8YnI+DQo8YnI+DQo8YnI+DQpEaXNjbGFpbWVyOiBJ4oCZbSBu b3QgYWZmaWxpYXRlZCB3aXRoIEdvb2dsZSBhbmQgdGhpcyBtaWdodCBub3QgYXQgYWxsIGJlIGhv dyB0aGluZ3Mgd291bGQgd29yaywgYnV0IGl0IGRvZXMgaGlnaGxpZ2h0IHNvbWUgb2YgdGhlIGNo YWxsZW5nZXMuDQo8YnI+DQo8YnI+DQo8YnI+DQpPZiBjb3Vyc2UsIHRvIGJlIGZhaXIsIENoaW5h IGlzIG5vdCB0aGUgb25seSBnb3Zlcm5tZW50IGVudGl0eSB0aGF0IG1pZ2h0IGhhdmUgYSB2ZXN0 ZWQgaW50ZXJlc3QuIExldCdzIHRha2UgYSBmaWN0aW9uYWwgZXhhbXBsZSBvZiBVUyBhIHJlYWwg ZXN0YXRlIGludmVzdG9yIHdpdGggaGVhdnkgdGllcyB0byB0aGUgZWFzdGVybiBldXJvcGVhbiBi bG9jayB3aG8gc29tZWhvdyBmaW5kcyBoaW1zZWxmIGVsZWN0ZWQgYXMgcHJlc2lkZW50IG5lZWRp bmcNCjxicj4NCnRvIGZpbmQgbGV2ZXJhZ2Ugb24gdHJhZGUgbmVnb3RpYXRpb25zIHdpdGhvdXQg ZWZmZWN0aXZlbHkgaHVydGluZyBwZXJzb25hbCBmaW5hbmNlcy4gSXQgdHVybnMgb3V0IHRoYXQg YmxvY2tpbmcgY2VydGFpbiBkaWdpdGFsIHNlcnZpY2VzIGZyb20gc2FpZCBlYXN0ZXJuIGV1cm9w ZWFuIGJsb2NrIGlzIHRoZSBwZXJmZWN0IHRvb2wgaW4gdGhlIHRyYWRlIG5lZ290aWF0aW9ucy4u IEFkdmlzZXJzIHBvaW50IG91dCB0aGF0IHRob3NlIHNlcnZpY2VzDQo8YnI+DQpydW4gaGVhdmls eSBlbmNyeXB0ZWQgb24gdGhlIGRhcmsgd2ViIHdpdGggcGVycGV0dWFsIGNpcmN1bGF0aW9uIG9m IElQIHJhbmdlcyBzbywgaWdub3JpbmcgYW55IGxlZ2FsIGNvbmNlcm5zLCBpdCB3b3VsZCBub3Qg YmUgcHJhY3RpY2FsbHkgcG9zc2libGUuIEV2ZW50dWFsbHkgc29tZW9uZSBmaWd1cmVzIG91dCB0 aGF0IHRoZXNlIHNlcnZpY2VzIGFsbCB1c3VhbGx5IGFyZSBhdCB0aGUgZm9yZWZyb250IG9mIHRl Y2hub2xvZ3kgYW5kIGN1cnJlbnRseQ0KPGJyPg0KdXNlIFFVSUMgdjMuMiBhbmQgbm8tb25lIGVs c2UgaGFzIGRlcGxveWVkIHRoYXQgdmVyc2lvbiB5ZXQsIHNvIGl0IHdvdWxkIHN1ZmZpY2UgdG8g YXNrIE5TQSB0byB0YXAgaW50byB0aGUgYmFja2JvbmUgYW5kIGRpc3J1cHQgc3BlY2lmaWMgcGFj a2V0cy4gT2YgY291cnNlLCB0aGlzIGVuZHMgdXAgdGFraW5nIGRvd24gdGhlIEJhdmFyaWFuIGxv Y2FsIGdvdmVybm1lbnQgZWxlY3Rpb24gcHJvY2VzcyBpbiBHZXJtYW55IHdoZXJlIHRoZXkgYXJl DQo8YnI+DQp0aGUgZmlyc3QgdG8gdXNlIGEgbmV3IGRpZ2l0YWwgZWxlY3Rpb24gc3lzdGVtLiBO b3QgdGhhdCB0aGUgaXMgYW4gaXNzdWUsIHNpbmNlIHRyYWRlIG5lZ290aWF0aW9ucyBhcmUgYWxz byBydW5uaW5nIGhvdCBpbiB0aGF0IGFyZWEsIHNvIHRoYXQgaXMganVzdCBhbiBhY2NpZGVudGFs IGJvbnVzLg0KPGJyPg0KPGJyPg0KPGJyPg0KT3IgYW4gZW5kbGVzcyBudW1iZXIgb2Ygb3RoZXIg ZGV2ZWxvcG1lbnRzIG92ZXIgdGhlIG5leHQgZmV3IGRlY2FkZXMgaWYgdGhlIHBhc3QgZmV3IHll YXJzIGlzIGFueXRoaW5nIHRvIGdvIGJ5Lg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KT24gMTAgQXByaWwgMjAxOSBhdCAyMC4xMy41OSwgR29ycnkgKGVyZykgKDxhIGhyZWY9 Im1haWx0bzpnb3JyeUBlcmcuYWJkbi4uYWMudWsiIHRhcmdldD0iX2JsYW5rIj5nb3JyeUBlcmcu YWJkbi5hYy51azwvYT4pIHdyb3RlOg0KPGJyPg0KPGJyPg0KVGhhbmtzIE1pa2tlbCwgSSBkbyB1 bmRlcnN0YW5kIHRoYXQgdmFyaW91cyBhY3RvcnMgaW50ZW50aW9uYWxseSBkcm9wIC0gYnV0IGFy ZSB5b3Ugc2F5aW5nIHRoZXNlIGFjdG9ycyB3b3VsZCBzcGVjaWZpY2FsbHkgY2hvb3NlIHRvIGJs b2NrIGEgbmV3IHZlcnNpb24gb2YgUVVJQyAuLi4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGF0IGFz c2VydGlvbi4NCjxicj4NCjxicj4NCjxicj4NCkdvcnJ5IDxicj4NCjxicj4NCk9uIDEwIEFwciAy MDE5LCBhdCAxODoyNSwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQ2hpbmEgYmxvY2tzIGFz IGEgcnVsZS4gPGJyPg0KUnVzc2lhIGlzIHJ1bm5pbmcgYW4gZXhwZXJpbWVudCB0byBibG9jayB0 aGUgcmVzdCBvZiB0aGUgaW50ZXJuZXQuIDxicj4NClVTQSBibG9ja3MgbmV0IG5ldXRyYWxpdHku IDxicj4NCkVVIGJsb2NrcyBjb29raWVzLiA8YnI+DQpHQiBibG9ja3MgaXRzZWxmLiA8YnI+DQo8 YnI+DQo8YnI+DQpTbyBibG9ja2luZyBpcyBub3QgbGltaXRlZCB0byB3aGF0IGFuIG9wZXJhdG9y IGNvbnNpZGVycyBiZXN0IGZvciBidXNpbmVzcy4gPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24g MTAgQXByaWwgMjAxOSBhdCAxOC41OS4xNSwgQm9yZGVyLCBKb2huICg8YSBocmVmPSJtYWlsdG86 am9obi5ib3JkZXJAaHVnaGVzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvaG4uYm9yZGVyQGh1Z2hl cy5jb208L2E+KSB3cm90ZToNCjxicj4NCjxicj4NCjxicj4NCkkgdW5kZXJzdGFuZCB3aHkgcGVv cGxlIHdhbnQgdG8gY29tZSBkb3duIG9uIHRoZSBzaWRlIG9mIHByZXZlbnRpbmcgb3NzaWZpY2F0 aW9uLiBCdXQsIHRoaW5ncyBoYXZlIGNoYW5nZWQuIFRoZXJlIGFyZSBhIGxvdCBvZiBtb3JlIG5l Z2F0aXZlIGNvbnNlcXVlbmNlcyBub3cgd2hlbiBwZW9wbGUgdW5uZWNlc3NhcmlseSBibG9jayB0 aGluZ3MuIEkgdGhpbmsgb3BlcmF0b3JzIHdvdWxkIHB1dCBhIGxvdCBvZiBwcmVzc3VyZSBvbiB2 ZW5kb3JzIHRvDQo8YnI+DQpub3QgZG8gaXQgbm93IGFuZCB0byBmaXggaXQgaWYgdGhleSBkaWQg JnF1b3Q7YnkgYWNjaWRlbnQmcXVvdDsuIE9mIGNvdXJzZSwgSSBhbSBvbmx5IG9uZSBvcGVyYXRv ci4gSXQgd291bGQgYmUgbmljZSB0byBoZWFyIGZyb20gb3RoZXJzLi4uDQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQpKb2huIDxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tIDxicj4NCkZyb206IFFVSUMgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBC ZWhhbGYgT2YgUm9iZXJ0byBQZW9uDQo8YnI+DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEwLCAy MDE5IDEyOjUyIFBNIDxicj4NClRvOiBHIEZhaXJodXJzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdv cnJ5QGVyZy5hYmRuLmFjLnVrIiB0YXJnZXQ9Il9ibGFuayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8 L2E+Jmd0OzsNCjxicj4NCjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+cXVpY0BpZXRmLm9yZzwvYT4gPGJyPg0KU3ViamVjdDogUmU6IElzICZxdW90O1ZlcnNp b24gR3JlYXNpbmcmcXVvdDsgYSBuZXcgYmVuZml0IG9yIGEgbmV3IG9ic3RhY2xlPyA8YnI+DQo8 YnI+DQpXQVJOSU5HOiBUaGUgc2VuZGVyIG9mIHRoaXMgZW1haWwgY291bGQgbm90IGJlIHZhbGlk YXRlZCBhbmQgbWF5IG5vdCBtYXRjaCB0aGUgcGVyc29uIGluIHRoZSAmcXVvdDtGcm9tJnF1b3Q7 IGZpZWxkLg0KPGJyPg0KPGJyPg0KQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20g b3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBh dHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBj b250ZW50IGlzIHNhZmUuDQo8YnI+DQo8YnI+DQo8YnI+DQpZb3UncmUga2luZGEgYmV0d2VlbiBh IHJvY2stYW5kLWEtaGFyZC1wbGFjZSBlaXRoZXIgd2F5OiA8YnI+DQo8YnI+DQotIFdlJ3ZlIHNl ZW4gaG93IG11Y2ggZnVuIG9zc2lmaWNhdGlvbiBpcyBpbiBUQ1AgYW5kIEhUVFAuIElmIHRoZSB0 aGluZyBpcyBvYnNlcnZhYmxlLCBpdCB3aWxsIGJlIG9zc2lmaWVkIHNlZW1zIHRvIGJlIHRoZSBs ZXNzb24uIEEgbG90IG9mIHRoZSByZWFzb24gd2h5IFFVSUMgd2FzIHN0YXJ0ZWQgaW4gdGhlIGZp cnN0IHBsYWNlIHdhcyBiZWNhdXNlIG9mIHRoZSBpbmFiaWxpdHkgdG8gaW1wcm92ZSBUQ1AgZHVl IHRvIHRoaXMgb3NzaWZpY2F0aW9uLg0KPGJyPg0KLSBPVE9ILCB0aGVyZSBpcyB0aGUgZmVhciBv ZiB1bmtub3duL3Vub2JzZXJ2YWJsZSB3aGljaCBtaWdodCBjYXVzZSBvcGVyYXRvcnMgdG8gYmxv Y2sgdGhpbmdzLCB3aGV0aGVyIHByZWRpY3RhYmx5IG9yIG5vdC4NCjxicj4NCjxicj4NCk15IG9w aW5pb24gaXMgdGhhdCBpdCBpcyBiZXR0ZXIgdG8gc3RhcnQgd2l0aCBwcmV2ZW50aW5nIG9zc2lm aWNhdGlvbiwgYW5kIHRoZW4gaWYgdGhhdCByZXN1bHRzIGluIHRvbyBsYXJnZSBhIHBlcmNlbnRh Z2Ugb2Ygb3BlcmF0b3JzIGJsb2NraW5nIHRoaW5ncywgdG8gcmUtZXZhbHVhdGUuDQo8YnI+DQo8 YnI+DQpNeSBndWVzc2VzOiA8YnI+DQpJUCYjNDM7cG9ydCB0dXBsZXMgYW5kIHRyYWZmaWMgcGF0 dGVybnMgYXJlIHN0aWxsIG9ic2VydmFibGUgKGZvciBiZXR0ZXIgYW5kIHdvcnNlKSwgd2hpY2gg aW1wbGllcyBvcGVyYXRvcnMgd2lsbCBzdGlsbCBoYXZlIHNpZ25pZmljYW50IHRvb2xzIGZvciBt YW5hZ2luZyB0cmFmZmljLiBJIGJlbGlldmUgdGhhdCB0aGVzZSBhcmUgYWN0ZWQgb24vbWF0Y2hl ZCAoTUwgb3Igbm90KSByZWdhcmRsZXNzIG9mIGFueSBvdGhlciBkYXRhIHByZXNlbnRlZC4gSW4N Cjxicj4NCm90aGVyIHdvcmRzLCBJIGhhdmUgYSBkb3VidCB0aGF0IHN0YXRpbmcgdGhlIHZlcnNp b24gaW4gYW4gb2JzZXJ2YWJsZSB3YXkgd2lsbCBwcmV2ZW50IHRoZSB1c2Ugb2Ygc3VjaCB0b29s cy4NCjxicj4NCjxicj4NCk1vc3QgcHJvYmxlbXMgSSd2ZSBzZWVuIGFzc29jaWF0ZWQgd2l0aCBp bXBsZW1lbnRhdGlvbnMgcmF0aGVyIHRoYW4gcHJvdG9jb2wgdmVyc2lvbnMgKHRob3VnaCB3aGVu IHRoZSBsYXR0ZXIgaGFwcGVucyBpdCBpcyBwcmV0dHkgc2V2ZXJlKS4uIElmIHlvdSBiZWxpZXZl IHRoaXMgYXNzZXJ0aW9uLCB0aGVuIGFjdGluZyBvbiBwcm90b2NvbCB2ZXJzaW9uIGlzIGxlc3Mg aW50ZXJlc3RpbmcgdGhhbiBhdHRlbXB0aW5nIHRvIGFjdCBiYXNlZCBvbiBpbXBsZW1lbnRhdGlv bg0KPGJyPg0KZmluZ2VycHJpbnRzLiA8YnI+DQotPVIgPGJyPg0KPGJyPg0KPGJyPg0KT24gNC8x MC8xOSwgMTo0OCBBTSwgJnF1b3Q7UVVJQyBvbiBiZWhhbGYgb2YgRyBGYWlyaHVyc3QmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGJyPg0KPGEgaHJlZj0i bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIiB0YXJnZXQ9Il9ibGFuayI+Z29ycnlAZXJnLmFi ZG4uYWMuLnVrPC9hPiZndDsgd3JvdGU6DQo8YnI+DQo8YnI+DQpPYnNjdXJpbmcgdGhlIHZlcnNp b24gb2YgYSBwcm90b2NvbCBzZWVtcyBsaWtlIGEgbWFqb3IgZGVzaWduIGRlc2lnbiA8YnI+DQpk ZWNpc2lvbiBmb3Igd2lkZXIgdXNlIGNhc2VzLiBTbywgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5k IHRoZSA8YnI+DQptb3RpdmF0aW9uIGZvciB2ZXJzaW9uIGdyZWFzaW5nLiA8YnI+DQo8YnI+DQoo MSkgSSBrbm93IHRoZXJlIHdlcmUgaW5zdGFuY2VzIHdoZXJlIHNvbWUgZWFybHkgdmVyc2lvbnMg b2YgUVVJQyB3ZXJlIDxicj4NCmJsb2NrZWQgZHVlIHRvIGFuIHVuaW5pdGVudGlvbmFsIG1hdGNo aW5nIG9mIHRoZSBoZWFkZXIuIElzIHRoZXJlIDxicj4NCmV2aWRlbmNlIG9mIGludGVudGlvbmFs IGF0dGVtcHRzIHRvIGJsb2NrIHVwZGF0ZXMgdG8gcHJvdG9jb2xzPyA8YnI+DQo8YnI+DQooMikg VGhpbmtpbmcgYWJvdXQgb3BlcmF0aW5nIGEgbmV0d29yayB0aGF0IGNhcmVzIGFib3V0IHVzZXIg c3VwcG9ydCBhbmQgPGJyPg0KcHJvdGVjdGlvbiBmcm9tIHVud2FudGVkIHRyYWZmaWMsIEkgd291 bGQgZXhwZWN0IHRoYXQgdGhlcmUgd291bGQgYmUgPGJyPg0KY2FzZXMgd2hlcmUgdHJhZmZpYyBw YXR0ZXJuIGFub21vbGllcyBhcmUgZm91bmQgYW5kIHRoZSBhcHByb3ByaWF0ZSA8YnI+DQp0aGlu ZyB3b3VsZCBiZSB0byB0cnkgdG8gZGV0ZXJtaW5lIGlmIGEgbmV3IHByb3RvY29sIGhhZCBiZWVu IGRlcGxveWVkIDxicj4NCmFuZCBtb25pdG9yIGl0LCBpZiBub3QsIHRoZW4gdGhlIG5leHQgbW9z dCBvYnZpb3VzIHRoaW5nIGNvdWxkIGJlIHRvIDxicj4NCmJsb2NrIGFsbCB1bmV4cGVjdGVkIHRy YWZmaWMsIHRoYXQgc2VlbXMgbGlrZSBhIGRlY2lzaW9uIHRvIGhpZGUgdGhlIDxicj4NCnZlcnNp b24gY291bGQgaW5jcmVhc2Ugb3NzaWZpY2F0aW9uIGZvciBuZXcgdmVyc2lvbnMgaW4gdGhlc2Ug Y2FzZXMuLiA8YnI+DQo8YnI+DQooMykgU2ltaWxhcmx5LCBpZiBhIHRocmVhdCBpcyBrbm93biB0 byBpbXBhY3Qgb25seSBhIHNwZWNpZmljIChvbGRlcikgPGJyPg0KdmVyc2lvbiwgaXQgd291bGQg c2VlbSB0byBtb3RpdmF0ZSBhIGRyb3Agb2YgdGhhdCB0cmFmZmljIHRoYXQgc2Vla3MgdG8gPGJy Pg0KdXNlIHRoYXQgdmVyc2lvbiwgd2hpbGUgc3RpbGwgcGVybWl0dGluZyBvdGhlciB0cmFmZmlj LiBGb3JjaW5nIHZlcnNpb24gPGJyPg0KZGV0ZWN0aW9uIHRvIHVzZSBwYXR0ZXJuIG1hdGNoaW5n L01MIHdpbGwgbGVhZCB0byBsZXNzIHByZWRpY3RhYmxlIDxicj4NCm91dGNvbWVzLCBvciBibG9j a2luZyBiYXNlZCBvbiBhZGRyZXNzLCBldGMuIDxicj4NCjxicj4NCig0KSBUaGlzIG9iZnVzdGlj YXRlcyB0aGUgbW9zdCBiYXNpYyBwaWVjZSBvZiByZXBvcnRpbmcgaW5mb3JtYXRpb24gdXNlZCA8 YnI+DQpmb3Igc3VwcG9ydC4gSXQgaGlkZXMgdGhlIGV4dGVudCBvZiBkZXBsb3ltZW50IG9mIHRo ZSBjdXJyZW50IHByb3RvY29sIDxicj4NCnZlcnNpb24gYW5kIHByZXZsYW5jZSBvZiBvbGQgaW1w bGVtZW50YXRpb25zLiA8YnI+DQo8YnI+DQooNSkgT24gdGhlIHN1cHBvcnQsIGlmIGEgcHJvYmxl bSBvbmx5IGVtZXJnZXMgd2hlbiBhIHBhcnRpY3VsYXIgdmVyc2lvbiA8YnI+DQppcyB1c2VkIHdp dGggYSBwYXJ0aWN1bGFyIGFkZHJlc3MsIHRoZW4gdGhpcyBoZWxwcyBwaW5wb2ludCB0aGUgaXNz dWVzLiA8YnI+DQpNYXRjaGluZyBjbGllbnQgdmVyc2lvbnMgdG8gc2VydmVycyBpcyBtdWNoIG1v cmUgb2YgYW4gaXNzdWUgaWYgdGhlIHVzZXIgPGJyPg0KY29tbXVuaXR5IHVzZXMgYSB3aWRlIHJh bmdlIG9mIHNlcnZlcnMgKGxlc3Mgc28sIEkgZXhwZWN0IGZvciBtYWpvciA8YnI+DQpwcm92aWRl cnM6IGdvb2dsZSwgZmFjZWJvb2ssIGV0YywgZXRjKSwgYnV0IHNpZ25pZmljYW50IHdoZW4gdGhl cmUgaXMgYSA8YnI+DQp1c2Ugb2YgYSBkaXZlcnNlIHNldCBvZiBleHRlcm5hbCBzaXRlcyBhbmQg c2l0ZXMgd2l0aCB0aGVpciBvd24gbG9hZCA8YnI+DQpiYWxhbmNlcnMsIGV0YyBhbmQgYSBuZWVk IHRvIG1hbmFnZSBpbnRlcmFjdGlvbnMgd2l0aCBMMiBzZXJ2aWNlcy4gPGJyPg0KPGJyPg0KSSBh bSBpbnRlcnN0ZWQgaW4ga25vd2luZyBpZiB0aGlzIGlzIGxpa2VseSB0byBiZW5lZml0IG9yIGJl IGEgbmV3IG9ic3RhY2xlPyA8YnI+DQo8YnI+DQpHb3JyeSA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_MW2PR2101MB10496C89AF5523D20B753D6CB6280MW2PR2101MB1049_-- From nobody Fri Apr 12 09:14:42 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDC41202EA for ; Fri, 12 Apr 2019 09:14:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 9eJzWZlcisKa for ; Fri, 12 Apr 2019 09:14:39 -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 D86A5120006 for ; Fri, 12 Apr 2019 09:14:29 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx62.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hEyoi-0001pr-FA for quic@ietf.org; Fri, 12 Apr 2019 18:14:19 +0200 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp05.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hEyo3-0002ek-Hd for quic@ietf.org; Fri, 12 Apr 2019 12:14:10 -0400 Received: (qmail 28258 invoked from network); 12 Apr 2019 16:13:34 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.204]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Apr 2019 16:13:33 -0000 To: Ian Swett , Praveen Balasubramanian Cc: "Gorry (erg)" , Roberto Peon , Mirja Kuehlewind , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "quic@ietf.org" , "Border, John" References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> Date: Fri, 12 Apr 2019 09:13:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------383F252D8F60216B31D21C00" Content-Language: en-US Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? X-Originating-IP: 168.144.250.245 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5heXGUEY33L3SuqRq/B1/dh602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVib4FXaeYWzXqH4yGi5ZkOXM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBCnY1T4UEFfy74vbELeG6IB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaIKaP92kYvCAgLvXDsJxwwjBghaQhmflKrDNyY/iPwMaIsqSF1qfykN oXQMKwAQL5iAImxrekFydH4DojSCKJXVXfdz0+Q1eHsqtFQKXUaZ+h596SWGosiQ15/fAFUBngWU swziTuoonQBgr0dS5AZLiwQzKw+6v3CaIMG6s7LqJB5zW4lvOt7yZYITzR9pjE5SyaRgIwuFZktu hI3SFVknr3KOT4rLUOf5LEA9gpTWpQ+EK/9ZZ/oAb/nWI9xFQs3tOuTWXXIj0TpQpfUxR/zGwdBB Bfh3x3VaPNtdo70DPj5Gegm2Di+XkC+U0gjMGGKacOVTXotsdlkDAl5HBq84rNLMkKiSx4DbX99P +gh4iWPT5m4OdqWMdE0b4Joz08+J+cv73CChOPjKA0/DVd830vHLIFSGGMV7x6CHvZpJG/9P/4OG qJ5dkO1xTEy0joEwyGTHIAoNFX+jcW7DGmdEezpuI9IICsCKA/p66v7fhw== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:14:41 -0000 This is a multi-part message in MIME format. --------------383F252D8F60216B31D21C00 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/12/2019 8:57 AM, Ian Swett wrote: > > *From:* Praveen Balasubramanian > *...* > > Version greasing will create problems for DDoS protection. The DDoS > protection middlebox will have to treat all traffic with unknown > version numbers as plain old QUIC and rate limit it. Any solution that > requires per connection state to track version numbers doesn=E2=80=99t = scale. > Especially in the cloud scenario customers bring their own web servers > so this makes any opt-out solution not good enough. So I do think this > is an obstacle for many deployments. > Don't we have an example of middle-box ossification just there? Praveen's example points to the perils of the "shortest path" approach to middle-box design. Taking the shortest path means finding something that works now, and once you have found it deploy it without worry about consequences -- which very often include ossification. If the DDOS protection box looks for "QUIC versions that it knows" and just rate limits the other types of packets, then the box will by design prevent deployment of versions that it does not know. I assume that big organizations like Azure will update their protections once a new version is out, but the experience shows that many other organizations don't. And even when they do, the focus on published versions will block experimenting with new versions, not to mention interfering with other features like connection migration. I take Praveen's example as an argument why we should in fact standardize version greasing, precisely to avoid this "shortest path middle-box design". In the case of DDOS protection, I will point out that DDOS protection also needs to work with short header packets, which do not carry any version number. In order to avoid DDOS by short header packets, the boxes have to be able to distinguish between packets that belong to authorized connections and packets that don't. And if you do that, then you don't really need to look at the version numbers, you can simply rely on the invariants. -- Christian Huitema --------------383F252D8F60216B31D21C00 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 4/12/2019 8:57 AM, Ian Swett wrote:

From: Praveen Balasubramanian
...

Version greasing will create problems for DDoS protection. The DDoS protection middlebox will have to treat all traffic with unknown version numbers as plain old QUIC and rate limit it. Any solution that requires per connection state to track version numbers doesn’t scale. Especially in the cloud scenario customers bring their own web servers so this makes any opt-out solution not good enough. So I do think this is an obstacle for many deployments.

Don't we have an example of middle-box ossification just there?

Praveen's example points to the perils of the "shortest path" approach to middle-box design. Taking the shortest path means finding something that works now, and once you have found it deploy it without worry about consequences -- which very often include ossification. If the DDOS protection box looks for "QUIC versions that it knows" and just rate limits the other types of packets, then the box will by design prevent deployment of versions that it does not know.

I assume that big organizations like Azure will update their protections once a new version is out, but the experience shows that many other organizations don't. And even when they do, the focus on published versions will block experimenting with new versions, not to mention interfering with other features like connection migration. I take Praveen's example as an argument why we should in fact standardize version greasing, precisely to avoid this "shortest path middle-box design".

In the case of DDOS protection, I will point out that DDOS protection also needs to work with short header packets, which do not carry any version number. In order to avoid DDOS by short header packets, the boxes have to be able to distinguish between packets that belong to authorized connections and packets that don't. And if you do that, then you don't really need to look at the version numbers, you can simply rely on the invariants.

-- Christian Huitema

--------------383F252D8F60216B31D21C00-- From nobody Fri Apr 12 09:16:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEEC1202F4 for ; Fri, 12 Apr 2019 09:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, 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 (1024-bit key) header.d=fb.com header.b=QdgJ2stn; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=YH2fHmzJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDM-juqlQleB for ; Fri, 12 Apr 2019 09:16:15 -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 DFF621200D7 for ; Fri, 12 Apr 2019 09:16:14 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.27/8.16.0.27) with SMTP id x3CGELDA005076; Fri, 12 Apr 2019 09:15:56 -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=AcFl6zLDFjOpoOYJUvHedLClhBV08NVyxryqFGIIcYc=; b=QdgJ2stnPko3vr5DL1oKlPIjSM+JNzaNOwbRUQr/cpGOTFrHST/JrG7ygJ56nZo3pYz3 2IVzsKm/BKqe2fw6Xd03wOicDqwKxMNk8vRIAQ33W7Jul+4Ss2NQXQNgs3R45bOxk9CZ i9JQhLQdMoTJwfdxqv8xEWMHw2TqhagUHXM= Received: from mail.thefacebook.com (mailout.thefacebook.com [199.201.64.23]) by m0001303.ppops.net with ESMTP id 2rtfspa7mr-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 12 Apr 2019 09:15:56 -0700 Received: from prn-hub03.TheFacebook.com (2620:10d:c081:35::127) by prn-hub04.TheFacebook.com (2620:10d:c081:35::128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 12 Apr 2019 09:15:53 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5 via Frontend Transport; Fri, 12 Apr 2019 09:15:53 -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:X-MS-Exchange-SenderADCheck; bh=AcFl6zLDFjOpoOYJUvHedLClhBV08NVyxryqFGIIcYc=; b=YH2fHmzJOy52j3tAQ/Pn6W8e06doZRnNG/ywoQXY8DbcrEHrCTMhWJF9BfOF2qZG315EaNxxGU7JhU+oP1qwtB2mXYYQsCEAEyd8D3kNIPJDRmJbvlEAQ58FXWE2w3qut3NASjEItEd++dm/wGdxgeCfNBplA98gfU6rE92CP3o= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB3237.namprd15.prod.outlook.com (20.179.57.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Fri, 12 Apr 2019 16:15:51 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7%2]) with mapi id 15.20.1771.021; Fri, 12 Apr 2019 16:15:51 +0000 From: Roberto Peon To: Christian Huitema , Ian Swett , Praveen Balasubramanian CC: "Gorry (erg)" , Mirja Kuehlewind , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , "Border, John" Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o3xTufubPn9E2URSuto2uLa6Y1JwYAgAB3W4CAAAdsgIAADYwAgAAcxQCAAMrxAIAABNWAgAIQ3wCAAACXAIAAAIaAgAAEgoD//4tNAA== Date: Fri, 12 Apr 2019 16:15:51 +0000 Message-ID: <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> In-Reply-To: <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 x-originating-ip: [2620:10d:c090:200::1ab6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca072af8-96be-430e-fd7e-08d6bf622205 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR15MB3237; x-ms-traffictypediagnostic: BYAPR15MB3237: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(366004)(346002)(136003)(199004)(189003)(6486002)(6246003)(66574012)(6436002)(54906003)(2616005)(11346002)(6116002)(229853002)(6306002)(53936002)(2906002)(25786009)(110136005)(6512007)(58126008)(36756003)(4326008)(486006)(97736004)(33656002)(68736007)(54896002)(46003)(6506007)(446003)(53546011)(186003)(102836004)(5660300002)(76176011)(105586002)(14454004)(81166006)(81156014)(8936002)(71190400001)(106356001)(476003)(99286004)(316002)(82746002)(478600001)(256004)(7736002)(83716004)(71200400001)(14444005)(8676002)(86362001)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB3237; H:BYAPR15MB2312.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BJG9BdmBO+zkzQjg1vl/71aXW/FEBpzgITOJ8MFSpRHyQCLZOWuRPsB3xwW4fklfdYLJxhMxZoBDqVL/kt1mSELMILoV341T+U7dY1eTsOuFv+BIwlmMy13vYhufiTnB5Y78VkUOnlnMXH1UNNOe4Vl/7mYnc6Y03SjjtnF5LklKjvkUamErm+df5EUBYd98Yj6AIeOn7dHV2x0C68wV+SuRi4QWe82A3EJSFEkMxa4ELyYlO6SopESOIpDuveO4t3M0KwfotOKGaSWamuuIzbzeP3j3wNf72Q99LXQzS3hp6hOcP+U4Q3DPFGmpXmo72GUW7vpC39BVwE/ekls8Hn6qKgCNnda6Ya9ZPGgBb4PrLtkLfE9Qeje2VJqVN+ipnTMyS3d8j2FxGdEuse1mLjdts1dIshyT0+NS3kDK+x0= Content-Type: multipart/alternative; boundary="_000_9C6D92FF763548BDA65BFAB4B544476Dfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ca072af8-96be-430e-fd7e-08d6bf622205 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 16:15:51.6280 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3237 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-12_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:16:17 -0000 --_000_9C6D92FF763548BDA65BFAB4B544476Dfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIGFueSBsYXJnZSBkZXBsb3ltZW50LCBJIHN1c3BlY3QgdGhleeKAmWxsIG5lZWQgTEIuDQoN CkZvciBtb3N0IGtpbmRzIG9mIExCLWluZywgSeKAmWQgZXhwZWN0IHRoZSBMQiBzeXN0ZW0gdG8g ZWl0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkgYmUgaW52b2x2ZWQgaW4gY2hvb3NpbmcvdmVu ZGluZyBjb25uZWN0aW9uIElEcy4NCg0KSWYgaXQgaXMgaW52b2x2ZWQgaW4gdmVuZGluZy9jaG9v c2luZyBjb25uZWN0aW9uIElEcywgaXQgY2FuIGVuY29kZSB2ZXJzaW9uIGluZm9ybWF0aW9uIGlu dG8gdGhlIENJRC4NCg0KLT1SDQoNCkZyb206IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1 aXRlbWEubmV0Pg0KRGF0ZTogRnJpZGF5LCBBcHJpbCAxMiwgMjAxOSBhdCA5OjEzIEFNDQpUbzog SWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+LCBQcmF2ZWVu IEJhbGFzdWJyYW1hbmlhbiA8cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPg0K Q2M6ICJHb3JyeSAoZXJnKSIgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPiwgUm9iZXJ0byBQZW9uIDxm ZW5peEBmYi5jb20+LCBNaXJqYSBLdWVobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQGVyaWNzc29u LmNvbT4sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4sICJx dWljQGlldGYub3JnIiA8cXVpY0BpZXRmLm9yZz4sICJCb3JkZXIsIEpvaG4iIDxqb2huLmJvcmRl ckBodWdoZXMuY29tPg0KU3ViamVjdDogUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBi ZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/DQoNCg0KDQpPbiA0LzEyLzIwMTkgODo1NyBBTSwgSWFu IFN3ZXR0IHdyb3RlOg0KRnJvbTogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NCi4uLg0KVmVyc2lv biBncmVhc2luZyB3aWxsIGNyZWF0ZSBwcm9ibGVtcyBmb3IgRERvUyBwcm90ZWN0aW9uLiBUaGUg RERvUyBwcm90ZWN0aW9uIG1pZGRsZWJveCB3aWxsIGhhdmUgdG8gdHJlYXQgYWxsIHRyYWZmaWMg d2l0aCB1bmtub3duIHZlcnNpb24gbnVtYmVycyBhcyBwbGFpbiBvbGQgUVVJQyBhbmQgcmF0ZSBs aW1pdCBpdC4gQW55IHNvbHV0aW9uIHRoYXQgcmVxdWlyZXMgcGVyIGNvbm5lY3Rpb24gc3RhdGUg dG8gdHJhY2sgdmVyc2lvbiBudW1iZXJzIGRvZXNu4oCZdCBzY2FsZS4gRXNwZWNpYWxseSBpbiB0 aGUgY2xvdWQgc2NlbmFyaW8gY3VzdG9tZXJzIGJyaW5nIHRoZWlyIG93biB3ZWIgc2VydmVycyBz byB0aGlzIG1ha2VzIGFueSBvcHQtb3V0IHNvbHV0aW9uIG5vdCBnb29kIGVub3VnaC4gU28gSSBk byB0aGluayB0aGlzIGlzIGFuIG9ic3RhY2xlIGZvciBtYW55IGRlcGxveW1lbnRzLg0KDQpEb24n dCB3ZSBoYXZlIGFuIGV4YW1wbGUgb2YgbWlkZGxlLWJveCBvc3NpZmljYXRpb24ganVzdCB0aGVy ZT8NCg0KUHJhdmVlbidzIGV4YW1wbGUgcG9pbnRzIHRvIHRoZSBwZXJpbHMgb2YgdGhlICJzaG9y dGVzdCBwYXRoIiBhcHByb2FjaCB0byBtaWRkbGUtYm94IGRlc2lnbi4gVGFraW5nIHRoZSBzaG9y dGVzdCBwYXRoIG1lYW5zIGZpbmRpbmcgc29tZXRoaW5nIHRoYXQgd29ya3Mgbm93LCBhbmQgb25j ZSB5b3UgaGF2ZSBmb3VuZCBpdCBkZXBsb3kgaXQgd2l0aG91dCB3b3JyeSBhYm91dCBjb25zZXF1 ZW5jZXMgLS0gd2hpY2ggdmVyeSBvZnRlbiBpbmNsdWRlIG9zc2lmaWNhdGlvbi4gSWYgdGhlIERE T1MgcHJvdGVjdGlvbiBib3ggbG9va3MgZm9yICJRVUlDIHZlcnNpb25zIHRoYXQgaXQga25vd3Mi IGFuZCBqdXN0IHJhdGUgbGltaXRzIHRoZSBvdGhlciB0eXBlcyBvZiBwYWNrZXRzLCB0aGVuIHRo ZSBib3ggd2lsbCBieSBkZXNpZ24gcHJldmVudCBkZXBsb3ltZW50IG9mIHZlcnNpb25zIHRoYXQg aXQgZG9lcyBub3Qga25vdy4NCg0KSSBhc3N1bWUgdGhhdCBiaWcgb3JnYW5pemF0aW9ucyBsaWtl IEF6dXJlIHdpbGwgdXBkYXRlIHRoZWlyIHByb3RlY3Rpb25zIG9uY2UgYSBuZXcgdmVyc2lvbiBp cyBvdXQsIGJ1dCB0aGUgZXhwZXJpZW5jZSBzaG93cyB0aGF0IG1hbnkgb3RoZXIgb3JnYW5pemF0 aW9ucyBkb24ndC4gQW5kIGV2ZW4gd2hlbiB0aGV5IGRvLCB0aGUgZm9jdXMgb24gcHVibGlzaGVk IHZlcnNpb25zIHdpbGwgYmxvY2sgZXhwZXJpbWVudGluZyB3aXRoIG5ldyB2ZXJzaW9ucywgbm90 IHRvIG1lbnRpb24gaW50ZXJmZXJpbmcgd2l0aCBvdGhlciBmZWF0dXJlcyBsaWtlIGNvbm5lY3Rp b24gbWlncmF0aW9uLiBJIHRha2UgUHJhdmVlbidzIGV4YW1wbGUgYXMgYW4gYXJndW1lbnQgd2h5 IHdlIHNob3VsZCBpbiBmYWN0IHN0YW5kYXJkaXplIHZlcnNpb24gZ3JlYXNpbmcsIHByZWNpc2Vs eSB0byBhdm9pZCB0aGlzICJzaG9ydGVzdCBwYXRoIG1pZGRsZS1ib3ggZGVzaWduIi4NCg0KSW4g dGhlIGNhc2Ugb2YgRERPUyBwcm90ZWN0aW9uLCBJIHdpbGwgcG9pbnQgb3V0IHRoYXQgRERPUyBw cm90ZWN0aW9uIGFsc28gbmVlZHMgdG8gd29yayB3aXRoIHNob3J0IGhlYWRlciBwYWNrZXRzLCB3 aGljaCBkbyBub3QgY2FycnkgYW55IHZlcnNpb24gbnVtYmVyLiBJbiBvcmRlciB0byBhdm9pZCBE RE9TIGJ5IHNob3J0IGhlYWRlciBwYWNrZXRzLCB0aGUgYm94ZXMgaGF2ZSB0byBiZSBhYmxlIHRv IGRpc3Rpbmd1aXNoIGJldHdlZW4gcGFja2V0cyB0aGF0IGJlbG9uZyB0byBhdXRob3JpemVkIGNv bm5lY3Rpb25zIGFuZCBwYWNrZXRzIHRoYXQgZG9uJ3QuIEFuZCBpZiB5b3UgZG8gdGhhdCwgdGhl biB5b3UgZG9uJ3QgcmVhbGx5IG5lZWQgdG8gbG9vayBhdCB0aGUgdmVyc2lvbiBudW1iZXJzLCB5 b3UgY2FuIHNpbXBseSByZWx5IG9uIHRoZSBpbnZhcmlhbnRzLg0KDQotLSBDaHJpc3RpYW4gSHVp dGVtYQ0K --_000_9C6D92FF763548BDA65BFAB4B544476Dfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <602C40DB499F514688F0F307AC03B739@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDIgMyAzIDIgMjt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgYW55IGxhcmdlIGRlcGxveW1lbnQsIEkg c3VzcGVjdCB0aGV54oCZbGwgbmVlZCBMQi48YnI+DQo8YnI+DQpGb3IgbW9zdCBraW5kcyBvZiBM Qi1pbmcsIEnigJlkIGV4cGVjdCB0aGUgTEIgc3lzdGVtIHRvIGVpdGhlciBkaXJlY3RseSBvciBp bmRpcmVjdGx5IGJlIGludm9sdmVkIGluIGNob29zaW5nL3ZlbmRpbmcgY29ubmVjdGlvbiBJRHMu PGJyPg0KPGJyPg0KSWYgaXQgaXMgaW52b2x2ZWQgaW4gdmVuZGluZy9jaG9vc2luZyBjb25uZWN0 aW9uIElEcywgaXQgY2FuIGVuY29kZSB2ZXJzaW9uIGluZm9ybWF0aW9uIGludG8gdGhlIENJRC48 YnI+DQo8YnI+DQotPVI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZy b206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkNocmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5GcmlkYXksIEFwcmlsIDEyLCAyMDE5IGF0IDk6MTMgQU08YnI+DQo8Yj5UbzogPC9i PklhbiBTd2V0dCAmbHQ7aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnJmd0Oywg UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p ZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O0dvcnJ5IChlcmcpJnF1b3Q7ICZsdDtn b3JyeUBlcmcuYWJkbi5hYy51ayZndDssIFJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0 OywgTWlyamEgS3VlaGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20mZ3Q7 LCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7LCAm cXVvdDtxdWljQGlldGYub3JnJnF1b3Q7ICZsdDtxdWljQGlldGYub3JnJmd0OywgJnF1b3Q7Qm9y ZGVyLCBKb2huJnF1b3Q7ICZsdDtqb2huLmJvcmRlckBodWdoZXMuY29tJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogSXMgJnF1b3Q7VmVyc2lvbiBHcmVhc2luZyZxdW90OyBhIG5ldyBiZW5m aXQgb3IgYSBuZXcgb2JzdGFjbGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQv MTIvMjAxOSA4OjU3IEFNLCBJYW4gU3dldHQgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+RnJvbTo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQo8YnI+DQo8Yj4uLi48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5W ZXJzaW9uIGdyZWFzaW5nIHdpbGwgY3JlYXRlIHByb2JsZW1zIGZvciBERG9TIHByb3RlY3Rpb24u IFRoZSBERG9TIHByb3RlY3Rpb24gbWlkZGxlYm94IHdpbGwgaGF2ZSB0byB0cmVhdCBhbGwgdHJh ZmZpYyB3aXRoIHVua25vd24gdmVyc2lvbiBudW1iZXJzIGFzIHBsYWluIG9sZCBRVUlDIGFuZCBy YXRlIGxpbWl0DQogaXQuIEFueSBzb2x1dGlvbiB0aGF0IHJlcXVpcmVzIHBlciBjb25uZWN0aW9u IHN0YXRlIHRvIHRyYWNrIHZlcnNpb24gbnVtYmVycyBkb2VzbuKAmXQgc2NhbGUuIEVzcGVjaWFs bHkgaW4gdGhlIGNsb3VkIHNjZW5hcmlvIGN1c3RvbWVycyBicmluZyB0aGVpciBvd24gd2ViIHNl cnZlcnMgc28gdGhpcyBtYWtlcyBhbnkgb3B0LW91dCBzb2x1dGlvbiBub3QgZ29vZCBlbm91Z2gu IFNvIEkgZG8gdGhpbmsgdGhpcyBpcyBhbiBvYnN0YWNsZSBmb3IgbWFueQ0KIGRlcGxveW1lbnRz LiA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPkRvbid0IHdlIGhhdmUgYW4gZXhh bXBsZSBvZiBtaWRkbGUtYm94IG9zc2lmaWNhdGlvbiBqdXN0IHRoZXJlPzxvOnA+PC9vOnA+PC9w Pg0KPHA+UHJhdmVlbidzIGV4YW1wbGUgcG9pbnRzIHRvIHRoZSBwZXJpbHMgb2YgdGhlICZxdW90 O3Nob3J0ZXN0IHBhdGgmcXVvdDsgYXBwcm9hY2ggdG8gbWlkZGxlLWJveCBkZXNpZ24uIFRha2lu ZyB0aGUgc2hvcnRlc3QgcGF0aCBtZWFucyBmaW5kaW5nIHNvbWV0aGluZyB0aGF0IHdvcmtzIG5v dywgYW5kIG9uY2UgeW91IGhhdmUgZm91bmQgaXQgZGVwbG95IGl0IHdpdGhvdXQgd29ycnkgYWJv dXQgY29uc2VxdWVuY2VzIC0tIHdoaWNoIHZlcnkgb2Z0ZW4gaW5jbHVkZQ0KIG9zc2lmaWNhdGlv bi4gSWYgdGhlIERET1MgcHJvdGVjdGlvbiBib3ggbG9va3MgZm9yICZxdW90O1FVSUMgdmVyc2lv bnMgdGhhdCBpdCBrbm93cyZxdW90OyBhbmQganVzdCByYXRlIGxpbWl0cyB0aGUgb3RoZXIgdHlw ZXMgb2YgcGFja2V0cywgdGhlbiB0aGUgYm94IHdpbGwgYnkgZGVzaWduIHByZXZlbnQgZGVwbG95 bWVudCBvZiB2ZXJzaW9ucyB0aGF0IGl0IGRvZXMgbm90IGtub3cuDQo8bzpwPjwvbzpwPjwvcD4N CjxwPkkgYXNzdW1lIHRoYXQgYmlnIG9yZ2FuaXphdGlvbnMgbGlrZSBBenVyZSB3aWxsIHVwZGF0 ZSB0aGVpciBwcm90ZWN0aW9ucyBvbmNlIGEgbmV3IHZlcnNpb24gaXMgb3V0LCBidXQgdGhlIGV4 cGVyaWVuY2Ugc2hvd3MgdGhhdCBtYW55IG90aGVyIG9yZ2FuaXphdGlvbnMgZG9uJ3QuIEFuZCBl dmVuIHdoZW4gdGhleSBkbywgdGhlIGZvY3VzIG9uIHB1Ymxpc2hlZCB2ZXJzaW9ucyB3aWxsIGJs b2NrIGV4cGVyaW1lbnRpbmcgd2l0aCBuZXcgdmVyc2lvbnMsDQogbm90IHRvIG1lbnRpb24gaW50 ZXJmZXJpbmcgd2l0aCBvdGhlciBmZWF0dXJlcyBsaWtlIGNvbm5lY3Rpb24gbWlncmF0aW9uLiBJ IHRha2UgUHJhdmVlbidzIGV4YW1wbGUgYXMgYW4gYXJndW1lbnQgd2h5IHdlIHNob3VsZCBpbiBm YWN0IHN0YW5kYXJkaXplIHZlcnNpb24gZ3JlYXNpbmcsIHByZWNpc2VseSB0byBhdm9pZCB0aGlz ICZxdW90O3Nob3J0ZXN0IHBhdGggbWlkZGxlLWJveCBkZXNpZ24mcXVvdDsuDQo8bzpwPjwvbzpw PjwvcD4NCjxwPkluIHRoZSBjYXNlIG9mIERET1MgcHJvdGVjdGlvbiwgSSB3aWxsIHBvaW50IG91 dCB0aGF0IERET1MgcHJvdGVjdGlvbiBhbHNvIG5lZWRzIHRvIHdvcmsgd2l0aCBzaG9ydCBoZWFk ZXIgcGFja2V0cywgd2hpY2ggZG8gbm90IGNhcnJ5IGFueSB2ZXJzaW9uIG51bWJlci4gSW4gb3Jk ZXIgdG8gYXZvaWQgRERPUyBieSBzaG9ydCBoZWFkZXIgcGFja2V0cywgdGhlIGJveGVzIGhhdmUg dG8gYmUgYWJsZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHBhY2tldHMNCiB0aGF0IGJlbG9uZyB0 byBhdXRob3JpemVkIGNvbm5lY3Rpb25zIGFuZCBwYWNrZXRzIHRoYXQgZG9uJ3QuIEFuZCBpZiB5 b3UgZG8gdGhhdCwgdGhlbiB5b3UgZG9uJ3QgcmVhbGx5IG5lZWQgdG8gbG9vayBhdCB0aGUgdmVy c2lvbiBudW1iZXJzLCB5b3UgY2FuIHNpbXBseSByZWx5IG9uIHRoZSBpbnZhcmlhbnRzLjxvOnA+ PC9vOnA+PC9wPg0KPHA+LS0gQ2hyaXN0aWFuIEh1aXRlbWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9C6D92FF763548BDA65BFAB4B544476Dfbcom_-- From nobody Fri Apr 12 09:28:22 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2801201B6 for ; Fri, 12 Apr 2019 09:28:21 -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, DKIMWL_WL_HIGH=-0.001, 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 OC0wv6oc7iSw for ; Fri, 12 Apr 2019 09:28:18 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730133.outbound.protection.outlook.com [40.107.73.133]) (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 BF61F1202E7 for ; Fri, 12 Apr 2019 09:28:17 -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:X-MS-Exchange-SenderADCheck; bh=KwHeuEFdZhJdSRmWeXEBh3S6LdS6ElMNpR/eekL5xmY=; b=Qb6qBIfMJL31qbA/2WHzPA7T01U/GD/HwIr6yqCjB/w1GrcOR4My9T0QJIMaLndEcRPiukG5hCsZsFiNphYM9e21tcfT685jTcklWdM9C6si6lZ55Mp4vwWqJZHi0xdvl032sIm5XSrdXuCLKztlYGDRWbByd8EowVha3/ZzVBQ= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1132.namprd21.prod.outlook.com (52.132.146.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.8; Fri, 12 Apr 2019 16:28:15 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c999:100b:9952:f8f6]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::c999:100b:9952:f8f6%5]) with mapi id 15.20.1813.000; Fri, 12 Apr 2019 16:28:15 +0000 From: Praveen Balasubramanian To: Roberto Peon , Christian Huitema , Ian Swett CC: "Gorry (erg)" , Mirja Kuehlewind , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , "Border, John" Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o0AOSUW1ZVWEa1WA8MStgy7KY1nGCAgAACAYCAAAdsgIAADYwAgAAcxQCAAMrxAIAABNWAgAIQK4CAAADVYIAAAPyAgAAEgoCAAACngIAAAFbg Date: Fri, 12 Apr 2019 16:28:15 +0000 Message-ID: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> In-Reply-To: <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:0:21b3:7b4b:b4a3:c3bf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9ed65b2a-516c-46b8-5fde-08d6bf63dd6d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB1132; x-ms-traffictypediagnostic: MW2PR2101MB1132: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(136003)(376002)(366004)(199004)(189003)(8676002)(9686003)(86612001)(316002)(55016002)(25786009)(6306002)(4326008)(54896002)(10290500003)(229853002)(7696005)(99286004)(86362001)(54906003)(53936002)(110136005)(93886005)(14444005)(790700001)(6116002)(14454004)(2906002)(6436002)(71200400001)(10090500001)(71190400001)(5660300002)(256004)(6246003)(236005)(478600001)(66574012)(22452003)(52536014)(8990500004)(11346002)(486006)(97736004)(446003)(476003)(102836004)(6506007)(53546011)(68736007)(76176011)(186003)(74316002)(8936002)(81166006)(7736002)(46003)(33656002)(106356001)(81156014)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1132; H:MW2PR2101MB1049.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: inxANhLtlXhormO087aE6ySK+1+xDnLtfv2j0dViE0gU1ajAJvAZ+OHcv0Td/k0PW/00jPDL+oNHaq/f5m6sAve7PD9VgOIYm6/J63MXQv+A/w2PGEnwsdJiuz17iCvwUqkveEoaKNzswc5W84pv1EVQOudnVQAGzgy9ZCITpihQvHbs9vd0kH/vkBO45ijscAt3HT0lCGaweGBIMxVwongFnAtQ6YQR04jSGUlnBqGsC+yCSmAqo99dNJiqvLXhkgdql/LSdzUD0ddmUMZGjhKYUgEyY2DK/SAZAvjjaFJLCVwLxSiHy9ACst1AQJMn9ZUX3kVkQBA6wB/iHTk3eqdyXWh/H3ohnV3jUH2V3VKMi8zdTKAXE6oGiCjFu4UrpkAz9zfHOEidHMDaNnRtK15CpfHCbwZ403sDYtOGW2A= Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB10498605DC0F1FC3905865F4B6280MW2PR2101MB1049_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ed65b2a-516c-46b8-5fde-08d6bf63dd6d X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 16:28:15.6644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1132 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:28:21 -0000 --_000_MW2PR2101MB10498605DC0F1FC3905865F4B6280MW2PR2101MB1049_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUuIEVuY29kaW5nIGluIENJRC4gVGhlbiBpdCBuZWVkcyB0byBiZSBzdGFuZGFyZGl6ZWQgYW5k IGlmIGl0IGlzIHN0YW5kYXJkaXplZCB3aGF04oCZcyB0aGUgcG9pbnQgaW4gZ3JlYXNpbmc/IExl dOKAmXMgbm90IGlnbm9yZSB0aGUgc21hbGxlciBzZXJ2aWNlcyB3aG8gdXNlIHRoZSBjbG91ZCBp LmUuIHBlb3BsZSBkZXBsb3lpbmcgc2F5IE5HSU5YIHdlYiBzZXJ2ZXJzIGluIEFXUywgQXp1cmUg b3IgR0NQLiBOb3QgZXZlcnkgUVVJQyBkZXBsb3ltZW50IGlzIGEgbGFyZ2UgZmlyc3QgcGFydHkg c2VydmljZSB3aGljaCBjb250cm9scyBhbGwgYXNwZWN0cyBob3cgTEIgYW5kIEREb1MgYXJlIGRv bmUuIEluIHB1YmxpYyBjbG91ZHMgTEIgYW5kIEREb1MgcHJvdGVjdGlvbiBhcmUgbmV0d29yayBm dW5jdGlvbnMgKHNlcnZpY2VzKSBhbmQgYXJlIG1pZGRsZWJveGVzIHVuZGVyIGEgY29tcGxldGVs eSBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KDQpDaHJpc3RpYW4sIHRoaXMgaXMg YWJvdXQgc291cmNlIGFkZHJlc3MgdmFsaWRhdGlvbiBieSB0aGUgbWlkZGxlYm94LiBUaGlzIGlz IGhvdyBpdCB3b3JrcyBmb3IgVENQICh0aGluayBTWU4gY29va2llcykgYW5kIHdlIG5lZWQgdG8g aGF2ZSBwYXJpdHkgZm9yIFFVSUMuIFdoZW4gdW5kZXIgYXR0YWNrLCBzaG9ydCBoZWFkZXIgcGFj a2V0cyB3aWxsIGJlIGRyb3BwZWQgZm9yIGFkZHJlc3NlcyB0aGF0IGhhdmUgbm90IGJlZW4gdmFs aWRhdGVkLCBidXQgdGhpcyBpcyB0aGUgc2FtZSBmb3Igbm9uLVNZTiBwYWNrZXRzIGZvciBUQ1Au IEkgZG9u4oCZdCB1bmRlcnN0YW5kIGhvdyBpbnZhcmlhbnRzIGNhbiBiZSB1c2VkIGhlcmUuIElm IHdlIGRvbuKAmXQgaGF2ZSBwYXJpdHkgZm9yIERvUyBwcm90ZWN0aW9uIGluIG5ldHdvcmsgdGhl biBRVUlDIHRyYWZmaWMgd2lsbCBiZSByYXRlIGxpbWl0ZWQgd2hpY2ggaXMgZ29pbmcgdG8gYmUg cmVhbGx5IGJhZCBmb3IgcGVyZm9ybWFuY2UuIEZXSVcgdGhlcmUgaXMgYWxyZWFkeSBEb1MgdHJh ZmZpYyB0aGF0IGxvb2tzIGxpa2UgUVVJQy4NCg0KRnJvbTogUm9iZXJ0byBQZW9uIDxmZW5peEBm Yi5jb20+DQpTZW50OiBGcmlkYXksIEFwcmlsIDEyLCAyMDE5IDk6MTYgQU0NClRvOiBDaHJpc3Rp YW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29v Z2xlLmNvbT47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPg0K Q2M6IEdvcnJ5IChlcmcpIDxnb3JyeUBlcmcuYWJkbi5hYy51az47IE1pcmphIEt1ZWhsZXdpbmQg PG1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPjsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNl biA8bWlra2VsZmpAZ21haWwuY29tPjsgcXVpY0BpZXRmLm9yZzsgQm9yZGVyLCBKb2huIDxqb2hu LmJvcmRlckBodWdoZXMuY29tPg0KU3ViamVjdDogUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBh IG5ldyBiZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/DQoNCkZvciBhbnkgbGFyZ2UgZGVwbG95bWVu dCwgSSBzdXNwZWN0IHRoZXnigJlsbCBuZWVkIExCLg0KDQpGb3IgbW9zdCBraW5kcyBvZiBMQi1p bmcsIEnigJlkIGV4cGVjdCB0aGUgTEIgc3lzdGVtIHRvIGVpdGhlciBkaXJlY3RseSBvciBpbmRp cmVjdGx5IGJlIGludm9sdmVkIGluIGNob29zaW5nL3ZlbmRpbmcgY29ubmVjdGlvbiBJRHMuDQoN CklmIGl0IGlzIGludm9sdmVkIGluIHZlbmRpbmcvY2hvb3NpbmcgY29ubmVjdGlvbiBJRHMsIGl0 IGNhbiBlbmNvZGUgdmVyc2lvbiBpbmZvcm1hdGlvbiBpbnRvIHRoZSBDSUQuDQoNCi09Ug0KDQpG cm9tOiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVt YUBodWl0ZW1hLm5ldD4+DQpEYXRlOiBGcmlkYXksIEFwcmlsIDEyLCAyMDE5IGF0IDk6MTMgQU0N ClRvOiBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4sIFByYXZlZW4gQmFsYXN1 YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnBy YXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpDYzogIkdvcnJ5IChlcmcpIiA8 Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj4sIFJvYmVy dG8gUGVvbiA8ZmVuaXhAZmIuY29tPG1haWx0bzpmZW5peEBmYi5jb20+PiwgTWlyamEgS3VlaGxl d2luZCA8bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb208bWFpbHRvOm1pcmphLmt1ZWhsZXdp bmRAZXJpY3Nzb24uY29tPj4sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdt YWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4sICJxdWljQGlldGYub3JnPG1haWx0 bzpxdWljQGlldGYub3JnPiIgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Piwg IkJvcmRlciwgSm9obiIgPGpvaG4uYm9yZGVyQGh1Z2hlcy5jb208bWFpbHRvOmpvaG4uYm9yZGVy QGh1Z2hlcy5jb20+Pg0KU3ViamVjdDogUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBi ZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/DQoNCg0KDQpPbiA0LzEyLzIwMTkgODo1NyBBTSwgSWFu IFN3ZXR0IHdyb3RlOg0KRnJvbTogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NCi4uLg0KVmVyc2lv biBncmVhc2luZyB3aWxsIGNyZWF0ZSBwcm9ibGVtcyBmb3IgRERvUyBwcm90ZWN0aW9uLiBUaGUg RERvUyBwcm90ZWN0aW9uIG1pZGRsZWJveCB3aWxsIGhhdmUgdG8gdHJlYXQgYWxsIHRyYWZmaWMg d2l0aCB1bmtub3duIHZlcnNpb24gbnVtYmVycyBhcyBwbGFpbiBvbGQgUVVJQyBhbmQgcmF0ZSBs aW1pdCBpdC4gQW55IHNvbHV0aW9uIHRoYXQgcmVxdWlyZXMgcGVyIGNvbm5lY3Rpb24gc3RhdGUg dG8gdHJhY2sgdmVyc2lvbiBudW1iZXJzIGRvZXNu4oCZdCBzY2FsZS4gRXNwZWNpYWxseSBpbiB0 aGUgY2xvdWQgc2NlbmFyaW8gY3VzdG9tZXJzIGJyaW5nIHRoZWlyIG93biB3ZWIgc2VydmVycyBz byB0aGlzIG1ha2VzIGFueSBvcHQtb3V0IHNvbHV0aW9uIG5vdCBnb29kIGVub3VnaC4gU28gSSBk byB0aGluayB0aGlzIGlzIGFuIG9ic3RhY2xlIGZvciBtYW55IGRlcGxveW1lbnRzLg0KDQpEb24n dCB3ZSBoYXZlIGFuIGV4YW1wbGUgb2YgbWlkZGxlLWJveCBvc3NpZmljYXRpb24ganVzdCB0aGVy ZT8NCg0KUHJhdmVlbidzIGV4YW1wbGUgcG9pbnRzIHRvIHRoZSBwZXJpbHMgb2YgdGhlICJzaG9y dGVzdCBwYXRoIiBhcHByb2FjaCB0byBtaWRkbGUtYm94IGRlc2lnbi4gVGFraW5nIHRoZSBzaG9y dGVzdCBwYXRoIG1lYW5zIGZpbmRpbmcgc29tZXRoaW5nIHRoYXQgd29ya3Mgbm93LCBhbmQgb25j ZSB5b3UgaGF2ZSBmb3VuZCBpdCBkZXBsb3kgaXQgd2l0aG91dCB3b3JyeSBhYm91dCBjb25zZXF1 ZW5jZXMgLS0gd2hpY2ggdmVyeSBvZnRlbiBpbmNsdWRlIG9zc2lmaWNhdGlvbi4gSWYgdGhlIERE T1MgcHJvdGVjdGlvbiBib3ggbG9va3MgZm9yICJRVUlDIHZlcnNpb25zIHRoYXQgaXQga25vd3Mi IGFuZCBqdXN0IHJhdGUgbGltaXRzIHRoZSBvdGhlciB0eXBlcyBvZiBwYWNrZXRzLCB0aGVuIHRo ZSBib3ggd2lsbCBieSBkZXNpZ24gcHJldmVudCBkZXBsb3ltZW50IG9mIHZlcnNpb25zIHRoYXQg aXQgZG9lcyBub3Qga25vdy4NCg0KSSBhc3N1bWUgdGhhdCBiaWcgb3JnYW5pemF0aW9ucyBsaWtl IEF6dXJlIHdpbGwgdXBkYXRlIHRoZWlyIHByb3RlY3Rpb25zIG9uY2UgYSBuZXcgdmVyc2lvbiBp cyBvdXQsIGJ1dCB0aGUgZXhwZXJpZW5jZSBzaG93cyB0aGF0IG1hbnkgb3RoZXIgb3JnYW5pemF0 aW9ucyBkb24ndC4gQW5kIGV2ZW4gd2hlbiB0aGV5IGRvLCB0aGUgZm9jdXMgb24gcHVibGlzaGVk IHZlcnNpb25zIHdpbGwgYmxvY2sgZXhwZXJpbWVudGluZyB3aXRoIG5ldyB2ZXJzaW9ucywgbm90 IHRvIG1lbnRpb24gaW50ZXJmZXJpbmcgd2l0aCBvdGhlciBmZWF0dXJlcyBsaWtlIGNvbm5lY3Rp b24gbWlncmF0aW9uLiBJIHRha2UgUHJhdmVlbidzIGV4YW1wbGUgYXMgYW4gYXJndW1lbnQgd2h5 IHdlIHNob3VsZCBpbiBmYWN0IHN0YW5kYXJkaXplIHZlcnNpb24gZ3JlYXNpbmcsIHByZWNpc2Vs eSB0byBhdm9pZCB0aGlzICJzaG9ydGVzdCBwYXRoIG1pZGRsZS1ib3ggZGVzaWduIi4NCg0KSW4g dGhlIGNhc2Ugb2YgRERPUyBwcm90ZWN0aW9uLCBJIHdpbGwgcG9pbnQgb3V0IHRoYXQgRERPUyBw cm90ZWN0aW9uIGFsc28gbmVlZHMgdG8gd29yayB3aXRoIHNob3J0IGhlYWRlciBwYWNrZXRzLCB3 aGljaCBkbyBub3QgY2FycnkgYW55IHZlcnNpb24gbnVtYmVyLiBJbiBvcmRlciB0byBhdm9pZCBE RE9TIGJ5IHNob3J0IGhlYWRlciBwYWNrZXRzLCB0aGUgYm94ZXMgaGF2ZSB0byBiZSBhYmxlIHRv IGRpc3Rpbmd1aXNoIGJldHdlZW4gcGFja2V0cyB0aGF0IGJlbG9uZyB0byBhdXRob3JpemVkIGNv bm5lY3Rpb25zIGFuZCBwYWNrZXRzIHRoYXQgZG9uJ3QuIEFuZCBpZiB5b3UgZG8gdGhhdCwgdGhl biB5b3UgZG9uJ3QgcmVhbGx5IG5lZWQgdG8gbG9vayBhdCB0aGUgdmVyc2lvbiBudW1iZXJzLCB5 b3UgY2FuIHNpbXBseSByZWx5IG9uIHRoZSBpbnZhcmlhbnRzLg0KDQotLSBDaHJpc3RpYW4gSHVp dGVtYQ0K --_000_MW2PR2101MB10498605DC0F1FC3905865F4B6280MW2PR2101MB1049_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZS4gRW5jb2RpbmcgaW4gQ0lE LiBUaGVuIGl0IG5lZWRzIHRvIGJlIHN0YW5kYXJkaXplZCBhbmQgaWYgaXQgaXMgc3RhbmRhcmRp emVkIHdoYXTigJlzIHRoZSBwb2ludCBpbiBncmVhc2luZz8gTGV04oCZcyBub3QgaWdub3JlIHRo ZSBzbWFsbGVyIHNlcnZpY2VzIHdobyB1c2UgdGhlIGNsb3VkIGkuZS4gcGVvcGxlIGRlcGxveWlu ZyBzYXkgTkdJTlggd2ViIHNlcnZlcnMgaW4gQVdTLCBBenVyZSBvciBHQ1AuIE5vdA0KIGV2ZXJ5 IFFVSUMgZGVwbG95bWVudCBpcyBhIGxhcmdlIGZpcnN0IHBhcnR5IHNlcnZpY2Ugd2hpY2ggY29u dHJvbHMgYWxsIGFzcGVjdHMgaG93IExCIGFuZCBERG9TIGFyZSBkb25lLiBJbiBwdWJsaWMgY2xv dWRzIExCIGFuZCBERG9TIHByb3RlY3Rpb24gYXJlIG5ldHdvcmsgZnVuY3Rpb25zIChzZXJ2aWNl cykgYW5kIGFyZSBtaWRkbGVib3hlcyB1bmRlciBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGFkbWlu aXN0cmF0aXZlIGRvbWFpbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaHJpc3RpYW4sIHRo aXMgaXMgYWJvdXQgc291cmNlIGFkZHJlc3MgdmFsaWRhdGlvbiBieSB0aGUgbWlkZGxlYm94LiBU aGlzIGlzIGhvdyBpdCB3b3JrcyBmb3IgVENQICh0aGluayBTWU4gY29va2llcykgYW5kIHdlIG5l ZWQgdG8gaGF2ZSBwYXJpdHkgZm9yIFFVSUMuIFdoZW4gdW5kZXIgYXR0YWNrLCBzaG9ydCBoZWFk ZXIgcGFja2V0cyB3aWxsIGJlIGRyb3BwZWQgZm9yIGFkZHJlc3NlcyB0aGF0IGhhdmUgbm90DQog YmVlbiB2YWxpZGF0ZWQsIGJ1dCB0aGlzIGlzIHRoZSBzYW1lIGZvciBub24tU1lOIHBhY2tldHMg Zm9yIFRDUC4gSSBkb27igJl0IHVuZGVyc3RhbmQgaG93IGludmFyaWFudHMgY2FuIGJlIHVzZWQg aGVyZS4gSWYgd2UgZG9u4oCZdCBoYXZlIHBhcml0eSBmb3IgRG9TIHByb3RlY3Rpb24gaW4gbmV0 d29yayB0aGVuIFFVSUMgdHJhZmZpYyB3aWxsIGJlIHJhdGUgbGltaXRlZCB3aGljaCBpcyBnb2lu ZyB0byBiZSByZWFsbHkgYmFkIGZvciBwZXJmb3JtYW5jZS4NCiBGV0lXIHRoZXJlIGlzIGFscmVh ZHkgRG9TIHRyYWZmaWMgdGhhdCBsb29rcyBsaWtlIFFVSUMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUm9iZXJ0 byBQZW9uICZsdDtmZW5peEBmYi5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFw cmlsIDEyLCAyMDE5IDk6MTYgQU08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGlhbiBIdWl0ZW1hICZs dDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzsgSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29nbGUu Y29tJmd0OzsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBHb3JyeSAoZXJnKSAmbHQ7Z29ycnlAZXJnLmFiZG4uYWMudWsm Z3Q7OyBNaXJqYSBLdWVobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbSZn dDs7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDs7 IHF1aWNAaWV0Zi5vcmc7IEJvcmRlciwgSm9obiAmbHQ7am9obi5ib3JkZXJAaHVnaGVzLmNvbSZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IElzICZxdW90O1ZlcnNpb24gR3JlYXNpbmcmcXVv dDsgYSBuZXcgYmVuZml0IG9yIGEgbmV3IG9ic3RhY2xlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGFueSBsYXJnZSBkZXBsb3ltZW50LCBJIHN1c3BlY3QgdGhl eeKAmWxsIG5lZWQgTEIuPGJyPg0KPGJyPg0KRm9yIG1vc3Qga2luZHMgb2YgTEItaW5nLCBJ4oCZ ZCBleHBlY3QgdGhlIExCIHN5c3RlbSB0byBlaXRoZXIgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSBi ZSBpbnZvbHZlZCBpbiBjaG9vc2luZy92ZW5kaW5nIGNvbm5lY3Rpb24gSURzLjxicj4NCjxicj4N CklmIGl0IGlzIGludm9sdmVkIGluIHZlbmRpbmcvY2hvb3NpbmcgY29ubmVjdGlvbiBJRHMsIGl0 IGNhbiBlbmNvZGUgdmVyc2lvbiBpbmZvcm1hdGlvbiBpbnRvIHRoZSBDSUQuPGJyPg0KPGJyPg0K LT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5DaHJpc3RpYW4g SHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQiPmh1aXRlbWFA aHVpdGVtYS5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEFwcmlsIDEyLCAy MDE5IGF0IDk6MTMgQU08YnI+DQo8Yj5UbzogPC9iPklhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyI+aWFuc3dldHQ9NDBnb29n bGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDssIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZs dDs8YSBocmVmPSJtYWlsdG86cHJhdmI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIj5w cmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8 L2I+JnF1b3Q7R29ycnkgKGVyZykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcu YWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OywgUm9iZXJ0byBQZW9uICZs dDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29tIj5mZW5peEBmYi5jb208L2E+Jmd0OywgTWly amEgS3VlaGxld2luZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nz b24uY29tIj5taXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCBNaWtrZWwNCiBG YWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20i Pm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cXVpY0Bp ZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWlj QGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDssICZxdW90O0JvcmRlciwgSm9obiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG4uYm9yZGVyQGh1Z2hlcy5jb20iPmpvaG4uYm9yZGVy QGh1Z2hlcy5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogSXMgJnF1b3Q7VmVy c2lvbiBHcmVhc2luZyZxdW90OyBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQvMTIvMjAxOSA4OjU3IEFNLCBJYW4gU3dldHQg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFByYXZlZW4gQmFs YXN1YnJhbWFuaWFuDQo8YnI+DQo8Yj4uLi48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5WZXJzaW9uIGdyZWFzaW5nIHdpbGwgY3JlYXRl IHByb2JsZW1zIGZvciBERG9TIHByb3RlY3Rpb24uIFRoZSBERG9TIHByb3RlY3Rpb24gbWlkZGxl Ym94IHdpbGwgaGF2ZSB0byB0cmVhdCBhbGwgdHJhZmZpYyB3aXRoIHVua25vd24gdmVyc2lvbiBu dW1iZXJzIGFzIHBsYWluIG9sZCBRVUlDIGFuZCByYXRlIGxpbWl0DQogaXQuIEFueSBzb2x1dGlv biB0aGF0IHJlcXVpcmVzIHBlciBjb25uZWN0aW9uIHN0YXRlIHRvIHRyYWNrIHZlcnNpb24gbnVt YmVycyBkb2VzbuKAmXQgc2NhbGUuIEVzcGVjaWFsbHkgaW4gdGhlIGNsb3VkIHNjZW5hcmlvIGN1 c3RvbWVycyBicmluZyB0aGVpciBvd24gd2ViIHNlcnZlcnMgc28gdGhpcyBtYWtlcyBhbnkgb3B0 LW91dCBzb2x1dGlvbiBub3QgZ29vZCBlbm91Z2guIFNvIEkgZG8gdGhpbmsgdGhpcyBpcyBhbiBv YnN0YWNsZSBmb3IgbWFueQ0KIGRlcGxveW1lbnRzLiA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwPkRvbid0IHdlIGhhdmUgYW4gZXhhbXBsZSBvZiBtaWRkbGUtYm94IG9zc2lmaWNh dGlvbiBqdXN0IHRoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPHA+UHJhdmVlbidzIGV4YW1wbGUgcG9p bnRzIHRvIHRoZSBwZXJpbHMgb2YgdGhlICZxdW90O3Nob3J0ZXN0IHBhdGgmcXVvdDsgYXBwcm9h Y2ggdG8gbWlkZGxlLWJveCBkZXNpZ24uIFRha2luZyB0aGUgc2hvcnRlc3QgcGF0aCBtZWFucyBm aW5kaW5nIHNvbWV0aGluZyB0aGF0IHdvcmtzIG5vdywgYW5kIG9uY2UgeW91IGhhdmUgZm91bmQg aXQgZGVwbG95IGl0IHdpdGhvdXQgd29ycnkgYWJvdXQgY29uc2VxdWVuY2VzIC0tIHdoaWNoIHZl cnkgb2Z0ZW4gaW5jbHVkZQ0KIG9zc2lmaWNhdGlvbi4gSWYgdGhlIERET1MgcHJvdGVjdGlvbiBi b3ggbG9va3MgZm9yICZxdW90O1FVSUMgdmVyc2lvbnMgdGhhdCBpdCBrbm93cyZxdW90OyBhbmQg anVzdCByYXRlIGxpbWl0cyB0aGUgb3RoZXIgdHlwZXMgb2YgcGFja2V0cywgdGhlbiB0aGUgYm94 IHdpbGwgYnkgZGVzaWduIHByZXZlbnQgZGVwbG95bWVudCBvZiB2ZXJzaW9ucyB0aGF0IGl0IGRv ZXMgbm90IGtub3cuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPkkgYXNzdW1lIHRoYXQgYmlnIG9yZ2Fu aXphdGlvbnMgbGlrZSBBenVyZSB3aWxsIHVwZGF0ZSB0aGVpciBwcm90ZWN0aW9ucyBvbmNlIGEg bmV3IHZlcnNpb24gaXMgb3V0LCBidXQgdGhlIGV4cGVyaWVuY2Ugc2hvd3MgdGhhdCBtYW55IG90 aGVyIG9yZ2FuaXphdGlvbnMgZG9uJ3QuIEFuZCBldmVuIHdoZW4gdGhleSBkbywgdGhlIGZvY3Vz IG9uIHB1Ymxpc2hlZCB2ZXJzaW9ucyB3aWxsIGJsb2NrIGV4cGVyaW1lbnRpbmcgd2l0aCBuZXcg dmVyc2lvbnMsDQogbm90IHRvIG1lbnRpb24gaW50ZXJmZXJpbmcgd2l0aCBvdGhlciBmZWF0dXJl cyBsaWtlIGNvbm5lY3Rpb24gbWlncmF0aW9uLiBJIHRha2UgUHJhdmVlbidzIGV4YW1wbGUgYXMg YW4gYXJndW1lbnQgd2h5IHdlIHNob3VsZCBpbiBmYWN0IHN0YW5kYXJkaXplIHZlcnNpb24gZ3Jl YXNpbmcsIHByZWNpc2VseSB0byBhdm9pZCB0aGlzICZxdW90O3Nob3J0ZXN0IHBhdGggbWlkZGxl LWJveCBkZXNpZ24mcXVvdDsuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPkluIHRoZSBjYXNlIG9mIERE T1MgcHJvdGVjdGlvbiwgSSB3aWxsIHBvaW50IG91dCB0aGF0IERET1MgcHJvdGVjdGlvbiBhbHNv IG5lZWRzIHRvIHdvcmsgd2l0aCBzaG9ydCBoZWFkZXIgcGFja2V0cywgd2hpY2ggZG8gbm90IGNh cnJ5IGFueSB2ZXJzaW9uIG51bWJlci4gSW4gb3JkZXIgdG8gYXZvaWQgRERPUyBieSBzaG9ydCBo ZWFkZXIgcGFja2V0cywgdGhlIGJveGVzIGhhdmUgdG8gYmUgYWJsZSB0byBkaXN0aW5ndWlzaCBi ZXR3ZWVuIHBhY2tldHMNCiB0aGF0IGJlbG9uZyB0byBhdXRob3JpemVkIGNvbm5lY3Rpb25zIGFu ZCBwYWNrZXRzIHRoYXQgZG9uJ3QuIEFuZCBpZiB5b3UgZG8gdGhhdCwgdGhlbiB5b3UgZG9uJ3Qg cmVhbGx5IG5lZWQgdG8gbG9vayBhdCB0aGUgdmVyc2lvbiBudW1iZXJzLCB5b3UgY2FuIHNpbXBs eSByZWx5IG9uIHRoZSBpbnZhcmlhbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHA+LS0gQ2hyaXN0aWFu IEh1aXRlbWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MW2PR2101MB10498605DC0F1FC3905865F4B6280MW2PR2101MB1049_-- From nobody Fri Apr 12 09:35:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5431201B6 for ; Fri, 12 Apr 2019 09:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=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 yjE3ReYSd6iZ for ; Fri, 12 Apr 2019 09:34:59 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BD7120160 for ; Fri, 12 Apr 2019 09:34:59 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id w15so16584797itc.0 for ; Fri, 12 Apr 2019 09:34: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=WLIH1gBB7/xaayeTiPFbgDBK31B/bKEWmG60CCkM2AM=; b=UqETCrjytjRmiQYORYkn16rGwM4paj7yiHeo1HnbOYHtABmVgiBcUgVAlHOQhVLos9 nbZeqqyEJUKvzAOMB/y25vQ5EL4lwNwwUeavAN4F8SjuPk1OSYlN5vxcjhjHX7ipYByN /egNq+tXz1aiTUhZmLMMEXOCuZKqT0JIl3OiyB7kp4Q3bsr7709uNgOlAK5KJajm7fAK 4aLs8sXyli838t/2daaptp2IEX8QbPafO3GaG0EDGPKd2KAyLR7lc5r96GrjjCib5mLl mNhPZeLrC7pcKflgFTTEl+I7ekq8k6Ej6QCSfScyBcQEWRl/GULB+ICiqAcHswWnejeW HPyg== 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=WLIH1gBB7/xaayeTiPFbgDBK31B/bKEWmG60CCkM2AM=; b=SNp+oZ/6n7bXPY1dR2PGQSMWs04GVUsiYuUwXYlFXi4im/1p/tDGOCd0u0zP14/A5e oZoMqU+VKfIctFhFesl5e8SQOQlrMskMiJ+2F+d331GokgkcwsPntJq74rxv5Xb1yW3O fyx52vfz1Z8BqiKw0OSkYH185nQAO4d3gNhY3POUQM9KA7uXK8/rzs4Fd8k2I78GVJIg Qay3qzLbtMsqAV6izpMzTYzZ5Vh4rbib6ksxTOtVCEIdl+di2ybnIc+DJwMn4jO95Yly 4Kw6rFSPM8e9ZdG4rovIqy87n74wKwQoFgNG5GWh9EuSE0m7qa83BQnO+946Vrv+WQ/m G47A== X-Gm-Message-State: APjAAAVmRL7GhRDzAQhuOsvsnzXYIQQSVaLcpn+Y/59Lbe+z1LIlJm3/ Px8E2nPleufgx/mcn5kKuUT35eUZ4WQ6pm3FSU4= X-Google-Smtp-Source: APXvYqwBU7zzE7v8lA5+zqUvigg5olu2X95/WIFALGxc7NvpN/kmVPsOFw7g3BGnRt0JoHurIRu1gu0NN8uQklh06YY= X-Received: by 2002:a24:e008:: with SMTP id c8mr13528956ith.93.1555086898123; Fri, 12 Apr 2019 09:34:58 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 12 Apr 2019 09:34:56 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 12 Apr 2019 09:34:56 -0700 Message-ID: Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? To: Ian Swett , Praveen Balasubramanian , Praveen Balasubramanian Cc: "Gorry (erg)" , "quic@ietf.org" , Roberto Peon , "Border, John" , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="000000000000285fdf058657e2af" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:35:06 -0000 --000000000000285fdf058657e2af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You could add some Magic(=E2=84=A2) to Kubernetes ingress controllers and Kubernetes services of kind Load Balancer. These already do coordination with mapping internal IP=E2=80=99s to externa= l IP=E2=80=99s (or ought to do that, since it doesn=E2=80=99t always work, but I guess thi= ngs will mature). For example, you have the name of a Kubernetes secret that is used to configure the load balancer. Of course, if you have high performance dedicated hardware that runs for many customers concurrently, it might be an issue, but surely the ordinary load balancers that take configurations can observe and alert dedicated hardware of suspicious 5-tuples. Outside of Kubernetes, various cloud providers have REST API=E2=80=99s for = setting TLS certificates etc, so I take it, a shared secret could also slip through here. I get it, that infrastructure folks don=E2=80=99t want to rewrite their loa= d balancers, but it is not like it is impossible by any stretch. Mikkel On 12 April 2019 at 18.08.09, Praveen Balasubramanian (pravb@microsoft.com) wrote: It being optional helps in cases where the service being deployed and the DoS protection service are under same administrative domain. So depending on how DoS protection is done the extension could be turned on or off. The problem is with the IaaS scenario if the extension is turned on by default in some major web server. Now DDoS protection cannot be offered as a cloud service without harming said traffic because it will be rate limited. And rate limiting is strictly worse than blocking QUIC because performance will suffer. We will likely need some text in manageability draft which says that turning on this extension may break network functions and cause performance issues so services / implementations should only turn this on after these considerations. *From:* QUIC *On Behalf Of * Ian Swett *Sent:* Friday, April 12, 2019 8:57 AM *To:* Praveen Balasubramanian *Cc:* Gorry (erg) ; Roberto Peon ; Mirja Kuehlewind ; Mikkel Fahn=C3=B8e J=C3= =B8rgensen < mikkelfj@gmail.com>; quic@ietf.org; Border, John *Subject:* Re: Is "Version Greasing" a new benfit or a new obstacle? Possibly I'm missing something, but wouldn't version greasing be an optional extension? So if you wanted to do so you could, but those with load balancing that couldn't handle it would not? On Fri, Apr 12, 2019 at 11:55 AM Praveen Balasubramanian wrote: Sorry for a typo. Plain old UDP not QUIC. *From:* Praveen Balasubramanian *Sent:* Friday, April 12, 2019 8:53 AM *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; Gorry (erg) < gorry@erg.abdn.ac.uk>; Mirja Kuehlewind *Cc:* quic@ietf.org; Border, John ; Roberto Peon < fenix@fb.com> *Subject:* RE: Is "Version Greasing" a new benfit or a new obstacle? Version greasing will create problems for DDoS protection. The DDoS protection middlebox will have to treat all traffic with unknown version numbers as plain old QUIC and rate limit it. Any solution that requires per connection state to track version numbers doesn=E2=80=99t scale. Especially= in the cloud scenario customers bring their own web servers so this makes any opt-out solution not good enough. So I do think this is an obstacle for many deployments. *From:* QUIC *On Behalf Of *Mikkel Fahn=C3=B8e J=C3= =B8rgensen *Sent:* Thursday, April 11, 2019 1:20 AM *To:* Gorry (erg) ; Mirja Kuehlewind < mirja.kuehlewind@ericsson.com> *Cc:* quic@ietf.org; Border, John ; Roberto Peon < fenix@fb.com> *Subject:* Re: Is "Version Greasing" a new benfit or a new obstacle? In a not so distant future, a fallback to TCP would not be a viable alternative for a number of services. Think WebRTC. If QUIC and other encrypted protocols become dominant, just blocking everything would literally block everything. Of course, http(s) as we know it, it will continue to live on, but many mobile apps would not. On 11 April 2019 at 10.03.14, Mirja Kuehlewind ( mirja.kuehlewind@ericsson.com) wrote: Hi Mikkel, I guess it is much more likely that any of those actors would just block QUIC all together (as there is actually a fallback to TCP). Mirja =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e J=C3=B8r= gensen" < quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: Let=E2=80=99s say China makes a deal with Google to allow their search engi= ne (a not entirely unreasonably proposition). The Great Firewall of China (GFC) is reconfigured to accept traffic from a specific IP range for QUIC protocol v1. Google later upgrades to v2. GFC is updated. Later, out of ignorance, some other department within said company decides that its browsers should all use forced version aliases as a rule. GFC breaks. (Assuming Googles servers are not located within the demilitarised zone and users use Chrome). Alternative 1: Google up front decides to deploy forced version aliasing. China rejects the deal because they do not want to support random traffic through GFC. Alternative 2: Google up front decides to deploy forced version aliasing, and China does not reject the deal, out of ignorance. Later some department in China GFC oversight realises the deal and forces Google to remove forced version aliasing, or shut down its service. Alternative 3: Google up front decides to deploy forced version aliasing and China says, of course, we trust everything from Googles IP range. Alternative 4: Google realises that forced version aliasing does not work in the general case, and makes a special case for users within a certain geographical area. Disclaimer: I=E2=80=99m not affiliated with Google and this might not at al= l be how things would work, but it does highlight some of the challenges. Of course, to be fair, China is not the only government entity that might have a vested interest. Let's take a fictional example of US a real estate investor with heavy ties to the eastern european block who somehow finds himself elected as president needing to find leverage on trade negotiations without effectively hurting personal finances. It turns out that blocking certain digital services from said eastern european block is the perfect tool in the trade negotiations.. Advisers point out that those services run heavily encrypted on the dark web with perpetual circulation of IP ranges so, ignoring any legal concerns, it would not be practically possible. Eventually someone figures out that these services all usually are at the forefront of technology and currently use QUIC v3.2 and no-one else has deployed that version yet, so it would suffice to ask NSA to tap into the backbone and disrupt specific packets. Of course, this ends up taking down the Bavarian local government election process in Germany where they are the first to use a new digital election system. Not that the is an issue, since trade negotiations are also running hot in that area, so that is just an accidental bonus. Or an endless number of other developments over the next few decades if the past few years is anything to go by. On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk ) wrote: Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ... I do not understand that assertion. Gorry On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: China blocks as a rule. Russia is running an experiment to block the rest of the internet. USA blocks net neutrality. EU blocks cookies. GB blocks itself. So blocking is not limited to what an operator considers best for business. On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote: I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others... John -----Original Message----- From: QUIC On Behalf Of Roberto Peon Sent: Wednesday, April 10, 2019 12:52 PM To: G Fairhurst ; quic@ietf.org Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? WARNING: The sender of this email could not be validated and may not match the person in the "From" field. CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. You're kinda between a rock-and-a-hard-place either way: - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification. - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not. My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate. My guesses: IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In other words, I have a doubt that stating the version in an observable way will prevent the use of such tools. Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe).. If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation fingerprints. -=3DR On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" > wrote: Obscuring the version of a protocol seems like a major design design decision for wider use cases. So, I'm trying to understand the motivation for version greasing. (1) I know there were instances where some early versions of QUIC were blocked due to an uninitentional matching of the header. Is there evidence of intentional attempts to block updates to protocols? (2) Thinking about operating a network that cares about user support and protection from unwanted traffic, I would expect that there would be cases where traffic pattern anomolies are found and the appropriate thing would be to try to determine if a new protocol had been deployed and monitor it, if not, then the next most obvious thing could be to block all unexpected traffic, that seems like a decision to hide the version could increase ossification for new versions in these cases.. (3) Similarly, if a threat is known to impact only a specific (older) version, it would seem to motivate a drop of that traffic that seeks to use that version, while still permitting other traffic. Forcing version detection to use pattern matching/ML will lead to less predictable outcomes, or blocking based on address, etc. (4) This obfusticates the most basic piece of reporting information used for support. It hides the extent of deployment of the current protocol version and prevlance of old implementations. (5) On the support, if a problem only emerges when a particular version is used with a particular address, then this helps pinpoint the issues. Matching client versions to servers is much more of an issue if the user community uses a wide range of servers (less so, I expect for major providers: google, facebook, etc, etc), but significant when there is a use of a diverse set of external sites and sites with their own load balancers, etc and a need to manage interactions with L2 services. I am intersted in knowing if this is likely to benefit or be a new obstacle? Gorry --000000000000285fdf058657e2af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = You could add some M= agic(=E2=84=A2) to Kubernetes ingress controllers and Kubernetes services o= f kind Load Balancer.
These already do coordination with mapping internal IP=E2=80=99s t= o external IP=E2=80=99s (or ought to do that, since it doesn=E2=80=99t alwa= ys work, but I guess things will mature).

For example, you have the name of a Kubernetes secre= t that is used to configure the load balancer.

Of course, if you have high performance dedicated= hardware that runs for many customers concurrently, it might be an issue, = but surely the ordinary load balancers that take configurations can observe= and alert dedicated hardware of suspicious 5-tuples.

Outside of Kubernetes, various cloud provi= ders have REST API=E2=80=99s for setting TLS certificates etc, so I take it= , a shared secret could also slip through here.

I get it, that infrastructure folks don=E2=80=99= t want to rewrite their load balancers, but it is not like it is impossible= by any stretch.

Mikkel

On 12 April 2019 at 1= 8.08.09, Praveen Balasubramanian (pr= avb@microsoft.com) wrote:

It being optional helps in cases where the service b= eing deployed and the DoS protection service are under same administrative = domain. So depending on how DoS protection is done the extension could be t= urned on or off. The problem is with the IaaS scenario if the extension is turned on by default in some major w= eb server. Now DDoS protection cannot be offered as a cloud service without= harming said traffic because it will be rate limited. And rate limiting is= strictly worse than blocking QUIC because performance will suffer.

=C2=A0

We will likely need some text in manageability draft= which says that turning on this extension may break network functions and = cause performance issues so services / implementations should only turn thi= s on after these considerations.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of Ian Swett
Sent: Friday, April 12, 2019 8:57 AM
To: Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org>
Cc: Gorry (erg) <gorry@er= g.abdn.ac.uk>; Roberto Peon <feni= x@fb.com>; Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>; Mikkel Fahn=C3=B8e J=C3= =B8rgensen <mikkelfj@gmail.com= >; quic@ietf.org; Border, John <= john.border@hughes.com> Subject: Re: Is "Version Greasing" a new benfit or a new o= bstacle?

=C2=A0

Possibly I'm missing something, but wouldn't= version greasing be an optional extension?=C2=A0 So if you wanted to do so= you could, but those with load balancing that couldn't handle it would= not?

=C2=A0

On Fri, Apr 12, 2019 at 11:55 AM Praveen Balasubrama= nian <pravb=3D40micros= oft.com@dmarc.ietf.org> wrote:

Sorry for a typo. Plain old UDP not QUIC.

=C2=A0

From: Praveen Balasubramanian
Sent: Friday, April 12, 2019 8:53 AM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; Gorry (erg) <<= a href=3D"mailto:gorry@erg.abdn.ac.uk" target=3D"_blank">gorry@erg.abdn.ac.= uk>; Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: quic@ietf.org= ; Border, John <john.border@hughes.com>; Roberto Peon <fenix@fb.com>
Subject: RE: Is "Version Greasing" a new benfit or a new o= bstacle?

=C2=A0

Version greasing will create problems for DDoS protection. The DDo= S protection middlebox will have to treat all traffic with unknown version = numbers as plain old QUIC and rate limit it. Any solution that requires per connection state to track version numbe= rs doesn=E2=80=99t scale. Especially in the cloud scenario customers bring = their own web servers so this makes any opt-out solution not good enough. S= o I do think this is an obstacle for many deployments.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Thursday, April 11, 2019 1:20 AM
To: Gorry (erg) <gorry@erg.abdn.ac.uk>; Mirja Kuehlewind <mirja.kuehlewind@eri= csson.com>
Cc: quic@ietf.org= ; Border, John <john.border@hughes.com>; Roberto Peon <fenix@fb.com>
Subject: Re: Is "Version Greasing" a new benfit or a new o= bstacle?

=C2=A0

In a not so distant future, a fallback to TCP would not be a vi= able alternative for a number of services. Think WebRTC.

If QUIC and other encrypted protocols become dominant, just blo= cking everything would literally block everything.

Of course, http(s) as we know it, it will continue to live on, = but many mobile apps would not.

=C2=A0

=C2=A0

On 11 April 2019 at 10= .03.14, Mirja Kuehlewind (mirja.kuehlewind@ericsson.com) wrote:

Hi Mikkel,

I guess it is much more likely that any of those actors would just block QU= IC all together (as there is actually a fallback to TCP).

Mirja



=EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikke= l Fahn=C3=B8e J=C3=B8rgensen" <quic-bounces@ietf.org on behalf of mikke= lfj@gmail.com> wrote:


Let=E2=80=99s say China makes a deal with Google to allow their search engi= ne (a not entirely unreasonably proposition).
The Great Firewall of China (GFC) is reconfigured to accept traffic from a = specific IP range for QUIC protocol v1.



Google later upgrades to v2. GFC is updated. Later, out of ignorance, some = other department within said company decides that its browsers should all u= se forced version aliases as a rule. GFC breaks. (Assuming Googles servers = are not located within the demilitarised
zone and users use Chrome).


Alternative 1: Google up front decides to deploy forced version aliasing. C= hina rejects the deal because they do not want to support random traffic th= rough GFC.


Alternative 2: Google up front decides to deploy forced version aliasing, a= nd China does not reject the deal, out of ignorance. Later some department = in China GFC oversight realises the deal and forces Google to remove forced= version aliasing, or shut down
its service.


Alternative 3: Google up front decides to deploy forced version aliasing an= d China says, of course, we trust everything from Googles IP range.


Alternative 4: Google realises that forced version aliasing does not work i= n the general case, and makes a special case for users within a certain geo= graphical area.


Disclaimer: I=E2=80=99m not affiliated with Google and this might not at al= l be how things would work, but it does highlight some of the challenges.


Of course, to be fair, China is not the only government entity that might h= ave a vested interest. Let's take a fictional example of US a real esta= te investor with heavy ties to the eastern european block who somehow finds= himself elected as president needing
to find leverage on trade negotiations without effectively hurting personal= finances. It turns out that blocking certain digital services from said ea= stern european block is the perfect tool in the trade negotiations.. Advise= rs point out that those services
run heavily encrypted on the dark web with perpetual circulation of IP rang= es so, ignoring any legal concerns, it would not be practically possible. E= ventually someone figures out that these services all usually are at the fo= refront of technology and currently
use QUIC v3.2 and no-one else has deployed that version yet, so it would su= ffice to ask NSA to tap into the backbone and disrupt specific packets. Of = course, this ends up taking down the Bavarian local government election pro= cess in Germany where they are
the first to use a new digital election system. Not that the is an issue, s= ince trade negotiations are also running hot in that area, so that is just = an accidental bonus.


Or an endless number of other developments over the next few decades if the= past few years is anything to go by.





On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote:

Thanks Mikkel, I do understand that various actors intentionally drop - but= are you saying these actors would specifically choose to block a new versi= on of QUIC ... I do not understand that assertion.


Gorry

On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wro= te:



China blocks as a rule.
Russia is running an experiment to block the rest of the internet.
USA blocks net neutrality.
EU blocks cookies.
GB blocks itself.


So blocking is not limited to what an operator considers best for business.=



On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote:


I understand why people want to come down on the side of preventing ossific= ation. But, things have changed. There are a lot of more negative consequen= ces now when people unnecessarily block things. I think operators would put= a lot of pressure on vendors to
not do it now and to fix it if they did "by accident". Of course,= I am only one operator. It would be nice to hear from others...



John


-----Original Message-----
From: QUIC <q= uic-bounces@ietf.org> On Behalf Of Roberto Peon
Sent: Wednesday, April 10, 2019 12:52 PM
To: G Fairhurst <gorry@erg.abdn.ac.uk>;
quic@ietf.org
Subject: Re: Is "Version Greasing" a new benfit or a new obstacle= ?

WARNING: The sender of this email could not be validated and may not match = the person in the "From" field.

CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you recognize the sender and know the c= ontent is safe.


You're kinda between a rock-and-a-hard-place either way:

- We've seen how much fun ossification is in TCP and HTTP. If the thing= is observable, it will be ossified seems to be the lesson. A lot of the re= ason why QUIC was started in the first place was because of the inability t= o improve TCP due to this ossification.
- OTOH, there is the fear of unknown/unobservable which might cause operato= rs to block things, whether predictably or not.

My opinion is that it is better to start with preventing ossification, and = then if that results in too large a percentage of operators blocking things= , to re-evaluate.

My guesses:
IP+port tuples and traffic patterns are still observable (for better and wo= rse), which implies operators will still have significant tools for managin= g traffic. I believe that these are acted on/matched (ML or not) regardless= of any other data presented. In
other words, I have a doubt that stating the version in an observable way w= ill prevent the use of such tools.

Most problems I've seen associated with implementations rather than pro= tocol versions (though when the latter happens it is pretty severe).. If yo= u believe this assertion, then acting on protocol version is less interesti= ng than attempting to act based on implementation
fingerprints.
-=3DR


On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" <quic-bounces@ietf.org on behalf of
gorry@erg.abdn.ac= ..uk> wrote:

Obscuring the version of a protocol seems like a major design design
decision for wider use cases. So, I'm trying to understand the
motivation for version greasing.

(1) I know there were instances where some early versions of QUIC were
blocked due to an uninitentional matching of the header. Is there
evidence of intentional attempts to block updates to protocols?

(2) Thinking about operating a network that cares about user support and protection from unwanted traffic, I would expect that there would be
cases where traffic pattern anomolies are found and the appropriate
thing would be to try to determine if a new protocol had been deployed
and monitor it, if not, then the next most obvious thing could be to
block all unexpected traffic, that seems like a decision to hide the
version could increase ossification for new versions in these cases..

(3) Similarly, if a threat is known to impact only a specific (older)
version, it would seem to motivate a drop of that traffic that seeks to use that version, while still permitting other traffic. Forcing version detection to use pattern matching/ML will lead to less predictable
outcomes, or blocking based on address, etc.

(4) This obfusticates the most basic piece of reporting information used for support. It hides the extent of deployment of the current protocol
version and prevlance of old implementations.

(5) On the support, if a problem only emerges when a particular version is used with a particular address, then this helps pinpoint the issues. Matching client versions to servers is much more of an issue if the user community uses a wide range of servers (less so, I expect for major
providers: google, facebook, etc, etc), but significant when there is a use of a diverse set of external sites and sites with their own load
balancers, etc and a need to manage interactions with L2 services.

I am intersted in knowing if this is likely to benefit or be a new obstacle= ?

Gorry













--000000000000285fdf058657e2af-- From nobody Fri Apr 12 09:42:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5311202F1 for ; Fri, 12 Apr 2019 09:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, 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 (1024-bit key) header.d=fb.com header.b=Tp/PToxT; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=kdSE4l9B Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R0N31WG8dxl for ; Fri, 12 Apr 2019 09:42:54 -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 0E274120072 for ; Fri, 12 Apr 2019 09:42:54 -0700 (PDT) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3CGeMos009803; Fri, 12 Apr 2019 09:42:37 -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=Ojl4yBPH57qBWJ4C4gM6X/J/EDt0d4hWa3KN/JNqVug=; b=Tp/PToxTuvs0zQd5eU2dL066WSX6ROC3TWnT/QNvzwtYuhiIuf+nDW5Kn1ec7iURDtKC be5+o7NYSoteLtXzHie8009tppW3cp4pO9uiNohvauWvqL5ChEkN6YYgylxfQkFBQqpE TCraeuMTkaPcT6bXpjGBxkJsV7ARjyVU1Rw= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2rtv7q8g6g-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 12 Apr 2019 09:42:37 -0700 Received: from frc-mbx07.TheFacebook.com (2620:10d:c0a1:f82::31) by frc-hub02.TheFacebook.com (2620:10d:c021:18::172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 12 Apr 2019 09:42:30 -0700 Received: from frc-hub02.TheFacebook.com (2620:10d:c021:18::172) by frc-mbx07.TheFacebook.com (2620:10d:c0a1:f82::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 12 Apr 2019 09:41:51 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5 via Frontend Transport; Fri, 12 Apr 2019 09:41:51 -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:X-MS-Exchange-SenderADCheck; bh=Ojl4yBPH57qBWJ4C4gM6X/J/EDt0d4hWa3KN/JNqVug=; b=kdSE4l9Bcu0IVnFMgVFYZcVrCL0xmK43DERXTjFM+bUYb/9H4DHIQ9ZJzJClfavUo+/KKpWFovDLXHWi+9p3CFWMUPAKO5MXE/suTAtU3/HS8dMnOmRmisvuXlubjuOVWrgOj8ZW7QiVg8DlXoDiSRlm0GhlZqjdhfM80NwpwbI= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2408.namprd15.prod.outlook.com (52.135.198.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.21; Fri, 12 Apr 2019 16:41:48 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7%2]) with mapi id 15.20.1771.021; Fri, 12 Apr 2019 16:41:48 +0000 From: Roberto Peon To: Praveen Balasubramanian , Christian Huitema , Ian Swett CC: "Gorry (erg)" , Mirja Kuehlewind , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , "Border, John" Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o3xTufubPn9E2URSuto2uLa6Y1JwYAgAB3W4CAAAdsgIAADYwAgAAcxQCAAMrxAIAABNWAgAIQ3wCAAACXAIAAAIaAgAAEgoD//4tNAIAAeNGA//+Ob4A= Date: Fri, 12 Apr 2019 16:41:48 +0000 Message-ID: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> <9C6D92FF-7635-48BD-A65B-FAB4B544476D@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.17.1.190326 x-originating-ip: [2620:10d:c090:200::1ab6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 499389cf-f903-4edc-219f-08d6bf65c1dc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR15MB2408; x-ms-traffictypediagnostic: BYAPR15MB2408: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(396003)(136003)(376002)(199004)(189003)(82746002)(58126008)(8676002)(186003)(2906002)(6116002)(446003)(2616005)(105586002)(46003)(256004)(81156014)(76176011)(14444005)(8936002)(486006)(476003)(54896002)(102836004)(316002)(106356001)(99286004)(66574012)(7736002)(6512007)(229853002)(97736004)(81166006)(6306002)(33656002)(93886005)(86362001)(68736007)(6506007)(54906003)(478600001)(45080400002)(11346002)(236005)(53936002)(4326008)(53546011)(110136005)(6486002)(6246003)(6436002)(25786009)(14454004)(36756003)(1511001)(71200400001)(71190400001)(5660300002)(83716004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2408; H:BYAPR15MB2312.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: k9cS2elridwdQnb2MKA0avpsYVQYALG7Yj6xiRu0474UDl7cWxtd34drzbTZmKFMxSjRIurAL7OQncYn4RDGvqaaXFHcpCiC82cYJBHPzu71VzolqaXy5KpQQxydKAEAkQc3iazFduMev0fjPsUDtfp3P4/hRwvsXDrR44HU1gbpGtYVTC4kSx9rZM+bSJXvxsjvNAhz7KiTeGcNo74m/cauWnlH/do8zPemuaPyFOd7ht12zJBs/MK6lLb82Batfi0vXCpWfQoBQpRfynodCZMNbfddlwsA/UWZTr+zNiIwc2OTbrGaakwKgExgd+hgaV0kSOc8M1CBBITDBpK9sUOXd/arKFPCewP81DpOcvVkY3uEXt1dyu+pCsM0Cf+3JrXRGCtmHbWz8w877Br3/ZjysDekITqgRwSIakinDA0= Content-Type: multipart/alternative; boundary="_000_BDEE786D9CCE457F946A8CC195E3CDA8fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 499389cf-f903-4edc-219f-08d6bf65c1dc X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 16:41:48.3554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2408 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-12_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:42:56 -0000 --_000_BDEE786D9CCE457F946A8CC195E3CDA8fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IHN1cmUgdGhhdCBJIGFncmVlIHRoZXJl4oCUdGhlcmUgaXMgbm8gbmVlZCB0byBo YXZlIGl0IHN0YW5kYXJkaXplZCBzbyBsb25nIGFzIHRoZSBMQiBpcyBpbnZvbHZlZCBpbiBwaWNr aW5nIGl0LiBFYWNoIExCIHN5c3RlbSBjYW4gY2hvb3NlIHdoYXRldmVyIGl0IHdhbnRzLiBUaHVz LCBldmVyeSBMQiAqZGVwbG95bWVudCogY291bGQgdXNlIGEgZGlmZmVyZW50IHNjaGVtZSB3aXRo IGRpZmZlcmVudCBncmVhc2UuIEV2ZXJ5IExCIGRlcGxveW1lbnQgY291bGQgY2hhbmdlIHRoZSBz Y2hlbWUgaXQgdXNlcyBwc2V1ZG8tcmFuZG9tbHkgb3IgYWNjb3JkaW5nIHRvIHRoZSBsdW5hciBj YWxlbmRhciwgZXRjLg0KDQpCZWNhdXNlIHRoZXJlIGlzIGEgZHluYW1pYyAoYW5kIGNvbnRyb2xs aW5nKSBjb21wb25lbnQgKG5hbWVseSB0aGUgcGFydCBvZiB0aGUgTEIgc3lzdGVtIHdoaWNoIHZl bmRzIGFuZCB0aGVuIGxhdGVyIHJvdXRlcyBDSURzKSwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgYW55 dGhpbmcgZWxzZS4NCg0KLT1SDQoNCkZyb206IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2 YkBtaWNyb3NvZnQuY29tPg0KRGF0ZTogRnJpZGF5LCBBcHJpbCAxMiwgMjAxOSBhdCA5OjI4IEFN DQpUbzogUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+LCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVp dGVtYUBodWl0ZW1hLm5ldD4sIElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT4NCkNjOiAi R29ycnkgKGVyZykiIDxnb3JyeUBlcmcuYWJkbi5hYy51az4sIE1pcmphIEt1ZWhsZXdpbmQgPG1p cmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPiwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8 bWlra2VsZmpAZ21haWwuY29tPiwgInF1aWNAaWV0Zi5vcmciIDxxdWljQGlldGYub3JnPiwgIkJv cmRlciwgSm9obiIgPGpvaG4uYm9yZGVyQGh1Z2hlcy5jb20+DQpTdWJqZWN0OiBSRTogSXMgIlZl cnNpb24gR3JlYXNpbmciIGEgbmV3IGJlbmZpdCBvciBhIG5ldyBvYnN0YWNsZT8NCg0KUmUuIEVu Y29kaW5nIGluIENJRC4gVGhlbiBpdCBuZWVkcyB0byBiZSBzdGFuZGFyZGl6ZWQgYW5kIGlmIGl0 IGlzIHN0YW5kYXJkaXplZCB3aGF04oCZcyB0aGUgcG9pbnQgaW4gZ3JlYXNpbmc/IExldOKAmXMg bm90IGlnbm9yZSB0aGUgc21hbGxlciBzZXJ2aWNlcyB3aG8gdXNlIHRoZSBjbG91ZCBpLmUuIHBl b3BsZSBkZXBsb3lpbmcgc2F5IE5HSU5YIHdlYiBzZXJ2ZXJzIGluIEFXUywgQXp1cmUgb3IgR0NQ LiBOb3QgZXZlcnkgUVVJQyBkZXBsb3ltZW50IGlzIGEgbGFyZ2UgZmlyc3QgcGFydHkgc2Vydmlj ZSB3aGljaCBjb250cm9scyBhbGwgYXNwZWN0cyBob3cgTEIgYW5kIEREb1MgYXJlIGRvbmUuIElu IHB1YmxpYyBjbG91ZHMgTEIgYW5kIEREb1MgcHJvdGVjdGlvbiBhcmUgbmV0d29yayBmdW5jdGlv bnMgKHNlcnZpY2VzKSBhbmQgYXJlIG1pZGRsZWJveGVzIHVuZGVyIGEgY29tcGxldGVseSBkaWZm ZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KDQpDaHJpc3RpYW4sIHRoaXMgaXMgYWJvdXQg c291cmNlIGFkZHJlc3MgdmFsaWRhdGlvbiBieSB0aGUgbWlkZGxlYm94LiBUaGlzIGlzIGhvdyBp dCB3b3JrcyBmb3IgVENQICh0aGluayBTWU4gY29va2llcykgYW5kIHdlIG5lZWQgdG8gaGF2ZSBw YXJpdHkgZm9yIFFVSUMuIFdoZW4gdW5kZXIgYXR0YWNrLCBzaG9ydCBoZWFkZXIgcGFja2V0cyB3 aWxsIGJlIGRyb3BwZWQgZm9yIGFkZHJlc3NlcyB0aGF0IGhhdmUgbm90IGJlZW4gdmFsaWRhdGVk LCBidXQgdGhpcyBpcyB0aGUgc2FtZSBmb3Igbm9uLVNZTiBwYWNrZXRzIGZvciBUQ1AuIEkgZG9u 4oCZdCB1bmRlcnN0YW5kIGhvdyBpbnZhcmlhbnRzIGNhbiBiZSB1c2VkIGhlcmUuIElmIHdlIGRv buKAmXQgaGF2ZSBwYXJpdHkgZm9yIERvUyBwcm90ZWN0aW9uIGluIG5ldHdvcmsgdGhlbiBRVUlD IHRyYWZmaWMgd2lsbCBiZSByYXRlIGxpbWl0ZWQgd2hpY2ggaXMgZ29pbmcgdG8gYmUgcmVhbGx5 IGJhZCBmb3IgcGVyZm9ybWFuY2UuIEZXSVcgdGhlcmUgaXMgYWxyZWFkeSBEb1MgdHJhZmZpYyB0 aGF0IGxvb2tzIGxpa2UgUVVJQy4NCg0KRnJvbTogUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+ DQpTZW50OiBGcmlkYXksIEFwcmlsIDEyLCAyMDE5IDk6MTYgQU0NClRvOiBDaHJpc3RpYW4gSHVp dGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNv bT47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPg0KQ2M6IEdv cnJ5IChlcmcpIDxnb3JyeUBlcmcuYWJkbi5hYy51az47IE1pcmphIEt1ZWhsZXdpbmQgPG1pcmph Lmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPjsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlr a2VsZmpAZ21haWwuY29tPjsgcXVpY0BpZXRmLm9yZzsgQm9yZGVyLCBKb2huIDxqb2huLmJvcmRl ckBodWdoZXMuY29tPg0KU3ViamVjdDogUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBi ZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/DQoNCkZvciBhbnkgbGFyZ2UgZGVwbG95bWVudCwgSSBz dXNwZWN0IHRoZXnigJlsbCBuZWVkIExCLg0KDQpGb3IgbW9zdCBraW5kcyBvZiBMQi1pbmcsIEni gJlkIGV4cGVjdCB0aGUgTEIgc3lzdGVtIHRvIGVpdGhlciBkaXJlY3RseSBvciBpbmRpcmVjdGx5 IGJlIGludm9sdmVkIGluIGNob29zaW5nL3ZlbmRpbmcgY29ubmVjdGlvbiBJRHMuDQoNCklmIGl0 IGlzIGludm9sdmVkIGluIHZlbmRpbmcvY2hvb3NpbmcgY29ubmVjdGlvbiBJRHMsIGl0IGNhbiBl bmNvZGUgdmVyc2lvbiBpbmZvcm1hdGlvbiBpbnRvIHRoZSBDSUQuDQoNCi09Ug0KDQpGcm9tOiBD aHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBodWl0 ZW1hLm5ldD4+DQpEYXRlOiBGcmlkYXksIEFwcmlsIDEyLCAyMDE5IGF0IDk6MTMgQU0NClRvOiBJ YW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86aWFu c3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4sIFByYXZlZW4gQmFsYXN1YnJhbWFu aWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnByYXZiPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpDYzogIkdvcnJ5IChlcmcpIiA8Z29ycnlA ZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj4sIFJvYmVydG8gUGVv biA8ZmVuaXhAZmIuY29tPG1haWx0bzpmZW5peEBmYi5jb20+PiwgTWlyamEgS3VlaGxld2luZCA8 bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb208bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAZXJp Y3Nzb24uY29tPj4sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNv bTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4sICJxdWljQGlldGYub3JnPG1haWx0bzpxdWlj QGlldGYub3JnPiIgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PiwgIkJvcmRl ciwgSm9obiIgPGpvaG4uYm9yZGVyQGh1Z2hlcy5jb208bWFpbHRvOmpvaG4uYm9yZGVyQGh1Z2hl cy5jb20+Pg0KU3ViamVjdDogUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBiZW5maXQg b3IgYSBuZXcgb2JzdGFjbGU/DQoNCg0KDQpPbiA0LzEyLzIwMTkgODo1NyBBTSwgSWFuIFN3ZXR0 IHdyb3RlOg0KRnJvbTogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NCi4uLg0KVmVyc2lvbiBncmVh c2luZyB3aWxsIGNyZWF0ZSBwcm9ibGVtcyBmb3IgRERvUyBwcm90ZWN0aW9uLiBUaGUgRERvUyBw cm90ZWN0aW9uIG1pZGRsZWJveCB3aWxsIGhhdmUgdG8gdHJlYXQgYWxsIHRyYWZmaWMgd2l0aCB1 bmtub3duIHZlcnNpb24gbnVtYmVycyBhcyBwbGFpbiBvbGQgUVVJQyBhbmQgcmF0ZSBsaW1pdCBp dC4gQW55IHNvbHV0aW9uIHRoYXQgcmVxdWlyZXMgcGVyIGNvbm5lY3Rpb24gc3RhdGUgdG8gdHJh Y2sgdmVyc2lvbiBudW1iZXJzIGRvZXNu4oCZdCBzY2FsZS4gRXNwZWNpYWxseSBpbiB0aGUgY2xv dWQgc2NlbmFyaW8gY3VzdG9tZXJzIGJyaW5nIHRoZWlyIG93biB3ZWIgc2VydmVycyBzbyB0aGlz IG1ha2VzIGFueSBvcHQtb3V0IHNvbHV0aW9uIG5vdCBnb29kIGVub3VnaC4gU28gSSBkbyB0aGlu ayB0aGlzIGlzIGFuIG9ic3RhY2xlIGZvciBtYW55IGRlcGxveW1lbnRzLg0KDQpEb24ndCB3ZSBo YXZlIGFuIGV4YW1wbGUgb2YgbWlkZGxlLWJveCBvc3NpZmljYXRpb24ganVzdCB0aGVyZT8NCg0K UHJhdmVlbidzIGV4YW1wbGUgcG9pbnRzIHRvIHRoZSBwZXJpbHMgb2YgdGhlICJzaG9ydGVzdCBw YXRoIiBhcHByb2FjaCB0byBtaWRkbGUtYm94IGRlc2lnbi4gVGFraW5nIHRoZSBzaG9ydGVzdCBw YXRoIG1lYW5zIGZpbmRpbmcgc29tZXRoaW5nIHRoYXQgd29ya3Mgbm93LCBhbmQgb25jZSB5b3Ug aGF2ZSBmb3VuZCBpdCBkZXBsb3kgaXQgd2l0aG91dCB3b3JyeSBhYm91dCBjb25zZXF1ZW5jZXMg LS0gd2hpY2ggdmVyeSBvZnRlbiBpbmNsdWRlIG9zc2lmaWNhdGlvbi4gSWYgdGhlIERET1MgcHJv dGVjdGlvbiBib3ggbG9va3MgZm9yICJRVUlDIHZlcnNpb25zIHRoYXQgaXQga25vd3MiIGFuZCBq dXN0IHJhdGUgbGltaXRzIHRoZSBvdGhlciB0eXBlcyBvZiBwYWNrZXRzLCB0aGVuIHRoZSBib3gg d2lsbCBieSBkZXNpZ24gcHJldmVudCBkZXBsb3ltZW50IG9mIHZlcnNpb25zIHRoYXQgaXQgZG9l cyBub3Qga25vdy4NCg0KSSBhc3N1bWUgdGhhdCBiaWcgb3JnYW5pemF0aW9ucyBsaWtlIEF6dXJl IHdpbGwgdXBkYXRlIHRoZWlyIHByb3RlY3Rpb25zIG9uY2UgYSBuZXcgdmVyc2lvbiBpcyBvdXQs IGJ1dCB0aGUgZXhwZXJpZW5jZSBzaG93cyB0aGF0IG1hbnkgb3RoZXIgb3JnYW5pemF0aW9ucyBk b24ndC4gQW5kIGV2ZW4gd2hlbiB0aGV5IGRvLCB0aGUgZm9jdXMgb24gcHVibGlzaGVkIHZlcnNp b25zIHdpbGwgYmxvY2sgZXhwZXJpbWVudGluZyB3aXRoIG5ldyB2ZXJzaW9ucywgbm90IHRvIG1l bnRpb24gaW50ZXJmZXJpbmcgd2l0aCBvdGhlciBmZWF0dXJlcyBsaWtlIGNvbm5lY3Rpb24gbWln cmF0aW9uLiBJIHRha2UgUHJhdmVlbidzIGV4YW1wbGUgYXMgYW4gYXJndW1lbnQgd2h5IHdlIHNo b3VsZCBpbiBmYWN0IHN0YW5kYXJkaXplIHZlcnNpb24gZ3JlYXNpbmcsIHByZWNpc2VseSB0byBh dm9pZCB0aGlzICJzaG9ydGVzdCBwYXRoIG1pZGRsZS1ib3ggZGVzaWduIi4NCg0KSW4gdGhlIGNh c2Ugb2YgRERPUyBwcm90ZWN0aW9uLCBJIHdpbGwgcG9pbnQgb3V0IHRoYXQgRERPUyBwcm90ZWN0 aW9uIGFsc28gbmVlZHMgdG8gd29yayB3aXRoIHNob3J0IGhlYWRlciBwYWNrZXRzLCB3aGljaCBk byBub3QgY2FycnkgYW55IHZlcnNpb24gbnVtYmVyLiBJbiBvcmRlciB0byBhdm9pZCBERE9TIGJ5 IHNob3J0IGhlYWRlciBwYWNrZXRzLCB0aGUgYm94ZXMgaGF2ZSB0byBiZSBhYmxlIHRvIGRpc3Rp bmd1aXNoIGJldHdlZW4gcGFja2V0cyB0aGF0IGJlbG9uZyB0byBhdXRob3JpemVkIGNvbm5lY3Rp b25zIGFuZCBwYWNrZXRzIHRoYXQgZG9uJ3QuIEFuZCBpZiB5b3UgZG8gdGhhdCwgdGhlbiB5b3Ug ZG9uJ3QgcmVhbGx5IG5lZWQgdG8gbG9vayBhdCB0aGUgdmVyc2lvbiBudW1iZXJzLCB5b3UgY2Fu IHNpbXBseSByZWx5IG9uIHRoZSBpbnZhcmlhbnRzLg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0K --_000_BDEE786D9CCE457F946A8CC195E3CDA8fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <8C8FB771D37AC34F918D2F827B9A8374@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDIgMyAzIDIgMjt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SeKAmW0gbm90IHN1cmUgdGhhdCBJIGFncmVlIHRoZXJl4oCUdGhlcmUgaXMgbm8g bmVlZCB0byBoYXZlIGl0IHN0YW5kYXJkaXplZCBzbyBsb25nIGFzIHRoZSBMQiBpcyBpbnZvbHZl ZCBpbiBwaWNraW5nIGl0LiBFYWNoIExCIHN5c3RlbSBjYW4gY2hvb3NlIHdoYXRldmVyIGl0IHdh bnRzLiBUaHVzLCBldmVyeSBMQiAqPGI+ZGVwbG95bWVudDwvYj4qIGNvdWxkIHVzZSBhIGRpZmZl cmVudCBzY2hlbWUgd2l0aCBkaWZmZXJlbnQNCiBncmVhc2UuIEV2ZXJ5IExCIGRlcGxveW1lbnQg Y291bGQgY2hhbmdlIHRoZSBzY2hlbWUgaXQgdXNlcyBwc2V1ZG8tcmFuZG9tbHkgb3IgYWNjb3Jk aW5nIHRvIHRoZSBsdW5hciBjYWxlbmRhciwgZXRjLg0KPGJyPg0KPGJyPg0KQmVjYXVzZSB0aGVy ZSBpcyBhIGR5bmFtaWMgKGFuZCBjb250cm9sbGluZykgY29tcG9uZW50IChuYW1lbHkgdGhlIHBh cnQgb2YgdGhlIExCIHN5c3RlbSB3aGljaCB2ZW5kcyBhbmQgdGhlbiBsYXRlciByb3V0ZXMgQ0lE cyksIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGFueXRoaW5nIGVsc2UuPGJyPg0KPGJyPg0KLT1SPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5QcmF2ZWVuIEJhbGFzdWJy YW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJp ZGF5LCBBcHJpbCAxMiwgMjAxOSBhdCA5OjI4IEFNPGJyPg0KPGI+VG86IDwvYj5Sb2JlcnRvIFBl b24gJmx0O2Zlbml4QGZiLmNvbSZndDssIENocmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1 aXRlbWEubmV0Jmd0OywgSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29nbGUuY29tJmd0Ozxicj4N CjxiPkNjOiA8L2I+JnF1b3Q7R29ycnkgKGVyZykmcXVvdDsgJmx0O2dvcnJ5QGVyZy5hYmRuLmFj LnVrJmd0OywgTWlyamEgS3VlaGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5j b20mZ3Q7LCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20m Z3Q7LCAmcXVvdDtxdWljQGlldGYub3JnJnF1b3Q7ICZsdDtxdWljQGlldGYub3JnJmd0OywgJnF1 b3Q7Qm9yZGVyLCBKb2huJnF1b3Q7ICZsdDtqb2huLmJvcmRlckBodWdoZXMuY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SRTogSXMgJnF1b3Q7VmVyc2lvbiBHcmVhc2luZyZxdW90OyBhIG5l dyBiZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlLiBFbmNvZGluZyBpbiBDSUQuIFRoZW4gaXQgbmVl ZHMgdG8gYmUgc3RhbmRhcmRpemVkIGFuZCBpZiBpdCBpcyBzdGFuZGFyZGl6ZWQgd2hhdOKAmXMg dGhlIHBvaW50IGluIGdyZWFzaW5nPyBMZXTigJlzIG5vdCBpZ25vcmUgdGhlIHNtYWxsZXIgc2Vy dmljZXMgd2hvIHVzZSB0aGUgY2xvdWQgaS5lLiBwZW9wbGUgZGVwbG95aW5nIHNheSBOR0lOWCB3 ZWIgc2VydmVycyBpbiBBV1MsIEF6dXJlIG9yIEdDUC4gTm90DQogZXZlcnkgUVVJQyBkZXBsb3lt ZW50IGlzIGEgbGFyZ2UgZmlyc3QgcGFydHkgc2VydmljZSB3aGljaCBjb250cm9scyBhbGwgYXNw ZWN0cyBob3cgTEIgYW5kIEREb1MgYXJlIGRvbmUuIEluIHB1YmxpYyBjbG91ZHMgTEIgYW5kIERE b1MgcHJvdGVjdGlvbiBhcmUgbmV0d29yayBmdW5jdGlvbnMgKHNlcnZpY2VzKSBhbmQgYXJlIG1p ZGRsZWJveGVzIHVuZGVyIGEgY29tcGxldGVseSBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9t YWluLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzdGlhbiwgdGhpcyBpcyBhYm91dCBz b3VyY2UgYWRkcmVzcyB2YWxpZGF0aW9uIGJ5IHRoZSBtaWRkbGVib3guIFRoaXMgaXMgaG93IGl0 IHdvcmtzIGZvciBUQ1AgKHRoaW5rIFNZTiBjb29raWVzKSBhbmQgd2UgbmVlZCB0byBoYXZlIHBh cml0eSBmb3IgUVVJQy4gV2hlbiB1bmRlciBhdHRhY2ssIHNob3J0IGhlYWRlciBwYWNrZXRzIHdp bGwgYmUgZHJvcHBlZCBmb3IgYWRkcmVzc2VzIHRoYXQgaGF2ZSBub3QNCiBiZWVuIHZhbGlkYXRl ZCwgYnV0IHRoaXMgaXMgdGhlIHNhbWUgZm9yIG5vbi1TWU4gcGFja2V0cyBmb3IgVENQLiBJIGRv buKAmXQgdW5kZXJzdGFuZCBob3cgaW52YXJpYW50cyBjYW4gYmUgdXNlZCBoZXJlLiBJZiB3ZSBk b27igJl0IGhhdmUgcGFyaXR5IGZvciBEb1MgcHJvdGVjdGlvbiBpbiBuZXR3b3JrIHRoZW4gUVVJ QyB0cmFmZmljIHdpbGwgYmUgcmF0ZSBsaW1pdGVkIHdoaWNoIGlzIGdvaW5nIHRvIGJlIHJlYWxs eSBiYWQgZm9yIHBlcmZvcm1hbmNlLg0KIEZXSVcgdGhlcmUgaXMgYWxyZWFkeSBEb1MgdHJhZmZp YyB0aGF0IGxvb2tzIGxpa2UgUVVJQy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBSb2JlcnRvIFBlb24gJmx0O2Zl bml4QGZiLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMTIsIDIwMTkg OToxNiBBTTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVp dGVtYS5uZXQmZ3Q7OyBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7OyBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IEdvcnJ5IChlcmcpICZsdDtnb3JyeUBlcmcuYWJkbi5hYy51ayZndDs7IE1pcmphIEt1 ZWhsZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tJmd0OzsgTWlra2VsIEZh aG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0OzsgcXVpY0BpZXRmLm9y ZzsgQm9yZGVyLCBKb2huICZsdDtqb2huLmJvcmRlckBodWdoZXMuY29tJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogSXMgJnF1b3Q7VmVyc2lvbiBHcmVhc2luZyZxdW90OyBhIG5ldyBiZW5m aXQgb3IgYSBuZXcgb2JzdGFjbGU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Gb3IgYW55IGxhcmdlIGRlcGxveW1lbnQsIEkgc3VzcGVjdCB0aGV54oCZbGwgbmVlZCBM Qi48YnI+DQo8YnI+DQpGb3IgbW9zdCBraW5kcyBvZiBMQi1pbmcsIEnigJlkIGV4cGVjdCB0aGUg TEIgc3lzdGVtIHRvIGVpdGhlciBkaXJlY3RseSBvciBpbmRpcmVjdGx5IGJlIGludm9sdmVkIGlu IGNob29zaW5nL3ZlbmRpbmcgY29ubmVjdGlvbiBJRHMuPGJyPg0KPGJyPg0KSWYgaXQgaXMgaW52 b2x2ZWQgaW4gdmVuZGluZy9jaG9vc2luZyBjb25uZWN0aW9uIElEcywgaXQgY2FuIGVuY29kZSB2 ZXJzaW9uIGluZm9ybWF0aW9uIGludG8gdGhlIENJRC48YnI+DQo8YnI+DQotPVI8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkNocmlzdGlhbiBIdWl0ZW1hICZsdDs8 YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwv YT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgQXByaWwgMTIsIDIwMTkgYXQgOToxMyBB TTxicj4NCjxiPlRvOiA8L2I+SWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHQ9 NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIj5pYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0OywgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciPnByYXZiPTQwbWljcm9z b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtHb3Jy eSAoZXJnKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj5n b3JyeUBlcmcuYWJkbi5hYy51azwvYT4mZ3Q7LCBSb2JlcnRvIFBlb24gJmx0OzxhIGhyZWY9Im1h aWx0bzpmZW5peEBmYi5jb20iPmZlbml4QGZiLmNvbTwvYT4mZ3Q7LCBNaXJqYSBLdWVobGV3aW5k ICZsdDs8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20iPm1pcmph Lmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPC9hPiZndDssIE1pa2tlbA0KIEZhaG7DuGUgSsO4cmdl bnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSI+bWlra2VsZmpAZ21h aWwuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWlj QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1 aWNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7Qm9yZGVyLCBKb2huJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86am9obi5ib3JkZXJAaHVnaGVzLmNvbSI+am9obi5ib3JkZXJAaHVnaGVzLmNvbTwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBJcyAmcXVvdDtWZXJzaW9uIEdyZWFzaW5n JnF1b3Q7IGEgbmV3IGJlbmZpdCBvciBhIG5ldyBvYnN0YWNsZT88L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gNC8xMi8yMDE5IDg6NTcgQU0sIElhbiBTd2V0dCB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4N Cjxicj4NCjxiPi4uLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlZlcnNpb24gZ3JlYXNpbmcgd2lsbCBjcmVhdGUgcHJvYmxlbXMgZm9y IEREb1MgcHJvdGVjdGlvbi4gVGhlIEREb1MgcHJvdGVjdGlvbiBtaWRkbGVib3ggd2lsbCBoYXZl IHRvIHRyZWF0IGFsbCB0cmFmZmljIHdpdGggdW5rbm93biB2ZXJzaW9uIG51bWJlcnMgYXMgcGxh aW4gb2xkIFFVSUMgYW5kIHJhdGUgbGltaXQNCiBpdC4gQW55IHNvbHV0aW9uIHRoYXQgcmVxdWly ZXMgcGVyIGNvbm5lY3Rpb24gc3RhdGUgdG8gdHJhY2sgdmVyc2lvbiBudW1iZXJzIGRvZXNu4oCZ dCBzY2FsZS4gRXNwZWNpYWxseSBpbiB0aGUgY2xvdWQgc2NlbmFyaW8gY3VzdG9tZXJzIGJyaW5n IHRoZWlyIG93biB3ZWIgc2VydmVycyBzbyB0aGlzIG1ha2VzIGFueSBvcHQtb3V0IHNvbHV0aW9u IG5vdCBnb29kIGVub3VnaC4gU28gSSBkbyB0aGluayB0aGlzIGlzIGFuIG9ic3RhY2xlIGZvciBt YW55DQogZGVwbG95bWVudHMuIDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+RG9u J3Qgd2UgaGF2ZSBhbiBleGFtcGxlIG9mIG1pZGRsZS1ib3ggb3NzaWZpY2F0aW9uIGp1c3QgdGhl cmU/PG86cD48L286cD48L3A+DQo8cD5QcmF2ZWVuJ3MgZXhhbXBsZSBwb2ludHMgdG8gdGhlIHBl cmlscyBvZiB0aGUgJnF1b3Q7c2hvcnRlc3QgcGF0aCZxdW90OyBhcHByb2FjaCB0byBtaWRkbGUt Ym94IGRlc2lnbi4gVGFraW5nIHRoZSBzaG9ydGVzdCBwYXRoIG1lYW5zIGZpbmRpbmcgc29tZXRo aW5nIHRoYXQgd29ya3Mgbm93LCBhbmQgb25jZSB5b3UgaGF2ZSBmb3VuZCBpdCBkZXBsb3kgaXQg d2l0aG91dCB3b3JyeSBhYm91dCBjb25zZXF1ZW5jZXMgLS0gd2hpY2ggdmVyeSBvZnRlbiBpbmNs dWRlDQogb3NzaWZpY2F0aW9uLiBJZiB0aGUgRERPUyBwcm90ZWN0aW9uIGJveCBsb29rcyBmb3Ig JnF1b3Q7UVVJQyB2ZXJzaW9ucyB0aGF0IGl0IGtub3dzJnF1b3Q7IGFuZCBqdXN0IHJhdGUgbGlt aXRzIHRoZSBvdGhlciB0eXBlcyBvZiBwYWNrZXRzLCB0aGVuIHRoZSBib3ggd2lsbCBieSBkZXNp Z24gcHJldmVudCBkZXBsb3ltZW50IG9mIHZlcnNpb25zIHRoYXQgaXQgZG9lcyBub3Qga25vdy4N CjxvOnA+PC9vOnA+PC9wPg0KPHA+SSBhc3N1bWUgdGhhdCBiaWcgb3JnYW5pemF0aW9ucyBsaWtl IEF6dXJlIHdpbGwgdXBkYXRlIHRoZWlyIHByb3RlY3Rpb25zIG9uY2UgYSBuZXcgdmVyc2lvbiBp cyBvdXQsIGJ1dCB0aGUgZXhwZXJpZW5jZSBzaG93cyB0aGF0IG1hbnkgb3RoZXIgb3JnYW5pemF0 aW9ucyBkb24ndC4gQW5kIGV2ZW4gd2hlbiB0aGV5IGRvLCB0aGUgZm9jdXMgb24gcHVibGlzaGVk IHZlcnNpb25zIHdpbGwgYmxvY2sgZXhwZXJpbWVudGluZyB3aXRoIG5ldyB2ZXJzaW9ucywNCiBu b3QgdG8gbWVudGlvbiBpbnRlcmZlcmluZyB3aXRoIG90aGVyIGZlYXR1cmVzIGxpa2UgY29ubmVj dGlvbiBtaWdyYXRpb24uIEkgdGFrZSBQcmF2ZWVuJ3MgZXhhbXBsZSBhcyBhbiBhcmd1bWVudCB3 aHkgd2Ugc2hvdWxkIGluIGZhY3Qgc3RhbmRhcmRpemUgdmVyc2lvbiBncmVhc2luZywgcHJlY2lz ZWx5IHRvIGF2b2lkIHRoaXMgJnF1b3Q7c2hvcnRlc3QgcGF0aCBtaWRkbGUtYm94IGRlc2lnbiZx dW90Oy4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+SW4gdGhlIGNhc2Ugb2YgRERPUyBwcm90ZWN0aW9u LCBJIHdpbGwgcG9pbnQgb3V0IHRoYXQgRERPUyBwcm90ZWN0aW9uIGFsc28gbmVlZHMgdG8gd29y ayB3aXRoIHNob3J0IGhlYWRlciBwYWNrZXRzLCB3aGljaCBkbyBub3QgY2FycnkgYW55IHZlcnNp b24gbnVtYmVyLiBJbiBvcmRlciB0byBhdm9pZCBERE9TIGJ5IHNob3J0IGhlYWRlciBwYWNrZXRz LCB0aGUgYm94ZXMgaGF2ZSB0byBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gcGFja2V0 cw0KIHRoYXQgYmVsb25nIHRvIGF1dGhvcml6ZWQgY29ubmVjdGlvbnMgYW5kIHBhY2tldHMgdGhh dCBkb24ndC4gQW5kIGlmIHlvdSBkbyB0aGF0LCB0aGVuIHlvdSBkb24ndCByZWFsbHkgbmVlZCB0 byBsb29rIGF0IHRoZSB2ZXJzaW9uIG51bWJlcnMsIHlvdSBjYW4gc2ltcGx5IHJlbHkgb24gdGhl IGludmFyaWFudHMuPG86cD48L286cD48L3A+DQo8cD4tLSBDaHJpc3RpYW4gSHVpdGVtYTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BDEE786D9CCE457F946A8CC195E3CDA8fbcom_-- From nobody Fri Apr 12 09:50:13 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162A31202E5 for ; Fri, 12 Apr 2019 09:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqYUcXU07JN4 for ; Fri, 12 Apr 2019 09:50:09 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC95120072 for ; Fri, 12 Apr 2019 09:50:09 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id x132so16851780itf.2 for ; Fri, 12 Apr 2019 09:50:09 -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=qHvMF/M2zX4SdK9gH2o6urj/w40zuJe/40DjwpDM9To=; b=trWzAbDrPUSrhfLVWld/4tAwgW2BhoVcm1yFXEcacxdFiFvTcv4EUv2wFKMtSCiTUU l68UC7qpwNrgHFEd6kIXdFS++1hQRKg78M8SmYkWYtgmkTLFsBtD5bBAIIYs0DauW6IE 5QWzPjKhAHL6wvhto7a9GZhoWoVV99Aim/3qYKB1RPMmw24fQjN4Z3RcBEMT3E/7spUt PhSBnDUZkFMSK4HlO9B/QQNPfjCfOoIbdrvGblKyoGH53vPrLL2dr41QD2aPP1TIc9Um LtmghHwC1nOZikRiEjii9pAkV9VR9AEew24bceVGV5fIN72DNPsGdGrqZUIUbOquXrUP SMSg== 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=qHvMF/M2zX4SdK9gH2o6urj/w40zuJe/40DjwpDM9To=; b=dbWVvTS/dGlqiNV2rCzFa/RTMI7+Wjun2RnJkadvo6CC+gJf1ON7uhNc+RuDtYJOBb yCLg/SjisKU2YtUN9qj1tC1TnzdPgw9cGhjjtbAH3LOb8u+6JVUwbOxX5zsRjB+SXJyL nbw8nqkXf+0d+HyNU1+KijfLLQgO2SsE2Tw7WTxLQ6b8btTqwhnPOAfHFW0mnZLzzbL6 EiJ8Jr+Y6ceXOv7gFWKR5nf5ey3BBRsSPqPTU4C2OxT20FAU5mvN3B4DMm+tpSP57ilW hXUvV4cdfZtjiOVdjHImK2HwjPhIWLD9k5/rq0jugBGt+VMI4w1/M2FFP7J944aFA4iD Q6xQ== X-Gm-Message-State: APjAAAVPsyEFuPWUahg8KTLv1NW+6LHPYgG3UXIGZiy5Hbx32rJ+0ZqY ARifhKDhKpGaciytyK8rfpfz+vYdQm7wzQnaFIY= X-Google-Smtp-Source: APXvYqwZ7YY1oYesxksdCPbuZKZrx+GHMFhxTj1ongRnFKWKTew0lzWq4C/rB4ed9pbD1C07X/FHZd8bV48PBkTucwE= X-Received: by 2002:a02:ab90:: with SMTP id t16mr41644502jan.119.1555087808513; Fri, 12 Apr 2019 09:50:08 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 12 Apr 2019 09:50:08 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 12 Apr 2019 09:50:08 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: Praveen Balasubramanian , Roberto Peon , Ian Swett , Christian Huitema Cc: "Gorry (erg)" , "quic@ietf.org" , "Border, John" , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="0000000000006bca1a05865818ff" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:50:11 -0000 --0000000000006bca1a05865818ff Content-Type: text/plain; charset="UTF-8" On 12 April 2019 at 18.42.45, Roberto Peon (fenix@fb.com) wrote: pseudo-randomly or according to the lunar calendar, etc. We had that problem at Nokia a long time ago. Mobile phones had problems adjusting the calendar in certain regions because local time was dependent on people standing on hills looking at the moon. And sometimes it was cloudy. --0000000000006bca1a05865818ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 12 April 2019 at = 18.42.45, Roberto Peon (fenix@fb.com) w= rote:
=C2=A0pseudo-randomly or a= ccording to the lunar calendar, etc.= =C2=A0


We had th= at problem at Nokia a long time ago. Mobile phones had problems adjusting t= he calendar in certain regions because local time was dependent on people s= tanding on hills looking at the moon. And sometimes it was cloudy.

=
--0000000000006bca1a05865818ff-- From nobody Fri Apr 12 09:50:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FA512049D for ; Fri, 12 Apr 2019 09:50:18 -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 segD-yYDdYDT for ; Fri, 12 Apr 2019 09:50:16 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EF7120816 for ; Fri, 12 Apr 2019 09:50:15 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id p16so9065811iod.2 for ; Fri, 12 Apr 2019 09:50:15 -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=7VLwicLWuiUjEpoZ2pwbTpByE268MCK5CPM4uK4ekQ4=; b=Fs75l9NImYXfrxKIpmSUaLq3CBSjv0y+OfXHazFq19XbbFstUbAdAqDx19Ie6oHNEZ CYACoTlr0mYhTsbBeB2itm8kNLh4zeRu9hwQf3A5FRa8ESw3QCMIuFEVmHd1hXxFuW4a 4frSRfjNTY3ha/YlelLjapJYqJjruBKg6ITrYxZnnCiAiSFgGl3DbJAmdpBvpc6ufMN9 3+nMhx5CdC7ofMQOX9Nxv08Y67EZ0D2CwPyEnizoDdf8d3QChOTSN8gNpaDuiSyK5UES u8MNzZKhx48MeIC2Or9mojWorTzc2Qjc4parPEDZwGCsv8kGdsmM6OcCaET5h3WPcO2H Nc4g== 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=7VLwicLWuiUjEpoZ2pwbTpByE268MCK5CPM4uK4ekQ4=; b=DBVRe9Fo7DEF+wF44Fah4EdjhHSpHhAzGtUL6qZI+EkN2hlcSTSTeokqlgzdpPxj7Y E/FEbXgjzp2BlYyvoVo3WW0nSIG/twVnrG2CvjaFiBPe9nmuqxTxVAIfw1H3CdlzmhVJ UoXXgWecofoM6x04p20Ngq/U+rkX+lfacp4jLLoBFac0WHMQRsEbcKzvpxR/25clwjJH TRHCV6ID/HeSTQ/gR1EWJmQoOkv38axzHFJZXlxhH0o6XBaC3L8h78UTUZzCU3JHJhig lS5JTHCLOwGHMgk83dsyMiwNNUsiSbDOxZlHWhHRr+5PJbnZDhezebBGxdqsguUfCgvp xeAQ== X-Gm-Message-State: APjAAAU3yT3LJqD9HELnrYUSH/3mOjrcSg4Fg4m/JMRW0pNEOuFmDcEl W+tqFmBIKzvFwkU7tUOQJ/gh6+hWF21A7eoOWeM= X-Google-Smtp-Source: APXvYqysyhQnpanflSqcTluRWTMZu2luE7rH7pGOShbCpZnz8LyGNxXDpEdq+mpT9LrRBFm/N6mnWF3XcQlDW0Z+ldo= X-Received: by 2002:a6b:e50a:: with SMTP id y10mr16244042ioc.91.1555087815078; Fri, 12 Apr 2019 09:50:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Fri, 12 Apr 2019 09:49:48 -0700 Message-ID: Subject: Re: QUICker connection establishment with out-of-band validation tokens To: sy@informatik.uni-hamburg.de Cc: QUIC WG Content-Type: multipart/alternative; boundary="000000000000cffaa50586581868" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:50:23 -0000 --000000000000cffaa50586581868 Content-Type: text/plain; charset="UTF-8" I would like to suggest that the Chairs rule this out of scope for the QUIC working group to consider during the completion of v1. Given where we are in the process, taking on the security and privacy analyses required will not be a short or simple exercise. To give a flavor of the analysis required, consider this from the proposal: To save a round-trip time via the proposed out-of-band tokens, the client > needs to receive the token before sending the connection request to the corresponding > QUIC server. Furthermore, clients usually do a domain name query to look > up the source address before they send their connection request. Thus, > DNS seems to be a suitable place to distribute out-of-band tokens as the > connection request often directly follows the corresponding DNS lookup > First, this proposal contains major assumptions about the DNS interactions that would appear to run counter to DNS caching semantics and, more generally, its distribution by recursive resolvers. While it might be possible to overcome the implied limitations by the use of short TTLs and very aggressive use of EDNS client-subnet, the performance impact of doing so would be unknown and the privacy implications appear to be poor. Second, it requires a level of trust between the resolver operator and the entity generating the tokens that is near total, acknowledged in the draft here: Note, that to construct valid out-of-band tokens, the resolver needs to be > trusted by the server hosting the specific domain name. Thus, the > respective server operator shared in advance the instructions and the > secret keys required to generate valid tokens for this domain. > There are many additional questions raised by the proposal, including when to consider including the novel RR as additional data, the interaction with DNSSEC, and the potential need to use a STUN-like service to get a view of the IP as it will be seen by the QUIC-speaking server. I appreciate the work of the authors to consider out-of-bind distribution, but I do not believe this proposal should be considered by the working group at this time. regards, Ted Hardie (wearing no hats) On Fri, Apr 12, 2019 at 7:18 AM Erik Sy wrote: > Hi folks, > > I suggest introducing out-of-band validation tokens to save a round-trip > time during QUIC's connection establishment. > These tokens can be distributed via DNS resolvers or other QUIC servers > and can avoid up to 100% of stateless retries during connection > establishments. > Below is a detailed description and evaluation on performance, security, > privacy and scalability of this proposal: > > https://svs.informatik.uni-hamburg.de/publications/2019/2019-04-12-Sy-preprint-QUICker_connection_establishment_with_out-of-band_validation_tokens.pdf > > Best, > Erik > > --000000000000cffaa50586581868 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to suggest that the Chairs rule this out= of scope for the QUIC working group to consider during the completion of v= 1.=C2=A0 Given where we are in the process, taking on the security and priv= acy analyses required will not be a short or simple exercise.
To give a flavor of the analysis required, consider this from t= he proposal:

To save a = round-trip time via the proposed out-of-band tokens, the client needs to receive the token b= efore sending the connection request to the corresponding QUIC server. Furthermore, = clients usually do a domain name query to look up the source address before they send their c= onnection request. Thus, DNS seems to be a suitable place to distribute out-of-b= and tokens as the connection request often directly follows the corresponding DN= S lookup

First, this proposal = contains major assumptions about the DNS interactions that would appear to = run counter to DNS caching semantics and, more generally, its distribution = by recursive resolvers.=C2=A0 While it might be possible to overcome the im= plied limitations by the use of short TTLs and very aggressive use of EDNS = client-subnet, the performance impact of doing so would be unknown and the = privacy implications appear to be poor.=C2=A0 Second, it requires a level o= f trust between the resolver operator and the entity generating the tokens = that is near total, acknowledged in the draft here:

Note, that to construct valid out-of-ba= nd tokens, the resolver needs to be trusted by the server hosting the specific domai= n name. T= hus, the respective server operator shared in advance the instructions and the secre= t keys required to generate valid tokens for this domain.
<= div>
There are many additional questions raised by the propos= al, including when to consider including the novel RR as additional data, t= he interaction with DNSSEC, and the potential need to use a STUN-like servi= ce to get a view of the IP as it will be seen by the QUIC-speaking server.= =C2=A0

I appreciate the work of the authors t= o consider out-of-bind distribution, but I do not believe this proposal sho= uld be considered by the working group at this time.=C2=A0
<= br>
regards,

Ted Hardie
(weari= ng no hats)
=C2=A0

=
On Fri, Apr 12, 2019 at 7:18 AM Erik = Sy <sy@informatik.uni-ha= mburg.de> wrote:
Hi folks,

I suggest introducing out-of-band validation tokens to save a round-trip ti= me during QUIC's connection establishment.
These tokens can be distributed via DNS resolvers or other QUIC servers and= can avoid up to 100% of stateless retries during connection establishments= .
Below is a detailed description and evaluation on performance, security, pr= ivacy and scalability of this proposal:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0
https://svs.informatik.un= i-hamburg.de/publications/2019/2019-04-12-Sy-preprint-QUICker_connection_es= tablishment_with_out-of-band_validation_tokens.pdf

Best,
Erik

--000000000000cffaa50586581868-- From nobody Fri Apr 12 10:58:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D189C1200B1 for ; Fri, 12 Apr 2019 10:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 TADO-e8MOgur for ; Fri, 12 Apr 2019 10:58:13 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8F51203B7 for ; Fri, 12 Apr 2019 10:58:13 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id k2so12272582qtm.1 for ; Fri, 12 Apr 2019 10:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=dguaPTM5S0wLhJNv41zfI5SnYV6x7HkPtDq+vrxkrik=; b=HIq0O+eYGy8QU/8FRh3K/rZQQO98cOjGFfXqneh2aF/TXssmgydo8Kuj6SBK8/Wkot pBaWYZek2SZg/5gRY6uFUvKBWKjapiTrUsSm1BIipZy078BRDWKH+kDkaZtKHoXI3znM KsaTSldKyHLJ4t/YUoSphD4Y9KUGfN+JiPP5tIfQdAr4I3ApYnFQKOCwDwZBRP7fUu8P AG1omo1oH6eByWbRn9IJAyD7M2LhpMziWEIYYUNyMIpHmCpSfjkKVJcseMlBpdHe9Blw E3QODXa7quaiV072cnIWh9M0ngDAaNb237QB8Z4agZgRaWVKsNPhnoRdiC2bdillol7p SNsw== 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=dguaPTM5S0wLhJNv41zfI5SnYV6x7HkPtDq+vrxkrik=; b=Gt0N5qK4tWHCIZVXH35Hiy1+oSj/JhH8vJB2D+I/1Bwutg6Z+ggNIDkcxaPNYgyee+ o645LXdcdAjsuWtMvLhy97R7h9PDoI+kGf0F1SZEokMDQrd4jOusr2pTTHF/i6zy5jCR jfVaM/utxJPRpn5fFntKeyUa/Fh5N7Uho+r3vNI6quyojalQNxk/ZxAVSZYFCcRpnzsU Ybe65jNzUm96atp9pXf3xS1sZv9UJDTmYyc9/NK8/VLsmXn4TTxTWuOKCM57pIT8Um+m 4vZRxn9N4rgy4mOSjlcyGUY1T5PPBR6SnshtuSgwzV0qJZlnN1Fc1a06cDLG8zr5QDR4 N2lw== X-Gm-Message-State: APjAAAXnTSjEx1QCuTgocbzhjqxYIE42RcrD/0B2KXHWqGmkeTQWk3QQ JbHah3AoNlUrENokJQ+qg93zEQ== X-Google-Smtp-Source: APXvYqxcPi6zMyelFGlQ4wxw399KHjm6ptI+NkrKqs7EWsBNTS5uwZwrS6aSSQanpUxRuOibsKtavw== X-Received: by 2002:ac8:32f2:: with SMTP id a47mr47600608qtb.251.1555091892720; Fri, 12 Apr 2019 10:58:12 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id x14sm27679973qtc.44.2019.04.12.10.58.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 10:58:11 -0700 (PDT) Date: Fri, 12 Apr 2019 13:58:06 -0400 From: Dmitri Tikhonov To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= Cc: Praveen Balasubramanian , Roberto Peon , Ian Swett , Christian Huitema , "Gorry (erg)" , "quic@ietf.org" , "Border, John" , Mirja Kuehlewind Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? Message-ID: <20190412175805.GA13348@ubuntu-dmitri> Mail-Followup-To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Praveen Balasubramanian , Roberto Peon , Ian Swett , Christian Huitema , "Gorry (erg)" , "quic@ietf.org" , "Border, John" , Mirja Kuehlewind References: <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 17:58:16 -0000 On Fri, Apr 12, 2019 at 09:50:08AM -0700, Mikkel Fahne Jrgensen wrote: > We had that problem at Nokia a long time ago. Mobile phones had problems > adjusting the calendar in certain regions because local time was dependent > on people standing on hills looking at the moon. And sometimes it was > cloudy. I'd love to hear the full story! I googled "nokia phone adjust time look at moon," [1] but nothing came up. - Dmitri. 1. https://www.google.com/search?q=nokia+phone+adjust+time+look+at+moon From nobody Fri Apr 12 11:29:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E6A120886 for ; Fri, 12 Apr 2019 11:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLRqaYoyxjAv for ; Fri, 12 Apr 2019 11:29:35 -0700 (PDT) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BA7120822 for ; Fri, 12 Apr 2019 11:29:34 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id y134so17374608itc.5 for ; Fri, 12 Apr 2019 11:29:34 -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=Gyb46nsEVB2xDR9xtLVhNA5A7Ed2RAIThCDVYMUPsEQ=; b=dCiwBVYvk0hnIqzD865Z9amH2ZMl0lkp1nNH9iIpOktoy9B3j+oEXk2wJy7gwYvTqK wNERJoV/KQXeG/DmU04i1B03OB1iPKruJF2kUH51TiHjn5BMy/nMUnViu6V3HIOwBmiE S6/DI9iZVWq2s2yM9vZuSd1ksK4ZgOSpfiwtIDupSzEnNH7Vf97WrVHBhHEa7LgIch10 XxBVX850uvlfkILivfB89SGmlpso4SPcP6eILw+Du8EOvD0v2BCXuEUJKzsDYkaefl9J foM/ayZj3bJt7i+V+11EMJ/QB0PW2QOG3viNLdbIKC3mnrKKt79ese4tGJrYNVJ8tXFf 3Lxg== 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=Gyb46nsEVB2xDR9xtLVhNA5A7Ed2RAIThCDVYMUPsEQ=; b=b6mcx8/TaCTqXv6ZrOL/WbQG7/C8oz1SeUSQe+bJfDrZ/dAXP2SejWu4yIciEDX0N5 Te+/im4uAH1mdYQ+hz2mY39pRM49yUa1OLMkxa+p6pqsYLHXhKIlVIa3RxM48eepOjrQ vsgiP92B9AO/RCOyAV+fjmg/p6QQTY4q5AemVqDQtoDrzSeniYyxeHbXXc/ZrD7VXSrM zLQGeumINh2pUe7a0zxlbk1IN7UtjlGG6OFVwxE9CdrlFK9grSIeGAt5z14mgk/2uWQq 5MX41P+3gpvk0OecwdAT9P7cPzwVPKHOdUk2QFIuOK64cxvCoQKHNUQwQzHoiYFHzIOv vy+w== X-Gm-Message-State: APjAAAWoiRGkEDCBGRdQ1C2txp8r/R4NJfpID8GdYQgEgDbzCWU5tcwp WyvyKfrLMOaWfeopVKEWSmRjx9uUZffE6oZr8TQ= X-Google-Smtp-Source: APXvYqwbaLHHKKjrStaMCxXe63EAFmXIYepx19D9oDXqYMU/jWc5EYoPmm0SsrDqO0rDU4yFI0nry/aWcIR9ZKBc83c= X-Received: by 2002:a24:c544:: with SMTP id f65mr14396427itg.90.1555093774154; Fri, 12 Apr 2019 11:29:34 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 12 Apr 2019 11:29:33 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <20190412175805.GA13348@ubuntu-dmitri> References: <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> <20190412175805.GA13348@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 12 Apr 2019 11:29:33 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: Dmitri Tikhonov Cc: "quic@ietf.org" , Roberto Peon , "Border, John" , Ian Swett , Christian Huitema , "Gorry (erg)" , Mirja Kuehlewind , Praveen Balasubramanian Content-Type: multipart/alternative; boundary="000000000000003ef10586597cd7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 18:29:42 -0000 --000000000000003ef10586597cd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "Each month of the Islamic calendar commences on the birth of the new lunar cycle. Traditionally this is based on actual observation of the crescent (*hilal *) marking the end of the previous lunar cycle and hence the previous month, thereby beginning the new month. Consequently, each month can have 29 or 30 days depending on the visibility of the moon, astronomical positioning of the earth and weather conditions." https://en.wikipedia.org/wiki/Islamic_calendar I believe some sort of standardisation took place to accommodate electronic calendars. I=E2=80=99m not familiar with the details, but I did have some c= oworkers working on time algorithms in the S30 series (from the 3310 team) who had been struggling with that problem. Mikkel On 12 April 2019 at 19.58.13, Dmitri Tikhonov (dtikhonov@litespeedtech.com) wrote: On Fri, Apr 12, 2019 at 09:50:08AM -0700, Mikkel Fahn=C3=B8e J=C3=B8rgensen= wrote: > We had that problem at Nokia a long time ago. Mobile phones had problems > adjusting the calendar in certain regions because local time was dependent > on people standing on hills looking at the moon. And sometimes it was > cloudy. I'd love to hear the full story! I googled "nokia phone adjust time look at moon," [1] but nothing came up. - Dmitri. 1. https://www.google.com/search?q=3Dnokia+phone+adjust+time+look+at+moon --000000000000003ef10586597cd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = "Each month of the Islamic calendar commences on the birth of= the new lunar cycle. Traditionally this is based on actual observation of = the crescent (hilal) marking the end of the previous lunar cycle and h= ence the previous month, thereby beginning the new month. Consequently, eac= h month can have 29 or 30 days depending on the visibility of the moon, ast= ronomical positioning of the earth and weather conditions."


<= /div>
I believe som= e sort of standardisation took place to accommodate electronic calendars. I= =E2=80=99m not familiar with the details, but I did have some coworkers wor= king on time algorithms in the S30 series (from the 3310 team) who had been= struggling with that problem.

Mikkel

On 12 April 2019 at 19.58.= 13, Dmitri Tikhonov (dtikhon= ov@litespeedtech.com) wrote:

On Fri, Apr 12, 2019 at 09:50:08AM -0700,= Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> We had that problem at Nokia a long time ago. Mobile phones had pr= oblems
> adjusting the calendar in certain regions because local time was d= ependent
> on people standing on hills looking at the moon. And sometimes it = was
> cloudy.

I'd love to hear the full story! I googled "nokia phone adjus= t time
look at moon," [1] but nothing came up.

- Dmitri.

1. https://www.google.com/search?q=3Dnokia+phone+adjust+time+lo= ok+at+moon
--000000000000003ef10586597cd7-- From nobody Fri Apr 12 12:08:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3191120811 for ; Fri, 12 Apr 2019 12:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 J3XLCmxEvPAQ for ; Fri, 12 Apr 2019 12:07:59 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C155A1207A0 for ; Fri, 12 Apr 2019 12:07:58 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id v14so12212006wmf.2 for ; Fri, 12 Apr 2019 12:07: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=UnG9L1ATBiS8OL7jJzGMlPLV3UzKEx8AeMM39UmHLq4=; b=f5Pbimna6jENn4WFuM6qnGzMWtfiF8CwKWWUFsC2VcuPU/CDy/NuA5C0KtihlNZY3R 4x90EGczdiczid8GSXp9BnkfkbITFPvMk98fpinPcd9sWuM+GAOMNALFE35SJrpIayPR UGRwBPiy02q4gxD2m26F4DtyL3+ShHYwQVxX5ssOHFIiDBZwP+GBU/d+sttnVHHSXcPu O8/33acTuehFkFDWNxfHDLkfWgKpnsTtYHwek42U1UqzqfnawI2GREwMYXpERgkukrFx nLfrGf5V006Mpmry2QTGDsZr0mprEgwsu1vz6aQ/N6ve3g9t7PhyxPQNEKQHCtbd0i7b HuKw== 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=UnG9L1ATBiS8OL7jJzGMlPLV3UzKEx8AeMM39UmHLq4=; b=BDbaU76Lvv+iYcPbl2UoBnzK0OTP/Ya1vtdLDPCfe/L7o0EdvcVQ8hmy1sj60R3zkb ZgVoqULCZVOYlH5nraTLv0k+EtqkccckLutOSQufkKc24pfleYESeEpagzx1I5D87kYF 37UQnM58RwDm+BRaEDebjBBp+0oyxUh3F2uH3b8WHg7fjekLV8PTSgu/huHnSd5aIo0+ nRi3+m6lA/kFwa1PKbr877SHmZY38uXObGQAIhgpV0LO3nv2fL0VM/T72wNmET+yhDsb /DMJc5YsgN9HwRSOxRXhGjtfMsHfU5AdFqGTlKGme5/7W26gB/3x9Sxdx+WzMECxMD4I Rduw== X-Gm-Message-State: APjAAAXH/5Dnk5uGBPJCTs13DIEYb459gM3xW/y7jPxzs5Rj66gQZzm1 T4uJxGhwHwJdg1ZARJ2wY3jj7zSC20bxOh5oQtZrSA== X-Google-Smtp-Source: APXvYqwAzuMNklmNSSX5Hp4YbweEU2IsO65W6ZINGue5wp8kNrqijHfAK4hFi74UgbisC4QX/ttidS4e+p4S0dHMxxg= X-Received: by 2002:a7b:c5d6:: with SMTP id n22mr12033102wmk.112.1555096076797; Fri, 12 Apr 2019 12:07:56 -0700 (PDT) MIME-Version: 1.0 References: <1699de63-a670-4c45-8d5a-d85303c4db83@www.fastmail.com> <50cde2d5-eb25-4947-a5b9-4d0bc36c2c3c@www.fastmail.com> <790e8897-310e-4800-b0b0-dd54d934c782@www.fastmail.com> <6fb2a0b7-c3cf-45a0-8824-0cae384be1cc@www.fastmail.com> In-Reply-To: <6fb2a0b7-c3cf-45a0-8824-0cae384be1cc@www.fastmail.com> From: Ian Swett Date: Fri, 12 Apr 2019 15:07:43 -0400 Message-ID: Subject: Re: Version Negotiation Greasing To: Martin Thomson Cc: Mirja Kuehlewind , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Kazuho Oku , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000402cf605865a0582" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 19:08:01 -0000 --000000000000402cf605865a0582 Content-Type: text/plain; charset="UTF-8" I'd prefer to see this as an extension, but it seems like an interesting and useful proposal. Adding a lifetime seems fairly critical in order to allow key rotation. Originally I thought this belonged in NEW_TOKEN, but after further thinking I think a new frame(ie: Jana's NEW_VERSION) or a transport param are both fine. A transport param is easier, so unless it has some unacceptable technical issue(s), I'd be inclined to start with that and move to something more complex as necessary. I think removing the private use space to make this approach more feasible makes sense to me. It seemed like we were heading in that direction with other proposals(ie: randomizing new version numbers). On Wed, Apr 10, 2019 at 9:29 PM Martin Thomson wrote: > On Wed, Apr 10, 2019, at 23:04, Mirja Kuehlewind wrote: > > Further thinking about this. I do understand that this requirement is > > needed to actually avoid blocking of alt-version, however, would > > anybody actually be ever willing to implement this? If you service does > > not get connectivity with the alt-version, is it not very tempting to > > also try the actual version in order to serve your user/customer at all? > > The number of layers of fallback-and-retry that we maintain is already > fairly terrible[1], so I suspect that we'll skip that step and fall > straight back to h2. > > [1] We don't want to add to happy eyeballs, alt-svc, network-level > connection retries, the eventual parallel QUIC/h2 attempts, and HTTP > request-level retries. > > --000000000000402cf605865a0582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd prefer to see this as an extension, but it seems l= ike an interesting and useful proposal.

Adding a lifetim= e=C2=A0seems fairly critical in order to allow key rotation.

=
Originally I thought=C2=A0this belonged in NEW_TOKEN, but after = further thinking I think a new frame(ie: Jana's NEW_VERSION) or a trans= port param are both fine.=C2=A0 A transport param is easier, so unless it h= as some unacceptable technical issue(s), I'd be inclined to start with = that and move to something more complex as necessary.

<= div>I think removing the private use space to make this approach more feasi= ble makes sense to me.=C2=A0 It seemed like we were heading in that directi= on with other proposals(ie: randomizing new version numbers).
On Wed, = Apr 10, 2019 at 9:29 PM Martin Thomson <mt@lowentropy.net> wrote:
On Wed, Apr 10, 2019, at 23:04, Mirja Kuehlewind wrot= e:
> Further thinking about this. I do understand that this requirement is =
> needed to actually avoid blocking of alt-version, however, would
> anybody actually be ever willing to implement this? If you service doe= s
> not get connectivity with the alt-version, is it not very tempting to =
> also try the actual version in order to serve your user/customer at al= l?

The number of layers of fallback-and-retry that we maintain is already fair= ly terrible[1], so I suspect that we'll skip that step and fall straigh= t back to h2.

[1] We don't want to add to happy eyeballs, alt-svc, network-level conn= ection retries, the eventual parallel QUIC/h2 attempts, and HTTP request-le= vel retries.

--000000000000402cf605865a0582-- From nobody Fri Apr 12 12:21:35 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B261202CB for ; Fri, 12 Apr 2019 12:21:33 -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 I-c_TnJDGPM6 for ; Fri, 12 Apr 2019 12:21:30 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 86BD61201B6 for ; Fri, 12 Apr 2019 12:21:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 80C0D11F; Fri, 12 Apr 2019 21:21:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MhLjlpuzgigS; Fri, 12 Apr 2019 21:21:28 +0200 (CEST) Received: from users-MBP.fritz.box (i59F5756F.versanet.de [89.245.117.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 8A67311E; Fri, 12 Apr 2019 21:21:26 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de Subject: Re: QUICker connection establishment with out-of-band validation tokens To: Ted Hardie Cc: QUIC WG References: From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <252aa9cd-1d72-5020-cbd0-f3f15add13a2@informatik.uni-hamburg.de> Date: Fri, 12 Apr 2019 21:21:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 19:21:34 -0000 On 4/12/19 18:49, Ted Hardie wrote: > I would like to suggest that the Chairs rule this out of scope for the > QUIC working group to consider during the completion of v1.  Given > where we are in the process, taking on the security and privacy > analyses required will not be a short or simple exercise. > > To give a flavor of the analysis required, consider this from the > proposal: > > To save a round-triptime via the proposed out-of-band tokens, the > client needs to receive the token before sending the connection > request to the corresponding QUIC server. Furthermore, clients > usually do a domain name query to look up the source address > before they send their connection request. Thus, DNS seems to be a > suitable place to distribute out-of-band tokens as the > connectionrequest often directly follows the corresponding DNS > lookupFirst, this proposal contains major assumptions about the > DNS interactions that would appear to run counter to DNS caching > semantics and, more generally, its distribution by recursive > resolvers.  While it might be possible to overcome the implied > limitations by the use of short TTLs and very aggressive use of > EDNS client-subnet, the performance impact of doing so would be > unknown and the privacy implications appear to be poor.  Second, > it requires a level of trust between the resolver operator and the > entity generating the tokens that is near total, acknowledged in > the draft here: > The article proposes two different distribution mechanisms for out-of-band tokens. The distribution via DNS resolvers is certainly more difficult to realize as it is a cross-layer performance optimization. The second proposed distribution mechanism using QUIC connections to other hostnames is much simpler to implement. Thus, I suggest to consider this mechanism to be in scope for QUIC v1. > > Note, that to construct valid out-of-band tokens, the resolver > needs to be trusted by the server hosting the specific domainname. > Thus, the respective server operator shared in advance the > instructions and the secret keys required to generate validtokens > for this domain. > > To put this in context, the QUIC server allows another 'trusted' entity to issue valid tokens, however the QUIC server can always revoke this trust-relation with immediate effect. > There are many additional questions raised by the proposal, including > when to consider including the novel RR as additional data, the > interaction with DNSSEC, and the potential need to use a STUN-like > service to get a view of the IP as it will be seen by the > QUIC-speaking server.  > > I appreciate the work of the authors to consider out-of-bind > distribution, but I do not believe this proposal should be considered > by the working group at this time.  > > regards, > > Ted Hardie > (wearing no hats) >   > > On Fri, Apr 12, 2019 at 7:18 AM Erik Sy > wrote: > > Hi folks, > > I suggest introducing out-of-band validation tokens to save a > round-trip time during QUIC's connection establishment. > These tokens can be distributed via DNS resolvers or other QUIC > servers and can avoid up to 100% of stateless retries during > connection establishments. > Below is a detailed description and evaluation on performance, > security, privacy and scalability of this proposal:        > https://svs.informatik.uni-hamburg.de/publications/2019/2019-04-12-Sy-preprint-QUICker_connection_establishment_with_out-of-band_validation_tokens.pdf > > Best, > Erik > From nobody Fri Apr 12 13:39:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDCA1201B6 for ; Fri, 12 Apr 2019 13:39:32 -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 xPgKCdl9yuaF for ; Fri, 12 Apr 2019 13:39:30 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09FF1201A5 for ; Fri, 12 Apr 2019 13:39:29 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id f22so17883973ita.3 for ; Fri, 12 Apr 2019 13:39:29 -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=jxLLX/lwVru7xKspvPmOMnDQuonmFSSXX6PkQXpu2mU=; b=Gl+K7KbfMsHahRd3JuvYKzuvMwjTqez6qcY8BRw7wfHvxc+Fyubil5VjC/Vi/ASIT6 hfqKkxpKOTXshwp0gwttU/whDnW26ADz3xBwxj5fPGKM9x5iYxvsnsDaaoYIX7E3ko47 08TXvqiYUc8Dss8gnMTXHHGLQ3WS3ArDNhv0SzKEDiK9rKlXcVyJ+C3Z1DnCdsw32Ew8 Cv/8lo9k/OpOqOoGRaF+2tn62pWV/Hpvw6o5aLvw9NgKKdkX9G243f0SbG2PxDeXBNR3 eDsAAGjhoE4cJPq4DHfAODMOe9IT3uTz27bWbP8Z70kzf/m4j7IzRTz2D8cyj+ZL0ibn 0wWg== 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=jxLLX/lwVru7xKspvPmOMnDQuonmFSSXX6PkQXpu2mU=; b=VdoQpkFssKGID6K0UKQyb+S/InoEjN4IMIji5SiVpVzqnD3dWmByGUCFfVFKo2b1V8 BZ5rjM+7tzHChuzOXrnXgph/F8CPuzksg1ic5bRGThdq+R1vhyaOH2Ooir56s1nLPsK2 uaRWHnPasu+ZAGCs2OVEq5aYGtaVZ6WMsGyoL8lDGzIeWdPU6p6XsIG2kb0MmOpW/u5Y B4KUh98puZfZDAr1YHAWgIN1081aQDlYrmpEgJtItjANNS+7v0diT9UW37iDKj0xSuVz EsC8z/g7tty8j+32Az8hskCCIqF1aCnNpHqTYafz2L0KEWGTd32vIvHM4AUXXGsmysQo GjnA== X-Gm-Message-State: APjAAAWsjurL6kMpMltFk8uF+GffUxzw6hgBCMf/dgjZtNa/jkGkHtVq lf5E2vjJv38Wsdwz2Ldr2fF8OnK0M/HzuEZIPtE= X-Google-Smtp-Source: APXvYqzLPJKCcDXhIDZ37qIt8Z49njW6LwqN+tgHLeQQqIZuR8a2D1LBGT5gfTiP9MudwNS0b+SNXeBNq2i0XEl634M= X-Received: by 2002:a24:610b:: with SMTP id s11mr11974163itc.156.1555101569009; Fri, 12 Apr 2019 13:39:29 -0700 (PDT) MIME-Version: 1.0 References: <252aa9cd-1d72-5020-cbd0-f3f15add13a2@informatik.uni-hamburg.de> In-Reply-To: <252aa9cd-1d72-5020-cbd0-f3f15add13a2@informatik.uni-hamburg.de> From: Ted Hardie Date: Fri, 12 Apr 2019 13:39:02 -0700 Message-ID: Subject: Re: QUICker connection establishment with out-of-band validation tokens To: sy@informatik.uni-hamburg.de Cc: QUIC WG Content-Type: multipart/alternative; boundary="0000000000009c4e1205865b4c09" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 20:39:32 -0000 --0000000000009c4e1205865b4c09 Content-Type: text/plain; charset="UTF-8" Thanks for your rapid reply. More in-line. On Fri, Apr 12, 2019 at 12:21 PM Erik Sy wrote: > On 4/12/19 18:49, Ted Hardie wrote: > > The article proposes two different distribution mechanisms for > out-of-band tokens. The distribution via DNS resolvers is certainly more > difficult to realize as it is a cross-layer performance optimization. > The second proposed distribution mechanism using QUIC connections to > other hostnames is much simpler to implement. Thus, I suggest to > consider this mechanism to be in scope for QUIC v1. > > The proposal for an EXTERNAL_TOKEN frame has security properties and performance properties that would still need considerable analysis. If the token is associated with a hostname which is already present in the certificate for the TLS session, it's not clear why the token would need to be presented on a new connection. If it is not, then the client's trust that it is okay to receive a token for example.com from mumblefratz.example is based on very unclear principles. While you have addressed why you believe the client is not harmed by presenting a bad token, it is not clear to me that this is true for servers nor that server's behavior toward those clients presenting bad tokens will be consistent. I must reiterate my statement that I don't think this should in scope for v1 at all. regards, Ted --0000000000009c4e1205865b4c09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your rapid reply.=C2=A0 More in-line.
<= /div>
O= n Fri, Apr 12, 2019 at 12:21 PM Erik Sy <sy@informatik.uni-hamburg.de> wrote:
On 4/12/19 18:49, Ted Hardie w= rote:

The article proposes two different distribution mechanisms for
out-of-band tokens. The distribution via DNS resolvers is certainly more difficult to realize as it is a cross-layer performance optimization.
The second proposed distribution mechanism using QUIC connections to
other hostnames is much simpler to implement. Thus, I suggest to
consider this mechanism to be in scope for QUIC v1.


The proposal for an EXTERNAL_TOKEN frame has security prop= erties and performance properties that would still need considerable analys= is.=C2=A0 If the token is associated with a hostname which is already prese= nt in the certificate for the TLS session, it's not clear why the token= would need to be presented on a new connection.=C2=A0 If it is not, then t= he client's trust that it is okay to receive a token for example.com from mumblefratz.example is based on very = unclear principles.=C2=A0 While you have addressed why you believe the clie= nt is not harmed by presenting a bad token, it is not clear to me that this= is true for servers nor that server's behavior toward those clients pr= esenting bad tokens will be consistent.

I must rei= terate my statement that I don't think this should in scope for v1 at a= ll.

regards,

Ted
--0000000000009c4e1205865b4c09-- From nobody Fri Apr 12 14:19:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DFD1200EC for ; Fri, 12 Apr 2019 14:19:32 -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 5utNievQ4D4u for ; Fri, 12 Apr 2019 14:19:30 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 255C01200B5 for ; Fri, 12 Apr 2019 14:19:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 98C5B586; Fri, 12 Apr 2019 23:19:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g6fNELSVgYfi; Fri, 12 Apr 2019 23:19:27 +0200 (CEST) Received: from users-MBP.fritz.box (i59F5756F.versanet.de [89.245.117.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 0148E585; Fri, 12 Apr 2019 23:19:26 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de Subject: Re: QUICker connection establishment with out-of-band validation tokens To: Ted Hardie Cc: QUIC WG References: <252aa9cd-1d72-5020-cbd0-f3f15add13a2@informatik.uni-hamburg.de> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <47e5c52f-fb35-dac1-d52c-5b64600b8583@informatik.uni-hamburg.de> Date: Fri, 12 Apr 2019 23:19:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 21:19:32 -0000 > Thanks for your rapid reply.  More in-line. > > On Fri, Apr 12, 2019 at 12:21 PM Erik Sy > wrote: > > On 4/12/19 18:49, Ted Hardie wrote: > > The article proposes two different distribution mechanisms for > out-of-band tokens. The distribution via DNS resolvers is > certainly more > difficult to realize as it is a cross-layer performance optimization. > The second proposed distribution mechanism using QUIC connections to > other hostnames is much simpler to implement. Thus, I suggest to > consider this mechanism to be in scope for QUIC v1. > > > The proposal for an EXTERNAL_TOKEN frame has security properties and > performance properties that would still need considerable analysis. Yes, some performance properties are still unknown. Do you have some missing performance analysis in mind which can be conducted before QUIC v1 is deployed on the web? >   If the token is associated with a hostname which is already present > in the certificate for the TLS session, it's not clear why the token > would need to be presented on a new connection.  If it is not, then > the client's trust that it is okay to receive a token for example.com > from mumblefratz.example is based on very unclear > principles.  While you have addressed why you believe the client is > not harmed by presenting a bad token, it is not clear to me that this > is true for servers nor that server's behavior toward those clients > presenting bad tokens will be consistent. For out-of-band tokens it is assumed to be okay to receive a token for example.com from mumblefratz.example. The server does its validation as normal. If the token is bad, then the validation will fail and possibly a stateless retry follows to validate the client's source address. Otherwise, if the token is valid for the client's source address, then the server proceeds with the cryptographic handshake. However, if the number of unrequited connections which had presented an valid token from mumblefratz.example exceeds a defined threshold value, then the server will revoke its trust in tokens issued by mumblefratz.example. > I must reiterate my statement that I don't think this should in scope > for v1 at all. > > regards, > > Ted From nobody Fri Apr 12 16:36:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1341203F5 for ; Fri, 12 Apr 2019 16:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 5yAPSExTwC_E for ; Fri, 12 Apr 2019 16:36:21 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7691E120431 for ; Fri, 12 Apr 2019 16:36:21 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id g3so13904644wrx.9 for ; Fri, 12 Apr 2019 16:36:21 -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=29BUM2ZJO0VqA3hAKJEkkf4D51r+xG6u6n7bsrbgcWo=; b=Xr7GPuRxwT3iVu2yjlXAUJClc3lRltJo+nl22Ls4pAfuNHb8Dnb6YFbYgOsUTYek03 C+8MkpBy3Un7zcexn9a1bpwUknLY4soxVhYs0SNjZUEeeIDj43FcZz1/LZUBRQF8Msbs lbNZ1T6K20iye5uhcR28bCtDeo6CgGUST6EBTyh0GuN0IE+bjv5US+mKsSNI4Oc35Go+ cBSs1UzBbV2gfUsTRDyRrpxetYCldcCyViqIufgJookjZt2BOxgd+sjZ19GNkc1qiDki A8cJo7iAtdUkCjl8nFRRMbA35Oj7Ck/RHBhwo15qbrk7Cj0H7VNJ/rikzqGCfHUapccs xN8g== 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=29BUM2ZJO0VqA3hAKJEkkf4D51r+xG6u6n7bsrbgcWo=; b=YwuFLb/Ez80TQRIMrAr5y6rPLAnQhJmVoUMnQEXMnNNVoPd5vZXKmnlOw/n2tQP3yR CwkaEWutjpA03CeDmYPrRt0CJ4eAVH7mdfJ8REgUdts0Y0G7+LfXm2ezKoR3lR595KgK rlsrsRWovhz58bi+DttktnH/gvQz9BIDUOglRzVXTStzW+n+9mNFkxu64ITljT1gFDnU hhSehfbxsu9LenOe/P4jWwMaS8Pf0CVlzSQUxDJ//JY+ElCira4JImQBqI9XfmdoRyAc Npt9FR4toer+ushMpyxx+o10zApqgtLKZbvzZIe8T/6ggz2ecfJ5z/0ll6C2iwHh8Lb0 YV6w== X-Gm-Message-State: APjAAAXWYnGa77n9ulYnvZtAD0wHe3khB531vR8bBYF5TgVRiaV/pBf5 1TY4sLqnPH5iZ4T5pmHKvgPlXyc6vv5dHjGTGfL6fA== X-Google-Smtp-Source: APXvYqxb8ry9gACtSWw12fQjQYGurYyg/Gsrti55pmUZy2aKNC8zplOHOOho5PCKgcjRVCZb193CBdna3xy1fGAyKq8= X-Received: by 2002:adf:cd06:: with SMTP id w6mr38371919wrm.52.1555112179636; Fri, 12 Apr 2019 16:36:19 -0700 (PDT) MIME-Version: 1.0 References: <252aa9cd-1d72-5020-cbd0-f3f15add13a2@informatik.uni-hamburg.de> <47e5c52f-fb35-dac1-d52c-5b64600b8583@informatik.uni-hamburg.de> In-Reply-To: <47e5c52f-fb35-dac1-d52c-5b64600b8583@informatik.uni-hamburg.de> From: Ian Swett Date: Fri, 12 Apr 2019 19:36:07 -0400 Message-ID: Subject: Re: QUICker connection establishment with out-of-band validation tokens To: sy@informatik.uni-hamburg.de Cc: Ted Hardie , QUIC WG Content-Type: multipart/alternative; boundary="0000000000000df2fc05865dc56a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 23:36:24 -0000 --0000000000000df2fc05865dc56a Content-Type: text/plain; charset="UTF-8" I appreciate your work and this may be valuable in some use cases, but I also agree with Ted's concerns and I think it's clearly out of scope for QUIC v1. On Fri, Apr 12, 2019 at 5:19 PM Erik Sy wrote: > > > Thanks for your rapid reply. More in-line. > > > > On Fri, Apr 12, 2019 at 12:21 PM Erik Sy > > wrote: > > > > On 4/12/19 18:49, Ted Hardie wrote: > > > > The article proposes two different distribution mechanisms for > > out-of-band tokens. The distribution via DNS resolvers is > > certainly more > > difficult to realize as it is a cross-layer performance optimization. > > The second proposed distribution mechanism using QUIC connections to > > other hostnames is much simpler to implement. Thus, I suggest to > > consider this mechanism to be in scope for QUIC v1. > > > > > > The proposal for an EXTERNAL_TOKEN frame has security properties and > > performance properties that would still need considerable analysis. > Yes, some performance properties are still unknown. Do you have some > missing performance analysis in mind which can be conducted before QUIC > v1 is deployed on the web? > > If the token is associated with a hostname which is already present > > in the certificate for the TLS session, it's not clear why the token > > would need to be presented on a new connection. If it is not, then > > the client's trust that it is okay to receive a token for example.com > > from mumblefratz.example is based on very unclear > > principles. While you have addressed why you believe the client is > > not harmed by presenting a bad token, it is not clear to me that this > > is true for servers nor that server's behavior toward those clients > > presenting bad tokens will be consistent. > > For out-of-band tokens it is assumed to be okay to receive a token for > example.com from mumblefratz.example. The server does its validation as > normal. If the token is bad, then the validation will fail and possibly > a stateless retry follows to validate the client's source address. > Otherwise, if the token is valid for the client's source address, then > the server proceeds with the cryptographic handshake. > However, if the number of unrequited connections which had presented an > valid token from mumblefratz.example exceeds a defined threshold value, > then the server will revoke its trust in tokens issued by > mumblefratz.example. > > > I must reiterate my statement that I don't think this should in scope > > for v1 at all. > > > > regards, > > > > Ted > > --0000000000000df2fc05865dc56a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I appreciate your work and this may be valuable in some u= se cases, but I also agree with Ted's concerns and I think it's cle= arly out of scope for QUIC v1.

On Fri, Apr 12, 2019 at 5:19 PM Erik Sy <<= a href=3D"mailto:sy@informatik.uni-hamburg.de" target=3D"_blank">sy@informa= tik.uni-hamburg.de> wrote:

> Thanks for your rapid reply.=C2=A0 More in-line.
>
> On Fri, Apr 12, 2019 at 12:21 PM Erik Sy <sy@informatik.uni-hamburg.de > <mailto:sy@informatik.uni-hamburg.de>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 4/12/19 18:49, Ted Hardie wrote:
>
>=C2=A0 =C2=A0 =C2=A0The article proposes two different distribution mec= hanisms for
>=C2=A0 =C2=A0 =C2=A0out-of-band tokens. The distribution via DNS resolv= ers is
>=C2=A0 =C2=A0 =C2=A0certainly more
>=C2=A0 =C2=A0 =C2=A0difficult to realize as it is a cross-layer perform= ance optimization.
>=C2=A0 =C2=A0 =C2=A0The second proposed distribution mechanism using QU= IC connections to
>=C2=A0 =C2=A0 =C2=A0other hostnames is much simpler to implement. Thus,= I suggest to
>=C2=A0 =C2=A0 =C2=A0consider this mechanism to be in scope for QUIC v1.=
>
>
> The proposal for an EXTERNAL_TOKEN frame has security properties and > performance properties that would still need considerable analysis. Yes, some performance properties are still unknown. Do you have some
missing performance analysis in mind which can be conducted before QUIC
v1 is deployed on the web?
> =C2=A0 If the token is associated with a hostname which is already pre= sent
> in the certificate for the TLS session, it's not clear why the tok= en
> would need to be presented on a new connection.=C2=A0 If it is not, th= en
> the client's trust that it is okay to receive a token for example.com
> <http://example.com> from mumblefratz.example is based on very uncl= ear
> principles.=C2=A0 While you have addressed why you believe the client = is
> not harmed by presenting a bad token, it is not clear to me that this<= br> > is true for servers nor that server's behavior toward those client= s
> presenting bad tokens will be consistent.

For out-of-band tokens it is assumed to be okay to receive a token for
example= .com from mumblefratz.example. The server does its validation as
normal. If the token is bad, then the validation will fail and possibly
a stateless retry follows to validate the client's source address.
Otherwise, if the token is valid for the client's source address, then<= br> the server proceeds with the cryptographic handshake.
However, if the number of unrequited connections which had presented an
valid token from mumblefratz.example exceeds a defined threshold value,
then the server will revoke its trust in tokens issued by
mumblefratz.example.

> I must reiterate my statement that I don't think this should in sc= ope
> for v1 at all.
>
> regards,
>
> Ted

--0000000000000df2fc05865dc56a-- From nobody Sat Apr 13 02:47:44 2019 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 A4A411200E5; Sat, 13 Apr 2019 02:47:42 -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-invariants-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <155514886245.14736.15359092902883595545@ietfa.amsl.com> Date: Sat, 13 Apr 2019 02:47:42 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 09:47:43 -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 : Version-Independent Properties of QUIC Author : Martin Thomson Filename : draft-ietf-quic-invariants-04.txt Pages : 9 Date : 2019-04-12 Abstract: This document defines the properties of the QUIC transport protocol that are expected to remain unchanged over time as new versions of the protocol are developed. 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/-invariants [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-invariants/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-invariants-04 https://datatracker.ietf.org/doc/html/draft-ietf-quic-invariants-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-invariants-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 13 04:03:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBC712007A for ; Sat, 13 Apr 2019 04:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URNHoDRtumhF for ; Sat, 13 Apr 2019 04:03:52 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id B75CC120043 for ; Sat, 13 Apr 2019 04:03:51 -0700 (PDT) Received: from G-MacBook.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id C7A401B0007C; Sat, 13 Apr 2019 12:03:40 +0100 (BST) Message-ID: <5CB1C214.4030501@erg.abdn.ac.uk> Date: Sat, 13 Apr 2019 12:03:48 +0100 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roberto Peon CC: Praveen Balasubramanian , Christian Huitema , Ian Swett , =?UTF-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbg==?= =?UTF-8?B?c2Vu?= , "quic@ietf.org" , "Border, John" , Mirja Kuehlewind Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 11:03:55 -0000 Bringing this thread back - to me it seems there has been lots of discussion about how "version greasing" can be added in various ways, and very little on what makes this necessary and worth the impact on the network. I still don't do not see that the side effects are worse when the protocol requires the version to be unobfusticated (as in most other IETF transport protocols). Gorry On 12/04/2019, 17:41, Roberto Peon wrote: > > I’m not sure that I agree there—there is no need to have it > standardized so long as the LB is involved in picking it. Each LB > system can choose whatever it wants. Thus, every LB **deployment** > could use a different scheme with different grease. Every LB > deployment could change the scheme it uses pseudo-randomly or > according to the lunar calendar, etc. > > Because there is a dynamic (and controlling) component (namely the > part of the LB system which vends and then later routes CIDs), there > is no need for anything else. > > -=R > > *From: *Praveen Balasubramanian > *Date: *Friday, April 12, 2019 at 9:28 AM > *To: *Roberto Peon , Christian Huitema > , Ian Swett > *Cc: *"Gorry (erg)" , Mirja Kuehlewind > , Mikkel Fahnøe Jørgensen > , "quic@ietf.org" , "Border, John" > > *Subject: *RE: Is "Version Greasing" a new benfit or a new obstacle? > > Re. Encoding in CID. Then it needs to be standardized and if it is > standardized what’s the point in greasing? Let’s not ignore the > smaller services who use the cloud i.e. people deploying say NGINX web > servers in AWS, Azure or GCP. Not every QUIC deployment is a large > first party service which controls all aspects how LB and DDoS are > done. In public clouds LB and DDoS protection are network functions > (services) and are middleboxes under a completely different > administrative domain. > > Christian, this is about source address validation by the middlebox. > This is how it works for TCP (think SYN cookies) and we need to have > parity for QUIC. When under attack, short header packets will be > dropped for addresses that have not been validated, but this is the > same for non-SYN packets for TCP. I don’t understand how invariants > can be used here. If we don’t have parity for DoS protection in > network then QUIC traffic will be rate limited which is going to be > really bad for performance. FWIW there is already DoS traffic that > looks like QUIC. > > *From:* Roberto Peon > *Sent:* Friday, April 12, 2019 9:16 AM > *To:* Christian Huitema ; Ian Swett > ; Praveen Balasubramanian > *Cc:* Gorry (erg) ; Mirja Kuehlewind > ; Mikkel Fahnøe Jørgensen > ; quic@ietf.org; Border, John > *Subject:* Re: Is "Version Greasing" a new benfit or a new obstacle? > > For any large deployment, I suspect they’ll need LB. > > For most kinds of LB-ing, I’d expect the LB system to either directly > or indirectly be involved in choosing/vending connection IDs. > > If it is involved in vending/choosing connection IDs, it can encode > version information into the CID. > > -=R > > *From: *Christian Huitema > > *Date: *Friday, April 12, 2019 at 9:13 AM > *To: *Ian Swett >, Praveen > Balasubramanian > > *Cc: *"Gorry (erg)" >, Roberto Peon >, Mirja Kuehlewind > >, Mikkel Fahnøe Jørgensen > >, "quic@ietf.org > " >, > "Border, John" > > *Subject: *Re: Is "Version Greasing" a new benfit or a new obstacle? > > On 4/12/2019 8:57 AM, Ian Swett wrote: > > *From:* Praveen Balasubramanian > *...* > > Version greasing will create problems for DDoS protection. The > DDoS protection middlebox will have to treat all traffic with > unknown version numbers as plain old QUIC and rate limit it. Any > solution that requires per connection state to track version > numbers doesn’t scale. Especially in the cloud scenario customers > bring their own web servers so this makes any opt-out solution not > good enough. So I do think this is an obstacle for many deployments. > > Don't we have an example of middle-box ossification just there? > > Praveen's example points to the perils of the "shortest path" approach > to middle-box design. Taking the shortest path means finding something > that works now, and once you have found it deploy it without worry > about consequences -- which very often include ossification. If the > DDOS protection box looks for "QUIC versions that it knows" and just > rate limits the other types of packets, then the box will by design > prevent deployment of versions that it does not know. > > I assume that big organizations like Azure will update their > protections once a new version is out, but the experience shows that > many other organizations don't. And even when they do, the focus on > published versions will block experimenting with new versions, not to > mention interfering with other features like connection migration. I > take Praveen's example as an argument why we should in fact > standardize version greasing, precisely to avoid this "shortest path > middle-box design". > > In the case of DDOS protection, I will point out that DDOS protection > also needs to work with short header packets, which do not carry any > version number. In order to avoid DDOS by short header packets, the > boxes have to be able to distinguish between packets that belong to > authorized connections and packets that don't. And if you do that, > then you don't really need to look at the version numbers, you can > simply rely on the invariants. > > -- Christian Huitema > From nobody Sat Apr 13 17:45:29 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AEF120089 for ; Sat, 13 Apr 2019 17:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=rAMt5SOn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pdbifcf3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsvwcH21bdvG for ; Sat, 13 Apr 2019 17:45:22 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA489120059 for ; Sat, 13 Apr 2019 17:45:21 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9C63221B55 for ; Sat, 13 Apr 2019 20:45:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 13 Apr 2019 20:45:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=FVWTkrVGnl5sCeMgx9aLHofX9RXj6ALCjqw1mEgsQkY=; b=rAMt5SOn 9pDRSTvFQbaaHV+tv7bx6udvzF4oqQ/WqCniaMSbxOh0Hvi3NN0P52/Ft+EHKMBO Cc2zo0/x/HPONg+DdRvQbQnw+6FZR3PblVBuleI6TG9VdRcuFgC0AR52b06FndRp I/YC2MqleIpmb0HAQJEbP+/qV1hENDtp5RzqplW3AHP88fVzjZVg1t8vxlk8+yh/ teGmYMNlvEJj77RLzzOMz19j3EKQGIsF29bEqqwJ6rkwye8bKeXEemkoJYbiW8CC pImK+yh+noihsfTwDVnO4okNOQUK/MTXZCsZQ0QYoZ+189++NIciEKXZQCoFz2eJ vDH4f5pcjFXfyA== 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-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=FVWTkrVGnl5sCeMgx9aLHofX9RXj6 ALCjqw1mEgsQkY=; b=pdbifcf3aZPWjTo81I5llsBLaYjEbADurea040WyDDe33 wDD0GKehMOkfSnzsfRnOBM1SpjF8y9GqTDwXAN7JzndjjfjoesVXvC+R+VHKaMKZ fz26B+9zwwgpg2Xx1iV4/SEB8LIkGgkxcL1AYIRO/VU+GYhq18ryMLSO7r/7/jkO YDoQKBqCTshaAoL43noWYbg87okeRwEvrQ0P+s3CyBc3aPEiV+aCC0b73gFmJWeF dzaWcvb+kPcuYHXq9P7Fs+J5+se4BjNDPGNNpXml2PNZhWvSGCGemWImJtmS5dpL 2bUlTuHTtCdyaCh7K6N2OHzdDtE6quSvecPfCuObA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvdeigdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepudduledrledrgeefrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id D2E171030F for ; Sat, 13 Apr 2019 20:45:18 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 896C8C0400 for ; Sun, 14 Apr 2019 00:45:15 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============3275883671652854553==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190414004515.896C8C0400@cloud.mnot.net> Date: Sun, 14 Apr 2019 00:45:15 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2019 00:45:26 -0000 --===============3275883671652854553== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+7/-4/=F0=9F=92=AC40) 7 issues created: - latest_rtt can be zero (by janaiyengar) https://github.com/quicwg/base-drafts/issues/2616 [-recovery] [design] = - lost_pn can go negative (by larseggert) https://github.com/quicwg/base-drafts/issues/2611 [-recovery] = - RTT Initial measurement (by goelvidhi) https://github.com/quicwg/base-drafts/issues/2607 = - HTTP/3 reserved value range (by LPardue) https://github.com/quicwg/base-drafts/issues/2606 = - Pseudocode fix: Data should be sent on loss-threshold timer (by janaiye= ngar) https://github.com/quicwg/base-drafts/issues/2604 [-recovery] [editoria= l] = - Idle timeout needs more description and a recommendation (by janaiyenga= r) https://github.com/quicwg/base-drafts/issues/2602 [-transport] [design] = - Use short headers for stateless reset (by martinthomson) https://github.com/quicwg/base-drafts/issues/2599 [-transport] [has-pro= posal] = 10 issues received 40 new comments: - #2607 RTT Initial measurement (9 by goelvidhi, marten-seemann, janaiyen= gar, kazuho, martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/2607 [-recovery] [editoria= l] = - #2602 Idle timeout needs more description and a recommendation (8 by ka= zuho, ianswett, janaiyengar, martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/issues/2602 [-transport] = - #2604 Pseudocode fix: Data should be sent on loss-threshold timer (5 by= janaiyengar, ianswett) https://github.com/quicwg/base-drafts/issues/2604 [-recovery] [editoria= l] = - #2555 Define idle period for congestion control (5 by janaiyengar, prav= b, ianswett) https://github.com/quicwg/base-drafts/issues/2555 [-recovery] [design] = - #2593 Persistent congestion interaction with app limited state (4 by si= yengar, janaiyengar, ianswett) https://github.com/quicwg/base-drafts/issues/2593 [-recovery] = - #2606 HTTP/3 reserved value range (4 by martinthomson, LPardue) https://github.com/quicwg/base-drafts/issues/2606 [-http] [-transport] = - #2599 Use short headers for stateless reset (2 by martinthomson, mikkel= fj) https://github.com/quicwg/base-drafts/issues/2599 [-transport] [has-pro= posal] = - #2596 Should platform delays be included in ack-delay? (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2596 [-recovery] [design] = - #2611 lost_pn can go negative (1 by marten-seemann) https://github.com/quicwg/base-drafts/issues/2611 [-recovery] = - #2554 Congestion control during application limited state (1 by janaiye= ngar) https://github.com/quicwg/base-drafts/issues/2554 [-recovery] [design] = 4 issues closed: - RTT Initial measurement https://github.com/quicwg/base-drafts/issues/26= 07 [-recovery] [editorial] = - HTTP/3 reserved value range https://github.com/quicwg/base-drafts/issue= s/2606 [-http] [-transport] = - Restructure RTT section https://github.com/quicwg/base-drafts/issues/25= 67 [-recovery] [editorial] = - Don't levy requirements on non-QUIC TLS endpoints https://github.com/qu= icwg/base-drafts/issues/2174 [-tls] [editorial] = Pull requests ------------- * quicwg/base-drafts (+12/-9/=F0=9F=92=AC27) 12 pull requests submitted: - Set loss delay at least kGranularity (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2617 = - Make latest_rtt global (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2615 = - Send ACK immediately when all data in PN space received (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2614 = - Remove old spin bit references (by LPardue) https://github.com/quicwg/base-drafts/pull/2613 = - Add further guidance related to unidirectional stream TPs (by LPardue) https://github.com/quicwg/base-drafts/pull/2612 = - Simplify UpdateRtt pseudocode (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2610 [-recovery] [editorial] = - consistent citing of internet drafts (by reschke) https://github.com/quicwg/base-drafts/pull/2609 = - non-QUIC TLS implementation don't validate transport parameters (by mar= tinthomson) https://github.com/quicwg/base-drafts/pull/2608 [-tls] [editorial] = - Reference RFC7661 for application limited (by ianswett) https://github.com/quicwg/base-drafts/pull/2605 = - nonsensical MUST on frames fitting in packets (by martinthomson) https://github.com/quicwg/base-drafts/pull/2603 [-transport] [editorial= ] = - Frames of unknown type cause connection close (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2601 [-transport] [editorial= ] = - Mandate the use of short header for stateless reset (by martinthomson) https://github.com/quicwg/base-drafts/pull/2600 [-transport] [design] = 7 pull requests received 27 new comments: - #2603 nonsensical MUST on frames fitting in packets (10 by kazuho, jana= iyengar, mikkelfj, martinthomson, ianswett, LPardue) https://github.com/quicwg/base-drafts/pull/2603 [-transport] [editorial= ] = - #2573 introduce a version alias mechanism (10 by kazuho, marten-seemann= , mikkelfj, philsbln, martinthomson, nibanks) https://github.com/quicwg/base-drafts/pull/2573 [-transport] [design] = - #2609 consistent citing of internet drafts (2 by reschke, martinthomson) https://github.com/quicwg/base-drafts/pull/2609 [-transport] [editorial= ] = - #2553 Change on idle behaviour (2 by janaiyengar, ianswett) https://github.com/quicwg/base-drafts/pull/2553 [-recovery] [editorial] = - #2592 Rewrite of RTT estimation section (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2592 [-recovery] [design] = - #2612 Add further guidance related to unidirectional stream TPs (1 by L= Pardue) https://github.com/quicwg/base-drafts/pull/2612 = - #2614 Send ACK immediately when all data in PN space received (1 by mar= tinthomson) https://github.com/quicwg/base-drafts/pull/2614 [-recovery] = 9 pull requests merged: - Send ACK immediately when all data in PN space received https://github.com/quicwg/base-drafts/pull/2614 [-recovery] = - Simplify UpdateRtt pseudocode https://github.com/quicwg/base-drafts/pull/2610 [-recovery] [editorial] = - Don't arm the handshake timer if there's no data https://github.com/quicwg/base-drafts/pull/2590 [-recovery] [design] = - Rewrite of RTT estimation section https://github.com/quicwg/base-drafts/pull/2592 [-recovery] [design] = - non-QUIC TLS implementation don't validate transport parameters https://github.com/quicwg/base-drafts/pull/2608 [-tls] [editorial] = - nonsensical MUST on frames fitting in packets https://github.com/quicwg/base-drafts/pull/2603 [-transport] [editorial= ] = - Updated spinbit text https://github.com/quicwg/base-drafts/pull/2564 = - Frames of unknown type cause connection close https://github.com/quicwg/base-drafts/pull/2601 [-transport] [editorial= ] = - Update name of TPs https://github.com/quicwg/base-drafts/pull/2539 [-transport] [editorial= ] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============3275883671652854553== 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 14, 2019

Issues

quicwg/base-drafts (+7/-4/=F0=9F=92=AC40)

7 issues created:

10 issues received 40 new comments:

4 issues closed:

Pull requests

quicwg/base-drafts (+12/-9/=F0=9F=92=AC27)

12 pull requests submitted:

7 pull requests received 27 new comments:

Repositories tracked by this digest:

--===============3275883671652854553==-- From nobody Mon Apr 15 02:20:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFCF12008A for ; Mon, 15 Apr 2019 02:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9AjdYn_fnktQ for ; Mon, 15 Apr 2019 02:20:14 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.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 A883212002F for ; Mon, 15 Apr 2019 02:20:12 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3F9Jn9h006245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 15 Apr 2019 11:19:50 +0200 Received: from [IPv6:2a00:79e1:abc:307:5d80:b383:7b80:b51b] ([IPv6:2a00:79e1:abc:307:5d80:b383:7b80:b51b]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3F9Jm05031695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Apr 2019 11:19:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? From: "Brian Trammell (IETF)" In-Reply-To: <5CB1C214.4030501@erg.abdn.ac.uk> Date: Mon, 15 Apr 2019 11:19:48 +0200 Cc: Roberto Peon , Praveen Balasubramanian , Ian Swett , Christian Huitema , Mirja Kuehlewind , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , "Border, John" Content-Transfer-Encoding: quoted-printable Message-Id: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> <5CB1C214.4030501@erg.abdn.ac.uk> To: G Fairhurst X-Mailer: Apple Mail (2.3445.102.3) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 09:20:17 -0000 hi Gorry, all, > On 13 Apr 2019, at 13:03, G Fairhurst wrote: >=20 > Bringing this thread back - to me it seems there has been lots of = discussion about how "version greasing" can be added in various ways, = and very little on what makes this necessary and worth the impact on the = network. >=20 > I still don't do not see that the side effects are worse when the = protocol requires the version to be unobfusticated (as in most other = IETF transport protocols). +1. I continue to be confused about the amount of effort we're = apparently willing to put into version negotiation protection of a = protocol that is *explicitly* designed to be blockable outright (by = virtue of the TCP fallback requirement). I haven't seen anything in this = thread, or any of these discussions preceding it on this subject, that = indicates that the actual risk of harm with respect to version blocking = is discernibly worse (or even discernibly different) than the risk of = harm with respect to blocking of the entire protocol regardless of = version.=20 I can see two reasons a version negotiation process could get blocked in = the network: (1) As an explicit choice by a traffic inspection function that it must = have a specific version (or versions) of a protocol because it inspects = information only available in that version of the wire image. Note that QUIC is different from all other situations from which we = could derive experience, since there simply isn't that much wire image = for an inspection function to grab on to, and I can't imagine a future = in which a future version would omit information it'd be worth blocking = the version over (as opposed to all of QUIC, forcing TCP). Indeed, note = that we made the latency spin bit probabilistic, as opposed to = negotiated, in part to remove a potential incentive to ossify version = negotiation. It's possible that a device might want to block non-V1 versions because = the handshake protection keys are hardcoded into the device. I'm not = sure I see how dynamic aliasing could be reliably made to address this = problem, though publishing v1 with N aliases (i.e. static aliasing) with = different keys would at least ensure that devices with only one key slot = don't work. (2) As an overcorrection by a traffic inspection function that mistakes = thinks that a particular sequence of version negotiation packets is a = protocol identifier. As I see it, the current version negotiation proposals only make this = worse, not better, by creating a semantically indistinguishable set of = aliases for the same operation. This problem could be nicely sidestepped = by punting version negotiation into the future. Cheers, Brian > Gorry >=20 >=20 > On 12/04/2019, 17:41, Roberto Peon wrote: >>=20 >> I=E2=80=99m not sure that I agree there=E2=80=94there is no need to = have it standardized so long as the LB is involved in picking it. Each = LB system can choose whatever it wants. Thus, every LB **deployment** = could use a different scheme with different grease. Every LB deployment = could change the scheme it uses pseudo-randomly or according to the = lunar calendar, etc. >>=20 >> Because there is a dynamic (and controlling) component (namely the = part of the LB system which vends and then later routes CIDs), there is = no need for anything else. >>=20 >> -=3DR >>=20 >> *From: *Praveen Balasubramanian >> *Date: *Friday, April 12, 2019 at 9:28 AM >> *To: *Roberto Peon , Christian Huitema = , Ian Swett >> *Cc: *"Gorry (erg)" , Mirja Kuehlewind = , Mikkel Fahn=C3=B8e J=C3=B8rgensen = , "quic@ietf.org" , "Border, John" = >> *Subject: *RE: Is "Version Greasing" a new benfit or a new obstacle? >>=20 >> Re. Encoding in CID. Then it needs to be standardized and if it is = standardized what=E2=80=99s the point in greasing? Let=E2=80=99s not = ignore the smaller services who use the cloud i.e. people deploying say = NGINX web servers in AWS, Azure or GCP. Not every QUIC deployment is a = large first party service which controls all aspects how LB and DDoS are = done. In public clouds LB and DDoS protection are network functions = (services) and are middleboxes under a completely different = administrative domain. >>=20 >> Christian, this is about source address validation by the middlebox. = This is how it works for TCP (think SYN cookies) and we need to have = parity for QUIC. When under attack, short header packets will be dropped = for addresses that have not been validated, but this is the same for = non-SYN packets for TCP. I don=E2=80=99t understand how invariants can = be used here. If we don=E2=80=99t have parity for DoS protection in = network then QUIC traffic will be rate limited which is going to be = really bad for performance. FWIW there is already DoS traffic that looks = like QUIC. >>=20 >> *From:* Roberto Peon >> *Sent:* Friday, April 12, 2019 9:16 AM >> *To:* Christian Huitema ; Ian Swett = ; Praveen Balasubramanian >> *Cc:* Gorry (erg) ; Mirja Kuehlewind = ; Mikkel Fahn=C3=B8e J=C3=B8rgensen = ; quic@ietf.org; Border, John = >> *Subject:* Re: Is "Version Greasing" a new benfit or a new obstacle? >>=20 >> For any large deployment, I suspect they=E2=80=99ll need LB. >>=20 >> For most kinds of LB-ing, I=E2=80=99d expect the LB system to either = directly or indirectly be involved in choosing/vending connection IDs. >>=20 >> If it is involved in vending/choosing connection IDs, it can encode = version information into the CID. >>=20 >> -=3DR >>=20 >> *From: *Christian Huitema >> >> *Date: *Friday, April 12, 2019 at 9:13 AM >> *To: *Ian Swett >>, = Praveen Balasubramanian >> >> *Cc: *"Gorry (erg)" >>, Roberto Peon >>, Mirja = Kuehlewind >>, Mikkel Fahn=C3=B8e = J=C3=B8rgensen >>, "quic@ietf.org = >" >>, = "Border, John" >> >> *Subject: *Re: Is "Version Greasing" a new benfit or a new obstacle? >>=20 >> On 4/12/2019 8:57 AM, Ian Swett wrote: >>=20 >> *From:* Praveen Balasubramanian >> *...* >>=20 >> Version greasing will create problems for DDoS protection. The >> DDoS protection middlebox will have to treat all traffic with >> unknown version numbers as plain old QUIC and rate limit it. Any >> solution that requires per connection state to track version >> numbers doesn=E2=80=99t scale. Especially in the cloud scenario = customers >> bring their own web servers so this makes any opt-out solution not >> good enough. So I do think this is an obstacle for many = deployments. >>=20 >> Don't we have an example of middle-box ossification just there? >>=20 >> Praveen's example points to the perils of the "shortest path" = approach to middle-box design. Taking the shortest path means finding = something that works now, and once you have found it deploy it without = worry about consequences -- which very often include ossification. If = the DDOS protection box looks for "QUIC versions that it knows" and just = rate limits the other types of packets, then the box will by design = prevent deployment of versions that it does not know. >>=20 >> I assume that big organizations like Azure will update their = protections once a new version is out, but the experience shows that = many other organizations don't. And even when they do, the focus on = published versions will block experimenting with new versions, not to = mention interfering with other features like connection migration. I = take Praveen's example as an argument why we should in fact standardize = version greasing, precisely to avoid this "shortest path middle-box = design". >>=20 >> In the case of DDOS protection, I will point out that DDOS protection = also needs to work with short header packets, which do not carry any = version number. In order to avoid DDOS by short header packets, the = boxes have to be able to distinguish between packets that belong to = authorized connections and packets that don't. And if you do that, then = you don't really need to look at the version numbers, you can simply = rely on the invariants. >>=20 >> -- Christian Huitema From nobody Mon Apr 15 02:20:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2CE12015D for ; Mon, 15 Apr 2019 02:20:35 -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 chbp6Zkuwdm3 for ; Mon, 15 Apr 2019 02:20:32 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.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 3DE9E120381 for ; Mon, 15 Apr 2019 02:20:30 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3F9KA6O008251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 15 Apr 2019 11:20:10 +0200 Received: from [IPv6:2a00:79e1:abc:307:5d80:b383:7b80:b51b] ([IPv6:2a00:79e1:abc:307:5d80:b383:7b80:b51b]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3F9Jm07031695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Apr 2019 11:20:10 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? From: Brian Trammell (IETF) In-Reply-To: Date: Mon, 15 Apr 2019 11:20:10 +0200 Cc: Gorry Fairhurst , Mirja Kuehlewind , "quic@ietf.org" , "Border, John" , Roberto Peon Content-Transfer-Encoding: quoted-printable Message-Id: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.102.3) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 09:20:35 -0000 hi Mikkel,=20 perhaps a bit late to this party, I'm not sure I understand the process = you envision by which the TCP fallback will go away.=20 Once it's in, it'll get used in a high enough proportion of cases that = the availability risk of turning it off, balanced against the fact that = it already works (as it's pretty much mandatory for deploying in today's = 95%-UDP-transparent Internet), will go away very slowly indeed. Cheers, Brian > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: >=20 > In a not so distant future, a fallback to TCP would not be a viable = alternative for a number of services. Think WebRTC. > If QUIC and other encrypted protocols become dominant, just blocking = everything would literally block everything. > Of course, http(s) as we know it, it will continue to live on, but = many mobile apps would not. >=20 >=20 > On 11 April 2019 at 10.03.14, Mirja Kuehlewind = (mirja.kuehlewind@ericsson.com) wrote: >=20 >> Hi Mikkel,=20 >>=20 >> I guess it is much more likely that any of those actors would just = block QUIC all together (as there is actually a fallback to TCP).=20 >>=20 >> Mirja=20 >>=20 >>=20 >>=20 >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e = J=C3=B8rgensen" = wrote:=20 >>=20 >>=20 >> Let=E2=80=99s say China makes a deal with Google to allow their = search engine (a not entirely unreasonably proposition).=20 >> The Great Firewall of China (GFC) is reconfigured to accept traffic = from a specific IP range for QUIC protocol v1.=20 >>=20 >>=20 >>=20 >> Google later upgrades to v2. GFC is updated. Later, out of ignorance, = some other department within said company decides that its browsers = should all use forced version aliases as a rule. GFC breaks. (Assuming = Googles servers are not located within the demilitarised=20 >> zone and users use Chrome).=20 >>=20 >>=20 >> Alternative 1: Google up front decides to deploy forced version = aliasing. China rejects the deal because they do not want to support = random traffic through GFC.=20 >>=20 >>=20 >> Alternative 2: Google up front decides to deploy forced version = aliasing, and China does not reject the deal, out of ignorance. Later = some department in China GFC oversight realises the deal and forces = Google to remove forced version aliasing, or shut down=20 >> its service.=20 >>=20 >>=20 >> Alternative 3: Google up front decides to deploy forced version = aliasing and China says, of course, we trust everything from Googles IP = range.=20 >>=20 >>=20 >> Alternative 4: Google realises that forced version aliasing does not = work in the general case, and makes a special case for users within a = certain geographical area.=20 >>=20 >>=20 >> Disclaimer: I=E2=80=99m not affiliated with Google and this might not = at all be how things would work, but it does highlight some of the = challenges.=20 >>=20 >>=20 >> Of course, to be fair, China is not the only government entity that = might have a vested interest. Let's take a fictional example of US a = real estate investor with heavy ties to the eastern european block who = somehow finds himself elected as president needing=20 >> to find leverage on trade negotiations without effectively hurting = personal finances. It turns out that blocking certain digital services = from said eastern european block is the perfect tool in the trade = negotiations.. Advisers point out that those services=20 >> run heavily encrypted on the dark web with perpetual circulation of = IP ranges so, ignoring any legal concerns, it would not be practically = possible. Eventually someone figures out that these services all usually = are at the forefront of technology and currently=20 >> use QUIC v3.2 and no-one else has deployed that version yet, so it = would suffice to ask NSA to tap into the backbone and disrupt specific = packets. Of course, this ends up taking down the Bavarian local = government election process in Germany where they are=20 >> the first to use a new digital election system. Not that the is an = issue, since trade negotiations are also running hot in that area, so = that is just an accidental bonus.=20 >>=20 >>=20 >> Or an endless number of other developments over the next few decades = if the past few years is anything to go by.=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) = wrote:=20 >>=20 >> Thanks Mikkel, I do understand that various actors intentionally drop = - but are you saying these actors would specifically choose to block a = new version of QUIC ... I do not understand that assertion.=20 >>=20 >>=20 >> Gorry=20 >>=20 >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote:=20 >>=20 >>=20 >>=20 >> China blocks as a rule.=20 >> Russia is running an experiment to block the rest of the internet.=20 >> USA blocks net neutrality.=20 >> EU blocks cookies.=20 >> GB blocks itself.=20 >>=20 >>=20 >> So blocking is not limited to what an operator considers best for = business.=20 >>=20 >>=20 >>=20 >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) = wrote:=20 >>=20 >>=20 >> I understand why people want to come down on the side of preventing = ossification. But, things have changed. There are a lot of more negative = consequences now when people unnecessarily block things. I think = operators would put a lot of pressure on vendors to=20 >> not do it now and to fix it if they did "by accident". Of course, I = am only one operator. It would be nice to hear from others...=20 >>=20 >>=20 >>=20 >> John=20 >>=20 >>=20 >> -----Original Message-----=20 >> From: QUIC On Behalf Of Roberto Peon=20 >> Sent: Wednesday, April 10, 2019 12:52 PM=20 >> To: G Fairhurst ;=20 >> quic@ietf.org=20 >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?=20 >>=20 >> WARNING: The sender of this email could not be validated and may not = match the person in the "From" field.=20 >>=20 >> CAUTION: This email originated from outside of the organization. Do = not click links or open attachments unless you recognize the sender and = know the content is safe.=20 >>=20 >>=20 >> You're kinda between a rock-and-a-hard-place either way:=20 >>=20 >> - We've seen how much fun ossification is in TCP and HTTP. If the = thing is observable, it will be ossified seems to be the lesson. A lot = of the reason why QUIC was started in the first place was because of the = inability to improve TCP due to this ossification.=20 >> - OTOH, there is the fear of unknown/unobservable which might cause = operators to block things, whether predictably or not.=20 >>=20 >> My opinion is that it is better to start with preventing = ossification, and then if that results in too large a percentage of = operators blocking things, to re-evaluate.=20 >>=20 >> My guesses:=20 >> IP+port tuples and traffic patterns are still observable (for better = and worse), which implies operators will still have significant tools = for managing traffic. I believe that these are acted on/matched (ML or = not) regardless of any other data presented. In=20 >> other words, I have a doubt that stating the version in an observable = way will prevent the use of such tools.=20 >>=20 >> Most problems I've seen associated with implementations rather than = protocol versions (though when the latter happens it is pretty severe).. = If you believe this assertion, then acting on protocol version is less = interesting than attempting to act based on implementation=20 >> fingerprints.=20 >> -=3DR=20 >>=20 >>=20 >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" = > gorry@erg.abdn.ac.uk> wrote:=20 >>=20 >> Obscuring the version of a protocol seems like a major design design=20= >> decision for wider use cases. So, I'm trying to understand the=20 >> motivation for version greasing.=20 >>=20 >> (1) I know there were instances where some early versions of QUIC = were=20 >> blocked due to an uninitentional matching of the header. Is there=20 >> evidence of intentional attempts to block updates to protocols?=20 >>=20 >> (2) Thinking about operating a network that cares about user support = and=20 >> protection from unwanted traffic, I would expect that there would be=20= >> cases where traffic pattern anomolies are found and the appropriate=20= >> thing would be to try to determine if a new protocol had been = deployed=20 >> and monitor it, if not, then the next most obvious thing could be to=20= >> block all unexpected traffic, that seems like a decision to hide the=20= >> version could increase ossification for new versions in these cases..=20= >>=20 >> (3) Similarly, if a threat is known to impact only a specific (older)=20= >> version, it would seem to motivate a drop of that traffic that seeks = to=20 >> use that version, while still permitting other traffic. Forcing = version=20 >> detection to use pattern matching/ML will lead to less predictable=20 >> outcomes, or blocking based on address, etc.=20 >>=20 >> (4) This obfusticates the most basic piece of reporting information = used=20 >> for support. It hides the extent of deployment of the current = protocol=20 >> version and prevlance of old implementations.=20 >>=20 >> (5) On the support, if a problem only emerges when a particular = version=20 >> is used with a particular address, then this helps pinpoint the = issues.=20 >> Matching client versions to servers is much more of an issue if the = user=20 >> community uses a wide range of servers (less so, I expect for major=20= >> providers: google, facebook, etc, etc), but significant when there is = a=20 >> use of a diverse set of external sites and sites with their own load=20= >> balancers, etc and a need to manage interactions with L2 services.=20 >>=20 >> I am intersted in knowing if this is likely to benefit or be a new = obstacle?=20 >>=20 >> Gorry From nobody Mon Apr 15 02:28:54 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D97812015F for ; Mon, 15 Apr 2019 02:28:53 -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 L4YNGjLjdHLD for ; Mon, 15 Apr 2019 02:28:50 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E663112015E for ; Mon, 15 Apr 2019 02:28:49 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id q14so10834398itk.0 for ; Mon, 15 Apr 2019 02:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=7UgK/rdZN/SEcEc8KUvEKsPg3iGVfImUFgZnXTKULnQ=; b=Iy1cn4baOhmjvKsayPUiLAbSSnuE+ZgW4kHxoKrXBgQAE+rQR+aKi4GKqQHr7sAOqz XM118JEgwf12ptaV0jEIHmLGyMqehflFi0lOd5zN7Q5QK56WP8VW9y4YE+2OMZdsI/Mt ycOl56Kh2xpQbKSOLvDafh8te+gxxXA4dNeuny/2madfa/HNTyfm0cDIPj+4tbGgzrki hFl8az3iuXMLkJIYgu1CltlIapcZf5VyJmiizFDQSQ4UJaGDOgZZfGvXSaZA9578vjA3 +iIa6dBqwGOe3smDiLEp1OAXN0QUQEzP+/IUqC/g6XuS00kcTR8mGEpobka2M/k8YsPn AMDg== 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=7UgK/rdZN/SEcEc8KUvEKsPg3iGVfImUFgZnXTKULnQ=; b=EXDDmApPz65g/Pvf4ozDVyCP0DRi1CN0zZyyUT2py956abalS4ZOMDMSb/svSrSHTV BwDHqUHdOU9GU+oBWkGbkGW2OMiBwn4AcK6JgbSMFrM86qVipjQnYlWBzzBagePCiskC yuyaNhV9mjLqIxLYcTqLq0pdYhC3Hr0Ft1OzTenl+PDMHt/zQxHYnMtJi83DKLmUGJZl hTptA4qmlYkWXlV7fkKdRV6E1KeEbzb7gzEM/imjqMk9+aGuV3VfVd8hoAts4t1jtewH MM6nArdWpt8LtoH3wgx3gHsaHrByg6VNHQnjhw60EQULYwYHksOgXPkLEDmgX3zzrEZl Kjuw== X-Gm-Message-State: APjAAAVxV8TnylMprQiqmFR9tJpTBXa6HDw930JOAJBrOzD/eGGNTsN5 Sf65x5sjsr35bvjyILNynwbolSuiFPZ9Y0XxmI0= X-Google-Smtp-Source: APXvYqx3Kiq93VESIyqFZCs6qk27rPX+JB5CrNGBthTfS2+hb/BuWfpwEynEZVnRbVHV/CqKtIfEBHfh/1/XYlHxwlU= X-Received: by 2002:a02:ab90:: with SMTP id t16mr51444895jan.119.1555320529130; Mon, 15 Apr 2019 02:28:49 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 15 Apr 2019 02:28:48 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 15 Apr 2019 02:28:47 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: Brian Trammell Cc: Gorry Fairhurst , "quic@ietf.org" , "Border, John" , Roberto Peon , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="000000000000a699d305868e47e1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 09:28:53 -0000 --000000000000a699d305868e47e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see how TC= P fallback will work for the general case. A lot of games, VR applications, streaming services etc. are going to build semi-proprietary QUIC versions, or at least use QUIC with customised application protocols where TCP fallback is simply pointless because it doesn=E2=80=99t support the framing needed and if it were possible, why wou= ld adapt an application layer protocol to work on TCP if you don=E2=80=99t have to -= of course you have to if it gets blocked - hence try to avoid that. I don=E2=80=99t have any numbers on transparency, but given the reach of vo= ice call applications, you can probably safely assume that UDP will be supported through most networks. The problem again is if only some UDP is allowed through traffic inspection or at least port numbering. It can be a good thing that a QUIC version is detectable if the alternative is that anything unknown gets blocked. That is the big unknown. Will it help to be is opaque as possible, or not? Some of the scenarios I posted earlier show that no matter what you do, something will get in the way. Mikkel On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote: hi Mikkel, perhaps a bit late to this party, I'm not sure I understand the process you envision by which the TCP fallback will go away. Once it's in, it'll get used in a high enough proportion of cases that the availability risk of turning it off, balanced against the fact that it already works (as it's pretty much mandatory for deploying in today's 95%-UDP-transparent Internet), will go away very slowly indeed. Cheers, Brian > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > In a not so distant future, a fallback to TCP would not be a viable alternative for a number of services. Think WebRTC. > If QUIC and other encrypted protocols become dominant, just blocking everything would literally block everything. > Of course, http(s) as we know it, it will continue to live on, but many mobile apps would not. > > > On 11 April 2019 at 10.03.14, Mirja Kuehlewind ( mirja.kuehlewind@ericsson.com) wrote: > >> Hi Mikkel, >> >> I guess it is much more likely that any of those actors would just block QUIC all together (as there is actually a fallback to TCP). >> >> Mirja >> >> >> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e J=C3= =B8rgensen" < quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: >> >> >> Let=E2=80=99s say China makes a deal with Google to allow their search e= ngine (a not entirely unreasonably proposition). >> The Great Firewall of China (GFC) is reconfigured to accept traffic from a specific IP range for QUIC protocol v1. >> >> >> >> Google later upgrades to v2. GFC is updated. Later, out of ignorance, some other department within said company decides that its browsers should all use forced version aliases as a rule. GFC breaks. (Assuming Googles servers are not located within the demilitarised >> zone and users use Chrome). >> >> >> Alternative 1: Google up front decides to deploy forced version aliasing. China rejects the deal because they do not want to support random traffic through GFC. >> >> >> Alternative 2: Google up front decides to deploy forced version aliasing, and China does not reject the deal, out of ignorance. Later some department in China GFC oversight realises the deal and forces Google to remove forced version aliasing, or shut down >> its service. >> >> >> Alternative 3: Google up front decides to deploy forced version aliasing and China says, of course, we trust everything from Googles IP range. >> >> >> Alternative 4: Google realises that forced version aliasing does not work in the general case, and makes a special case for users within a certain geographical area. >> >> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might not at= all be how things would work, but it does highlight some of the challenges. >> >> >> Of course, to be fair, China is not the only government entity that might have a vested interest. Let's take a fictional example of US a real estate investor with heavy ties to the eastern european block who somehow finds himself elected as president needing >> to find leverage on trade negotiations without effectively hurting personal finances. It turns out that blocking certain digital services from said eastern european block is the perfect tool in the trade negotiations.. Advisers point out that those services >> run heavily encrypted on the dark web with perpetual circulation of IP ranges so, ignoring any legal concerns, it would not be practically possible. Eventually someone figures out that these services all usually are at the forefront of technology and currently >> use QUIC v3.2 and no-one else has deployed that version yet, so it would suffice to ask NSA to tap into the backbone and disrupt specific packets. Of course, this ends up taking down the Bavarian local government election process in Germany where they are >> the first to use a new digital election system. Not that the is an issue, since trade negotiations are also running hot in that area, so that is just an accidental bonus. >> >> >> Or an endless number of other developments over the next few decades if the past few years is anything to go by. >> >> >> >> >> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote: >> >> Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ... I do not understand that assertion. >> >> >> Gorry >> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> >> >> >> China blocks as a rule. >> Russia is running an experiment to block the rest of the internet. >> USA blocks net neutrality. >> EU blocks cookies. >> GB blocks itself. >> >> >> So blocking is not limited to what an operator considers best for business. >> >> >> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote: >> >> >> I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to >> not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others... >> >> >> >> John >> >> >> -----Original Message----- >> From: QUIC On Behalf Of Roberto Peon >> Sent: Wednesday, April 10, 2019 12:52 PM >> To: G Fairhurst ; >> quic@ietf.org >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? >> >> WARNING: The sender of this email could not be validated and may not match the person in the "From" field. >> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> You're kinda between a rock-and-a-hard-place either way: >> >> - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification. >> - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not. >> >> My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate. >> >> My guesses: >> IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In >> other words, I have a doubt that stating the version in an observable way will prevent the use of such tools. >> >> Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe).. If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation >> fingerprints. >> -=3DR >> >> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" < quic-bounces@ietf.org on behalf of >> gorry@erg.abdn.ac.uk> wrote: >> >> Obscuring the version of a protocol seems like a major design design >> decision for wider use cases. So, I'm trying to understand the >> motivation for version greasing. >> >> (1) I know there were instances where some early versions of QUIC were >> blocked due to an uninitentional matching of the header. Is there >> evidence of intentional attempts to block updates to protocols? >> >> (2) Thinking about operating a network that cares about user support and >> protection from unwanted traffic, I would expect that there would be >> cases where traffic pattern anomolies are found and the appropriate >> thing would be to try to determine if a new protocol had been deployed >> and monitor it, if not, then the next most obvious thing could be to >> block all unexpected traffic, that seems like a decision to hide the >> version could increase ossification for new versions in these cases.. >> >> (3) Similarly, if a threat is known to impact only a specific (older) >> version, it would seem to motivate a drop of that traffic that seeks to >> use that version, while still permitting other traffic. Forcing version >> detection to use pattern matching/ML will lead to less predictable >> outcomes, or blocking based on address, etc. >> >> (4) This obfusticates the most basic piece of reporting information used >> for support. It hides the extent of deployment of the current protocol >> version and prevlance of old implementations. >> >> (5) On the support, if a problem only emerges when a particular version >> is used with a particular address, then this helps pinpoint the issues. >> Matching client versions to servers is much more of an issue if the user >> community uses a wide range of servers (less so, I expect for major >> providers: google, facebook, etc, etc), but significant when there is a >> use of a diverse set of external sites and sites with their own load >> balancers, etc and a need to manage interactions with L2 services. >> >> I am intersted in knowing if this is likely to benefit or be a new obstacle? >> >> Gorry --000000000000a699d305868e47e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = QUIC is not going to= be used only for HTTP/3 and I don=E2=80=99t see how TCP fallback will work= for the general case.


I don=E2=80=99t have an= y numbers on transparency, but given the reach of voice call applications, = you can probably safely assume that UDP will be supported through most netw= orks. The problem again is if only some UDP is allowed through traffic insp= ection or at least port numbering.

It can be a good thing that a QUIC version is detectable if = the alternative is that anything unknown gets blocked. That is the big unkn= own. Will it help to be is opaque as possible, or not? Some of the scenario= s I posted earlier show that no matter what you do, something will get in t= he way.

<= /div>
Mikkel
<= 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">

On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote:

hi Mikkel, =20

perhaps a bit late to this party, I'm not sure I understand the pro= cess you envision by which the TCP fallback will go away. =20

Once it's in, it'll get used in a high enough proportion of cas= es that the availability risk of turning it off, balanced against the fact = that it already works (as it's pretty much mandatory for deploying in t= oday's 95%-UDP-transparent Internet), will go away very slowly indeed.

Cheers,

Brian

> On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
> =20
> In a not so distant future, a fallback to TCP would not be a viabl= e alternative for a number of services. Think WebRTC.
> If QUIC and other encrypted protocols become dominant, just blocki= ng everything would literally block everything.
> Of course, http(s) as we know it, it will continue to live on, but= many mobile apps would not.
> =20
> =20
> On 11 April 2019 at 10.03.14, Mirja Kuehlewind (mirja.kuehlewind@ericsson.com) wrote:
> =20
>> Hi Mikkel, =20
>> =20
>> I guess it is much more likely that any of those actors would = just block QUIC all together (as there is actually a fallback to TCP). =20
>> =20
>> Mirja =20
>> =20
>> =20
>> =20
>> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fa= hn=C3=B8e J=C3=B8rgensen" <quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: =20
>> =20
>> =20
>> Let=E2=80=99s say China makes a deal with Google to allow thei= r search engine (a not entirely unreasonably proposition). =20
>> The Great Firewall of China (GFC) is reconfigured to accept tr= affic from a specific IP range for QUIC protocol v1. =20
>> =20
>> =20
>> =20
>> Google later upgrades to v2. GFC is updated. Later, out of ign= orance, some other department within said company decides that its browsers= should all use forced version aliases as a rule. GFC breaks. (Assuming Goo= gles servers are not located within the demilitarised =20
>> zone and users use Chrome). =20
>> =20
>> =20
>> Alternative 1: Google up front decides to deploy forced versio= n aliasing. China rejects the deal because they do not want to support rand= om traffic through GFC. =20
>> =20
>> =20
>> Alternative 2: Google up front decides to deploy forced versio= n aliasing, and China does not reject the deal, out of ignorance. Later som= e department in China GFC oversight realises the deal and forces Google to = remove forced version aliasing, or shut down =20
>> its service. =20
>> =20
>> =20
>> Alternative 3: Google up front decides to deploy forced versio= n aliasing and China says, of course, we trust everything from Googles IP r= ange. =20
>> =20
>> =20
>> Alternative 4: Google realises that forced version aliasing do= es not work in the general case, and makes a special case for users within = a certain geographical area. =20
>> =20
>> =20
>> Disclaimer: I=E2=80=99m not affiliated with Google and this mi= ght not at all be how things would work, but it does highlight some of the = challenges. =20
>> =20
>> =20
>> Of course, to be fair, China is not the only government entity= that might have a vested interest. Let's take a fictional example of U= S a real estate investor with heavy ties to the eastern european block who = somehow finds himself elected as president needing =20
>> to find leverage on trade negotiations without effectively hur= ting personal finances. It turns out that blocking certain digital services= from said eastern european block is the perfect tool in the trade negotiat= ions.. Advisers point out that those services =20
>> run heavily encrypted on the dark web with perpetual circulati= on of IP ranges so, ignoring any legal concerns, it would not be practicall= y possible. Eventually someone figures out that these services all usually = are at the forefront of technology and currently =20
>> use QUIC v3.2 and no-one else has deployed that version yet, s= o it would suffice to ask NSA to tap into the backbone and disrupt specific= packets. Of course, this ends up taking down the Bavarian local government= election process in Germany where they are =20
>> the first to use a new digital election system. Not that the i= s an issue, since trade negotiations are also running hot in that area, so = that is just an accidental bonus. =20
>> =20
>> =20
>> Or an endless number of other developments over the next few d= ecades if the past few years is anything to go by. =20
>> =20
>> =20
>> =20
>> =20
>> =20
>> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote: =20
>> =20
>> Thanks Mikkel, I do understand that various actors intentional= ly drop - but are you saying these actors would specifically choose to bloc= k a new version of QUIC ... I do not understand that assertion. =20
>> =20
>> =20
>> Gorry =20
>> =20
>> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen &l= t;mikkelfj@gmail.com> wrote: = =20
>> =20
>> =20
>> =20
>> China blocks as a rule. =20
>> Russia is running an experiment to block the rest of the inter= net. =20
>> USA blocks net neutrality. =20
>> EU blocks cookies. =20
>> GB blocks itself. =20
>> =20
>> =20
>> So blocking is not limited to what an operator considers best = for business. =20
>> =20
>> =20
>> =20
>> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote: =20
>> =20
>> =20
>> I understand why people want to come down on the side of preve= nting ossification. But, things have changed. There are a lot of more negat= ive consequences now when people unnecessarily block things. I think operat= ors would put a lot of pressure on vendors to =20
>> not do it now and to fix it if they did "by accident"= ;. Of course, I am only one operator. It would be nice to hear from others.= .. =20
>> =20
>> =20
>> =20
>> John =20
>> =20
>> =20
>> -----Original Message----- =20
>> From: QUIC <quic-b= ounces@ietf.org> On Behalf Of Roberto Peon =20
>> Sent: Wednesday, April 10, 2019 12:52 PM =20
>> To: G Fairhurst <go= rry@erg.abdn.ac.uk>; =20
>> quic@ietf.org =20
>> Subject: Re: Is "Version Greasing" a new benfit or a= new obstacle? =20
>> =20
>> WARNING: The sender of this email could not be validated and m= ay not match the person in the "From" field. =20
>> =20
>> CAUTION: This email originated from outside of the organizatio= n. Do not click links or open attachments unless you recognize the sender a= nd know the content is safe. =20
>> =20
>> =20
>> You're kinda between a rock-and-a-hard-place either way: = =20
>> =20
>> - We've seen how much fun ossification is in TCP and HTTP.= If the thing is observable, it will be ossified seems to be the lesson. A = lot of the reason why QUIC was started in the first place was because of th= e inability to improve TCP due to this ossification. =20
>> - OTOH, there is the fear of unknown/unobservable which might = cause operators to block things, whether predictably or not. =20
>> =20
>> My opinion is that it is better to start with preventing ossif= ication, and then if that results in too large a percentage of operators bl= ocking things, to re-evaluate. =20
>> =20
>> My guesses: =20
>> IP+port tuples and traffic patterns are still observable (for = better and worse), which implies operators will still have significant tool= s for managing traffic. I believe that these are acted on/matched (ML or no= t) regardless of any other data presented. In =20
>> other words, I have a doubt that stating the version in an obs= ervable way will prevent the use of such tools. =20
>> =20
>> Most problems I've seen associated with implementations ra= ther than protocol versions (though when the latter happens it is pretty se= vere).. If you believe this assertion, then acting on protocol version is l= ess interesting than attempting to act based on implementation =20
>> fingerprints. =20
>> -=3DR =20
>> =20
>> =20
>> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst"= <quic-bounces@ietf.org on = behalf of =20
>> gorry@erg.abdn.ac.uk> wrote: =20
>> =20
>> Obscuring the version of a protocol seems like a major design = design =20
>> decision for wider use cases. So, I'm trying to understand= the =20
>> motivation for version greasing. =20
>> =20
>> (1) I know there were instances where some early versions of Q= UIC were =20
>> blocked due to an uninitentional matching of the header. Is th= ere =20
>> evidence of intentional attempts to block updates to protocols= ? =20
>> =20
>> (2) Thinking about operating a network that cares about user s= upport and =20
>> protection from unwanted traffic, I would expect that there wo= uld be =20
>> cases where traffic pattern anomolies are found and the approp= riate =20
>> thing would be to try to determine if a new protocol had been = deployed =20
>> and monitor it, if not, then the next most obvious thing could= be to =20
>> block all unexpected traffic, that seems like a decision to hi= de the =20
>> version could increase ossification for new versions in these = cases.. =20
>> =20
>> (3) Similarly, if a threat is known to impact only a specific = (older) =20
>> version, it would seem to motivate a drop of that traffic that= seeks to =20
>> use that version, while still permitting other traffic. Forcin= g version =20
>> detection to use pattern matching/ML will lead to less predict= able =20
>> outcomes, or blocking based on address, etc. =20
>> =20
>> (4) This obfusticates the most basic piece of reporting inform= ation used =20
>> for support. It hides the extent of deployment of the current = protocol =20
>> version and prevlance of old implementations. =20
>> =20
>> (5) On the support, if a problem only emerges when a particula= r version =20
>> is used with a particular address, then this helps pinpoint th= e issues. =20
>> Matching client versions to servers is much more of an issue i= f the user =20
>> community uses a wide range of servers (less so, I expect for = major =20
>> providers: google, facebook, etc, etc), but significant when t= here is a =20
>> use of a diverse set of external sites and sites with their ow= n load =20
>> balancers, etc and a need to manage interactions with L2 servi= ces. =20
>> =20
>> I am intersted in knowing if this is likely to benefit or be a= new obstacle? =20
>> =20
>> Gorry

--000000000000a699d305868e47e1-- From nobody Mon Apr 15 04:15:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CD2120091 for ; Mon, 15 Apr 2019 04:15:18 -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 J4N69Ybp6LmY for ; Mon, 15 Apr 2019 04:15:15 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.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 D507912008D for ; Mon, 15 Apr 2019 04:15:14 -0700 (PDT) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3FBExxe020676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 15 Apr 2019 13:14:59 +0200 Received: from [IPv6:2a00:79e1:abc:307:48cf:72ee:630e:c476] ([IPv6:2a00:79e1:abc:307:48cf:72ee:630e:c476]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3FBEwiv063747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Apr 2019 13:14:59 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? From: "Brian Trammell (IETF)" In-Reply-To: Date: Mon, 15 Apr 2019 13:14:58 +0200 Cc: Gorry Fairhurst , "quic@ietf.org" , "Border, John" , Roberto Peon , Mirja Kuehlewind Content-Transfer-Encoding: quoted-printable Message-Id: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.102.3) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 11:15:19 -0000 > On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: >=20 > QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see = how TCP fallback will work for the general case. >=20 > A lot of games, VR applications, streaming services etc. are going to = build semi-proprietary QUIC versions, or at least use QUIC with = customised application protocols where TCP fallback is simply pointless = because it doesn=E2=80=99t support the framing needed and if it were = possible, why would adapt an application layer protocol to work on TCP = if you don=E2=80=99t have to - of course you have to if it gets blocked = - hence try to avoid that. So you see the deployment strategy for these applications to be "zero = availability on non-UDP-accessible networks"? That seems bold to me = unless you're talking about QUIC being used as a replacement for = "application-provided transport layer over UDP", which is certainly a = big part of the market but not all of it. You could always tunnel UDP over TCP of course, but from a transport = layer perspective (and a transport-visible wire image perspective), = that's a TCP fallback. > I don=E2=80=99t have any numbers on transparency, but given the reach = of voice call applications, you can probably safely assume that UDP will = be supported through most networks. When we looked at this, admittedly a few years ago, we saw UDP blocking = on par with the QUIC failure rates reported by Google in 2015 - O(3-6%) = of paths. That's one nine of availability pathwise, which is... not = great. > The problem again is if only some UDP is allowed through traffic = inspection or at least port numbering. >=20 > It can be a good thing that a QUIC version is detectable if the = alternative is that anything unknown gets blocked. That is the big = unknown. As I said in my other message this morning, I don't think version = negotiation greasing is useful at this time because there is no = reasonable model of a wire-visible version difference where an on-path = device might want to let through one greased-version and not another = greased-version, because the wire-image profiles and semantic properties = of those two versions are by definition of greasing identical.=20 At this point, given connection-availability as the metric to optimize = for, it seems like reducing features that might be mistaken for = QUIC-distinguishers in the wire image would be useful, and version = greasing seems like one such feature. > Will it help to be is opaque as possible, or not? Some of the = scenarios I posted earlier show that no matter what you do, something = will get in the way. This all comes down to the threat model, and the model of incentives for = on-path devices. I personally think the correct design target is to put trivial = QUIC-discriminability into the wire image, since there will be a lot of = pressure to distinguish QUIC from not-QUIC traffic regardless of what we = do, and if we don't put grippy bits in the wire image, the = distinguishing functions will grip on to the slippy bits, with difficult = to predict outcomes. I recognize I am in the minority (of people who = speak up) on this issue, though. Cheers, Brian > On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote: >=20 >> hi Mikkel, =20 >>=20 >> perhaps a bit late to this party, I'm not sure I understand the = process you envision by which the TCP fallback will go away. =20 >>=20 >> Once it's in, it'll get used in a high enough proportion of cases = that the availability risk of turning it off, balanced against the fact = that it already works (as it's pretty much mandatory for deploying in = today's 95%-UDP-transparent Internet), will go away very slowly indeed.=20= >>=20 >> Cheers,=20 >>=20 >> Brian=20 >>=20 >> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote:=20 >> > =20 >> > In a not so distant future, a fallback to TCP would not be a viable = alternative for a number of services. Think WebRTC.=20 >> > If QUIC and other encrypted protocols become dominant, just = blocking everything would literally block everything.=20 >> > Of course, http(s) as we know it, it will continue to live on, but = many mobile apps would not.=20 >> > =20 >> > =20 >> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind = (mirja.kuehlewind@ericsson.com) wrote:=20 >> > =20 >> >> Hi Mikkel, =20 >> >> =20 >> >> I guess it is much more likely that any of those actors would just = block QUIC all together (as there is actually a fallback to TCP). =20 >> >> =20 >> >> Mirja =20 >> >> =20 >> >> =20 >> >> =20 >> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e = J=C3=B8rgensen" = wrote: =20 >> >> =20 >> >> =20 >> >> Let=E2=80=99s say China makes a deal with Google to allow their = search engine (a not entirely unreasonably proposition). =20 >> >> The Great Firewall of China (GFC) is reconfigured to accept = traffic from a specific IP range for QUIC protocol v1. =20 >> >> =20 >> >> =20 >> >> =20 >> >> Google later upgrades to v2. GFC is updated. Later, out of = ignorance, some other department within said company decides that its = browsers should all use forced version aliases as a rule. GFC breaks. = (Assuming Googles servers are not located within the demilitarised =20 >> >> zone and users use Chrome). =20 >> >> =20 >> >> =20 >> >> Alternative 1: Google up front decides to deploy forced version = aliasing. China rejects the deal because they do not want to support = random traffic through GFC. =20 >> >> =20 >> >> =20 >> >> Alternative 2: Google up front decides to deploy forced version = aliasing, and China does not reject the deal, out of ignorance. Later = some department in China GFC oversight realises the deal and forces = Google to remove forced version aliasing, or shut down =20 >> >> its service. =20 >> >> =20 >> >> =20 >> >> Alternative 3: Google up front decides to deploy forced version = aliasing and China says, of course, we trust everything from Googles IP = range. =20 >> >> =20 >> >> =20 >> >> Alternative 4: Google realises that forced version aliasing does = not work in the general case, and makes a special case for users within = a certain geographical area. =20 >> >> =20 >> >> =20 >> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might = not at all be how things would work, but it does highlight some of the = challenges. =20 >> >> =20 >> >> =20 >> >> Of course, to be fair, China is not the only government entity = that might have a vested interest. Let's take a fictional example of US = a real estate investor with heavy ties to the eastern european block who = somehow finds himself elected as president needing =20 >> >> to find leverage on trade negotiations without effectively hurting = personal finances. It turns out that blocking certain digital services = from said eastern european block is the perfect tool in the trade = negotiations.. Advisers point out that those services =20 >> >> run heavily encrypted on the dark web with perpetual circulation = of IP ranges so, ignoring any legal concerns, it would not be = practically possible. Eventually someone figures out that these services = all usually are at the forefront of technology and currently =20 >> >> use QUIC v3.2 and no-one else has deployed that version yet, so it = would suffice to ask NSA to tap into the backbone and disrupt specific = packets. Of course, this ends up taking down the Bavarian local = government election process in Germany where they are =20 >> >> the first to use a new digital election system. Not that the is an = issue, since trade negotiations are also running hot in that area, so = that is just an accidental bonus. =20 >> >> =20 >> >> =20 >> >> Or an endless number of other developments over the next few = decades if the past few years is anything to go by. =20 >> >> =20 >> >> =20 >> >> =20 >> >> =20 >> >> =20 >> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) = wrote: =20 >> >> =20 >> >> Thanks Mikkel, I do understand that various actors intentionally = drop - but are you saying these actors would specifically choose to = block a new version of QUIC ... I do not understand that assertion. =20 >> >> =20 >> >> =20 >> >> Gorry =20 >> >> =20 >> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: =20 >> >> =20 >> >> =20 >> >> =20 >> >> China blocks as a rule. =20 >> >> Russia is running an experiment to block the rest of the internet. = =20 >> >> USA blocks net neutrality. =20 >> >> EU blocks cookies. =20 >> >> GB blocks itself. =20 >> >> =20 >> >> =20 >> >> So blocking is not limited to what an operator considers best for = business. =20 >> >> =20 >> >> =20 >> >> =20 >> >> On 10 April 2019 at 18.59.15, Border, John = (john.border@hughes.com) wrote: =20 >> >> =20 >> >> =20 >> >> I understand why people want to come down on the side of = preventing ossification. But, things have changed. There are a lot of = more negative consequences now when people unnecessarily block things. I = think operators would put a lot of pressure on vendors to =20 >> >> not do it now and to fix it if they did "by accident". Of course, = I am only one operator. It would be nice to hear from others... =20 >> >> =20 >> >> =20 >> >> =20 >> >> John =20 >> >> =20 >> >> =20 >> >> -----Original Message----- =20 >> >> From: QUIC On Behalf Of Roberto Peon =20 >> >> Sent: Wednesday, April 10, 2019 12:52 PM =20 >> >> To: G Fairhurst ; =20 >> >> quic@ietf.org =20 >> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? = =20 >> >> =20 >> >> WARNING: The sender of this email could not be validated and may = not match the person in the "From" field. =20 >> >> =20 >> >> CAUTION: This email originated from outside of the organization. = Do not click links or open attachments unless you recognize the sender = and know the content is safe. =20 >> >> =20 >> >> =20 >> >> You're kinda between a rock-and-a-hard-place either way: =20 >> >> =20 >> >> - We've seen how much fun ossification is in TCP and HTTP. If the = thing is observable, it will be ossified seems to be the lesson. A lot = of the reason why QUIC was started in the first place was because of the = inability to improve TCP due to this ossification. =20 >> >> - OTOH, there is the fear of unknown/unobservable which might = cause operators to block things, whether predictably or not. =20 >> >> =20 >> >> My opinion is that it is better to start with preventing = ossification, and then if that results in too large a percentage of = operators blocking things, to re-evaluate. =20 >> >> =20 >> >> My guesses: =20 >> >> IP+port tuples and traffic patterns are still observable (for = better and worse), which implies operators will still have significant = tools for managing traffic. I believe that these are acted on/matched = (ML or not) regardless of any other data presented. In =20 >> >> other words, I have a doubt that stating the version in an = observable way will prevent the use of such tools. =20 >> >> =20 >> >> Most problems I've seen associated with implementations rather = than protocol versions (though when the latter happens it is pretty = severe).. If you believe this assertion, then acting on protocol version = is less interesting than attempting to act based on implementation =20 >> >> fingerprints. =20 >> >> -=3DR =20 >> >> =20 >> >> =20 >> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" = > >> gorry@erg.abdn.ac.uk> wrote: =20 >> >> =20 >> >> Obscuring the version of a protocol seems like a major design = design =20 >> >> decision for wider use cases. So, I'm trying to understand the =20 >> >> motivation for version greasing. =20 >> >> =20 >> >> (1) I know there were instances where some early versions of QUIC = were =20 >> >> blocked due to an uninitentional matching of the header. Is there =20= >> >> evidence of intentional attempts to block updates to protocols? =20= >> >> =20 >> >> (2) Thinking about operating a network that cares about user = support and =20 >> >> protection from unwanted traffic, I would expect that there would = be =20 >> >> cases where traffic pattern anomolies are found and the = appropriate =20 >> >> thing would be to try to determine if a new protocol had been = deployed =20 >> >> and monitor it, if not, then the next most obvious thing could be = to =20 >> >> block all unexpected traffic, that seems like a decision to hide = the =20 >> >> version could increase ossification for new versions in these = cases.. =20 >> >> =20 >> >> (3) Similarly, if a threat is known to impact only a specific = (older) =20 >> >> version, it would seem to motivate a drop of that traffic that = seeks to =20 >> >> use that version, while still permitting other traffic. Forcing = version =20 >> >> detection to use pattern matching/ML will lead to less predictable = =20 >> >> outcomes, or blocking based on address, etc. =20 >> >> =20 >> >> (4) This obfusticates the most basic piece of reporting = information used =20 >> >> for support. It hides the extent of deployment of the current = protocol =20 >> >> version and prevlance of old implementations. =20 >> >> =20 >> >> (5) On the support, if a problem only emerges when a particular = version =20 >> >> is used with a particular address, then this helps pinpoint the = issues. =20 >> >> Matching client versions to servers is much more of an issue if = the user =20 >> >> community uses a wide range of servers (less so, I expect for = major =20 >> >> providers: google, facebook, etc, etc), but significant when there = is a =20 >> >> use of a diverse set of external sites and sites with their own = load =20 >> >> balancers, etc and a need to manage interactions with L2 services. = =20 >> >> =20 >> >> I am intersted in knowing if this is likely to benefit or be a new = obstacle? =20 >> >> =20 >> >> Gorry From nobody Mon Apr 15 04:31:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE5D12008D for ; Mon, 15 Apr 2019 04:31:15 -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 EcUC_RbxHNPn for ; Mon, 15 Apr 2019 04:31:11 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDEB12002E for ; Mon, 15 Apr 2019 04:31:11 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id w15so26024315itc.0 for ; Mon, 15 Apr 2019 04:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=MbI/HC9Rqxm0RWdUep90p+wHzYJ7B0SE7scCM6Duf3k=; b=EV73/pHw8K8PuwgPuYcgEVwMRzEnjbPtGA5T5nyJ6cpphhIiLw8cVWo0e68Z8ra19P kvNE26rn1Mewszi69bZthH4dEryIaubXzffVt4nilm1ZcVTPIBqFKWsviTh+JeTMmrWf X5VY4RI3kfMJZfPAMw6V4BvYBcQMYYDzWS+ZDgGLx0Hw1xqMqvHknQ3YGP8ofyWDI1H/ 6mgRgRvAJYJcy2gzAv5KnQhcJJOLxGipth5Dvxebokun5CWK3BHmRT7Ui/WGoMF5T6Lr +R9xQC4rt8kRyxR5g+96p8gmcbq55zUv+kILBEUVNWUq46Q7m7svPANAGl14JIIJ9Udb 5P9Q== 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=MbI/HC9Rqxm0RWdUep90p+wHzYJ7B0SE7scCM6Duf3k=; b=L7euHZDVzojpLO8cpxIAWAPF6UqcltIhFA/4fjTY3yyVbn9B0bMrnmjeA+Vljnx8jD rx6RUs0SeArEd+tjesgCQch0xsxwzXPPQ6inwB4zHdiJ0IuxZS6pyT2X65avYkwVh0Vt 64HUTh+p9AukwWsE//XUO+U5eKJUTOrsXpjKESfTRoL8Uo6cntgCfzIjGC9scMMTcnPi QryEbrcXjHhLFPBtiMst6VqdTqZilXL++RyDek4nLCCAs2ZdfUnwsKNK+UVUlSgLqmKC Q8AjI5Z1PZhebF4Fipj7FMAMm0zlhIE91CnXSyq3lTgt7wxJgIMwtT7fG0jlg8QiIMWL zczw== X-Gm-Message-State: APjAAAUM5Jkrufwn70LnPMLC7oMOChEW+orSNab6UlQxoUI6B7swIZor +RoMuVzVBvAM9Z5TzB2oyCjBVlkGrKI0Nr/zX5U= X-Google-Smtp-Source: APXvYqwtt9oeez92FalOl5HKWXBLGpiU+4yagWuwE98miWGPW7FyfpVbVIBd0Bhrid/mbrw0S9umfpz4fvIz5/TI1zY= X-Received: by 2002:a24:e008:: with SMTP id c8mr23748397ith.93.1555327870562; Mon, 15 Apr 2019 04:31:10 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 15 Apr 2019 04:31:09 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 15 Apr 2019 04:31:09 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: "Brian Trammell (IETF)" Cc: Gorry Fairhurst , "Border, John" , "quic@ietf.org" , Roberto Peon , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="0000000000003bf81b05868ffd07" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 11:31:15 -0000 --0000000000003bf81b05868ffd07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Any kind of game or low latency control system such as 5G avionics cannot use TCP as fallback since the buffering would be a non-starter. I would expect UDP to be more commonly supported both as games with their own protocols, WebRTC, and QUIC all become more prominent. Also, it would be helpful to understand where UDP is not supported. For example, it might be that UDP is blocked on some corporate firewalls because conferencing is only supported on the internal network, or via VPN. In these cases QUIC would probably still work perfectly fine for the intended use cases, assuming the VPN solution does not introduce buffering in packet tunnelling. Adding TCP as a fallback isn=E2=80=99t merely tunneling data. It requires a= new QUIC emulation interface and it typically requires a separate host with separate TLS certificate management. TCP typically runs in kernel where QUIC runs in userspace and pulling in a userspace TCP stack is also work. And then of course the latency considerations. So many deployments would happily sacrifice the 5% of users that are not running UDP as they done before with users running IE6. On 15 April 2019 at 13.15.09, Brian Trammell (IETF) (ietf@trammell.ch) wrote: > On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see how = TCP fallback will work for the general case. > > A lot of games, VR applications, streaming services etc. are going to build semi-proprietary QUIC versions, or at least use QUIC with customised application protocols where TCP fallback is simply pointless because it doesn=E2=80=99t support the framing needed and if it were possible, why wou= ld adapt an application layer protocol to work on TCP if you don=E2=80=99t have to -= of course you have to if it gets blocked - hence try to avoid that. So you see the deployment strategy for these applications to be "zero availability on non-UDP-accessible networks"? That seems bold to me unless you're talking about QUIC being used as a replacement for "application-provided transport layer over UDP", which is certainly a big part of the market but not all of it. You could always tunnel UDP over TCP of course, but from a transport layer perspective (and a transport-visible wire image perspective), that's a TCP fallback. > I don=E2=80=99t have any numbers on transparency, but given the reach of = voice call applications, you can probably safely assume that UDP will be supported through most networks. When we looked at this, admittedly a few years ago, we saw UDP blocking on par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of paths. That's one nine of availability pathwise, which is... not great. > The problem again is if only some UDP is allowed through traffic inspection or at least port numbering. > > It can be a good thing that a QUIC version is detectable if the alternative is that anything unknown gets blocked. That is the big unknown. As I said in my other message this morning, I don't think version negotiation greasing is useful at this time because there is no reasonable model of a wire-visible version difference where an on-path device might want to let through one greased-version and not another greased-version, because the wire-image profiles and semantic properties of those two versions are by definition of greasing identical. At this point, given connection-availability as the metric to optimize for, it seems like reducing features that might be mistaken for QUIC-distinguishers in the wire image would be useful, and version greasing seems like one such feature. > Will it help to be is opaque as possible, or not? Some of the scenarios I posted earlier show that no matter what you do, something will get in the way. This all comes down to the threat model, and the model of incentives for on-path devices. I personally think the correct design target is to put trivial QUIC-discriminability into the wire image, since there will be a lot of pressure to distinguish QUIC from not-QUIC traffic regardless of what we do, and if we don't put grippy bits in the wire image, the distinguishing functions will grip on to the slippy bits, with difficult to predict outcomes. I recognize I am in the minority (of people who speak up) on this issue, though. Cheers, Brian > On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote: > >> hi Mikkel, >> >> perhaps a bit late to this party, I'm not sure I understand the process you envision by which the TCP fallback will go away. >> >> Once it's in, it'll get used in a high enough proportion of cases that the availability risk of turning it off, balanced against the fact that it already works (as it's pretty much mandatory for deploying in today's 95%-UDP-transparent Internet), will go away very slowly indeed. >> >> Cheers, >> >> Brian >> >> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> > >> > In a not so distant future, a fallback to TCP would not be a viable alternative for a number of services. Think WebRTC. >> > If QUIC and other encrypted protocols become dominant, just blocking everything would literally block everything. >> > Of course, http(s) as we know it, it will continue to live on, but many mobile apps would not. >> > >> > >> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind ( mirja.kuehlewind@ericsson.com) wrote: >> > >> >> Hi Mikkel, >> >> >> >> I guess it is much more likely that any of those actors would just block QUIC all together (as there is actually a fallback to TCP). >> >> >> >> Mirja >> >> >> >> >> >> >> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e J= =C3=B8rgensen" < quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: >> >> >> >> >> >> Let=E2=80=99s say China makes a deal with Google to allow their searc= h engine (a not entirely unreasonably proposition). >> >> The Great Firewall of China (GFC) is reconfigured to accept traffic from a specific IP range for QUIC protocol v1. >> >> >> >> >> >> >> >> Google later upgrades to v2. GFC is updated. Later, out of ignorance, some other department within said company decides that its browsers should all use forced version aliases as a rule. GFC breaks. (Assuming Googles servers are not located within the demilitarised >> >> zone and users use Chrome). >> >> >> >> >> >> Alternative 1: Google up front decides to deploy forced version aliasing. China rejects the deal because they do not want to support random traffic through GFC. >> >> >> >> >> >> Alternative 2: Google up front decides to deploy forced version aliasing, and China does not reject the deal, out of ignorance. Later some department in China GFC oversight realises the deal and forces Google to remove forced version aliasing, or shut down >> >> its service. >> >> >> >> >> >> Alternative 3: Google up front decides to deploy forced version aliasing and China says, of course, we trust everything from Googles IP range. >> >> >> >> >> >> Alternative 4: Google realises that forced version aliasing does not work in the general case, and makes a special case for users within a certain geographical area. >> >> >> >> >> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might not= at all be how things would work, but it does highlight some of the challenges. >> >> >> >> >> >> Of course, to be fair, China is not the only government entity that might have a vested interest. Let's take a fictional example of US a real estate investor with heavy ties to the eastern european block who somehow finds himself elected as president needing >> >> to find leverage on trade negotiations without effectively hurting personal finances. It turns out that blocking certain digital services from said eastern european block is the perfect tool in the trade negotiations.. Advisers point out that those services >> >> run heavily encrypted on the dark web with perpetual circulation of IP ranges so, ignoring any legal concerns, it would not be practically possible. Eventually someone figures out that these services all usually are at the forefront of technology and currently >> >> use QUIC v3.2 and no-one else has deployed that version yet, so it would suffice to ask NSA to tap into the backbone and disrupt specific packets. Of course, this ends up taking down the Bavarian local government election process in Germany where they are >> >> the first to use a new digital election system. Not that the is an issue, since trade negotiations are also running hot in that area, so that is just an accidental bonus. >> >> >> >> >> >> Or an endless number of other developments over the next few decades if the past few years is anything to go by. >> >> >> >> >> >> >> >> >> >> >> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote: >> >> >> >> Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ... I do not understand that assertion. >> >> >> >> >> >> Gorry >> >> >> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> >> >> >> >> >> >> >> China blocks as a rule. >> >> Russia is running an experiment to block the rest of the internet. >> >> USA blocks net neutrality. >> >> EU blocks cookies. >> >> GB blocks itself. >> >> >> >> >> >> So blocking is not limited to what an operator considers best for business. >> >> >> >> >> >> >> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote: >> >> >> >> >> >> I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to >> >> not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others... >> >> >> >> >> >> >> >> John >> >> >> >> >> >> -----Original Message----- >> >> From: QUIC On Behalf Of Roberto Peon >> >> Sent: Wednesday, April 10, 2019 12:52 PM >> >> To: G Fairhurst ; >> >> quic@ietf.org >> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? >> >> >> >> WARNING: The sender of this email could not be validated and may not match the person in the "From" field. >> >> >> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> >> >> >> You're kinda between a rock-and-a-hard-place either way: >> >> >> >> - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification. >> >> - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not. >> >> >> >> My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate. >> >> >> >> My guesses: >> >> IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In >> >> other words, I have a doubt that stating the version in an observable way will prevent the use of such tools. >> >> >> >> Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe).. If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation >> >> fingerprints. >> >> -=3DR >> >> >> >> >> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" < quic-bounces@ietf.org on behalf of >> >> gorry@erg.abdn.ac.uk> wrote: >> >> >> >> Obscuring the version of a protocol seems like a major design design >> >> decision for wider use cases. So, I'm trying to understand the >> >> motivation for version greasing. >> >> >> >> (1) I know there were instances where some early versions of QUIC were >> >> blocked due to an uninitentional matching of the header. Is there >> >> evidence of intentional attempts to block updates to protocols? >> >> >> >> (2) Thinking about operating a network that cares about user support and >> >> protection from unwanted traffic, I would expect that there would be >> >> cases where traffic pattern anomolies are found and the appropriate >> >> thing would be to try to determine if a new protocol had been deployed >> >> and monitor it, if not, then the next most obvious thing could be to >> >> block all unexpected traffic, that seems like a decision to hide the >> >> version could increase ossification for new versions in these cases.. >> >> >> >> (3) Similarly, if a threat is known to impact only a specific (older) >> >> version, it would seem to motivate a drop of that traffic that seeks to >> >> use that version, while still permitting other traffic. Forcing version >> >> detection to use pattern matching/ML will lead to less predictable >> >> outcomes, or blocking based on address, etc. >> >> >> >> (4) This obfusticates the most basic piece of reporting information used >> >> for support. It hides the extent of deployment of the current protocol >> >> version and prevlance of old implementations. >> >> >> >> (5) On the support, if a problem only emerges when a particular version >> >> is used with a particular address, then this helps pinpoint the issues. >> >> Matching client versions to servers is much more of an issue if the user >> >> community uses a wide range of servers (less so, I expect for major >> >> providers: google, facebook, etc, etc), but significant when there is a >> >> use of a diverse set of external sites and sites with their own load >> >> balancers, etc and a need to manage interactions with L2 services. >> >> >> >> I am intersted in knowing if this is likely to benefit or be a new obstacle? >> >> >> >> Gorry --0000000000003bf81b05868ffd07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Any kind of game or = low latency control system such as 5G avionics cannot use TCP as fallback s= ince the buffering would be a non-starter.

I would expect UDP to be more commonly supported bot= h as games with their own protocols, WebRTC, and QUIC all become more promi= nent.
Also, i= t would be helpful to understand where UDP is not supported. For example, i= t might be that UDP is blocked on some corporate firewalls because conferen= cing is only supported on the internal network, or via VPN. In these cases = QUIC would probably still work perfectly fine for the intended use cases, a= ssuming the VPN solution does not introduce buffering in packet tunnelling.=

Adding TCP as a fall= back isn=E2=80=99t merely tunneling data. It requires a new QUIC emulation = interface and it typically requires a separate host with separate TLS certi= ficate management. TCP typically runs in kernel where QUIC runs in userspac= e and pulling in a userspace TCP stack is also work. And then of course the= latency considerations. So many deployments would happily sacrifice the 5%= of users that are not running UDP as they done before with users running I= E6.


On 15 April 2019 at 13.15.09, Brian Trammell = (IETF) (ietf@trammell.ch) wrote:



> On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
> =20
> QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t s= ee how TCP fallback will work for the general case.
> =20
> A lot of games, VR applications, streaming services etc. are going= to build semi-proprietary QUIC versions, or at least use QUIC with customi= sed application protocols where TCP fallback is simply pointless because it= doesn=E2=80=99t support the framing needed and if it were possible, why wo= uld adapt an application layer protocol to work on TCP if you don=E2=80=99t= have to - of course you have to if it gets blocked - hence try to avoid th= at.

So you see the deployment strategy for these applications to be "z= ero availability on non-UDP-accessible networks"? That seems bold to m= e unless you're talking about QUIC being used as a replacement for &quo= t;application-provided transport layer over UDP", which is certainly a= big part of the market but not all of it.

You could always tunnel UDP over TCP of course, but from a transport la= yer perspective (and a transport-visible wire image perspective), that'= s a TCP fallback.

> I don=E2=80=99t have any numbers on transparency, but given the re= ach of voice call applications, you can probably safely assume that UDP wil= l be supported through most networks.

When we looked at this, admittedly a few years ago, we saw UDP blocking= on par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of= paths. That's one nine of availability pathwise, which is... not great= .

> The problem again is if only some UDP is allowed through traffic i= nspection or at least port numbering.
> =20
> It can be a good thing that a QUIC version is detectable if the al= ternative is that anything unknown gets blocked. That is the big unknown.

As I said in my other message this morning, I don't think version n= egotiation greasing is useful at this time because there is no reasonable m= odel of a wire-visible version difference where an on-path device might wan= t to let through one greased-version and not another greased-version, becau= se the wire-image profiles and semantic properties of those two versions ar= e by definition of greasing identical. =20

At this point, given connection-availability as the metric to optimize = for, it seems like reducing features that might be mistaken for QUIC-distin= guishers in the wire image would be useful, and version greasing seems like= one such feature.

> Will it help to be is opaque as possible, or not? Some of the scen= arios I posted earlier show that no matter what you do, something will get = in the way.

This all comes down to the threat model, and the model of incentives fo= r on-path devices.

I personally think the correct design target is to put trivial QUIC-dis= criminability into the wire image, since there will be a lot of pressure to= distinguish QUIC from not-QUIC traffic regardless of what we do, and if we= don't put grippy bits in the wire image, the distinguishing functions = will grip on to the slippy bits, with difficult to predict outcomes. I reco= gnize I am in the minority (of people who speak up) on this issue, though.

Cheers,

Brian

> On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote:
> =20
>> hi Mikkel, =20
>> =20
>> perhaps a bit late to this party, I'm not sure I understan= d the process you envision by which the TCP fallback will go away. =20
>> =20
>> Once it's in, it'll get used in a high enough proporti= on of cases that the availability risk of turning it off, balanced against = the fact that it already works (as it's pretty much mandatory for deplo= ying in today's 95%-UDP-transparent Internet), will go away very slowly= indeed. =20
>> =20
>> Cheers, =20
>> =20
>> Brian =20
>> =20
>> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgens= en <mikkelfj@gmail.com> wro= te: =20
>> > =20
>> > In a not so distant future, a fallback to TCP would not b= e a viable alternative for a number of services. Think WebRTC. =20
>> > If QUIC and other encrypted protocols become dominant, ju= st blocking everything would literally block everything. =20
>> > Of course, http(s) as we know it, it will continue to liv= e on, but many mobile apps would not. =20
>> > =20
>> > =20
>> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind (mirja.kuehlewind@ericsson.com= ) wrote: =20
>> > =20
>> >> Hi Mikkel, =20
>> >> =20
>> >> I guess it is much more likely that any of those acto= rs would just block QUIC all together (as there is actually a fallback to T= CP). =20
>> >> =20
>> >> Mirja =20
>> >> =20
>> >> =20
>> >> =20
>> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of = Mikkel Fahn=C3=B8e J=C3=B8rgensen" <quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: =20
>> >> =20
>> >> =20
>> >> Let=E2=80=99s say China makes a deal with Google to a= llow their search engine (a not entirely unreasonably proposition). =20
>> >> The Great Firewall of China (GFC) is reconfigured to = accept traffic from a specific IP range for QUIC protocol v1. =20
>> >> =20
>> >> =20
>> >> =20
>> >> Google later upgrades to v2. GFC is updated. Later, o= ut of ignorance, some other department within said company decides that its= browsers should all use forced version aliases as a rule. GFC breaks. (Ass= uming Googles servers are not located within the demilitarised =20
>> >> zone and users use Chrome). =20
>> >> =20
>> >> =20
>> >> Alternative 1: Google up front decides to deploy forc= ed version aliasing. China rejects the deal because they do not want to sup= port random traffic through GFC. =20
>> >> =20
>> >> =20
>> >> Alternative 2: Google up front decides to deploy forc= ed version aliasing, and China does not reject the deal, out of ignorance. = Later some department in China GFC oversight realises the deal and forces G= oogle to remove forced version aliasing, or shut down =20
>> >> its service. =20
>> >> =20
>> >> =20
>> >> Alternative 3: Google up front decides to deploy forc= ed version aliasing and China says, of course, we trust everything from Goo= gles IP range. =20
>> >> =20
>> >> =20
>> >> Alternative 4: Google realises that forced version al= iasing does not work in the general case, and makes a special case for user= s within a certain geographical area. =20
>> >> =20
>> >> =20
>> >> Disclaimer: I=E2=80=99m not affiliated with Google an= d this might not at all be how things would work, but it does highlight som= e of the challenges. =20
>> >> =20
>> >> =20
>> >> Of course, to be fair, China is not the only governme= nt entity that might have a vested interest. Let's take a fictional exa= mple of US a real estate investor with heavy ties to the eastern european b= lock who somehow finds himself elected as president needing =20
>> >> to find leverage on trade negotiations without effect= ively hurting personal finances. It turns out that blocking certain digital= services from said eastern european block is the perfect tool in the trade= negotiations.. Advisers point out that those services =20
>> >> run heavily encrypted on the dark web with perpetual = circulation of IP ranges so, ignoring any legal concerns, it would not be p= ractically possible. Eventually someone figures out that these services all= usually are at the forefront of technology and currently =20
>> >> use QUIC v3.2 and no-one else has deployed that versi= on yet, so it would suffice to ask NSA to tap into the backbone and disrupt= specific packets. Of course, this ends up taking down the Bavarian local g= overnment election process in Germany where they are =20
>> >> the first to use a new digital election system. Not t= hat the is an issue, since trade negotiations are also running hot in that = area, so that is just an accidental bonus. =20
>> >> =20
>> >> =20
>> >> Or an endless number of other developments over the n= ext few decades if the past few years is anything to go by. =20
>> >> =20
>> >> =20
>> >> =20
>> >> =20
>> >> =20
>> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote: =20
>> >> =20
>> >> Thanks Mikkel, I do understand that various actors in= tentionally drop - but are you saying these actors would specifically choos= e to block a new version of QUIC ... I do not understand that assertion. = =20
>> >> =20
>> >> =20
>> >> Gorry =20
>> >> =20
>> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8r= gensen <mikkelfj@gmail.com>= wrote: =20
>> >> =20
>> >> =20
>> >> =20
>> >> China blocks as a rule. =20
>> >> Russia is running an experiment to block the rest of = the internet. =20
>> >> USA blocks net neutrality. =20
>> >> EU blocks cookies. =20
>> >> GB blocks itself. =20
>> >> =20
>> >> =20
>> >> So blocking is not limited to what an operator consid= ers best for business. =20
>> >> =20
>> >> =20
>> >> =20
>> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote: =20
>> >> =20
>> >> =20
>> >> I understand why people want to come down on the side= of preventing ossification. But, things have changed. There are a lot of m= ore negative consequences now when people unnecessarily block things. I thi= nk operators would put a lot of pressure on vendors to =20
>> >> not do it now and to fix it if they did "by acci= dent". Of course, I am only one operator. It would be nice to hear fro= m others... =20
>> >> =20
>> >> =20
>> >> =20
>> >> John =20
>> >> =20
>> >> =20
>> >> -----Original Message----- =20
>> >> From: QUIC <quic-bounces@ietf.org> On Behalf Of Roberto Peon =20
>> >> Sent: Wednesday, April 10, 2019 12:52 PM =20
>> >> To: G Fairhurst <gorry@erg.abdn.ac.uk>; =20
>> >> quic@ietf.org = =20
>> >> Subject: Re: Is "Version Greasing" a new be= nfit or a new obstacle? =20
>> >> =20
>> >> WARNING: The sender of this email could not be valida= ted and may not match the person in the "From" field. =20
>> >> =20
>> >> CAUTION: This email originated from outside of the or= ganization. Do not click links or open attachments unless you recognize the= sender and know the content is safe. =20
>> >> =20
>> >> =20
>> >> You're kinda between a rock-and-a-hard-place eith= er way: =20
>> >> =20
>> >> - We've seen how much fun ossification is in TCP = and HTTP. If the thing is observable, it will be ossified seems to be the l= esson. A lot of the reason why QUIC was started in the first place was beca= use of the inability to improve TCP due to this ossification. =20
>> >> - OTOH, there is the fear of unknown/unobservable whi= ch might cause operators to block things, whether predictably or not. =20
>> >> =20
>> >> My opinion is that it is better to start with prevent= ing ossification, and then if that results in too large a percentage of ope= rators blocking things, to re-evaluate. =20
>> >> =20
>> >> My guesses: =20
>> >> IP+port tuples and traffic patterns are still observa= ble (for better and worse), which implies operators will still have signifi= cant tools for managing traffic. I believe that these are acted on/matched = (ML or not) regardless of any other data presented. In =20
>> >> other words, I have a doubt that stating the version = in an observable way will prevent the use of such tools. =20
>> >> =20
>> >> Most problems I've seen associated with implement= ations rather than protocol versions (though when the latter happens it is = pretty severe).. If you believe this assertion, then acting on protocol ver= sion is less interesting than attempting to act based on implementation = =20
>> >> fingerprints. =20
>> >> -=3DR =20
>> >> =20
>> >> =20
>> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhu= rst" <quic-bounces@ietf.or= g on behalf of =20
>> >> gorry@erg.abd= n.ac.uk> wrote: =20
>> >> =20
>> >> Obscuring the version of a protocol seems like a majo= r design design =20
>> >> decision for wider use cases. So, I'm trying to u= nderstand the =20
>> >> motivation for version greasing. =20
>> >> =20
>> >> (1) I know there were instances where some early vers= ions of QUIC were =20
>> >> blocked due to an uninitentional matching of the head= er. Is there =20
>> >> evidence of intentional attempts to block updates to = protocols? =20
>> >> =20
>> >> (2) Thinking about operating a network that cares abo= ut user support and =20
>> >> protection from unwanted traffic, I would expect that= there would be =20
>> >> cases where traffic pattern anomolies are found and t= he appropriate =20
>> >> thing would be to try to determine if a new protocol = had been deployed =20
>> >> and monitor it, if not, then the next most obvious th= ing could be to =20
>> >> block all unexpected traffic, that seems like a decis= ion to hide the =20
>> >> version could increase ossification for new versions = in these cases.. =20
>> >> =20
>> >> (3) Similarly, if a threat is known to impact only a = specific (older) =20
>> >> version, it would seem to motivate a drop of that tra= ffic that seeks to =20
>> >> use that version, while still permitting other traffi= c. Forcing version =20
>> >> detection to use pattern matching/ML will lead to les= s predictable =20
>> >> outcomes, or blocking based on address, etc. =20
>> >> =20
>> >> (4) This obfusticates the most basic piece of reporti= ng information used =20
>> >> for support. It hides the extent of deployment of the= current protocol =20
>> >> version and prevlance of old implementations. =20
>> >> =20
>> >> (5) On the support, if a problem only emerges when a = particular version =20
>> >> is used with a particular address, then this helps pi= npoint the issues. =20
>> >> Matching client versions to servers is much more of a= n issue if the user =20
>> >> community uses a wide range of servers (less so, I ex= pect for major =20
>> >> providers: google, facebook, etc, etc), but significa= nt when there is a =20
>> >> use of a diverse set of external sites and sites with= their own load =20
>> >> balancers, etc and a need to manage interactions with= L2 services. =20
>> >> =20
>> >> I am intersted in knowing if this is likely to benefi= t or be a new obstacle? =20
>> >> =20
>> >> Gorry

--0000000000003bf81b05868ffd07-- From nobody Mon Apr 15 04:32:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23951200B2 for ; Mon, 15 Apr 2019 04:32:34 -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 1SMtsMg0VD5S for ; Mon, 15 Apr 2019 04:32:30 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09DF1200B8 for ; Mon, 15 Apr 2019 04:32:30 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id c4so14234652ioh.9 for ; Mon, 15 Apr 2019 04:32:30 -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=BGvjCu/mhBJqTDDtqflxlkoKpyXwCvJmA1yr9PLjzz4=; b=T/ikZ9cOxAJ3yZ3Qh3nhzej2o3kavBIwUDgqOwVmOajaGb9mQ/0flhyMyxUxRodBR2 4sCW+poOO+tR4EJisCfuQcQ+3U9cpvcxGrFbSsEgayvl+BAT8ndtDz/ZOAX6WrHXj6UU PpZhUOdgJSS/LJUltxKswj1+D0L1ms9Zw/JsEUk5qJ50+r7ftqGcGa0bHZkDX9cVMsHj ZH8GL+lSZz8p9vJEzGhP3gV46IX4fP8AH6Zm4qEbs+fHQ1oTduk323Kf1VUI34SR4r36 zP/FPjjZlwczNyoLKGkgknHsaPb6/TEFBiS0UIzvT5WHRcTscnflKJlZMRDH2m/RwxKj XNSw== 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=BGvjCu/mhBJqTDDtqflxlkoKpyXwCvJmA1yr9PLjzz4=; b=e4tPPNAwKnj3WC9gaJtqTih9vJP1ptYPf4mUN9amQj4Dib6K8Eda7jSFUpClk0vIvC rEuHN8ZDKs9uaMPnW6uKsXLj+i7YS6TK/3+VnBmwe1rKk1sKpLn/6iFfujJTA8KlBbLK CluDE9t0Ho3Bof0AtQrAYmTpAIbdpqR2fpoZPAO9O6Jk2f3mAIyNkzwCWhKHmmHt4uyS ljFCzcbnm9F0Sn8uHQpxlykJz+xKlJH24Hhu7dsAyOpMwaRmiUvcWmv+ma1BGRslQ2lP TW1wqeJX89RauKZsEGcBvAEWJzjtpGGdaaZMsgpvppJXOWG3RK0drzwPB3Ta0h40UXaV TPgg== X-Gm-Message-State: APjAAAXt1A2oDFy9djgImgVKDzIzak4n6p3O6WJFechgTvrKHk+ZFUSh J9UEn/xgwYVr2bxubiKW0iCZ2upIvD/BwS35Bkw= X-Google-Smtp-Source: APXvYqxSTqKWGpiM+y6or8G2jcNVTwDcW9gyvN6KT8NcDSYUAFrqyUuFo1fyaTRZMSHhS9CKsMUww7Ztpu638EBHCeI= X-Received: by 2002:a5d:8902:: with SMTP id b2mr47534230ion.267.1555327949960; Mon, 15 Apr 2019 04:32:29 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 15 Apr 2019 04:32:29 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 15 Apr 2019 04:32:29 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: "Brian Trammell (IETF)" Cc: Gorry Fairhurst , "quic@ietf.org" , "Border, John" , Roberto Peon , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="000000000000f779530586900152" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 11:32:35 -0000 --000000000000f779530586900152 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To be clear, I=E2=80=99m not saying that TCP fallback goes away from HTTP/3= - this is not likely. But in this case infrastructure is available in abundance already. On 15 April 2019 at 13.31.09, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@g= mail.com) wrote: Any kind of game or low latency control system such as 5G avionics cannot use TCP as fallback since the buffering would be a non-starter. I would expect UDP to be more commonly supported both as games with their own protocols, WebRTC, and QUIC all become more prominent. Also, it would be helpful to understand where UDP is not supported. For example, it might be that UDP is blocked on some corporate firewalls because conferencing is only supported on the internal network, or via VPN. In these cases QUIC would probably still work perfectly fine for the intended use cases, assuming the VPN solution does not introduce buffering in packet tunnelling. Adding TCP as a fallback isn=E2=80=99t merely tunneling data. It requires a= new QUIC emulation interface and it typically requires a separate host with separate TLS certificate management. TCP typically runs in kernel where QUIC runs in userspace and pulling in a userspace TCP stack is also work. And then of course the latency considerations. So many deployments would happily sacrifice the 5% of users that are not running UDP as they done before with users running IE6. On 15 April 2019 at 13.15.09, Brian Trammell (IETF) (ietf@trammell.ch) wrote: > On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see how = TCP fallback will work for the general case. > > A lot of games, VR applications, streaming services etc. are going to build semi-proprietary QUIC versions, or at least use QUIC with customised application protocols where TCP fallback is simply pointless because it doesn=E2=80=99t support the framing needed and if it were possible, why wou= ld adapt an application layer protocol to work on TCP if you don=E2=80=99t have to -= of course you have to if it gets blocked - hence try to avoid that. So you see the deployment strategy for these applications to be "zero availability on non-UDP-accessible networks"? That seems bold to me unless you're talking about QUIC being used as a replacement for "application-provided transport layer over UDP", which is certainly a big part of the market but not all of it. You could always tunnel UDP over TCP of course, but from a transport layer perspective (and a transport-visible wire image perspective), that's a TCP fallback. > I don=E2=80=99t have any numbers on transparency, but given the reach of = voice call applications, you can probably safely assume that UDP will be supported through most networks. When we looked at this, admittedly a few years ago, we saw UDP blocking on par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of paths. That's one nine of availability pathwise, which is... not great. > The problem again is if only some UDP is allowed through traffic inspection or at least port numbering. > > It can be a good thing that a QUIC version is detectable if the alternative is that anything unknown gets blocked. That is the big unknown. As I said in my other message this morning, I don't think version negotiation greasing is useful at this time because there is no reasonable model of a wire-visible version difference where an on-path device might want to let through one greased-version and not another greased-version, because the wire-image profiles and semantic properties of those two versions are by definition of greasing identical. At this point, given connection-availability as the metric to optimize for, it seems like reducing features that might be mistaken for QUIC-distinguishers in the wire image would be useful, and version greasing seems like one such feature. > Will it help to be is opaque as possible, or not? Some of the scenarios I posted earlier show that no matter what you do, something will get in the way. This all comes down to the threat model, and the model of incentives for on-path devices. I personally think the correct design target is to put trivial QUIC-discriminability into the wire image, since there will be a lot of pressure to distinguish QUIC from not-QUIC traffic regardless of what we do, and if we don't put grippy bits in the wire image, the distinguishing functions will grip on to the slippy bits, with difficult to predict outcomes. I recognize I am in the minority (of people who speak up) on this issue, though. Cheers, Brian > On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote: > >> hi Mikkel, >> >> perhaps a bit late to this party, I'm not sure I understand the process you envision by which the TCP fallback will go away. >> >> Once it's in, it'll get used in a high enough proportion of cases that the availability risk of turning it off, balanced against the fact that it already works (as it's pretty much mandatory for deploying in today's 95%-UDP-transparent Internet), will go away very slowly indeed. >> >> Cheers, >> >> Brian >> >> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> > >> > In a not so distant future, a fallback to TCP would not be a viable alternative for a number of services. Think WebRTC. >> > If QUIC and other encrypted protocols become dominant, just blocking everything would literally block everything. >> > Of course, http(s) as we know it, it will continue to live on, but many mobile apps would not. >> > >> > >> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind ( mirja.kuehlewind@ericsson.com) wrote: >> > >> >> Hi Mikkel, >> >> >> >> I guess it is much more likely that any of those actors would just block QUIC all together (as there is actually a fallback to TCP). >> >> >> >> Mirja >> >> >> >> >> >> >> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e J= =C3=B8rgensen" < quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: >> >> >> >> >> >> Let=E2=80=99s say China makes a deal with Google to allow their searc= h engine (a not entirely unreasonably proposition). >> >> The Great Firewall of China (GFC) is reconfigured to accept traffic from a specific IP range for QUIC protocol v1. >> >> >> >> >> >> >> >> Google later upgrades to v2. GFC is updated. Later, out of ignorance, some other department within said company decides that its browsers should all use forced version aliases as a rule. GFC breaks. (Assuming Googles servers are not located within the demilitarised >> >> zone and users use Chrome). >> >> >> >> >> >> Alternative 1: Google up front decides to deploy forced version aliasing. China rejects the deal because they do not want to support random traffic through GFC. >> >> >> >> >> >> Alternative 2: Google up front decides to deploy forced version aliasing, and China does not reject the deal, out of ignorance. Later some department in China GFC oversight realises the deal and forces Google to remove forced version aliasing, or shut down >> >> its service. >> >> >> >> >> >> Alternative 3: Google up front decides to deploy forced version aliasing and China says, of course, we trust everything from Googles IP range. >> >> >> >> >> >> Alternative 4: Google realises that forced version aliasing does not work in the general case, and makes a special case for users within a certain geographical area. >> >> >> >> >> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might not= at all be how things would work, but it does highlight some of the challenges. >> >> >> >> >> >> Of course, to be fair, China is not the only government entity that might have a vested interest. Let's take a fictional example of US a real estate investor with heavy ties to the eastern european block who somehow finds himself elected as president needing >> >> to find leverage on trade negotiations without effectively hurting personal finances. It turns out that blocking certain digital services from said eastern european block is the perfect tool in the trade negotiations.. Advisers point out that those services >> >> run heavily encrypted on the dark web with perpetual circulation of IP ranges so, ignoring any legal concerns, it would not be practically possible. Eventually someone figures out that these services all usually are at the forefront of technology and currently >> >> use QUIC v3.2 and no-one else has deployed that version yet, so it would suffice to ask NSA to tap into the backbone and disrupt specific packets. Of course, this ends up taking down the Bavarian local government election process in Germany where they are >> >> the first to use a new digital election system. Not that the is an issue, since trade negotiations are also running hot in that area, so that is just an accidental bonus. >> >> >> >> >> >> Or an endless number of other developments over the next few decades if the past few years is anything to go by. >> >> >> >> >> >> >> >> >> >> >> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote: >> >> >> >> Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ... I do not understand that assertion. >> >> >> >> >> >> Gorry >> >> >> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> >> >> >> >> >> >> >> China blocks as a rule. >> >> Russia is running an experiment to block the rest of the internet. >> >> USA blocks net neutrality. >> >> EU blocks cookies. >> >> GB blocks itself. >> >> >> >> >> >> So blocking is not limited to what an operator considers best for business. >> >> >> >> >> >> >> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrote: >> >> >> >> >> >> I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to >> >> not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others... >> >> >> >> >> >> >> >> John >> >> >> >> >> >> -----Original Message----- >> >> From: QUIC On Behalf Of Roberto Peon >> >> Sent: Wednesday, April 10, 2019 12:52 PM >> >> To: G Fairhurst ; >> >> quic@ietf.org >> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? >> >> >> >> WARNING: The sender of this email could not be validated and may not match the person in the "From" field. >> >> >> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> >> >> >> You're kinda between a rock-and-a-hard-place either way: >> >> >> >> - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification. >> >> - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not. >> >> >> >> My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate. >> >> >> >> My guesses: >> >> IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In >> >> other words, I have a doubt that stating the version in an observable way will prevent the use of such tools. >> >> >> >> Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe).. If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation >> >> fingerprints. >> >> -=3DR >> >> >> >> >> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" < quic-bounces@ietf.org on behalf of >> >> gorry@erg.abdn.ac.uk> wrote: >> >> >> >> Obscuring the version of a protocol seems like a major design design >> >> decision for wider use cases. So, I'm trying to understand the >> >> motivation for version greasing. >> >> >> >> (1) I know there were instances where some early versions of QUIC wer= e >> >> blocked due to an uninitentional matching of the header. Is there >> >> evidence of intentional attempts to block updates to protocols? >> >> >> >> (2) Thinking about operating a network that cares about user support and >> >> protection from unwanted traffic, I would expect that there would be >> >> cases where traffic pattern anomolies are found and the appropriate >> >> thing would be to try to determine if a new protocol had been deploye= d >> >> and monitor it, if not, then the next most obvious thing could be to >> >> block all unexpected traffic, that seems like a decision to hide the >> >> version could increase ossification for new versions in these cases.. >> >> >> >> (3) Similarly, if a threat is known to impact only a specific (older) >> >> version, it would seem to motivate a drop of that traffic that seeks to >> >> use that version, while still permitting other traffic. Forcing version >> >> detection to use pattern matching/ML will lead to less predictable >> >> outcomes, or blocking based on address, etc. >> >> >> >> (4) This obfusticates the most basic piece of reporting information used >> >> for support. It hides the extent of deployment of the current protoco= l >> >> version and prevlance of old implementations. >> >> >> >> (5) On the support, if a problem only emerges when a particular version >> >> is used with a particular address, then this helps pinpoint the issues. >> >> Matching client versions to servers is much more of an issue if the user >> >> community uses a wide range of servers (less so, I expect for major >> >> providers: google, facebook, etc, etc), but significant when there is a >> >> use of a diverse set of external sites and sites with their own load >> >> balancers, etc and a need to manage interactions with L2 services. >> >> >> >> I am intersted in knowing if this is likely to benefit or be a new obstacle? >> >> >> >> Gorry --000000000000f779530586900152 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = To be clear, I=E2=80= =99m not saying that TCP fallback goes away from HTTP/3 - this is not likel= y. But in this case infrastructure is available in abundance already.
=


On 15 April 2019 at 13.31.09, Mikkel Fahn=C3=B8e J=C3=B8r= gensen (mikkelfj@gmail.com) wrote= :

Any kind of game or low latency control system such as 5G avionics cannot use TCP as fallback since the buffering would be a non-starter.

I would expect UDP to be more commonly supported both as games with their own protocols, WebRTC, and QUIC all become more prominent.
Also, it would be helpful to understand where UDP is not supported. For example, it might be that UDP is blocked on some corporate firewalls because conferencing is only supported on the internal network, or via VPN. In these cases QUIC would probably still work perfectly fine for the intended use cases, assuming the VPN solution does not introduce buffering in packet tunnelling.

Adding TCP as a fallback isn=E2=80=99t merely tunneling data. It requires a new QUIC emulation interface and it typically requires a separate host with separate TLS certificate management. TCP typically runs in kernel where QUIC runs in userspace and pulling in a userspace TCP stack is also work. And then of course the latency considerations. So many deployments would happily sacrifice the 5% of users that are not running UDP as they done before with users running IE6.


On 15 April 2019 at 13.15.09, Brian Trammell (IETF) (ietf@trammell.ch) wrote:



> On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:=
>
> QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see how TCP fallback will work for the general case.
>
> A lot of games, VR applications, streaming services etc. are going to build semi-proprietary QUIC versions, or at least use QUIC with customised application protocols where TCP fallback is simply pointless because it doesn=E2=80=99t support the framing needed and if it were possible, why would adapt an application layer protocol to work on TCP if you don=E2=80=99t have to - of course you have to if it gets blocked - hence try to avoid that.

So you see the deployment strategy for these applications to be "zero availability on non-UDP-accessible networks"? That seems bo= ld to me unless you're talking about QUIC being used as a replacement for "application-provided transport layer over UDP", which is certainly a big part of the market but not all of it.

You could always tunnel UDP over TCP of course, but from a transport layer perspective (and a transport-visible wire image perspective), that's a TCP fallback.

> I don=E2=80=99t have any numbers on transparency, but given the reach of voice call applications, you can probably safely assume that UDP will be supported through most networks.

When we looked at this, admittedly a few years ago, we saw UDP blocking on par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of paths. That's one nine of availability pathwise, which is... not great.

> The problem again is if only some UDP is allowed through traffic inspection or at least port numbering.
>
> It can be a good thing that a QUIC version is detectable if the alternative is that anything unknown gets blocked. That is the big unknown.

As I said in my other message this morning, I don't think version negotiation greasing is useful at this time because there is no reasonable model of a wire-visible version difference where an on-path device might want to let through one greased-version and not another greased-version, because the wire-image profiles and semantic properties of those two versions are by definition of greasing identical.

At this point, given connection-availability as the metric to optimize for, it seems like reducing features that might be mistaken for QUIC-distinguishers in the wire image would be useful, and version greasing seems like one such feature.

> Will it help to be is opaque as possible, or not? Some of the scenarios I posted earlier show that no matter what you do, something will get in the way.

This all comes down to the threat model, and the model of incentives for on-path devices.

I personally think the correct design target is to put trivial QUIC-discriminability into the wire image, since there will be a lot of pressure to distinguish QUIC from not-QUIC traffic regardless of what we do, and if we don't put grippy bits in the wire image, the distinguishing functions will grip on to the slippy bits, with difficult to predict outcomes. I recognize I am in the minority (of people who speak up) on this issue, though.

Cheers,

Brian

> On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote:
>
>> hi Mikkel,
>>
>> perhaps a bit late to this party, I'm not sure I understand the process you envision by which the TCP fallback will go away.
>>
>> Once it's in, it'll get used in a high enough proportion of cases that the availability risk of turning it off, balanced against the fact that it already works (as it's pretty much mandatory for deploying in today's 95%-UDP-transparent Internet), will go away very slowly indeed.
>>
>> Cheers,
>>
>> Brian
>>
>> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:=
>> >
>> > In a not so distant future, a fallback to TCP would not be a viable alternative for a number of services. Think WebRTC.
>> > If QUIC and other encrypted protocols become dominant, just blocking everything would literally block everything.
>> > Of course, http(s) as we know it, it will continue to live on, but many mobile apps would not.
>> >
>> >
>> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind (mirja.kuehlewind@ericsson= .com) wrote:
>> >
>> >> Hi Mikkel,
>> >>
>> >> I guess it is much more likely that any of those actors would just block QUIC all together (as there is actually a fallback to TCP).
>> >>
>> >> Mirja
>> >>
>> >>
>> >>
>> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikk= el Fahn=C3=B8e J=C3=B8rgensen" <quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote:
>> >>
>> >>
>> >> Let=E2=80=99s say China makes a deal with Google to allow their search engine (a not entirely unreasonably proposition).
>> >> The Great Firewall of China (GFC) is reconfigured to accept traffic from a specific IP range for QUIC protocol v1.
>> >>
>> >>
>> >>
>> >> Google later upgrades to v2. GFC is updated. Later, out of ignorance, some other department within said company decides that its browsers should all use forced version aliases as a rule. GFC breaks. (Assuming Googles servers are not located within the demilitarised
>> >> zone and users use Chrome).
>> >>
>> >>
>> >> Alternative 1: Google up front decides to deploy forced version aliasing. China rejects the deal because they do not want to support random traffic through GFC.
>> >>
>> >>
>> >> Alternative 2: Google up front decides to deploy forced version aliasing, and China does not reject the deal, out of ignorance. Later some department in China GFC oversight realises the deal and forces Google to remove forced version aliasing, or shut down
>> >> its service.
>> >>
>> >>
>> >> Alternative 3: Google up front decides to deploy forced version aliasing and China says, of course, we trust everything from Googles IP range.
>> >>
>> >>
>> >> Alternative 4: Google realises that forced version aliasing does not work in the general case, and makes a special case for users within a certain geographical area.
>> >>
>> >>
>> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might not at all be how things would work, but it does highlight some of the challenges.
>> >>
>> >>
>> >> Of course, to be fair, China is not the only government entity that might have a vested interest. Let's take a fictional example of US a real estate investor with heavy ties to the eastern european block who somehow finds himself elected as president needing
>> >> to find leverage on trade negotiations without effectively hurting personal finances. It turns out that blocking certain digital services from said eastern european block is the perfect tool in the trade negotiations.. Advisers point out that those services
>> >> run heavily encrypted on the dark web with perpetual circulation of IP ranges so, ignoring any legal concerns, it would not be practically possible. Eventually someone figures out that these services all usually are at the forefront of technology and currently
>> >> use QUIC v3.2 and no-one else has deployed that version yet, so it would suffice to ask NSA to tap into the backbone and disrupt specific packets. Of course, this ends up taking down the Bavarian local government election process in Germany where they are
>> >> the first to use a new digital election system. Not that the is an issue, since trade negotiations are also running hot in that area, so that is just an accidental bonus.
>> >>
>> >>
>> >> Or an endless number of other developments over the next few decades if the past few years is anything to go by.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote: >> >>
>> >> Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ... I do not understand that assertion.
>> >>
>> >>
>> >> Gorry
>> >>
>> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgens= en <mikkelfj@gmail.com> wrote:=
>> >>
>> >>
>> >>
>> >> China blocks as a rule.
>> >> Russia is running an experiment to block the rest of the internet.
>> >> USA blocks net neutrality.
>> >> EU blocks cookies.
>> >> GB blocks itself.
>> >>
>> >>
>> >> So blocking is not limited to what an operator considers best for business.
>> >>
>> >>
>> >>
>> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) wrot= e:
>> >>
>> >>
>> >> I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to
>> >> not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others...
>> >>
>> >>
>> >>
>> >> John
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: QUIC <q= uic-bounces@ietf.org> On Behalf Of Roberto Peon
>> >> Sent: Wednesday, April 10, 2019 12:52 PM
>> >> To: G Fairhurst <gorry@erg.abdn.ac.uk>; >> >> quic@ietf.org
>> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?
>> >>
>> >> WARNING: The sender of this email could not be validated and may not match the person in the "From" field.
>> >>
>> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>> >>
>> >>
>> >> You're kinda between a rock-and-a-hard-place either way:
>> >>
>> >> - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification.
>> >> - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not.
>> >>
>> >> My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate.
>> >>
>> >> My guesses:
>> >> IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In
>> >> other words, I have a doubt that stating the version in an observable way will prevent the use of such tools.
>> >>
>> >> Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe).. If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation
>> >> fingerprints.
>> >> -=3DR
>> >>
>> >>
>> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" <quic-bounces@i= etf.org on behalf of
>> >> gorry@erg.abdn.ac= .uk> wrote:
>> >>
>> >> Obscuring the version of a protocol seems like a major design design
>> >> decision for wider use cases. So, I'm trying to understand the
>> >> motivation for version greasing.
>> >>
>> >> (1) I know there were instances where some early versions of QUIC were
>> >> blocked due to an uninitentional matching of the header. Is there
>> >> evidence of intentional attempts to block updates to protocols?
>> >>
>> >> (2) Thinking about operating a network that cares about user support and
>> >> protection from unwanted traffic, I would expect that there would be
>> >> cases where traffic pattern anomolies are found and the appropriate
>> >> thing would be to try to determine if a new protocol had been deployed
>> >> and monitor it, if not, then the next most obvious thing could be to
>> >> block all unexpected traffic, that seems like a decision to hide the
>> >> version could increase ossification for new versions in these cases..
>> >>
>> >> (3) Similarly, if a threat is known to impact only a specific (older)
>> >> version, it would seem to motivate a drop of that traffic that seeks to
>> >> use that version, while still permitting other traffic. Forcing version
>> >> detection to use pattern matching/ML will lead to less predictable
>> >> outcomes, or blocking based on address, etc.
>> >>
>> >> (4) This obfusticates the most basic piece of reporting information used
>> >> for support. It hides the extent of deployment of the current protocol
>> >> version and prevlance of old implementations.
>> >>
>> >> (5) On the support, if a problem only emerges when a particular version
>> >> is used with a particular address, then this helps pinpoint the issues.
>> >> Matching client versions to servers is much more of an issue if the user
>> >> community uses a wide range of servers (less so, I expect for major
>> >> providers: google, facebook, etc, etc), but significant when there is a
>> >> use of a diverse set of external sites and sites with their own load
>> >> balancers, etc and a need to manage interactions with L2 services.
>> >>
>> >> I am intersted in knowing if this is likely to benefit or be a new obstacle?
>> >>
>> >> Gorry

--000000000000f779530586900152-- From nobody Mon Apr 15 08:29:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80901201FA for ; Mon, 15 Apr 2019 08:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_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_BOUND_DIGITS_15=0.798, 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 HXSWBXVIsKSm for ; Mon, 15 Apr 2019 08:29:23 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47BED1203D0 for ; Mon, 15 Apr 2019 08:29:23 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id x132so27658905itf.2 for ; Mon, 15 Apr 2019 08:29:23 -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=Ur1FyjV664l3D7luLI9Qnh8ETJUmRMwt1fAi9x2kAH4=; b=M1A+PCX3/EWD/+5rB5j0wGau+cmaPt9arBLvmWY1X1gSqWX4Wmtx9IZlG84uVdWLPu jEKZ3GrbdcDBGsOPtceMHD0EWerEUqJsrucCsKzho0NEyk6Pj6JOUhRf6kpg+Ro9B89p 5xQkTQUxFRE6GevczmMvON2nJlqH0ze4DXGNyJBtwoLh46VFsiayDa8IgMA0GIh5mKHy TDdG6qGnmXjvn7+iOJZBMiMB6P63R1B5Zovwa+62bKftfXyv60GVC318u+R6KGiff4c6 XAz2YjTY+JSH1vWaEj7KoPlGNNrEtKGzHIWUcj+i62p05JznWHi6QoN28a0M5YjrLbuv D34A== 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=Ur1FyjV664l3D7luLI9Qnh8ETJUmRMwt1fAi9x2kAH4=; b=ogp6fMfQjIx6IqflxKCRrUzhBwq3MMZj8VSCs9//AGVb+QPzQvG1ozcWrcQkN5AhjP 7h1PwcVj4pk2zC8C/qtWSNnf/89dwklN071rBi02Ji+DMUMdcip27o551MnF167WaGl4 ovvgpRBq8REw0ej1zgb+nz2z++nl2Y+F+1I4oVWBe9sdwGySvMu4fOPWCekYQyKgRJoZ fNc0k/afG4PH3/HFAhqfZ1wyUdk0QcSJNU8iUaZif+MEgj+wdYmryUShQNWdxoecqe+3 ULWj1nnYv6fVSEszHt/QN7hf4/jLGh/LCowedUxY4VolJApnrZ6gT0MuEgkx04CVfC3p 1MsA== X-Gm-Message-State: APjAAAUu1HmoDvlOHu0ZuCdndH/t7ACKzF4g3FLbluadczHaiKeqYaD1 obkrWOct0NRDPLO+PvbwDduxMcNQyM6NQWBYO4c= X-Google-Smtp-Source: APXvYqxN1atA9+vsNGIhFlW5WZs1+iO65lvkjlnc9XAz2A6vV2TQ55gtyBa/nnXvvq0tiKAsYEZxWYylzS7WD4xmnbc= X-Received: by 2002:a24:610b:: with SMTP id s11mr22454041itc.156.1555342162410; Mon, 15 Apr 2019 08:29:22 -0700 (PDT) MIME-Version: 1.0 References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> In-Reply-To: From: Ted Hardie Date: Mon, 15 Apr 2019 08:28:55 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: "Brian Trammell (IETF)" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Gorry Fairhurst , "quic@ietf.org" , "Border, John" , Roberto Peon , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="0000000000001840600586935119" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 15:29:27 -0000 --0000000000001840600586935119 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy, On Mon, Apr 15, 2019 at 4:15 AM Brian Trammell (IETF) wrote: > > > > On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > > > > QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see ho= w TCP > fallback will work for the general case. > > > > A lot of games, VR applications, streaming services etc. are going to > build semi-proprietary QUIC versions, or at least use QUIC with customise= d > application protocols where TCP fallback is simply pointless because it > doesn=E2=80=99t support the framing needed and if it were possible, why w= ould adapt > an application layer protocol to work on TCP if you don=E2=80=99t have to= - of > course you have to if it gets blocked - hence try to avoid that. > > So you see the deployment strategy for these applications to be "zero > availability on non-UDP-accessible networks"? That seems bold to me unles= s > you're talking about QUIC being used as a replacement for > "application-provided transport layer over UDP", which is certainly a big > part of the market but not all of it. > > There are classes of applications for which it is not particularly bold, since they don't function well at all with TCP. There are also classes where the fallback would be to a different stack. DNS over QUIC might fall back to DNS over TLS if UDP is blocked, for example. QUIC doesn't need a fallback there because the DNS stack has one. Ted > You could always tunnel UDP over TCP of course, but from a transport laye= r > perspective (and a transport-visible wire image perspective), that's a TC= P > fallback. > > > I don=E2=80=99t have any numbers on transparency, but given the reach o= f voice > call applications, you can probably safely assume that UDP will be > supported through most networks. > > When we looked at this, admittedly a few years ago, we saw UDP blocking o= n > par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of > paths. That's one nine of availability pathwise, which is... not great. > > > The problem again is if only some UDP is allowed through traffic > inspection or at least port numbering. > > > > It can be a good thing that a QUIC version is detectable if the > alternative is that anything unknown gets blocked. That is the big unknow= n. > > As I said in my other message this morning, I don't think version > negotiation greasing is useful at this time because there is no reasonabl= e > model of a wire-visible version difference where an on-path device might > want to let through one greased-version and not another greased-version, > because the wire-image profiles and semantic properties of those two > versions are by definition of greasing identical. > > At this point, given connection-availability as the metric to optimize > for, it seems like reducing features that might be mistaken for > QUIC-distinguishers in the wire image would be useful, and version greasi= ng > seems like one such feature. > > > Will it help to be is opaque as possible, or not? Some of the scenarios > I posted earlier show that no matter what you do, something will get in t= he > way. > > This all comes down to the threat model, and the model of incentives for > on-path devices. > > I personally think the correct design target is to put trivial > QUIC-discriminability into the wire image, since there will be a lot of > pressure to distinguish QUIC from not-QUIC traffic regardless of what we > do, and if we don't put grippy bits in the wire image, the distinguishing > functions will grip on to the slippy bits, with difficult to predict > outcomes. I recognize I am in the minority (of people who speak up) on th= is > issue, though. > > Cheers, > > Brian > > > On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote: > > > >> hi Mikkel, > >> > >> perhaps a bit late to this party, I'm not sure I understand the proces= s > you envision by which the TCP fallback will go away. > >> > >> Once it's in, it'll get used in a high enough proportion of cases that > the availability risk of turning it off, balanced against the fact that i= t > already works (as it's pretty much mandatory for deploying in today's > 95%-UDP-transparent Internet), will go away very slowly indeed. > >> > >> Cheers, > >> > >> Brian > >> > >> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > >> > > >> > In a not so distant future, a fallback to TCP would not be a viable > alternative for a number of services. Think WebRTC. > >> > If QUIC and other encrypted protocols become dominant, just blocking > everything would literally block everything. > >> > Of course, http(s) as we know it, it will continue to live on, but > many mobile apps would not. > >> > > >> > > >> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind ( > mirja.kuehlewind@ericsson.com) wrote: > >> > > >> >> Hi Mikkel, > >> >> > >> >> I guess it is much more likely that any of those actors would just > block QUIC all together (as there is actually a fallback to TCP). > >> >> > >> >> Mirja > >> >> > >> >> > >> >> > >> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e = J=C3=B8rgensen" < > quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: > >> >> > >> >> > >> >> Let=E2=80=99s say China makes a deal with Google to allow their sea= rch > engine (a not entirely unreasonably proposition). > >> >> The Great Firewall of China (GFC) is reconfigured to accept traffic > from a specific IP range for QUIC protocol v1. > >> >> > >> >> > >> >> > >> >> Google later upgrades to v2. GFC is updated. Later, out of > ignorance, some other department within said company decides that its > browsers should all use forced version aliases as a rule. GFC breaks. > (Assuming Googles servers are not located within the demilitarised > >> >> zone and users use Chrome). > >> >> > >> >> > >> >> Alternative 1: Google up front decides to deploy forced version > aliasing. China rejects the deal because they do not want to support rand= om > traffic through GFC. > >> >> > >> >> > >> >> Alternative 2: Google up front decides to deploy forced version > aliasing, and China does not reject the deal, out of ignorance. Later som= e > department in China GFC oversight realises the deal and forces Google to > remove forced version aliasing, or shut down > >> >> its service. > >> >> > >> >> > >> >> Alternative 3: Google up front decides to deploy forced version > aliasing and China says, of course, we trust everything from Googles IP > range. > >> >> > >> >> > >> >> Alternative 4: Google realises that forced version aliasing does no= t > work in the general case, and makes a special case for users within a > certain geographical area. > >> >> > >> >> > >> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might n= ot at all > be how things would work, but it does highlight some of the challenges. > >> >> > >> >> > >> >> Of course, to be fair, China is not the only government entity that > might have a vested interest. Let's take a fictional example of US a real > estate investor with heavy ties to the eastern european block who somehow > finds himself elected as president needing > >> >> to find leverage on trade negotiations without effectively hurting > personal finances. It turns out that blocking certain digital services fr= om > said eastern european block is the perfect tool in the trade negotiations= .. > Advisers point out that those services > >> >> run heavily encrypted on the dark web with perpetual circulation of > IP ranges so, ignoring any legal concerns, it would not be practically > possible. Eventually someone figures out that these services all usually > are at the forefront of technology and currently > >> >> use QUIC v3.2 and no-one else has deployed that version yet, so it > would suffice to ask NSA to tap into the backbone and disrupt specific > packets. Of course, this ends up taking down the Bavarian local governmen= t > election process in Germany where they are > >> >> the first to use a new digital election system. Not that the is an > issue, since trade negotiations are also running hot in that area, so tha= t > is just an accidental bonus. > >> >> > >> >> > >> >> Or an endless number of other developments over the next few decade= s > if the past few years is anything to go by. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) > wrote: > >> >> > >> >> Thanks Mikkel, I do understand that various actors intentionally > drop - but are you saying these actors would specifically choose to block= a > new version of QUIC ... I do not understand that assertion. > >> >> > >> >> > >> >> Gorry > >> >> > >> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> >> > >> >> > >> >> > >> >> China blocks as a rule. > >> >> Russia is running an experiment to block the rest of the internet. > >> >> USA blocks net neutrality. > >> >> EU blocks cookies. > >> >> GB blocks itself. > >> >> > >> >> > >> >> So blocking is not limited to what an operator considers best for > business. > >> >> > >> >> > >> >> > >> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) > wrote: > >> >> > >> >> > >> >> I understand why people want to come down on the side of preventing > ossification. But, things have changed. There are a lot of more negative > consequences now when people unnecessarily block things. I think operator= s > would put a lot of pressure on vendors to > >> >> not do it now and to fix it if they did "by accident". Of course, I > am only one operator. It would be nice to hear from others... > >> >> > >> >> > >> >> > >> >> John > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: QUIC On Behalf Of Roberto Peon > >> >> Sent: Wednesday, April 10, 2019 12:52 PM > >> >> To: G Fairhurst ; > >> >> quic@ietf.org > >> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? > >> >> > >> >> WARNING: The sender of this email could not be validated and may no= t > match the person in the "From" field. > >> >> > >> >> CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender and > know the content is safe. > >> >> > >> >> > >> >> You're kinda between a rock-and-a-hard-place either way: > >> >> > >> >> - We've seen how much fun ossification is in TCP and HTTP. If the > thing is observable, it will be ossified seems to be the lesson. A lot of > the reason why QUIC was started in the first place was because of the > inability to improve TCP due to this ossification. > >> >> - OTOH, there is the fear of unknown/unobservable which might cause > operators to block things, whether predictably or not. > >> >> > >> >> My opinion is that it is better to start with preventing > ossification, and then if that results in too large a percentage of > operators blocking things, to re-evaluate. > >> >> > >> >> My guesses: > >> >> IP+port tuples and traffic patterns are still observable (for bette= r > and worse), which implies operators will still have significant tools for > managing traffic. I believe that these are acted on/matched (ML or not) > regardless of any other data presented. In > >> >> other words, I have a doubt that stating the version in an > observable way will prevent the use of such tools. > >> >> > >> >> Most problems I've seen associated with implementations rather than > protocol versions (though when the latter happens it is pretty severe).. = If > you believe this assertion, then acting on protocol version is less > interesting than attempting to act based on implementation > >> >> fingerprints. > >> >> -=3DR > >> >> > >> >> > >> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" < > quic-bounces@ietf.org on behalf of > >> >> gorry@erg.abdn.ac.uk> wrote: > >> >> > >> >> Obscuring the version of a protocol seems like a major design > design > >> >> decision for wider use cases. So, I'm trying to understand the > >> >> motivation for version greasing. > >> >> > >> >> (1) I know there were instances where some early versions of QUIC > were > >> >> blocked due to an uninitentional matching of the header. Is there > >> >> evidence of intentional attempts to block updates to protocols? > >> >> > >> >> (2) Thinking about operating a network that cares about user suppor= t > and > >> >> protection from unwanted traffic, I would expect that there would > be > >> >> cases where traffic pattern anomolies are found and the appropriate > >> >> thing would be to try to determine if a new protocol had been > deployed > >> >> and monitor it, if not, then the next most obvious thing could be > to > >> >> block all unexpected traffic, that seems like a decision to hide > the > >> >> version could increase ossification for new versions in these > cases.. > >> >> > >> >> (3) Similarly, if a threat is known to impact only a specific > (older) > >> >> version, it would seem to motivate a drop of that traffic that seek= s > to > >> >> use that version, while still permitting other traffic. Forcing > version > >> >> detection to use pattern matching/ML will lead to less predictable > >> >> outcomes, or blocking based on address, etc. > >> >> > >> >> (4) This obfusticates the most basic piece of reporting information > used > >> >> for support. It hides the extent of deployment of the current > protocol > >> >> version and prevlance of old implementations. > >> >> > >> >> (5) On the support, if a problem only emerges when a particular > version > >> >> is used with a particular address, then this helps pinpoint the > issues. > >> >> Matching client versions to servers is much more of an issue if the > user > >> >> community uses a wide range of servers (less so, I expect for major > >> >> providers: google, facebook, etc, etc), but significant when there > is a > >> >> use of a diverse set of external sites and sites with their own > load > >> >> balancers, etc and a need to manage interactions with L2 services. > >> >> > >> >> I am intersted in knowing if this is likely to benefit or be a new > obstacle? > >> >> > >> >> Gorry > > --0000000000001840600586935119 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Mon, Apr 15, 2019 at 4:15 AM= Brian Trammell (IETF) <ietf@trammel= l.ch> wrote:


> On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= ; wrote:
>
> QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see h= ow TCP fallback will work for the general case.
>
> A lot of games, VR applications, streaming services etc. are going to = build semi-proprietary QUIC versions, or at least use QUIC with customised = application protocols where TCP fallback is simply pointless because it doe= sn=E2=80=99t support the framing needed and if it were possible, why would = adapt an application layer protocol to work on TCP if you don=E2=80=99t hav= e to - of course you have to if it gets blocked - hence try to avoid that.<= br>
So you see the deployment strategy for these applications to be "zero = availability on non-UDP-accessible networks"? That seems bold to me un= less you're talking about QUIC being used as a replacement for "ap= plication-provided transport layer over UDP", which is certainly a big= part of the market but not all of it.


There are classes of applications for = which it is not particularly bold, since they don't function well at al= l with TCP.=C2=A0

There are also classes wher= e the fallback would be to a different stack.=C2=A0 DNS over QUIC might fal= l back to DNS over TLS if UDP is blocked, for example.=C2=A0 QUIC doesn'= ;t need a fallback there because the DNS stack has one.

Ted

=C2=A0
You could always tunnel UDP over TCP of course, but from a transport layer = perspective (and a transport-visible wire image perspective), that's a = TCP fallback.

> I don=E2=80=99t have any numbers on transparency, but given the reach = of voice call applications, you can probably safely assume that UDP will be= supported through most networks.

When we looked at this, admittedly a few years ago, we saw UDP blocking on = par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of pat= hs. That's one nine of availability pathwise, which is... not great.
> The problem again is if only some UDP is allowed through traffic inspe= ction or at least port numbering.
>
> It can be a good thing that a QUIC version is detectable if the altern= ative is that anything unknown gets blocked. That is the big unknown.

As I said in my other message this morning, I don't think version negot= iation greasing is useful at this time because there is no reasonable model= of a wire-visible version difference where an on-path device might want to= let through one greased-version and not another greased-version, because t= he wire-image profiles and semantic properties of those two versions are by= definition of greasing identical.

At this point, given connection-availability as the metric to optimize for,= it seems like reducing features that might be mistaken for QUIC-distinguis= hers in the wire image would be useful, and version greasing seems like one= such feature.

> Will it help to be is opaque as possible, or not? Some of the scenario= s I posted earlier show that no matter what you do, something will get in t= he way.

This all comes down to the threat model, and the model of incentives for on= -path devices.

I personally think the correct design target is to put trivial QUIC-discrim= inability into the wire image, since there will be a lot of pressure to dis= tinguish QUIC from not-QUIC traffic regardless of what we do, and if we don= 't put grippy bits in the wire image, the distinguishing functions will= grip on to the slippy bits, with difficult to predict outcomes. I recogniz= e I am in the minority (of people who speak up) on this issue, though.

Cheers,

Brian

> On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote:
>
>> hi Mikkel,=C2=A0
>>
>> perhaps a bit late to this party, I'm not sure I understand th= e process you envision by which the TCP fallback will go away.=C2=A0
>>
>> Once it's in, it'll get used in a high enough proportion o= f cases that the availability risk of turning it off, balanced against the = fact that it already works (as it's pretty much mandatory for deploying= in today's 95%-UDP-transparent Internet), will go away very slowly ind= eed.
>>
>> Cheers,
>>
>> Brian
>>
>> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen &= lt;mikkelfj@gmail.c= om> wrote:
>> >=C2=A0
>> > In a not so distant future, a fallback to TCP would not be a = viable alternative for a number of services. Think WebRTC.
>> > If QUIC and other encrypted protocols become dominant, just b= locking everything would literally block everything.
>> > Of course, http(s) as we know it, it will continue to live on= , but many mobile apps would not.
>> >=C2=A0
>> >=C2=A0
>> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind (mirja.kuehlewind@eric= sson.com) wrote:
>> >=C2=A0
>> >> Hi Mikkel,=C2=A0
>> >>=C2=A0
>> >> I guess it is much more likely that any of those actors w= ould just block QUIC all together (as there is actually a fallback to TCP).= =C2=A0
>> >>=C2=A0
>> >> Mirja=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikk= el Fahn=C3=B8e J=C3=B8rgensen" <quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrot= e:=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Let=E2=80=99s say China makes a deal with Google to allow= their search engine (a not entirely unreasonably proposition).=C2=A0
>> >> The Great Firewall of China (GFC) is reconfigured to acce= pt traffic from a specific IP range for QUIC protocol v1.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Google later upgrades to v2. GFC is updated. Later, out o= f ignorance, some other department within said company decides that its bro= wsers should all use forced version aliases as a rule. GFC breaks. (Assumin= g Googles servers are not located within the demilitarised=C2=A0
>> >> zone and users use Chrome).=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 1: Google up front decides to deploy forced v= ersion aliasing. China rejects the deal because they do not want to support= random traffic through GFC.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 2: Google up front decides to deploy forced v= ersion aliasing, and China does not reject the deal, out of ignorance. Late= r some department in China GFC oversight realises the deal and forces Googl= e to remove forced version aliasing, or shut down=C2=A0
>> >> its service.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 3: Google up front decides to deploy forced v= ersion aliasing and China says, of course, we trust everything from Googles= IP range.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 4: Google realises that forced version aliasi= ng does not work in the general case, and makes a special case for users wi= thin a certain geographical area.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Disclaimer: I=E2=80=99m not affiliated with Google and th= is might not at all be how things would work, but it does highlight some of= the challenges.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Of course, to be fair, China is not the only government e= ntity that might have a vested interest. Let's take a fictional example= of US a real estate investor with heavy ties to the eastern european block= who somehow finds himself elected as president needing=C2=A0
>> >> to find leverage on trade negotiations without effectivel= y hurting personal finances. It turns out that blocking certain digital ser= vices from said eastern european block is the perfect tool in the trade neg= otiations.. Advisers point out that those services=C2=A0
>> >> run heavily encrypted on the dark web with perpetual circ= ulation of IP ranges so, ignoring any legal concerns, it would not be pract= ically possible. Eventually someone figures out that these services all usu= ally are at the forefront of technology and currently=C2=A0
>> >> use QUIC v3.2 and no-one else has deployed that version y= et, so it would suffice to ask NSA to tap into the backbone and disrupt spe= cific packets. Of course, this ends up taking down the Bavarian local gover= nment election process in Germany where they are=C2=A0
>> >> the first to use a new digital election system. Not that = the is an issue, since trade negotiations are also running hot in that area= , so that is just an accidental bonus.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Or an endless number of other developments over the next = few decades if the past few years is anything to go by.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) wrote= :=C2=A0
>> >>=C2=A0
>> >> Thanks Mikkel, I do understand that various actors intent= ionally drop - but are you saying these actors would specifically choose to= block a new version of QUIC ... I do not understand that assertion.=C2=A0 =
>> >>=C2=A0
>> >>=C2=A0
>> >> Gorry=C2=A0
>> >>=C2=A0
>> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgens= en <mikkelfj@gma= il.com> wrote:=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> China blocks as a rule.=C2=A0
>> >> Russia is running an experiment to block the rest of the = internet.=C2=A0
>> >> USA blocks net neutrality.=C2=A0
>> >> EU blocks cookies.=C2=A0
>> >> GB blocks itself.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> So blocking is not limited to what an operator considers = best for business.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) = wrote:=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> I understand why people want to come down on the side of = preventing ossification. But, things have changed. There are a lot of more = negative consequences now when people unnecessarily block things. I think o= perators would put a lot of pressure on vendors to=C2=A0
>> >> not do it now and to fix it if they did "by accident= ". Of course, I am only one operator. It would be nice to hear from ot= hers...=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> John=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> -----Original Message-----=C2=A0
>> >> From: QUIC <quic-bounces@ietf.org> On Behalf Of Roberto Peon=C2= =A0
>> >> Sent: Wednesday, April 10, 2019 12:52 PM=C2=A0
>> >> To: G Fairhurst <gorry@erg.abdn.ac.uk>;=C2=A0
>> >> quic@i= etf.org=C2=A0
>> >> Subject: Re: Is "Version Greasing" a new benfit= or a new obstacle?=C2=A0
>> >>=C2=A0
>> >> WARNING: The sender of this email could not be validated = and may not match the person in the "From" field.=C2=A0
>> >>=C2=A0
>> >> CAUTION: This email originated from outside of the organi= zation. Do not click links or open attachments unless you recognize the sen= der and know the content is safe.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> You're kinda between a rock-and-a-hard-place either w= ay:=C2=A0
>> >>=C2=A0
>> >> - We've seen how much fun ossification is in TCP and = HTTP. If the thing is observable, it will be ossified seems to be the lesso= n. A lot of the reason why QUIC was started in the first place was because = of the inability to improve TCP due to this ossification.=C2=A0
>> >> - OTOH, there is the fear of unknown/unobservable which m= ight cause operators to block things, whether predictably or not.=C2=A0 >> >>=C2=A0
>> >> My opinion is that it is better to start with preventing = ossification, and then if that results in too large a percentage of operato= rs blocking things, to re-evaluate.=C2=A0
>> >>=C2=A0
>> >> My guesses:=C2=A0
>> >> IP+port tuples and traffic patterns are still observable = (for better and worse), which implies operators will still have significant= tools for managing traffic. I believe that these are acted on/matched (ML = or not) regardless of any other data presented. In=C2=A0
>> >> other words, I have a doubt that stating the version in a= n observable way will prevent the use of such tools.=C2=A0
>> >>=C2=A0
>> >> Most problems I've seen associated with implementatio= ns rather than protocol versions (though when the latter happens it is pret= ty severe).. If you believe this assertion, then acting on protocol version= is less interesting than attempting to act based on implementation=C2=A0 <= br> >> >> fingerprints.=C2=A0
>> >> -=3DR=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst&= quot; <quic-b= ounces@ietf.org on behalf of=C2=A0
>> >> gorry@erg.abdn.ac.uk> wrote:=C2=A0
>> >>=C2=A0
>> >> Obscuring the version of a protocol seems like a major de= sign design=C2=A0
>> >> decision for wider use cases. So, I'm trying to under= stand the=C2=A0
>> >> motivation for version greasing.=C2=A0
>> >>=C2=A0
>> >> (1) I know there were instances where some early versions= of QUIC were=C2=A0
>> >> blocked due to an uninitentional matching of the header. = Is there=C2=A0
>> >> evidence of intentional attempts to block updates to prot= ocols?=C2=A0
>> >>=C2=A0
>> >> (2) Thinking about operating a network that cares about u= ser support and=C2=A0
>> >> protection from unwanted traffic, I would expect that the= re would be=C2=A0
>> >> cases where traffic pattern anomolies are found and the a= ppropriate=C2=A0
>> >> thing would be to try to determine if a new protocol had = been deployed=C2=A0
>> >> and monitor it, if not, then the next most obvious thing = could be to=C2=A0
>> >> block all unexpected traffic, that seems like a decision = to hide the=C2=A0
>> >> version could increase ossification for new versions in t= hese cases..=C2=A0
>> >>=C2=A0
>> >> (3) Similarly, if a threat is known to impact only a spec= ific (older)=C2=A0
>> >> version, it would seem to motivate a drop of that traffic= that seeks to=C2=A0
>> >> use that version, while still permitting other traffic. F= orcing version=C2=A0
>> >> detection to use pattern matching/ML will lead to less pr= edictable=C2=A0
>> >> outcomes, or blocking based on address, etc.=C2=A0
>> >>=C2=A0
>> >> (4) This obfusticates the most basic piece of reporting i= nformation used=C2=A0
>> >> for support. It hides the extent of deployment of the cur= rent protocol=C2=A0
>> >> version and prevlance of old implementations.=C2=A0
>> >>=C2=A0
>> >> (5) On the support, if a problem only emerges when a part= icular version=C2=A0
>> >> is used with a particular address, then this helps pinpoi= nt the issues.=C2=A0
>> >> Matching client versions to servers is much more of an is= sue if the user=C2=A0
>> >> community uses a wide range of servers (less so, I expect= for major=C2=A0
>> >> providers: google, facebook, etc, etc), but significant w= hen there is a=C2=A0
>> >> use of a diverse set of external sites and sites with the= ir own load=C2=A0
>> >> balancers, etc and a need to manage interactions with L2 = services.=C2=A0
>> >>=C2=A0
>> >> I am intersted in knowing if this is likely to benefit or= be a new obstacle?=C2=A0
>> >>=C2=A0
>> >> Gorry

--0000000000001840600586935119-- From nobody Mon Apr 15 08:35:13 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096941203E8 for ; Mon, 15 Apr 2019 08:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 lkui2kFOvj02 for ; Mon, 15 Apr 2019 08:35:10 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690106.outbound.protection.outlook.com [40.107.69.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 4911D1203D5 for ; Mon, 15 Apr 2019 08:35:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=dwDNmvkjOgphzYeYa//D+y2ODPyve5KdEkVFcK0FCeCcGvNkANOoX4d3gRSC+50kSDGINTXa7H+Ov3ID5892S6gn9lWVSEdSrMiTXyMka1yGNJw5nEY2b4oNdEexHZr6IdpHkisDN1pdb5+hyY/Ubd4RdPrgXjFyCsZQiL1xyHJ0y4XSpFXHI2AZkrk7PDmUpsrjTZsvu7S1cXLhuExilY21ZWUAQGBjAQyJafVDOIPxkhGWGiQAPJJxoEF/PbJFcf86VkyZZtDZDyoPwZTlNaV8U3bs+kGRwfh35TKp0WBI00kLT7AXXZRFFhMcc0DW7BGe8UulFwr7laqCTFcmJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M3cM/+tw6Zf27lwM/ExpHkTibidwe3dU4UwSOB2bVis=; b=hkZpMv8qB2vVXOPPE54yFh+PzXJQPHw96U3J+BSnqveu9kW/+YkHrvwR0oEma8HIF0DVi+zMdSMrNVmX3Qowyh/26Q8WROBajEj3xfTibF1VhGIjzZQaTsIMr0re0HbWh0F60axWKSU6AZ27pYM+RT4rnyS48cXV1eP7qCVER8Y4yU4+u1P5JHexXAeFCQ4TRD+rp87liDCozOc0zhgPbuX72FEZVCnNt8AOaSlovU4bTWAnNVbL5oJqaeHO7KVjbQ9i2ErUtw7EwI1iFeBHzE8ZsS9gcEkuaX+7K/HT/l9mrGOXPR5xFrh6Q249Mn/iPXsHHyeW6QrPqnJaK+9g4Q== ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none 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:X-MS-Exchange-SenderADCheck; bh=M3cM/+tw6Zf27lwM/ExpHkTibidwe3dU4UwSOB2bVis=; b=KzvycUHxv2jDo8zuCTOLKyWy3qmQFs4KgUB/NUBYADNtKY/mL7jQjvIi52Dljn4fvBFlJhuw35JjT3mDtqBZpSZeYGCp1/1gELd4W86VIXs/oMjxEb75jk4PoPVsZuEg1LCIoFqzdSy/jzy2FiMo1cOV8oDk6NIwW5Uq3Sztgv8= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1020.namprd21.prod.outlook.com (52.132.148.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.2; Mon, 15 Apr 2019 15:35:03 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::31bf:cd85:ffed:1e7]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::31bf:cd85:ffed:1e7%8]) with mapi id 15.20.1835.000; Mon, 15 Apr 2019 15:35:03 +0000 From: Praveen Balasubramanian To: "Brian Trammell (IETF)" , G Fairhurst CC: Ian Swett , Roberto Peon , Christian Huitema , Mirja Kuehlewind , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , "Border, John" Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o0AOSUW1ZVWEa1WA8MStgy7KY1nGCAgAACAYCAAAdsgIAADYwAgAAcxQCAAMrxAIAABNWAgAIQK4CAAADVYIAAAPyAgAAEgoCAAACngIAAAFbggAAG6gCAATPmAIADB5sAgABlw/A= Date: Mon, 15 Apr 2019 15:35:03 +0000 Message-ID: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> <5CB1C214.4030501@erg.abdn.ac.uk> 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=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:f:1115:651:1b62:f721] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dccfc8d5-0fbe-4830-c037-08d6c1b7edbf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MW2PR2101MB1020; x-ms-traffictypediagnostic: MW2PR2101MB1020: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(39860400002)(376002)(396003)(189003)(199004)(13464003)(66574012)(14444005)(256004)(71200400001)(229853002)(86612001)(97736004)(102836004)(6436002)(186003)(46003)(71190400001)(86362001)(93886005)(68736007)(6506007)(53546011)(8676002)(81166006)(110136005)(305945005)(81156014)(7696005)(33656002)(7736002)(76176011)(54906003)(105586002)(55016002)(316002)(10090500001)(6116002)(4326008)(8936002)(10290500003)(6246003)(2906002)(99286004)(486006)(446003)(476003)(11346002)(106356001)(5660300002)(22452003)(52536014)(478600001)(9686003)(14454004)(8990500004)(25786009)(53936002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1020; H:MW2PR2101MB1049.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zaW/KJCWcL+YbZKEbA79bUn7tEsqcZKHPHpVnlERGwN3RhuOuXd9AKWrXOAJztZDdkGWG+fde6FllhkWJRX7ZFlyXXT+lHnqkaRj0/aH4MHNpALXTBXI9uwg+pUZ8rQFeLXmPoxEnY0SCR+lEm04w3QJUqcYedl5m2qCZrT+F5YvD/MnlBD84yeROCBNi+fhgsMwaY4ICT7DDjrYFxVsbguUBehsn9GbXntLNpGkA0DEYqJiG0wV/f3c0qVOrpKx/g4MjoMIKCkZUgKLztgmMFpsuywRssVb21WNI4hT79r+/nJIFweqC5MSKi+khmIhK/eCEFnLC5L9jUasoCSHbuPE4Q3hqCB7omenena75LUY5sSQ5sBSzr2l/bywWoaw4b0cINR+VD2C1CpCybwaNR8ela3n9un/bwzA0s1kD/E= 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: dccfc8d5-0fbe-4830-c037-08d6c1b7edbf X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 15:35:03.0647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1020 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 15:35:13 -0000 UmUuICgxKSBJIGRvbuKAmXQgdGhpbmsgYW55IGluc3BlY3Rpb24gZnVuY3Rpb24gd2lsbCBibG9j ayB2ZXJzaW9ucyBvZiBRVUlDIGl0IGRvZXNu4oCZdCB1bmRlcnN0YW5kLCBhbHRob3VnaCBJIHVu ZGVyc3RhbmQgdGhhdCBub3RoaW5nIHByZXZlbnRzIGl0IGZyb20gZG9pbmcgc28gZGVzaXJlZC4g VGhlc2UgdmVyc2lvbnMgc2hvdWxkIGp1c3QgYmUgdHJlYXRlZCBsaWtlIGdlbmVyYWwgVURQIHRy YWZmaWMsIHNvIHRoYXQgd2UgYXJlIG5vIHdvcnNlIG9mZiBmcm9tIHRoZSB3YXkgdGhpbmdzIGFy ZSB0b2RheSBpbiB0aGUgbmV0d29yay4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCcmlhbiBUcmFt bWVsbCAoSUVURikNClNlbnQ6IE1vbmRheSwgQXByaWwgMTUsIDIwMTkgMjoyMCBBTQ0KVG86IEcg RmFpcmh1cnN0IDxnb3JyeUBlcmcuYWJkbi5hYy51az4NCkNjOiBQcmF2ZWVuIEJhbGFzdWJyYW1h bmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNv bT47IFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRl bWFAaHVpdGVtYS5uZXQ+OyBNaXJqYSBLdWVobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQGVyaWNz c29uLmNvbT47IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47 IHF1aWNAaWV0Zi5vcmc7IEJvcmRlciwgSm9obiA8am9obi5ib3JkZXJAaHVnaGVzLmNvbT4NClN1 YmplY3Q6IFJlOiBJcyAiVmVyc2lvbiBHcmVhc2luZyIgYSBuZXcgYmVuZml0IG9yIGEgbmV3IG9i c3RhY2xlPw0KDQpoaSBHb3JyeSwgYWxsLA0KDQo+IE9uIDEzIEFwciAyMDE5LCBhdCAxMzowMywg RyBGYWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPiB3cm90ZToNCj4gDQo+IEJyaW5naW5n IHRoaXMgdGhyZWFkIGJhY2sgLSB0byBtZSBpdCBzZWVtcyB0aGVyZSBoYXMgYmVlbiBsb3RzIG9m IGRpc2N1c3Npb24gYWJvdXQgaG93ICJ2ZXJzaW9uIGdyZWFzaW5nIiBjYW4gYmUgYWRkZWQgaW4g dmFyaW91cyB3YXlzLCBhbmQgdmVyeSBsaXR0bGUgb24gd2hhdCBtYWtlcyB0aGlzIG5lY2Vzc2Fy eSBhbmQgd29ydGggdGhlIGltcGFjdCBvbiB0aGUgbmV0d29yay4NCj4gDQo+IEkgc3RpbGwgZG9u J3QgZG8gbm90IHNlZSB0aGF0IHRoZSBzaWRlIGVmZmVjdHMgYXJlIHdvcnNlIHdoZW4gdGhlIHBy b3RvY29sIHJlcXVpcmVzIHRoZSB2ZXJzaW9uIHRvIGJlIHVub2JmdXN0aWNhdGVkIChhcyBpbiBt b3N0IG90aGVyIElFVEYgdHJhbnNwb3J0IHByb3RvY29scykuDQoNCisxLiBJIGNvbnRpbnVlIHRv IGJlIGNvbmZ1c2VkIGFib3V0IHRoZSBhbW91bnQgb2YgZWZmb3J0IHdlJ3JlIGFwcGFyZW50bHkg d2lsbGluZyB0byBwdXQgaW50byB2ZXJzaW9uIG5lZ290aWF0aW9uIHByb3RlY3Rpb24gb2YgYSBw cm90b2NvbCB0aGF0IGlzICpleHBsaWNpdGx5KiBkZXNpZ25lZCB0byBiZSBibG9ja2FibGUgb3V0 cmlnaHQgKGJ5IHZpcnR1ZSBvZiB0aGUgVENQIGZhbGxiYWNrIHJlcXVpcmVtZW50KS4gSSBoYXZl bid0IHNlZW4gYW55dGhpbmcgaW4gdGhpcyB0aHJlYWQsIG9yIGFueSBvZiB0aGVzZSBkaXNjdXNz aW9ucyBwcmVjZWRpbmcgaXQgb24gdGhpcyBzdWJqZWN0LCB0aGF0IGluZGljYXRlcyB0aGF0IHRo ZSBhY3R1YWwgcmlzayBvZiBoYXJtIHdpdGggcmVzcGVjdCB0byB2ZXJzaW9uIGJsb2NraW5nIGlz IGRpc2Nlcm5pYmx5IHdvcnNlIChvciBldmVuIGRpc2Nlcm5pYmx5IGRpZmZlcmVudCkgdGhhbiB0 aGUgcmlzayBvZiBoYXJtIHdpdGggcmVzcGVjdCB0byBibG9ja2luZyBvZiB0aGUgZW50aXJlIHBy b3RvY29sIHJlZ2FyZGxlc3Mgb2YgdmVyc2lvbi4gDQoNCkkgY2FuIHNlZSB0d28gcmVhc29ucyBh IHZlcnNpb24gbmVnb3RpYXRpb24gcHJvY2VzcyBjb3VsZCBnZXQgYmxvY2tlZCBpbiB0aGUgbmV0 d29yazoNCg0KDQooMSkgQXMgYW4gZXhwbGljaXQgY2hvaWNlIGJ5IGEgdHJhZmZpYyBpbnNwZWN0 aW9uIGZ1bmN0aW9uIHRoYXQgaXQgbXVzdCBoYXZlIGEgc3BlY2lmaWMgdmVyc2lvbiAob3IgdmVy c2lvbnMpIG9mIGEgcHJvdG9jb2wgYmVjYXVzZSBpdCBpbnNwZWN0cyBpbmZvcm1hdGlvbiBvbmx5 IGF2YWlsYWJsZSBpbiB0aGF0IHZlcnNpb24gb2YgdGhlIHdpcmUgaW1hZ2UuDQoNCk5vdGUgdGhh dCBRVUlDIGlzIGRpZmZlcmVudCBmcm9tIGFsbCBvdGhlciBzaXR1YXRpb25zIGZyb20gd2hpY2gg d2UgY291bGQgZGVyaXZlIGV4cGVyaWVuY2UsIHNpbmNlIHRoZXJlIHNpbXBseSBpc24ndCB0aGF0 IG11Y2ggd2lyZSBpbWFnZSBmb3IgYW4gaW5zcGVjdGlvbiBmdW5jdGlvbiB0byBncmFiIG9uIHRv LCBhbmQgSSBjYW4ndCBpbWFnaW5lIGEgZnV0dXJlIGluIHdoaWNoIGEgZnV0dXJlIHZlcnNpb24g d291bGQgb21pdCBpbmZvcm1hdGlvbiBpdCdkIGJlIHdvcnRoIGJsb2NraW5nIHRoZSB2ZXJzaW9u IG92ZXIgKGFzIG9wcG9zZWQgdG8gYWxsIG9mIFFVSUMsIGZvcmNpbmcgVENQKS4gSW5kZWVkLCBu b3RlIHRoYXQgd2UgbWFkZSB0aGUgbGF0ZW5jeSBzcGluIGJpdCBwcm9iYWJpbGlzdGljLCBhcyBv cHBvc2VkIHRvIG5lZ290aWF0ZWQsIGluIHBhcnQgdG8gcmVtb3ZlIGEgcG90ZW50aWFsIGluY2Vu dGl2ZSB0byBvc3NpZnkgdmVyc2lvbiBuZWdvdGlhdGlvbi4NCg0KSXQncyBwb3NzaWJsZSB0aGF0 IGEgZGV2aWNlIG1pZ2h0IHdhbnQgdG8gYmxvY2sgbm9uLVYxIHZlcnNpb25zIGJlY2F1c2UgdGhl IGhhbmRzaGFrZSBwcm90ZWN0aW9uIGtleXMgYXJlIGhhcmRjb2RlZCBpbnRvIHRoZSBkZXZpY2Uu IEknbSBub3Qgc3VyZSBJIHNlZSBob3cgZHluYW1pYyBhbGlhc2luZyBjb3VsZCBiZSByZWxpYWJs eSBtYWRlIHRvIGFkZHJlc3MgdGhpcyBwcm9ibGVtLCB0aG91Z2ggcHVibGlzaGluZyB2MSB3aXRo IE4gYWxpYXNlcyAoaS5lLiBzdGF0aWMgYWxpYXNpbmcpIHdpdGggZGlmZmVyZW50IGtleXMgd291 bGQgYXQgbGVhc3QgZW5zdXJlIHRoYXQgZGV2aWNlcyB3aXRoIG9ubHkgb25lIGtleSBzbG90IGRv bid0IHdvcmsuDQoNCg0KKDIpIEFzIGFuIG92ZXJjb3JyZWN0aW9uIGJ5IGEgdHJhZmZpYyBpbnNw ZWN0aW9uIGZ1bmN0aW9uIHRoYXQgbWlzdGFrZXMgdGhpbmtzIHRoYXQgYSBwYXJ0aWN1bGFyIHNl cXVlbmNlIG9mIHZlcnNpb24gbmVnb3RpYXRpb24gcGFja2V0cyBpcyBhIHByb3RvY29sIGlkZW50 aWZpZXIuDQoNCkFzIEkgc2VlIGl0LCB0aGUgY3VycmVudCB2ZXJzaW9uIG5lZ290aWF0aW9uIHBy b3Bvc2FscyBvbmx5IG1ha2UgdGhpcyB3b3JzZSwgbm90IGJldHRlciwgYnkgY3JlYXRpbmcgYSBz ZW1hbnRpY2FsbHkgaW5kaXN0aW5ndWlzaGFibGUgc2V0IG9mIGFsaWFzZXMgZm9yIHRoZSBzYW1l IG9wZXJhdGlvbi4gVGhpcyBwcm9ibGVtIGNvdWxkIGJlIG5pY2VseSBzaWRlc3RlcHBlZCBieSBw dW50aW5nIHZlcnNpb24gbmVnb3RpYXRpb24gaW50byB0aGUgZnV0dXJlLg0KDQpDaGVlcnMsDQoN CkJyaWFuDQoNCg0KPiBHb3JyeQ0KPiANCj4gDQo+IE9uIDEyLzA0LzIwMTksIDE3OjQxLCBSb2Jl cnRvIFBlb24gd3JvdGU6DQo+PiANCj4+IEnigJltIG5vdCBzdXJlIHRoYXQgSSBhZ3JlZSB0aGVy ZeKAlHRoZXJlIGlzIG5vIG5lZWQgdG8gaGF2ZSBpdCBzdGFuZGFyZGl6ZWQgc28gbG9uZyBhcyB0 aGUgTEIgaXMgaW52b2x2ZWQgaW4gcGlja2luZyBpdC4gRWFjaCBMQiBzeXN0ZW0gY2FuIGNob29z ZSB3aGF0ZXZlciBpdCB3YW50cy4gVGh1cywgZXZlcnkgTEIgKipkZXBsb3ltZW50KiogY291bGQg dXNlIGEgZGlmZmVyZW50IHNjaGVtZSB3aXRoIGRpZmZlcmVudCBncmVhc2UuIEV2ZXJ5IExCIGRl cGxveW1lbnQgY291bGQgY2hhbmdlIHRoZSBzY2hlbWUgaXQgdXNlcyBwc2V1ZG8tcmFuZG9tbHkg b3IgYWNjb3JkaW5nIHRvIHRoZSBsdW5hciBjYWxlbmRhciwgZXRjLg0KPj4gDQo+PiBCZWNhdXNl IHRoZXJlIGlzIGEgZHluYW1pYyAoYW5kIGNvbnRyb2xsaW5nKSBjb21wb25lbnQgKG5hbWVseSB0 aGUgcGFydCBvZiB0aGUgTEIgc3lzdGVtIHdoaWNoIHZlbmRzIGFuZCB0aGVuIGxhdGVyIHJvdXRl cyBDSURzKSwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgYW55dGhpbmcgZWxzZS4NCj4+IA0KPj4gLT1S DQo+PiANCj4+ICpGcm9tOiAqUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29m dC5jb20+DQo+PiAqRGF0ZTogKkZyaWRheSwgQXByaWwgMTIsIDIwMTkgYXQgOToyOCBBTQ0KPj4g KlRvOiAqUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+LCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVp dGVtYUBodWl0ZW1hLm5ldD4sIElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT4NCj4+ICpD YzogKiJHb3JyeSAoZXJnKSIgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPiwgTWlyamEgS3VlaGxld2lu ZCA8bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20+LCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuIDxtaWtrZWxmakBnbWFpbC5jb20+LCAicXVpY0BpZXRmLm9yZyIgPHF1aWNAaWV0Zi5vcmc+ LCAiQm9yZGVyLCBKb2huIiA8am9obi5ib3JkZXJAaHVnaGVzLmNvbT4NCj4+ICpTdWJqZWN0OiAq UkU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2JzdGFjbGU/ DQo+PiANCj4+IFJlLiBFbmNvZGluZyBpbiBDSUQuIFRoZW4gaXQgbmVlZHMgdG8gYmUgc3RhbmRh cmRpemVkIGFuZCBpZiBpdCBpcyBzdGFuZGFyZGl6ZWQgd2hhdOKAmXMgdGhlIHBvaW50IGluIGdy ZWFzaW5nPyBMZXTigJlzIG5vdCBpZ25vcmUgdGhlIHNtYWxsZXIgc2VydmljZXMgd2hvIHVzZSB0 aGUgY2xvdWQgaS5lLiBwZW9wbGUgZGVwbG95aW5nIHNheSBOR0lOWCB3ZWIgc2VydmVycyBpbiBB V1MsIEF6dXJlIG9yIEdDUC4gTm90IGV2ZXJ5IFFVSUMgZGVwbG95bWVudCBpcyBhIGxhcmdlIGZp cnN0IHBhcnR5IHNlcnZpY2Ugd2hpY2ggY29udHJvbHMgYWxsIGFzcGVjdHMgaG93IExCIGFuZCBE RG9TIGFyZSBkb25lLiBJbiBwdWJsaWMgY2xvdWRzIExCIGFuZCBERG9TIHByb3RlY3Rpb24gYXJl IG5ldHdvcmsgZnVuY3Rpb25zIChzZXJ2aWNlcykgYW5kIGFyZSBtaWRkbGVib3hlcyB1bmRlciBh IGNvbXBsZXRlbHkgZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIGRvbWFpbi4NCj4+IA0KPj4gQ2hy aXN0aWFuLCB0aGlzIGlzIGFib3V0IHNvdXJjZSBhZGRyZXNzIHZhbGlkYXRpb24gYnkgdGhlIG1p ZGRsZWJveC4gVGhpcyBpcyBob3cgaXQgd29ya3MgZm9yIFRDUCAodGhpbmsgU1lOIGNvb2tpZXMp IGFuZCB3ZSBuZWVkIHRvIGhhdmUgcGFyaXR5IGZvciBRVUlDLiBXaGVuIHVuZGVyIGF0dGFjaywg c2hvcnQgaGVhZGVyIHBhY2tldHMgd2lsbCBiZSBkcm9wcGVkIGZvciBhZGRyZXNzZXMgdGhhdCBo YXZlIG5vdCBiZWVuIHZhbGlkYXRlZCwgYnV0IHRoaXMgaXMgdGhlIHNhbWUgZm9yIG5vbi1TWU4g cGFja2V0cyBmb3IgVENQLiBJIGRvbuKAmXQgdW5kZXJzdGFuZCBob3cgaW52YXJpYW50cyBjYW4g YmUgdXNlZCBoZXJlLiBJZiB3ZSBkb27igJl0IGhhdmUgcGFyaXR5IGZvciBEb1MgcHJvdGVjdGlv biBpbiBuZXR3b3JrIHRoZW4gUVVJQyB0cmFmZmljIHdpbGwgYmUgcmF0ZSBsaW1pdGVkIHdoaWNo IGlzIGdvaW5nIHRvIGJlIHJlYWxseSBiYWQgZm9yIHBlcmZvcm1hbmNlLiBGV0lXIHRoZXJlIGlz IGFscmVhZHkgRG9TIHRyYWZmaWMgdGhhdCBsb29rcyBsaWtlIFFVSUMuDQo+PiANCj4+ICpGcm9t OiogUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQo+PiAqU2VudDoqIEZyaWRheSwgQXByaWwg MTIsIDIwMTkgOToxNiBBTQ0KPj4gKlRvOiogQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVp dGVtYS5uZXQ+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBQcmF2ZWVuIEJhbGFz dWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCj4+ICpDYzoqIEdvcnJ5IChlcmcpIDxn b3JyeUBlcmcuYWJkbi5hYy51az47IE1pcmphIEt1ZWhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRA ZXJpY3Nzb24uY29tPjsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwu Y29tPjsgcXVpY0BpZXRmLm9yZzsgQm9yZGVyLCBKb2huIDxqb2huLmJvcmRlckBodWdoZXMuY29t Pg0KPj4gKlN1YmplY3Q6KiBSZTogSXMgIlZlcnNpb24gR3JlYXNpbmciIGEgbmV3IGJlbmZpdCBv ciBhIG5ldyBvYnN0YWNsZT8NCj4+IA0KPj4gRm9yIGFueSBsYXJnZSBkZXBsb3ltZW50LCBJIHN1 c3BlY3QgdGhleeKAmWxsIG5lZWQgTEIuDQo+PiANCj4+IEZvciBtb3N0IGtpbmRzIG9mIExCLWlu ZywgSeKAmWQgZXhwZWN0IHRoZSBMQiBzeXN0ZW0gdG8gZWl0aGVyIGRpcmVjdGx5IG9yIGluZGly ZWN0bHkgYmUgaW52b2x2ZWQgaW4gY2hvb3NpbmcvdmVuZGluZyBjb25uZWN0aW9uIElEcy4NCj4+ IA0KPj4gSWYgaXQgaXMgaW52b2x2ZWQgaW4gdmVuZGluZy9jaG9vc2luZyBjb25uZWN0aW9uIElE cywgaXQgY2FuIGVuY29kZSB2ZXJzaW9uIGluZm9ybWF0aW9uIGludG8gdGhlIENJRC4NCj4+IA0K Pj4gLT1SDQo+PiANCj4+ICpGcm9tOiAqQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVt YS5uZXQgPG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0PjxtYWlsdG86aHVpdGVtYUBodWl0ZW1h Lm5ldCA8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+Pj4NCj4+ICpEYXRlOiAqRnJpZGF5LCBB cHJpbCAxMiwgMjAxOSBhdCA5OjEzIEFNDQo+PiAqVG86ICpJYW4gU3dldHQgPGlhbnN3ZXR0PTQw Z29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyA8bWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBk bWFyYy5pZXRmLm9yZz48bWFpbHRvOmlhbnN3ZXR0PTQwZ29vZ2xlLi5jb21AZG1hcmMuaWV0Zi5v cmcgPG1haWx0bzppYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+Pj4sIFByYXZl ZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmcg PG1haWx0bzpwcmF2Yj00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PG1haWx0bzpwcmF2 Yj00MG1pY3Jvc29mdC4uY29tQGRtYXJjLmlldGYub3JnIDxtYWlsdG86cHJhdmI9NDBtaWNyb3Nv ZnQuY29tQGRtYXJjLmlldGYub3JnPj4+DQo+PiAqQ2M6ICoiR29ycnkgKGVyZykiIDxnb3JyeUBl cmcuYWJkbi5hYy51ayA8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPjxtYWlsdG86Z29ycnlA ZXJnLmFiZG4uYWMudWsgPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+PiwgUm9iZXJ0byBQ ZW9uIDxmZW5peEBmYi5jb20gPG1haWx0bzpmZW5peEBmYi5jb20+PG1haWx0bzpmZW5peEBmYi5j b20gPG1haWx0bzpmZW5peEBmYi5jb20+Pj4sIE1pcmphIEt1ZWhsZXdpbmQgPG1pcmphLmt1ZWhs ZXdpbmRAZXJpY3Nzb24uY29tIDxtYWlsdG86bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20+ PG1haWx0bzptaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbSA8bWFpbHRvOm1pcmphLmt1ZWhs ZXdpbmRAZXJpY3Nzb24uY29tPj4+LCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxm akBnbWFpbC5jb20gPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PG1haWx0bzptaWtrZWxmakBn bWFpbC5jb20gPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+Pj4sICJxdWljQGlldGYub3JnIDxt YWlsdG86cXVpY0BpZXRmLm9yZz4gPG1haWx0bzpxdWljQGlldGYub3JnIDxtYWlsdG86cXVpY0Bp ZXRmLm9yZz4+IiA8cXVpY0BpZXRmLm9yZyA8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PG1haWx0bzpx dWljQGlldGYub3JnIDxtYWlsdG86cXVpY0BpZXRmLm9yZz4+PiwgIkJvcmRlciwgSm9obiIgPGpv aG4uYm9yZGVyQGh1Z2hlcy5jb20gPG1haWx0bzpqb2huLmJvcmRlckBodWdoZXMuY29tPjxtYWls dG86am9obi5ib3JkZXJAaHVnaGVzLmNvbSA8bWFpbHRvOmpvaG4uYm9yZGVyQGh1Z2hlcy5jb20+ Pj4NCj4+ICpTdWJqZWN0OiAqUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBiZW5maXQg b3IgYSBuZXcgb2JzdGFjbGU/DQo+PiANCj4+IE9uIDQvMTIvMjAxOSA4OjU3IEFNLCBJYW4gU3dl dHQgd3JvdGU6DQo+PiANCj4+ICAgICpGcm9tOiogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NCj4+ ICAgICouLi4qDQo+PiANCj4+ICAgIFZlcnNpb24gZ3JlYXNpbmcgd2lsbCBjcmVhdGUgcHJvYmxl bXMgZm9yIEREb1MgcHJvdGVjdGlvbi4gVGhlDQo+PiAgICBERG9TIHByb3RlY3Rpb24gbWlkZGxl Ym94IHdpbGwgaGF2ZSB0byB0cmVhdCBhbGwgdHJhZmZpYyB3aXRoDQo+PiAgICB1bmtub3duIHZl cnNpb24gbnVtYmVycyBhcyBwbGFpbiBvbGQgUVVJQyBhbmQgcmF0ZSBsaW1pdCBpdC4gQW55DQo+ PiAgICBzb2x1dGlvbiB0aGF0IHJlcXVpcmVzIHBlciBjb25uZWN0aW9uIHN0YXRlIHRvIHRyYWNr IHZlcnNpb24NCj4+ICAgIG51bWJlcnMgZG9lc27igJl0IHNjYWxlLiBFc3BlY2lhbGx5IGluIHRo ZSBjbG91ZCBzY2VuYXJpbyBjdXN0b21lcnMNCj4+ICAgIGJyaW5nIHRoZWlyIG93biB3ZWIgc2Vy dmVycyBzbyB0aGlzIG1ha2VzIGFueSBvcHQtb3V0IHNvbHV0aW9uIG5vdA0KPj4gICAgZ29vZCBl bm91Z2guIFNvIEkgZG8gdGhpbmsgdGhpcyBpcyBhbiBvYnN0YWNsZSBmb3IgbWFueSBkZXBsb3lt ZW50cy4NCj4+IA0KPj4gRG9uJ3Qgd2UgaGF2ZSBhbiBleGFtcGxlIG9mIG1pZGRsZS1ib3ggb3Nz aWZpY2F0aW9uIGp1c3QgdGhlcmU/DQo+PiANCj4+IFByYXZlZW4ncyBleGFtcGxlIHBvaW50cyB0 byB0aGUgcGVyaWxzIG9mIHRoZSAic2hvcnRlc3QgcGF0aCIgYXBwcm9hY2ggdG8gbWlkZGxlLWJv eCBkZXNpZ24uIFRha2luZyB0aGUgc2hvcnRlc3QgcGF0aCBtZWFucyBmaW5kaW5nIHNvbWV0aGlu ZyB0aGF0IHdvcmtzIG5vdywgYW5kIG9uY2UgeW91IGhhdmUgZm91bmQgaXQgZGVwbG95IGl0IHdp dGhvdXQgd29ycnkgYWJvdXQgY29uc2VxdWVuY2VzIC0tIHdoaWNoIHZlcnkgb2Z0ZW4gaW5jbHVk ZSBvc3NpZmljYXRpb24uIElmIHRoZSBERE9TIHByb3RlY3Rpb24gYm94IGxvb2tzIGZvciAiUVVJ QyB2ZXJzaW9ucyB0aGF0IGl0IGtub3dzIiBhbmQganVzdCByYXRlIGxpbWl0cyB0aGUgb3RoZXIg dHlwZXMgb2YgcGFja2V0cywgdGhlbiB0aGUgYm94IHdpbGwgYnkgZGVzaWduIHByZXZlbnQgZGVw bG95bWVudCBvZiB2ZXJzaW9ucyB0aGF0IGl0IGRvZXMgbm90IGtub3cuDQo+PiANCj4+IEkgYXNz dW1lIHRoYXQgYmlnIG9yZ2FuaXphdGlvbnMgbGlrZSBBenVyZSB3aWxsIHVwZGF0ZSB0aGVpciBw cm90ZWN0aW9ucyBvbmNlIGEgbmV3IHZlcnNpb24gaXMgb3V0LCBidXQgdGhlIGV4cGVyaWVuY2Ug c2hvd3MgdGhhdCBtYW55IG90aGVyIG9yZ2FuaXphdGlvbnMgZG9uJ3QuIEFuZCBldmVuIHdoZW4g dGhleSBkbywgdGhlIGZvY3VzIG9uIHB1Ymxpc2hlZCB2ZXJzaW9ucyB3aWxsIGJsb2NrIGV4cGVy aW1lbnRpbmcgd2l0aCBuZXcgdmVyc2lvbnMsIG5vdCB0byBtZW50aW9uIGludGVyZmVyaW5nIHdp dGggb3RoZXIgZmVhdHVyZXMgbGlrZSBjb25uZWN0aW9uIG1pZ3JhdGlvbi4gSSB0YWtlIFByYXZl ZW4ncyBleGFtcGxlIGFzIGFuIGFyZ3VtZW50IHdoeSB3ZSBzaG91bGQgaW4gZmFjdCBzdGFuZGFy ZGl6ZSB2ZXJzaW9uIGdyZWFzaW5nLCBwcmVjaXNlbHkgdG8gYXZvaWQgdGhpcyAic2hvcnRlc3Qg cGF0aCBtaWRkbGUtYm94IGRlc2lnbiIuDQo+PiANCj4+IEluIHRoZSBjYXNlIG9mIERET1MgcHJv dGVjdGlvbiwgSSB3aWxsIHBvaW50IG91dCB0aGF0IERET1MgcHJvdGVjdGlvbiBhbHNvIG5lZWRz IHRvIHdvcmsgd2l0aCBzaG9ydCBoZWFkZXIgcGFja2V0cywgd2hpY2ggZG8gbm90IGNhcnJ5IGFu eSB2ZXJzaW9uIG51bWJlci4gSW4gb3JkZXIgdG8gYXZvaWQgRERPUyBieSBzaG9ydCBoZWFkZXIg cGFja2V0cywgdGhlIGJveGVzIGhhdmUgdG8gYmUgYWJsZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVu IHBhY2tldHMgdGhhdCBiZWxvbmcgdG8gYXV0aG9yaXplZCBjb25uZWN0aW9ucyBhbmQgcGFja2V0 cyB0aGF0IGRvbid0LiBBbmQgaWYgeW91IGRvIHRoYXQsIHRoZW4geW91IGRvbid0IHJlYWxseSBu ZWVkIHRvIGxvb2sgYXQgdGhlIHZlcnNpb24gbnVtYmVycywgeW91IGNhbiBzaW1wbHkgcmVseSBv biB0aGUgaW52YXJpYW50cy4NCj4+IA0KPj4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0K From nobody Mon Apr 15 08:45:04 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F56C1203B2 for ; Mon, 15 Apr 2019 08:44:51 -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 wfDuhLCAv3AD for ; Mon, 15 Apr 2019 08:44:46 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F26B120426 for ; Mon, 15 Apr 2019 08:44:46 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id v10so14940569iom.8 for ; Mon, 15 Apr 2019 08:44: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=SObGSgTpxjrPlLljsA6W5A3zLngUxyeys1iHA1qS3bg=; b=Ch7pYeAF1h+Z87pSKaGMwD+thoFdMb0pIBS29u6Jh+7A34PDqM/NqJRBMSDiZsM24+ Vamr0cszrpqgfMxxVWdUaF+LDTy3UXyshsLDr4tNLcnBSYUY0g3Nfnvqmq18o7kSgqmS JCMMMwpXIzt9vUqJUr95rjLX0zrPnpoLB1GXy5SWhrp2SZ8j85lmXg5r4TKjpKzWH+ay LVfqE7DwOT8AYkYjJ++uWpmzmldffVklHZxrpERzEIvj38qPuHL24vEORz5BMvxLck4g GfkfExkZbvs21E3q856bvVtQm0EVpBEcR0NL21xT2g+rH20igUKgp1hqej8Zl4Ja1c0M mHHw== 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=SObGSgTpxjrPlLljsA6W5A3zLngUxyeys1iHA1qS3bg=; b=DWV76wLVnjDnfFm8zagokPIRNx4YvBkEaXdO7dq/TlaoMFSuGh1CDa2TN4sft/+As7 alvaKZeQpCNXbUWJQAYl/R+2SYsy5SjXOv084fMpFVlgdz2tNYTqDIorAp2AyXz/11c3 q+WGFUM4L4sIb+CBFJUocz8gO3VDpgmPmyfEsw6yc6ie/x4HLetxCe5WggOOJMxHzv1U qtBMEHvx4QE4oFU5NMGR7M/YJtJTkzU101XcPmlGS5OINknpgmTPT813rJXfW6kn8Rei A1OSJHqUjwYazGbvsplMlmqYe0f2pr8Fo1T3b3tRrXtwc7vUOIu6XgcaO6aZuNJDNy7d sXBg== X-Gm-Message-State: APjAAAWovjF9tJ+4etD1+JaNz1j9PJZAn+QwlV6yPz2qpE2xCqTuWjxd IGeeGYk8OdnUnjnTGpx91EXPnJreemX4tX3U120= X-Google-Smtp-Source: APXvYqw4jcwLiACNlIKos8T6k9cFYchujXLFlzBFKbmh/cl6vfirmTVXtVAVFPv70thLW7fknlKK8AmmC3rZA5nqkL0= X-Received: by 2002:a5d:9914:: with SMTP id x20mr12628414iol.257.1555343085661; Mon, 15 Apr 2019 08:44:45 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 15 Apr 2019 08:44:44 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 15 Apr 2019 08:44:44 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: Ted Hardie , "Brian Trammell (IETF)" Cc: Gorry Fairhurst , "Border, John" , "quic@ietf.org" , Roberto Peon , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="0000000000001ff2a205869388fc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 15:44:56 -0000 --0000000000001ff2a205869388fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, these examples are chosen exactly because they don=E2=80=99t work wel= l with TLS. If you argue that TLS fallback doesn=E2=80=99t always work, it is no g= ood coming up with examples where they do work, especially when it is not contested that there are cases where fallback is valid. Since QUIC is QUIC, any cloaking applies to all application classes. You can=E2=80=99t argue cloaking is not needed because HTTP and DNS does not ne= ed it due to fallback. Besides, it is an unproven assumption that cloaking is not worthwhile for cases where fallback is required. If both peers accept QUIC and the network generally does not block random appearing UDP cloaking could work, although it does not guarantee privacy. Part of the concerns are that when recognised as QUIC, only certain QUIC versions are permitted. That could happen due to broken subsystems where packets go to bucket A or B, where A is QUIC and B is everything else. FWIW I=E2=80=99m not convinced that this version negotiation cloaking is wo= rthwhile or even beneficial, I=E2=80=99m just pointing out that whatever you do, it = has consequences. On the specific example of DNS falling back to TLS. That might not work if QUIC-DNS introduces a higher level of privacy. A fallback would be a privacy leak. Of course, that would then break things on another level, so it would be an opt-in, but if chosen, fallback should be disabled. Mikkel On 15 April 2019 at 17.29.22, Ted Hardie (ted.ietf@gmail.com) wrote: Howdy, On Mon, Apr 15, 2019 at 4:15 AM Brian Trammell (IETF) wrote: > > > > On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > > > > QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see ho= w TCP > fallback will work for the general case. > > > > A lot of games, VR applications, streaming services etc. are going to > build semi-proprietary QUIC versions, or at least use QUIC with customise= d > application protocols where TCP fallback is simply pointless because it > doesn=E2=80=99t support the framing needed and if it were possible, why w= ould adapt > an application layer protocol to work on TCP if you don=E2=80=99t have to= - of > course you have to if it gets blocked - hence try to avoid that. > > So you see the deployment strategy for these applications to be "zero > availability on non-UDP-accessible networks"? That seems bold to me unles= s > you're talking about QUIC being used as a replacement for > "application-provided transport layer over UDP", which is certainly a big > part of the market but not all of it. > > There are classes of applications for which it is not particularly bold, since they don't function well at all with TCP. There are also classes where the fallback would be to a different stack. DNS over QUIC might fall back to DNS over TLS if UDP is blocked, for example. QUIC doesn't need a fallback there because the DNS stack has one. Ted > You could always tunnel UDP over TCP of course, but from a transport laye= r > perspective (and a transport-visible wire image perspective), that's a TC= P > fallback. > > > I don=E2=80=99t have any numbers on transparency, but given the reach o= f voice > call applications, you can probably safely assume that UDP will be > supported through most networks. > > When we looked at this, admittedly a few years ago, we saw UDP blocking o= n > par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of > paths. That's one nine of availability pathwise, which is... not great. > > > The problem again is if only some UDP is allowed through traffic > inspection or at least port numbering. > > > > It can be a good thing that a QUIC version is detectable if the > alternative is that anything unknown gets blocked. That is the big unknow= n. > > As I said in my other message this morning, I don't think version > negotiation greasing is useful at this time because there is no reasonabl= e > model of a wire-visible version difference where an on-path device might > want to let through one greased-version and not another greased-version, > because the wire-image profiles and semantic properties of those two > versions are by definition of greasing identical. > > At this point, given connection-availability as the metric to optimize > for, it seems like reducing features that might be mistaken for > QUIC-distinguishers in the wire image would be useful, and version greasi= ng > seems like one such feature. > > > Will it help to be is opaque as possible, or not? Some of the scenarios > I posted earlier show that no matter what you do, something will get in t= he > way. > > This all comes down to the threat model, and the model of incentives for > on-path devices. > > I personally think the correct design target is to put trivial > QUIC-discriminability into the wire image, since there will be a lot of > pressure to distinguish QUIC from not-QUIC traffic regardless of what we > do, and if we don't put grippy bits in the wire image, the distinguishing > functions will grip on to the slippy bits, with difficult to predict > outcomes. I recognize I am in the minority (of people who speak up) on th= is > issue, though. > > Cheers, > > Brian > > > On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote: > > > >> hi Mikkel, > >> > >> perhaps a bit late to this party, I'm not sure I understand the proces= s > you envision by which the TCP fallback will go away. > >> > >> Once it's in, it'll get used in a high enough proportion of cases that > the availability risk of turning it off, balanced against the fact that i= t > already works (as it's pretty much mandatory for deploying in today's > 95%-UDP-transparent Internet), will go away very slowly indeed. > >> > >> Cheers, > >> > >> Brian > >> > >> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > >> > > >> > In a not so distant future, a fallback to TCP would not be a viable > alternative for a number of services. Think WebRTC. > >> > If QUIC and other encrypted protocols become dominant, just blocking > everything would literally block everything. > >> > Of course, http(s) as we know it, it will continue to live on, but > many mobile apps would not. > >> > > >> > > >> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind ( > mirja.kuehlewind@ericsson.com) wrote: > >> > > >> >> Hi Mikkel, > >> >> > >> >> I guess it is much more likely that any of those actors would just > block QUIC all together (as there is actually a fallback to TCP). > >> >> > >> >> Mirja > >> >> > >> >> > >> >> > >> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e = J=C3=B8rgensen" < > quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: > >> >> > >> >> > >> >> Let=E2=80=99s say China makes a deal with Google to allow their sea= rch > engine (a not entirely unreasonably proposition). > >> >> The Great Firewall of China (GFC) is reconfigured to accept traffic > from a specific IP range for QUIC protocol v1. > >> >> > >> >> > >> >> > >> >> Google later upgrades to v2. GFC is updated. Later, out of > ignorance, some other department within said company decides that its > browsers should all use forced version aliases as a rule. GFC breaks. > (Assuming Googles servers are not located within the demilitarised > >> >> zone and users use Chrome). > >> >> > >> >> > >> >> Alternative 1: Google up front decides to deploy forced version > aliasing. China rejects the deal because they do not want to support rand= om > traffic through GFC. > >> >> > >> >> > >> >> Alternative 2: Google up front decides to deploy forced version > aliasing, and China does not reject the deal, out of ignorance. Later som= e > department in China GFC oversight realises the deal and forces Google to > remove forced version aliasing, or shut down > >> >> its service. > >> >> > >> >> > >> >> Alternative 3: Google up front decides to deploy forced version > aliasing and China says, of course, we trust everything from Googles IP > range. > >> >> > >> >> > >> >> Alternative 4: Google realises that forced version aliasing does no= t > work in the general case, and makes a special case for users within a > certain geographical area. > >> >> > >> >> > >> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might n= ot at all > be how things would work, but it does highlight some of the challenges. > >> >> > >> >> > >> >> Of course, to be fair, China is not the only government entity that > might have a vested interest. Let's take a fictional example of US a real > estate investor with heavy ties to the eastern european block who somehow > finds himself elected as president needing > >> >> to find leverage on trade negotiations without effectively hurting > personal finances. It turns out that blocking certain digital services fr= om > said eastern european block is the perfect tool in the trade negotiations= .. > Advisers point out that those services > >> >> run heavily encrypted on the dark web with perpetual circulation of > IP ranges so, ignoring any legal concerns, it would not be practically > possible. Eventually someone figures out that these services all usually > are at the forefront of technology and currently > >> >> use QUIC v3.2 and no-one else has deployed that version yet, so it > would suffice to ask NSA to tap into the backbone and disrupt specific > packets. Of course, this ends up taking down the Bavarian local governmen= t > election process in Germany where they are > >> >> the first to use a new digital election system. Not that the is an > issue, since trade negotiations are also running hot in that area, so tha= t > is just an accidental bonus. > >> >> > >> >> > >> >> Or an endless number of other developments over the next few decade= s > if the past few years is anything to go by. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) > wrote: > >> >> > >> >> Thanks Mikkel, I do understand that various actors intentionally > drop - but are you saying these actors would specifically choose to block= a > new version of QUIC ... I do not understand that assertion. > >> >> > >> >> > >> >> Gorry > >> >> > >> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> >> > >> >> > >> >> > >> >> China blocks as a rule. > >> >> Russia is running an experiment to block the rest of the internet. > >> >> USA blocks net neutrality. > >> >> EU blocks cookies. > >> >> GB blocks itself. > >> >> > >> >> > >> >> So blocking is not limited to what an operator considers best for > business. > >> >> > >> >> > >> >> > >> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) > wrote: > >> >> > >> >> > >> >> I understand why people want to come down on the side of preventing > ossification. But, things have changed. There are a lot of more negative > consequences now when people unnecessarily block things. I think operator= s > would put a lot of pressure on vendors to > >> >> not do it now and to fix it if they did "by accident". Of course, I > am only one operator. It would be nice to hear from others... > >> >> > >> >> > >> >> > >> >> John > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: QUIC On Behalf Of Roberto Peon > >> >> Sent: Wednesday, April 10, 2019 12:52 PM > >> >> To: G Fairhurst ; > >> >> quic@ietf.org > >> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? > >> >> > >> >> WARNING: The sender of this email could not be validated and may no= t > match the person in the "From" field. > >> >> > >> >> CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender and > know the content is safe. > >> >> > >> >> > >> >> You're kinda between a rock-and-a-hard-place either way: > >> >> > >> >> - We've seen how much fun ossification is in TCP and HTTP. If the > thing is observable, it will be ossified seems to be the lesson. A lot of > the reason why QUIC was started in the first place was because of the > inability to improve TCP due to this ossification. > >> >> - OTOH, there is the fear of unknown/unobservable which might cause > operators to block things, whether predictably or not. > >> >> > >> >> My opinion is that it is better to start with preventing > ossification, and then if that results in too large a percentage of > operators blocking things, to re-evaluate. > >> >> > >> >> My guesses: > >> >> IP+port tuples and traffic patterns are still observable (for bette= r > and worse), which implies operators will still have significant tools for > managing traffic. I believe that these are acted on/matched (ML or not) > regardless of any other data presented. In > >> >> other words, I have a doubt that stating the version in an > observable way will prevent the use of such tools. > >> >> > >> >> Most problems I've seen associated with implementations rather than > protocol versions (though when the latter happens it is pretty severe).. = If > you believe this assertion, then acting on protocol version is less > interesting than attempting to act based on implementation > >> >> fingerprints. > >> >> -=3DR > >> >> > >> >> > >> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" < > quic-bounces@ietf.org on behalf of > >> >> gorry@erg.abdn.ac.uk> wrote: > >> >> > >> >> Obscuring the version of a protocol seems like a major design desig= n > >> >> decision for wider use cases. So, I'm trying to understand the > >> >> motivation for version greasing. > >> >> > >> >> (1) I know there were instances where some early versions of QUIC > were > >> >> blocked due to an uninitentional matching of the header. Is there > >> >> evidence of intentional attempts to block updates to protocols? > >> >> > >> >> (2) Thinking about operating a network that cares about user suppor= t > and > >> >> protection from unwanted traffic, I would expect that there would b= e > >> >> cases where traffic pattern anomolies are found and the appropriate > >> >> thing would be to try to determine if a new protocol had been > deployed > >> >> and monitor it, if not, then the next most obvious thing could be t= o > >> >> block all unexpected traffic, that seems like a decision to hide th= e > >> >> version could increase ossification for new versions in these > cases.. > >> >> > >> >> (3) Similarly, if a threat is known to impact only a specific > (older) > >> >> version, it would seem to motivate a drop of that traffic that seek= s > to > >> >> use that version, while still permitting other traffic. Forcing > version > >> >> detection to use pattern matching/ML will lead to less predictable > >> >> outcomes, or blocking based on address, etc. > >> >> > >> >> (4) This obfusticates the most basic piece of reporting information > used > >> >> for support. It hides the extent of deployment of the current > protocol > >> >> version and prevlance of old implementations. > >> >> > >> >> (5) On the support, if a problem only emerges when a particular > version > >> >> is used with a particular address, then this helps pinpoint the > issues. > >> >> Matching client versions to servers is much more of an issue if the > user > >> >> community uses a wide range of servers (less so, I expect for major > >> >> providers: google, facebook, etc, etc), but significant when there > is a > >> >> use of a diverse set of external sites and sites with their own loa= d > >> >> balancers, etc and a need to manage interactions with L2 services. > >> >> > >> >> I am intersted in knowing if this is likely to benefit or be a new > obstacle? > >> >> > >> >> Gorry > > --0000000000001ff2a205869388fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Sure, these examples= are chosen exactly because they don=E2=80=99t work well with TLS. If you a= rgue that TLS fallback doesn=E2=80=99t always work, it is no good coming up= with examples where they do work, especially when it is not contested that= there are cases where fallback is valid.

Since QUIC is QUIC, any cloaking applies to all appl= ication classes. You can=E2=80=99t argue cloaking is not needed because HTT= P and DNS does not need it due to fallback. Besides, it is an unproven assu= mption that cloaking is not worthwhile for cases where fallback is required= . If both peers accept QUIC and the network generally does not block random= appearing UDP cloaking could work, although it does not guarantee privacy.= Part of the concerns are that when recognised as QUIC, only certain QUIC v= ersions are permitted. That could happen due to broken subsystems where pac= kets go to bucket A or B, where A is QUIC and B is everything else.

FWIW I=E2=80=99m not convinc= ed that this version negotiation cloaking is worthwhile or even beneficial,= I=E2=80=99m just pointing out that whatever you do, it has consequences.

On the specific exampl= e of DNS falling back to TLS. That might not work if QUIC-DNS introduces a = higher level of privacy. A fallback would be a privacy leak. Of course, tha= t would then break things on another level, so it would be an opt-in, but i= f chosen, fallback should be disabled.

Mikkel

On 1= 5 April 2019 at 17.29.22, Ted Hardie (ted.ietf@gmail.com) wrote:

Howdy,

On Mon, Apr 15, 2019 at 4:15 AM Brian Trammell (IETF) <ietf@trammell= .ch> wrote:


> On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= ; wrote:
>
> QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see how TCP fallback will work for the general case.
>
> A lot of games, VR applications, streaming services etc. are going to build semi-proprietary QUIC versions, or at least use QUIC with customised application protocols where TCP fallback is simply pointless because it doesn=E2=80=99t support the framing needed and if it were possible, why would adapt an application layer protocol to work on TCP if you don=E2=80=99t have to - of course you have to if it gets blocked - hence try to avoid that.

So you see the deployment strategy for these applications to be "zero availability on non-UDP-accessible networks"? That seems bo= ld to me unless you're talking about QUIC being used as a replacement for "application-provided transport layer over UDP", which is certainly a big part of the market but not all of it.


There are classes of applications for which it is not particularly bold, since they don't function well at all with TCP.=C2=A0

There are also classes where the fallback would be to a different stack.=C2=A0 DNS over QUIC might fall back to DNS over TLS if UDP is blocked, for example.=C2=A0 QUIC doesn't need a fallback there because the DNS stack has one.

Ted

=C2=A0
You could always tunnel UDP over TCP of course, but from a transport layer perspective (and a transport-visible wire image perspective), that's a TCP fallback.

> I don=E2=80=99t have any numbers on transparency, but given the reach of voice call applications, you can probably safely assume that UDP will be supported through most networks.

When we looked at this, admittedly a few years ago, we saw UDP blocking on par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of paths. That's one nine of availability pathwise, which is... not great.

> The problem again is if only some UDP is allowed through traffic inspection or at least port numbering.
>
> It can be a good thing that a QUIC version is detectable if the alternative is that anything unknown gets blocked. That is the big unknown.

As I said in my other message this morning, I don't think version negotiation greasing is useful at this time because there is no reasonable model of a wire-visible version difference where an on-path device might want to let through one greased-version and not another greased-version, because the wire-image profiles and semantic properties of those two versions are by definition of greasing identical.

At this point, given connection-availability as the metric to optimize for, it seems like reducing features that might be mistaken for QUIC-distinguishers in the wire image would be useful, and version greasing seems like one such feature.

> Will it help to be is opaque as possible, or not? Some of the scenarios I posted earlier show that no matter what you do, something will get in the way.

This all comes down to the threat model, and the model of incentives for on-path devices.

I personally think the correct design target is to put trivial QUIC-discriminability into the wire image, since there will be a lot of pressure to distinguish QUIC from not-QUIC traffic regardless of what we do, and if we don't put grippy bits in the wire image, the distinguishing functions will grip on to the slippy bits, with difficult to predict outcomes. I recognize I am in the minority (of people who speak up) on this issue, though.

Cheers,

Brian

> On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote:
>
>> hi Mikkel,=C2=A0
>>
>> perhaps a bit late to this party, I'm not sure I understand the process you envision by which the TCP fallback will go away.=C2=A0
>>
>> Once it's in, it'll get used in a high enough proportion of cases that the availability risk of turning it off, balanced against the fact that it already works (as it's pretty much mandatory for deploying in today's 95%-UDP-transparent Internet), will go away very slowly indeed.
>>
>> Cheers,
>>
>> Brian
>>
>> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.= com> wrote:
>> >=C2=A0
>> > In a not so distant future, a fallback to TCP would not be a viable alternative for a number of services. Think WebRTC.
>> > If QUIC and other encrypted protocols become dominant, just blocking everything would literally block everything.
>> > Of course, http(s) as we know it, it will continue to live on, but many mobile apps would not.
>> >=C2=A0
>> >=C2=A0
>> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind (mirja.k= uehlewind@ericsson.com) wrote:
>> >=C2=A0
>> >> Hi Mikkel,=C2=A0
>> >>=C2=A0
>> >> I guess it is much more likely that any of those actors would just block QUIC all together (as there is actually a fallback to TCP).=C2=A0
>> >>=C2=A0
>> >> Mirja=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikk= el Fahn=C3=B8e J=C3=B8rgensen" <quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote:= =C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Let=E2=80=99s say China makes a deal with Google to allow their search engine (a not entirely unreasonably proposition).=C2=A0
>> >> The Great Firewall of China (GFC) is reconfigured to accept traffic from a specific IP range for QUIC protocol v1.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Google later upgrades to v2. GFC is updated. Later, out of ignorance, some other department within said company decides that its browsers should all use forced version aliases as a rule. GFC breaks. (Assuming Googles servers are not located within the demilitarised=C2=A0
>> >> zone and users use Chrome).=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 1: Google up front decides to deploy forced version aliasing. China rejects the deal because they do not want to support random traffic through GFC.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 2: Google up front decides to deploy forced version aliasing, and China does not reject the deal, out of ignorance. Later some department in China GFC oversight realises the deal and forces Google to remove forced version aliasing, or shut down=C2=A0
>> >> its service.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 3: Google up front decides to deploy forced version aliasing and China says, of course, we trust everything from Googles IP range.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 4: Google realises that forced version aliasing does not work in the general case, and makes a special case for users within a certain geographical area.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might not at all be how things would work, but it does highlight some of the challenges.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Of course, to be fair, China is not the only government entity that might have a vested interest. Let's take a fictional example of US a real estate investor with heavy ties to the eastern european block who somehow finds himself elected as president needing=C2=A0
>> >> to find leverage on trade negotiations without effectively hurting personal finances. It turns out that blocking certain digital services from said eastern european block is the perfect tool in the trade negotiations.. Advisers point out that those services=C2=A0
>> >> run heavily encrypted on the dark web with perpetual circulation of IP ranges so, ignoring any legal concerns, it would not be practically possible. Eventually someone figures out that these services all usually are at the forefront of technology and currently=C2=A0
>> >> use QUIC v3.2 and no-one else has deployed that version yet, so it would suffice to ask NSA to tap into the backbone and disrupt specific packets. Of course, this ends up taking down the Bavarian local government election process in Germany where they are=C2=A0
>> >> the first to use a new digital election system. Not that the is an issue, since trade negotiations are also running hot in that area, so that is just an accidental bonus.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Or an endless number of other developments over the next few decades if the past few years is anything to go by.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.a= c.uk) wrote:=C2=A0
>> >>=C2=A0
>> >> Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ... I do not understand that assertion.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Gorry=C2=A0
>> >>=C2=A0
>> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgens= en <mikkelfj@gmail.= com> wrote:=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> China blocks as a rule.=C2=A0
>> >> Russia is running an experiment to block the rest of the internet.=C2=A0
>> >> USA blocks net neutrality.=C2=A0
>> >> EU blocks cookies.=C2=A0
>> >> GB blocks itself.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> So blocking is not limited to what an operator considers best for business.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hu= ghes.com) wrote:=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to=C2=A0
>> >> not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others...=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> John=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> -----Original Message-----=C2=A0
>> >> From: QUIC <quic-bounces@ietf.org> On Behalf Of Roberto Peon=C2=A0
>> >> Sent: Wednesday, April 10, 2019 12:52 PM=C2=A0
>> >> To: G Fairhurst <gorry@erg.abdn.ac.uk>;=C2=A0
>> >> quic@i= etf.org=C2=A0
>> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?=C2=A0
>> >>=C2=A0
>> >> WARNING: The sender of this email could not be validated and may not match the person in the "From" field.=C2=A0
>> >>=C2=A0
>> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> You're kinda between a rock-and-a-hard-place either way:=C2=A0
>> >>=C2=A0
>> >> - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification.=C2=A0
>> >> - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not.=C2=A0
>> >>=C2=A0
>> >> My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate.=C2=A0
>> >>=C2=A0
>> >> My guesses:=C2=A0
>> >> IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In=C2=A0
>> >> other words, I have a doubt that stating the version in an observable way will prevent the use of such tools.=C2=A0
>> >>=C2=A0
>> >> Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe).. If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation=C2=A0
>> >> fingerprints.=C2=A0
>> >> -=3DR=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" <quic-bounces@ietf.org on behalf of=C2=A0
>> >> gorry@erg.abdn.ac.uk> wrote:=C2=A0
>> >>=C2=A0
>> >> Obscuring the version of a protocol seems like a major design design=C2=A0
>> >> decision for wider use cases. So, I'm trying to understand the=C2=A0
>> >> motivation for version greasing.=C2=A0
>> >>=C2=A0
>> >> (1) I know there were instances where some early versions of QUIC were=C2=A0
>> >> blocked due to an uninitentional matching of the header. Is there=C2=A0
>> >> evidence of intentional attempts to block updates to protocols?=C2=A0
>> >>=C2=A0
>> >> (2) Thinking about operating a network that cares about user support and=C2=A0
>> >> protection from unwanted traffic, I would expect that there would be=C2=A0
>> >> cases where traffic pattern anomolies are found and the appropriate=C2=A0
>> >> thing would be to try to determine if a new protocol had been deployed=C2=A0
>> >> and monitor it, if not, then the next most obvious thing could be to=C2=A0
>> >> block all unexpected traffic, that seems like a decision to hide the=C2=A0
>> >> version could increase ossification for new versions in these cases..=C2=A0
>> >>=C2=A0
>> >> (3) Similarly, if a threat is known to impact only a specific (older)=C2=A0
>> >> version, it would seem to motivate a drop of that traffic that seeks to=C2=A0
>> >> use that version, while still permitting other traffic. Forcing version=C2=A0
>> >> detection to use pattern matching/ML will lead to less predictable=C2=A0
>> >> outcomes, or blocking based on address, etc.=C2=A0
>> >>=C2=A0
>> >> (4) This obfusticates the most basic piece of reporting information used=C2=A0
>> >> for support. It hides the extent of deployment of the current protocol=C2=A0
>> >> version and prevlance of old implementations.=C2=A0
>> >>=C2=A0
>> >> (5) On the support, if a problem only emerges when a particular version=C2=A0
>> >> is used with a particular address, then this helps pinpoint the issues.=C2=A0
>> >> Matching client versions to servers is much more of an issue if the user=C2=A0
>> >> community uses a wide range of servers (less so, I expect for major=C2=A0
>> >> providers: google, facebook, etc, etc), but significant when there is a=C2=A0
>> >> use of a diverse set of external sites and sites with their own load=C2=A0
>> >> balancers, etc and a need to manage interactions with L2 services.=C2=A0
>> >>=C2=A0
>> >> I am intersted in knowing if this is likely to benefit or be a new obstacle?=C2=A0
>> >>=C2=A0
>> >> Gorry

--0000000000001ff2a205869388fc-- From nobody Mon Apr 15 08:57:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8752120397 for ; Mon, 15 Apr 2019 08:56:59 -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 mZf-2RdnHxC4 for ; Mon, 15 Apr 2019 08:56:55 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB1012038F for ; Mon, 15 Apr 2019 08:56:55 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id s3so13095322itk.1 for ; Mon, 15 Apr 2019 08:56: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=VVE0gNFNgnshDya0Qjn21v9t585hsWLh3d2ksD2fhEU=; b=LctBFa1eIcTPIK2MQsAjYEmUh/XVgc7/Z/Oxfg+4DbzzIxGQXYPxfQsivQCYQ+Yw3O GURX5JKl7z8n6T9kzWSDGdbjp3hQ85H15RIaXjIq0IGX3dk1JEPCROeR2n3WAlnuEl32 NemMZaQ+fK9UHbKAGdYiC53nVlmfWPUgCjSCwqA/cGsto5tkkr33DUDhUiKzabMHBCoc +eQbIkIN6e9FUjDQlHljTMpTh0e+ChXtuNya/vJW3DhI8D9nPHvQSf/jwGFGGc58vKyT TqKCv4dNHSjR9hNEQz6tdsnnRWtdr89iXPbOy1J8l/uAWrsgBuWfbmdRabP4ufAKvmi/ fX7A== 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=VVE0gNFNgnshDya0Qjn21v9t585hsWLh3d2ksD2fhEU=; b=ndNfnySqtWghKmpLV7PBV1OSCq2IcswsSxFAinYvgaysWkfm7PJwtmgeXWL3tG4dOa p3InuIL/JmmtJp97nyo+TZw6JzDg8uHz7oydUlGYAjWGZM7VWo7bFFdwJwId7nuYHHRx MW0g8UjI33GGNi2WkYzZf8d0m46NqpHVKlvIhwCFk2BTygQsEZ0tXu/QxQbzfe5WT0Fi +W7Z+n6fHIOX2jXf+6QHYINfq7/NIxAYG6OklIO681YBs4BXktNoGb/w7MRYWSqAUPRo EwOTPW/rItyIAihBWiDmThj32eqzktZAMMlRTAeqyfCjHFk+8bKh7lZ3CutR8IK8lOSO ZsVw== X-Gm-Message-State: APjAAAW6Ke8sKBHdXtN41PjFC6vMlzClPVYSNEPIP/xmuEeEkFGB6uo/ L2eBzFeMHenG/Jc5vyQNfJ7kpxO8oJ13GhG+Quc= X-Google-Smtp-Source: APXvYqxZOnoqvs4+qYDhgi9l+LNboL03B7bb5a+bX/YE17TQb+vYoGBKxt7QpG8ha6n0/jX9Kg4RsVkIkQ9GpgOKkHk= X-Received: by 2002:a24:4d:: with SMTP id 74mr26918597ita.6.1555343814853; Mon, 15 Apr 2019 08:56:54 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 15 Apr 2019 08:56:54 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 15 Apr 2019 08:56:54 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: Ted Hardie , "Brian Trammell (IETF)" Cc: Gorry Fairhurst , "quic@ietf.org" , "Border, John" , Roberto Peon , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="000000000000968ce4058693b38b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 15:57:00 -0000 --000000000000968ce4058693b38b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable s/TLS/TCP/ first line 19 at 17.44.44, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrot= e: Sure, these examples are chosen exactly because they don=E2=80=99t work wel= l with TLS. If you argue that TLS fallback doesn=E2=80=99t always work, it is no g= ood coming up with examples where they do work, especially when it is not contested that there are cases where fallback is valid. Since QUIC is QUIC, any cloaking applies to all application classes. You can=E2=80=99t argue cloaking is not needed because HTTP and DNS does not ne= ed it due to fallback. Besides, it is an unproven assumption that cloaking is not worthwhile for cases where fallback is required. If both peers accept QUIC and the network generally does not block random appearing UDP cloaking could work, although it does not guarantee privacy. Part of the concerns are that when recognised as QUIC, only certain QUIC versions are permitted. That could happen due to broken subsystems where packets go to bucket A or B, where A is QUIC and B is everything else. FWIW I=E2=80=99m not convinced that this version negotiation cloaking is wo= rthwhile or even beneficial, I=E2=80=99m just pointing out that whatever you do, it = has consequences. On the specific example of DNS falling back to TLS. That might not work if QUIC-DNS introduces a higher level of privacy. A fallback would be a privacy leak. Of course, that would then break things on another level, so it would be an opt-in, but if chosen, fallback should be disabled. Mikkel On 15 April 2019 at 17.29.22, Ted Hardie (ted.ietf@gmail.com) wrote: Howdy, On Mon, Apr 15, 2019 at 4:15 AM Brian Trammell (IETF) wrote: > > > > On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > > > > QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see ho= w TCP > fallback will work for the general case. > > > > A lot of games, VR applications, streaming services etc. are going to > build semi-proprietary QUIC versions, or at least use QUIC with customise= d > application protocols where TCP fallback is simply pointless because it > doesn=E2=80=99t support the framing needed and if it were possible, why w= ould adapt > an application layer protocol to work on TCP if you don=E2=80=99t have to= - of > course you have to if it gets blocked - hence try to avoid that. > > So you see the deployment strategy for these applications to be "zero > availability on non-UDP-accessible networks"? That seems bold to me unles= s > you're talking about QUIC being used as a replacement for > "application-provided transport layer over UDP", which is certainly a big > part of the market but not all of it. > > There are classes of applications for which it is not particularly bold, since they don't function well at all with TCP. There are also classes where the fallback would be to a different stack. DNS over QUIC might fall back to DNS over TLS if UDP is blocked, for example. QUIC doesn't need a fallback there because the DNS stack has one. Ted > You could always tunnel UDP over TCP of course, but from a transport laye= r > perspective (and a transport-visible wire image perspective), that's a TC= P > fallback. > > > I don=E2=80=99t have any numbers on transparency, but given the reach o= f voice > call applications, you can probably safely assume that UDP will be > supported through most networks. > > When we looked at this, admittedly a few years ago, we saw UDP blocking o= n > par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of > paths. That's one nine of availability pathwise, which is... not great. > > > The problem again is if only some UDP is allowed through traffic > inspection or at least port numbering. > > > > It can be a good thing that a QUIC version is detectable if the > alternative is that anything unknown gets blocked. That is the big unknow= n. > > As I said in my other message this morning, I don't think version > negotiation greasing is useful at this time because there is no reasonabl= e > model of a wire-visible version difference where an on-path device might > want to let through one greased-version and not another greased-version, > because the wire-image profiles and semantic properties of those two > versions are by definition of greasing identical. > > At this point, given connection-availability as the metric to optimize > for, it seems like reducing features that might be mistaken for > QUIC-distinguishers in the wire image would be useful, and version greasi= ng > seems like one such feature. > > > Will it help to be is opaque as possible, or not? Some of the scenarios > I posted earlier show that no matter what you do, something will get in t= he > way. > > This all comes down to the threat model, and the model of incentives for > on-path devices. > > I personally think the correct design target is to put trivial > QUIC-discriminability into the wire image, since there will be a lot of > pressure to distinguish QUIC from not-QUIC traffic regardless of what we > do, and if we don't put grippy bits in the wire image, the distinguishing > functions will grip on to the slippy bits, with difficult to predict > outcomes. I recognize I am in the minority (of people who speak up) on th= is > issue, though. > > Cheers, > > Brian > > > On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote: > > > >> hi Mikkel, > >> > >> perhaps a bit late to this party, I'm not sure I understand the proces= s > you envision by which the TCP fallback will go away. > >> > >> Once it's in, it'll get used in a high enough proportion of cases that > the availability risk of turning it off, balanced against the fact that i= t > already works (as it's pretty much mandatory for deploying in today's > 95%-UDP-transparent Internet), will go away very slowly indeed. > >> > >> Cheers, > >> > >> Brian > >> > >> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > >> > > >> > In a not so distant future, a fallback to TCP would not be a viable > alternative for a number of services. Think WebRTC. > >> > If QUIC and other encrypted protocols become dominant, just blocking > everything would literally block everything. > >> > Of course, http(s) as we know it, it will continue to live on, but > many mobile apps would not. > >> > > >> > > >> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind ( > mirja.kuehlewind@ericsson.com) wrote: > >> > > >> >> Hi Mikkel, > >> >> > >> >> I guess it is much more likely that any of those actors would just > block QUIC all together (as there is actually a fallback to TCP). > >> >> > >> >> Mirja > >> >> > >> >> > >> >> > >> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikkel Fahn=C3=B8e = J=C3=B8rgensen" < > quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote: > >> >> > >> >> > >> >> Let=E2=80=99s say China makes a deal with Google to allow their sea= rch > engine (a not entirely unreasonably proposition). > >> >> The Great Firewall of China (GFC) is reconfigured to accept traffic > from a specific IP range for QUIC protocol v1. > >> >> > >> >> > >> >> > >> >> Google later upgrades to v2. GFC is updated. Later, out of > ignorance, some other department within said company decides that its > browsers should all use forced version aliases as a rule. GFC breaks. > (Assuming Googles servers are not located within the demilitarised > >> >> zone and users use Chrome). > >> >> > >> >> > >> >> Alternative 1: Google up front decides to deploy forced version > aliasing. China rejects the deal because they do not want to support rand= om > traffic through GFC. > >> >> > >> >> > >> >> Alternative 2: Google up front decides to deploy forced version > aliasing, and China does not reject the deal, out of ignorance. Later som= e > department in China GFC oversight realises the deal and forces Google to > remove forced version aliasing, or shut down > >> >> its service. > >> >> > >> >> > >> >> Alternative 3: Google up front decides to deploy forced version > aliasing and China says, of course, we trust everything from Googles IP > range. > >> >> > >> >> > >> >> Alternative 4: Google realises that forced version aliasing does no= t > work in the general case, and makes a special case for users within a > certain geographical area. > >> >> > >> >> > >> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might n= ot at all > be how things would work, but it does highlight some of the challenges. > >> >> > >> >> > >> >> Of course, to be fair, China is not the only government entity that > might have a vested interest. Let's take a fictional example of US a real > estate investor with heavy ties to the eastern european block who somehow > finds himself elected as president needing > >> >> to find leverage on trade negotiations without effectively hurting > personal finances. It turns out that blocking certain digital services fr= om > said eastern european block is the perfect tool in the trade negotiations= .. > Advisers point out that those services > >> >> run heavily encrypted on the dark web with perpetual circulation of > IP ranges so, ignoring any legal concerns, it would not be practically > possible. Eventually someone figures out that these services all usually > are at the forefront of technology and currently > >> >> use QUIC v3.2 and no-one else has deployed that version yet, so it > would suffice to ask NSA to tap into the backbone and disrupt specific > packets. Of course, this ends up taking down the Bavarian local governmen= t > election process in Germany where they are > >> >> the first to use a new digital election system. Not that the is an > issue, since trade negotiations are also running hot in that area, so tha= t > is just an accidental bonus. > >> >> > >> >> > >> >> Or an endless number of other developments over the next few decade= s > if the past few years is anything to go by. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.ac.uk) > wrote: > >> >> > >> >> Thanks Mikkel, I do understand that various actors intentionally > drop - but are you saying these actors would specifically choose to block= a > new version of QUIC ... I do not understand that assertion. > >> >> > >> >> > >> >> Gorry > >> >> > >> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> >> > >> >> > >> >> > >> >> China blocks as a rule. > >> >> Russia is running an experiment to block the rest of the internet. > >> >> USA blocks net neutrality. > >> >> EU blocks cookies. > >> >> GB blocks itself. > >> >> > >> >> > >> >> So blocking is not limited to what an operator considers best for > business. > >> >> > >> >> > >> >> > >> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hughes.com) > wrote: > >> >> > >> >> > >> >> I understand why people want to come down on the side of preventing > ossification. But, things have changed. There are a lot of more negative > consequences now when people unnecessarily block things. I think operator= s > would put a lot of pressure on vendors to > >> >> not do it now and to fix it if they did "by accident". Of course, I > am only one operator. It would be nice to hear from others... > >> >> > >> >> > >> >> > >> >> John > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: QUIC On Behalf Of Roberto Peon > >> >> Sent: Wednesday, April 10, 2019 12:52 PM > >> >> To: G Fairhurst ; > >> >> quic@ietf.org > >> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? > >> >> > >> >> WARNING: The sender of this email could not be validated and may no= t > match the person in the "From" field. > >> >> > >> >> CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender and > know the content is safe. > >> >> > >> >> > >> >> You're kinda between a rock-and-a-hard-place either way: > >> >> > >> >> - We've seen how much fun ossification is in TCP and HTTP. If the > thing is observable, it will be ossified seems to be the lesson. A lot of > the reason why QUIC was started in the first place was because of the > inability to improve TCP due to this ossification. > >> >> - OTOH, there is the fear of unknown/unobservable which might cause > operators to block things, whether predictably or not. > >> >> > >> >> My opinion is that it is better to start with preventing > ossification, and then if that results in too large a percentage of > operators blocking things, to re-evaluate. > >> >> > >> >> My guesses: > >> >> IP+port tuples and traffic patterns are still observable (for bette= r > and worse), which implies operators will still have significant tools for > managing traffic. I believe that these are acted on/matched (ML or not) > regardless of any other data presented. In > >> >> other words, I have a doubt that stating the version in an > observable way will prevent the use of such tools. > >> >> > >> >> Most problems I've seen associated with implementations rather than > protocol versions (though when the latter happens it is pretty severe).. = If > you believe this assertion, then acting on protocol version is less > interesting than attempting to act based on implementation > >> >> fingerprints. > >> >> -=3DR > >> >> > >> >> > >> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" < > quic-bounces@ietf.org on behalf of > >> >> gorry@erg.abdn.ac.uk> wrote: > >> >> > >> >> Obscuring the version of a protocol seems like a major design desig= n > >> >> decision for wider use cases. So, I'm trying to understand the > >> >> motivation for version greasing. > >> >> > >> >> (1) I know there were instances where some early versions of QUIC > were > >> >> blocked due to an uninitentional matching of the header. Is there > >> >> evidence of intentional attempts to block updates to protocols? > >> >> > >> >> (2) Thinking about operating a network that cares about user suppor= t > and > >> >> protection from unwanted traffic, I would expect that there would b= e > >> >> cases where traffic pattern anomolies are found and the appropriate > >> >> thing would be to try to determine if a new protocol had been > deployed > >> >> and monitor it, if not, then the next most obvious thing could be t= o > >> >> block all unexpected traffic, that seems like a decision to hide th= e > >> >> version could increase ossification for new versions in these > cases.. > >> >> > >> >> (3) Similarly, if a threat is known to impact only a specific > (older) > >> >> version, it would seem to motivate a drop of that traffic that seek= s > to > >> >> use that version, while still permitting other traffic. Forcing > version > >> >> detection to use pattern matching/ML will lead to less predictable > >> >> outcomes, or blocking based on address, etc. > >> >> > >> >> (4) This obfusticates the most basic piece of reporting information > used > >> >> for support. It hides the extent of deployment of the current > protocol > >> >> version and prevlance of old implementations. > >> >> > >> >> (5) On the support, if a problem only emerges when a particular > version > >> >> is used with a particular address, then this helps pinpoint the > issues. > >> >> Matching client versions to servers is much more of an issue if the > user > >> >> community uses a wide range of servers (less so, I expect for major > >> >> providers: google, facebook, etc, etc), but significant when there > is a > >> >> use of a diverse set of external sites and sites with their own loa= d > >> >> balancers, etc and a need to manage interactions with L2 services. > >> >> > >> >> I am intersted in knowing if this is likely to benefit or be a new > obstacle? > >> >> > >> >> Gorry > > --000000000000968ce4058693b38b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = s/TLS/TCP/ first lin= e

19 at 17.44.44, Mikkel Fahn=C3=B8e J=C3=B8r= gensen (mikkelfj@gmail.com) wrote= :

Sure, these examples are chosen exactly because they don=E2=80=99t work well with TLS. If you argue that TLS fallback doesn=E2=80=99t always work, it is no good coming up with examples where they do work, especially when it is not contested that there are cases where fallback is valid.

Since QUIC is QUIC, any cloaking applies to all application classes. You can=E2=80=99t argue cloaking is not needed because HTTP and DNS does not need it due to fallback. Besides, it is an unproven assumption that cloaking is not worthwhile for cases where fallback is required. If both peers accept QUIC and the network generally does not block random appearing UDP cloaking could work, although it does not guarantee privacy. Part of the concerns are that when recognised as QUIC, only certain QUIC versions are permitted. That could happen due to broken subsystems where packets go to bucket A or B, where A is QUIC and B is everything else.

FWIW I=E2=80=99m not convinced that this version negotiation cloaking is worthwhile or even beneficial, I=E2=80=99m just pointing out that whatever you do, it has consequences.

On the specific example of DNS falling back to TLS. That might not work if QUIC-DNS introduces a higher level of privacy. A fallback would be a privacy leak. Of course, that would then break things on another level, so it would be an opt-in, but if chosen, fallback should be disabled.

Mikkel

On 15 April 2019 at 17.29.22, Ted Hardie (ted.ietf@gmail.com) wrote:

Howdy,

On Mon, Apr 15, 2019 at 4:15 AM Brian Trammell (IETF) <ietf@= trammell.ch> wrote:


> On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= ; wrote:
>
> QUIC is not going to be used only for HTTP/3 and I don=E2=80=99t see how TCP fallback will work for the general case.
>
> A lot of games, VR applications, streaming services etc. are going to build semi-proprietary QUIC versions, or at least use QUIC with customised application protocols where TCP fallback is simply pointless because it doesn=E2=80=99t support the framing needed and if it were possible, why would adapt an application layer protocol to work on TCP if you don=E2=80=99t have to - of course you have to if it gets blocked - hence try to avoid that.

So you see the deployment strategy for these applications to be "zero availability on non-UDP-accessible networks"? That seems bo= ld to me unless you're talking about QUIC being used as a replacement for "application-provided transport layer over UDP", which is certainly a big part of the market but not all of it.


There are classes of applications for which it is not particularly bold, since they don't function well at all with TCP.=C2=A0

There are also classes where the fallback would be to a different stack.=C2=A0 DNS over QUIC might fall back to DNS over TLS if UDP is blocked, for example.=C2=A0 QUIC doesn't need a fallback there because the DNS stack has one.

Ted

=C2=A0
You could always tunnel UDP over TCP of course, but from a transport layer perspective (and a transport-visible wire image perspective), that's a TCP fallback.

> I don=E2=80=99t have any numbers on transparency, but given the reach of voice call applications, you can probably safely assume that UDP will be supported through most networks.

When we looked at this, admittedly a few years ago, we saw UDP blocking on par with the QUIC failure rates reported by Google in 2015 - O(3-6%) of paths. That's one nine of availability pathwise, which is... not great.

> The problem again is if only some UDP is allowed through traffic inspection or at least port numbering.
>
> It can be a good thing that a QUIC version is detectable if the alternative is that anything unknown gets blocked. That is the big unknown.

As I said in my other message this morning, I don't think version negotiation greasing is useful at this time because there is no reasonable model of a wire-visible version difference where an on-path device might want to let through one greased-version and not another greased-version, because the wire-image profiles and semantic properties of those two versions are by definition of greasing identical.

At this point, given connection-availability as the metric to optimize for, it seems like reducing features that might be mistaken for QUIC-distinguishers in the wire image would be useful, and version greasing seems like one such feature.

> Will it help to be is opaque as possible, or not? Some of the scenarios I posted earlier show that no matter what you do, something will get in the way.

This all comes down to the threat model, and the model of incentives for on-path devices.

I personally think the correct design target is to put trivial QUIC-discriminability into the wire image, since there will be a lot of pressure to distinguish QUIC from not-QUIC traffic regardless of what we do, and if we don't put grippy bits in the wire image, the distinguishing functions will grip on to the slippy bits, with difficult to predict outcomes. I recognize I am in the minority (of people who speak up) on this issue, though.

Cheers,

Brian

> On 15 April 2019 at 11.20.25, Brian Trammell (ietf@trammell.ch) wrote:
>
>> hi Mikkel,=C2=A0
>>
>> perhaps a bit late to this party, I'm not sure I understand the process you envision by which the TCP fallback will go away.=C2=A0
>>
>> Once it's in, it'll get used in a high enough proportion of cases that the availability risk of turning it off, balanced against the fact that it already works (as it's pretty much mandatory for deploying in today's 95%-UDP-transparent Internet), will go away very slowly indeed.
>>
>> Cheers,
>>
>> Brian
>>
>> > On 11 Apr 2019, at 10:20, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.= com> wrote:
>> >=C2=A0
>> > In a not so distant future, a fallback to TCP would not be a viable alternative for a number of services. Think WebRTC.
>> > If QUIC and other encrypted protocols become dominant, just blocking everything would literally block everything.
>> > Of course, http(s) as we know it, it will continue to live on, but many mobile apps would not.
>> >=C2=A0
>> >=C2=A0
>> > On 11 April 2019 at 10.03.14, Mirja Kuehlewind (mirja.k= uehlewind@ericsson.com) wrote:
>> >=C2=A0
>> >> Hi Mikkel,=C2=A0
>> >>=C2=A0
>> >> I guess it is much more likely that any of those actors would just block QUIC all together (as there is actually a fallback to TCP).=C2=A0
>> >>=C2=A0
>> >> Mirja=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> =EF=BB=BFOn 10.04.19, 21:57, "QUIC on behalf of Mikk= el Fahn=C3=B8e J=C3=B8rgensen" <quic-bounces@ietf.org on behalf of mikkelfj@gmail.com> wrote:= =C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Let=E2=80=99s say China makes a deal with Google to allow their search engine (a not entirely unreasonably proposition).=C2=A0
>> >> The Great Firewall of China (GFC) is reconfigured to accept traffic from a specific IP range for QUIC protocol v1.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Google later upgrades to v2. GFC is updated. Later, out of ignorance, some other department within said company decides that its browsers should all use forced version aliases as a rule. GFC breaks. (Assuming Googles servers are not located within the demilitarised=C2=A0
>> >> zone and users use Chrome).=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 1: Google up front decides to deploy forced version aliasing. China rejects the deal because they do not want to support random traffic through GFC.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 2: Google up front decides to deploy forced version aliasing, and China does not reject the deal, out of ignorance. Later some department in China GFC oversight realises the deal and forces Google to remove forced version aliasing, or shut down=C2=A0
>> >> its service.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 3: Google up front decides to deploy forced version aliasing and China says, of course, we trust everything from Googles IP range.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Alternative 4: Google realises that forced version aliasing does not work in the general case, and makes a special case for users within a certain geographical area.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Disclaimer: I=E2=80=99m not affiliated with Google and this might not at all be how things would work, but it does highlight some of the challenges.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Of course, to be fair, China is not the only government entity that might have a vested interest. Let's take a fictional example of US a real estate investor with heavy ties to the eastern european block who somehow finds himself elected as president needing=C2=A0
>> >> to find leverage on trade negotiations without effectively hurting personal finances. It turns out that blocking certain digital services from said eastern european block is the perfect tool in the trade negotiations.. Advisers point out that those services=C2=A0
>> >> run heavily encrypted on the dark web with perpetual circulation of IP ranges so, ignoring any legal concerns, it would not be practically possible. Eventually someone figures out that these services all usually are at the forefront of technology and currently=C2=A0
>> >> use QUIC v3.2 and no-one else has deployed that version yet, so it would suffice to ask NSA to tap into the backbone and disrupt specific packets. Of course, this ends up taking down the Bavarian local government election process in Germany where they are=C2=A0
>> >> the first to use a new digital election system. Not that the is an issue, since trade negotiations are also running hot in that area, so that is just an accidental bonus.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Or an endless number of other developments over the next few decades if the past few years is anything to go by.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> On 10 April 2019 at 20.13.59, Gorry (erg) (gorry@erg.abdn.a= c.uk) wrote:=C2=A0
>> >>=C2=A0
>> >> Thanks Mikkel, I do understand that various actors intentionally drop - but are you saying these actors would specifically choose to block a new version of QUIC ... I do not understand that assertion.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> Gorry=C2=A0
>> >>=C2=A0
>> >> On 10 Apr 2019, at 18:25, Mikkel Fahn=C3=B8e J=C3=B8rgens= en <mikkelfj@gmail.= com> wrote:=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> China blocks as a rule.=C2=A0
>> >> Russia is running an experiment to block the rest of the internet.=C2=A0
>> >> USA blocks net neutrality.=C2=A0
>> >> EU blocks cookies.=C2=A0
>> >> GB blocks itself.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> So blocking is not limited to what an operator considers best for business.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> On 10 April 2019 at 18.59.15, Border, John (john.border@hu= ghes.com) wrote:=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> I understand why people want to come down on the side of preventing ossification. But, things have changed. There are a lot of more negative consequences now when people unnecessarily block things. I think operators would put a lot of pressure on vendors to=C2=A0
>> >> not do it now and to fix it if they did "by accident". Of course, I am only one operator. It would be nice to hear from others...=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> John=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> -----Original Message-----=C2=A0
>> >> From: QUIC <quic-bounces@ietf.org> On Behalf Of Roberto Peon=C2=A0
>> >> Sent: Wednesday, April 10, 2019 12:52 PM=C2=A0
>> >> To: G Fairhurst <gorry@erg.abdn.ac.uk>;=C2=A0
>> >> quic@i= etf.org=C2=A0
>> >> Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?=C2=A0
>> >>=C2=A0
>> >> WARNING: The sender of this email could not be validated and may not match the person in the "From" field.=C2=A0
>> >>=C2=A0
>> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> You're kinda between a rock-and-a-hard-place either way:=C2=A0
>> >>=C2=A0
>> >> - We've seen how much fun ossification is in TCP and HTTP. If the thing is observable, it will be ossified seems to be the lesson. A lot of the reason why QUIC was started in the first place was because of the inability to improve TCP due to this ossification.=C2=A0
>> >> - OTOH, there is the fear of unknown/unobservable which might cause operators to block things, whether predictably or not.=C2=A0
>> >>=C2=A0
>> >> My opinion is that it is better to start with preventing ossification, and then if that results in too large a percentage of operators blocking things, to re-evaluate.=C2=A0
>> >>=C2=A0
>> >> My guesses:=C2=A0
>> >> IP+port tuples and traffic patterns are still observable (for better and worse), which implies operators will still have significant tools for managing traffic. I believe that these are acted on/matched (ML or not) regardless of any other data presented. In=C2=A0
>> >> other words, I have a doubt that stating the version in an observable way will prevent the use of such tools.=C2=A0
>> >>=C2=A0
>> >> Most problems I've seen associated with implementations rather than protocol versions (though when the latter happens it is pretty severe).. If you believe this assertion, then acting on protocol version is less interesting than attempting to act based on implementation=C2=A0
>> >> fingerprints.=C2=A0
>> >> -=3DR=C2=A0
>> >>=C2=A0
>> >>=C2=A0
>> >> On 4/10/19, 1:48 AM, "QUIC on behalf of G Fairhurst" <quic-bounces@ietf.org on behalf of=C2=A0
>> >> gorry@erg.abdn.ac.uk> wrote:=C2=A0
>> >>=C2=A0
>> >> Obscuring the version of a protocol seems like a major design design=C2=A0
>> >> decision for wider use cases. So, I'm trying to understand the=C2=A0
>> >> motivation for version greasing.=C2=A0
>> >>=C2=A0
>> >> (1) I know there were instances where some early versions of QUIC were=C2=A0
>> >> blocked due to an uninitentional matching of the header. Is there=C2=A0
>> >> evidence of intentional attempts to block updates to protocols?=C2=A0
>> >>=C2=A0
>> >> (2) Thinking about operating a network that cares about user support and=C2=A0
>> >> protection from unwanted traffic, I would expect that there would be=C2=A0
>> >> cases where traffic pattern anomolies are found and the appropriate=C2=A0
>> >> thing would be to try to determine if a new protocol had been deployed=C2=A0
>> >> and monitor it, if not, then the next most obvious thing could be to=C2=A0
>> >> block all unexpected traffic, that seems like a decision to hide the=C2=A0
>> >> version could increase ossification for new versions in these cases..=C2=A0
>> >>=C2=A0
>> >> (3) Similarly, if a threat is known to impact only a specific (older)=C2=A0
>> >> version, it would seem to motivate a drop of that traffic that seeks to=C2=A0
>> >> use that version, while still permitting other traffic. Forcing version=C2=A0
>> >> detection to use pattern matching/ML will lead to less predictable=C2=A0
>> >> outcomes, or blocking based on address, etc.=C2=A0
>> >>=C2=A0
>> >> (4) This obfusticates the most basic piece of reporting information used=C2=A0
>> >> for support. It hides the extent of deployment of the current protocol=C2=A0
>> >> version and prevlance of old implementations.=C2=A0
>> >>=C2=A0
>> >> (5) On the support, if a problem only emerges when a particular version=C2=A0
>> >> is used with a particular address, then this helps pinpoint the issues.=C2=A0
>> >> Matching client versions to servers is much more of an issue if the user=C2=A0
>> >> community uses a wide range of servers (less so, I expect for major=C2=A0
>> >> providers: google, facebook, etc, etc), but significant when there is a=C2=A0
>> >> use of a diverse set of external sites and sites with their own load=C2=A0
>> >> balancers, etc and a need to manage interactions with L2 services.=C2=A0
>> >>=C2=A0
>> >> I am intersted in knowing if this is likely to benefit or be a new obstacle?=C2=A0
>> >>=C2=A0
>> >> Gorry

--000000000000968ce4058693b38b-- From nobody Mon Apr 15 11:48:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B52812017D for ; Mon, 15 Apr 2019 11:48:00 -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 gEzsGbLRydYB for ; Mon, 15 Apr 2019 11:47:55 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.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 617D1120046 for ; Mon, 15 Apr 2019 11:47:55 -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 orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Apr 2019 11:47:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,354,1549958400"; d="scan'208,217";a="149639879" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by FMSMGA003.fm.intel.com with ESMTP; 15 Apr 2019 11:47:53 -0700 Received: from orsmsx123.amr.corp.intel.com (10.22.240.116) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Apr 2019 11:47:53 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.39]) by ORSMSX123.amr.corp.intel.com ([169.254.1.141]) with mapi id 14.03.0415.000; Mon, 15 Apr 2019 11:47:52 -0700 From: "Deval, Manasi" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Ted Hardie , "Brian Trammell (IETF)" CC: Gorry Fairhurst , "quic@ietf.org" , "Border, John" , Roberto Peon , "Mirja Kuehlewind" Subject: RE: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73pCar/cuMtfrEumudEVMGce4KY2EbmAgAACAICAAAdtgIAADYsAgAAcxQCAAMryAIAABNSAgAZaAACAAAJpgIAAHasAgABG84CAAARsAIAAA2YA//+ycFA= Date: Mon, 15 Apr 2019 18:47:52 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998BA3EF85@ORSMSX111.amr.corp.intel.com> References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998BA3EF85ORSMSX111amrcor_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 18:48:00 -0000 --_000_1F436ED13A22A246A59CA374CBC543998BA3EF85ORSMSX111amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGN1cnJlbnQgY29ubmVjdGlvbiBzZXR1cCBoYXBwZW5zIGZyb20gY2xpZW50IHRvIHNlcnZl ci4gVmVyc2lvbiBuZWdvdGlhdGlvbiBkcmFmdCBzdGF0ZXMgdGhhdDoNCnRoZSBjbGllbnQNCiAg IG1haW50YWlucyBhIGxpc3Qgb2YgUVVJQyB2ZXJzaW9ucyBpdCBzdXBwb3J0cywgb3JkZXJlZCBi eSBwcmVmZXJlbmNlLg0KICAgSXRzIEluaXRpYWwgcGFja2V0IGlzIHNlbnQgdXNpbmcgdGhlIHZl cnNpb24gdGhhdCB0aGUgc2VydmVyIGlzIG1vc3QNCiAgIGxpa2VseSB0byBzdXBwb3J0DQoNClRo ZSBpbml0aWF0b3Igb2YgdGhlIGdyZWFzZWQgdmVyc2lvbiB2YWx1ZSBpcyBjcnVjaWFsIGZvciB0 aGlzIGRlZmluaXRpb24uIElzIHRoaXMgYWdyZWVkIHVwb24gYWxyZWFkeT8gSWYgdGhlIGdyZWFz ZWQgdmVyc2lvbiB2YWx1ZSB3YXMgY2hvc2VuIGJ5IGEgY2xpZW50LCB0aGlzIGNhbiBnZXQgaW5j b25zaXN0ZW50IHZlcnkgcXVpY2tseSwgc28gZ3JlYXNlZCB2YWx1ZXMgbXVzdCB1bml2ZXJzYWxs eSBjb3JyZXNwb25kIHRvIHBhcnRpY3VsYXIgUVVJQyBvcGVyYXRpb25hbCB2ZXJzaW9uLg0KDQpG b3IgdGhlIG1pZGRsZWJveGVzIGRvaW5nIGxvYWRiYWxhbmNpbmcgYW5kIGZpcmV3YWxsLCB0aGV5 IG5lZWQgdG8gaWRlbnRpZnkgYW5kIGNsYXNzaWZ5IGluY29taW5nIHBhY2tldHMgYmFzZWQgb24g dGhlIElQLCBVRFAgYW5kIFFVSUMgaGVhZGVyIGZpZWxkcyBmb3IgZWZmZWN0aXZlIG9wZXJhdGlv bi4gV2UgYXJlIGFscmVhZHkgc2VlaW5nIHRoYXQgdGhlIGxlbmd0aCBvZiBjb25uZWN0aW9uIElk IGNhbm5vdCBiZSBkZWNpcGhlcmVkIGluIHNob3J0IGhlYWRlciBwYWNrZXRzLiBXb3VsZCB0aGUg dmVyc2lvbiBudW1iZXIgbmVnb3RpYXRpb24gb3BlbiB1cCBtb3JlIGlzc3VlcyBsaWtlIHRoaXMu DQoNCk1hbmFzaQ0KDQoNCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KU2VudDogTW9uZGF5 LCBBcHJpbCAxNSwgMjAxOSA4OjU3IEFNDQpUbzogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwu Y29tPjsgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPg0KQ2M6IEdvcnJ5 IEZhaXJodXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs+OyBxdWljQGlldGYub3JnOyBCb3JkZXIs IEpvaG4gPGpvaG4uYm9yZGVyQGh1Z2hlcy5jb20+OyBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNv bT47IE1pcmphIEt1ZWhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPg0KU3Vi amVjdDogUmU6IElzICJWZXJzaW9uIEdyZWFzaW5nIiBhIG5ldyBiZW5maXQgb3IgYSBuZXcgb2Jz dGFjbGU/DQoNCnMvVExTL1RDUC8gZmlyc3QgbGluZQ0KDQoxOSBhdCAxNy40NC40NCwgTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbiAobWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBn bWFpbC5jb20+KSB3cm90ZToNClN1cmUsIHRoZXNlIGV4YW1wbGVzIGFyZSBjaG9zZW4gZXhhY3Rs eSBiZWNhdXNlIHRoZXkgZG9u4oCZdCB3b3JrIHdlbGwgd2l0aCBUTFMuIElmIHlvdSBhcmd1ZSB0 aGF0IFRMUyBmYWxsYmFjayBkb2VzbuKAmXQgYWx3YXlzIHdvcmssIGl0IGlzIG5vIGdvb2QgY29t aW5nIHVwIHdpdGggZXhhbXBsZXMgd2hlcmUgdGhleSBkbyB3b3JrLCBlc3BlY2lhbGx5IHdoZW4g aXQgaXMgbm90IGNvbnRlc3RlZCB0aGF0IHRoZXJlIGFyZSBjYXNlcyB3aGVyZSBmYWxsYmFjayBp cyB2YWxpZC4NCg0KU2luY2UgUVVJQyBpcyBRVUlDLCBhbnkgY2xvYWtpbmcgYXBwbGllcyB0byBh bGwgYXBwbGljYXRpb24gY2xhc3Nlcy4gWW91IGNhbuKAmXQgYXJndWUgY2xvYWtpbmcgaXMgbm90 IG5lZWRlZCBiZWNhdXNlIEhUVFAgYW5kIEROUyBkb2VzIG5vdCBuZWVkIGl0IGR1ZSB0byBmYWxs YmFjay4gQmVzaWRlcywgaXQgaXMgYW4gdW5wcm92ZW4gYXNzdW1wdGlvbiB0aGF0IGNsb2FraW5n IGlzIG5vdCB3b3J0aHdoaWxlIGZvciBjYXNlcyB3aGVyZSBmYWxsYmFjayBpcyByZXF1aXJlZC4g SWYgYm90aCBwZWVycyBhY2NlcHQgUVVJQyBhbmQgdGhlIG5ldHdvcmsgZ2VuZXJhbGx5IGRvZXMg bm90IGJsb2NrIHJhbmRvbSBhcHBlYXJpbmcgVURQIGNsb2FraW5nIGNvdWxkIHdvcmssIGFsdGhv dWdoIGl0IGRvZXMgbm90IGd1YXJhbnRlZSBwcml2YWN5LiBQYXJ0IG9mIHRoZSBjb25jZXJucyBh cmUgdGhhdCB3aGVuIHJlY29nbmlzZWQgYXMgUVVJQywgb25seSBjZXJ0YWluIFFVSUMgdmVyc2lv bnMgYXJlIHBlcm1pdHRlZC4gVGhhdCBjb3VsZCBoYXBwZW4gZHVlIHRvIGJyb2tlbiBzdWJzeXN0 ZW1zIHdoZXJlIHBhY2tldHMgZ28gdG8gYnVja2V0IEEgb3IgQiwgd2hlcmUgQSBpcyBRVUlDIGFu ZCBCIGlzIGV2ZXJ5dGhpbmcgZWxzZS4NCg0KRldJVyBJ4oCZbSBub3QgY29udmluY2VkIHRoYXQg dGhpcyB2ZXJzaW9uIG5lZ290aWF0aW9uIGNsb2FraW5nIGlzIHdvcnRod2hpbGUgb3IgZXZlbiBi ZW5lZmljaWFsLCBJ4oCZbSBqdXN0IHBvaW50aW5nIG91dCB0aGF0IHdoYXRldmVyIHlvdSBkbywg aXQgaGFzIGNvbnNlcXVlbmNlcy4NCg0KT24gdGhlIHNwZWNpZmljIGV4YW1wbGUgb2YgRE5TIGZh bGxpbmcgYmFjayB0byBUTFMuIFRoYXQgbWlnaHQgbm90IHdvcmsgaWYgUVVJQy1ETlMgaW50cm9k dWNlcyBhIGhpZ2hlciBsZXZlbCBvZiBwcml2YWN5LiBBIGZhbGxiYWNrIHdvdWxkIGJlIGEgcHJp dmFjeSBsZWFrLiBPZiBjb3Vyc2UsIHRoYXQgd291bGQgdGhlbiBicmVhayB0aGluZ3Mgb24gYW5v dGhlciBsZXZlbCwgc28gaXQgd291bGQgYmUgYW4gb3B0LWluLCBidXQgaWYgY2hvc2VuLCBmYWxs YmFjayBzaG91bGQgYmUgZGlzYWJsZWQuDQoNCk1pa2tlbA0KDQpPbiAxNSBBcHJpbCAyMDE5IGF0 IDE3LjI5LjIyLCBUZWQgSGFyZGllICh0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRm QGdtYWlsLmNvbT4pIHdyb3RlOg0KSG93ZHksDQoNCk9uIE1vbiwgQXByIDE1LCAyMDE5IGF0IDQ6 MTUgQU0gQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPG1haWx0bzppZXRm QHRyYW1tZWxsLmNoPj4gd3JvdGU6DQoNCg0KPiBPbiAxNSBBcHIgMjAxOSwgYXQgMTE6MjgsIE1p a2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2Vs ZmpAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+IFFVSUMgaXMgbm90IGdvaW5nIHRvIGJlIHVzZWQg b25seSBmb3IgSFRUUC8zIGFuZCBJIGRvbuKAmXQgc2VlIGhvdyBUQ1AgZmFsbGJhY2sgd2lsbCB3 b3JrIGZvciB0aGUgZ2VuZXJhbCBjYXNlLg0KPg0KPiBBIGxvdCBvZiBnYW1lcywgVlIgYXBwbGlj YXRpb25zLCBzdHJlYW1pbmcgc2VydmljZXMgZXRjLiBhcmUgZ29pbmcgdG8gYnVpbGQgc2VtaS1w cm9wcmlldGFyeSBRVUlDIHZlcnNpb25zLCBvciBhdCBsZWFzdCB1c2UgUVVJQyB3aXRoIGN1c3Rv bWlzZWQgYXBwbGljYXRpb24gcHJvdG9jb2xzIHdoZXJlIFRDUCBmYWxsYmFjayBpcyBzaW1wbHkg cG9pbnRsZXNzIGJlY2F1c2UgaXQgZG9lc27igJl0IHN1cHBvcnQgdGhlIGZyYW1pbmcgbmVlZGVk IGFuZCBpZiBpdCB3ZXJlIHBvc3NpYmxlLCB3aHkgd291bGQgYWRhcHQgYW4gYXBwbGljYXRpb24g bGF5ZXIgcHJvdG9jb2wgdG8gd29yayBvbiBUQ1AgaWYgeW91IGRvbuKAmXQgaGF2ZSB0byAtIG9m IGNvdXJzZSB5b3UgaGF2ZSB0byBpZiBpdCBnZXRzIGJsb2NrZWQgLSBoZW5jZSB0cnkgdG8gYXZv aWQgdGhhdC4NCg0KU28geW91IHNlZSB0aGUgZGVwbG95bWVudCBzdHJhdGVneSBmb3IgdGhlc2Ug YXBwbGljYXRpb25zIHRvIGJlICJ6ZXJvIGF2YWlsYWJpbGl0eSBvbiBub24tVURQLWFjY2Vzc2li bGUgbmV0d29ya3MiPyBUaGF0IHNlZW1zIGJvbGQgdG8gbWUgdW5sZXNzIHlvdSdyZSB0YWxraW5n IGFib3V0IFFVSUMgYmVpbmcgdXNlZCBhcyBhIHJlcGxhY2VtZW50IGZvciAiYXBwbGljYXRpb24t cHJvdmlkZWQgdHJhbnNwb3J0IGxheWVyIG92ZXIgVURQIiwgd2hpY2ggaXMgY2VydGFpbmx5IGEg YmlnIHBhcnQgb2YgdGhlIG1hcmtldCBidXQgbm90IGFsbCBvZiBpdC4NCg0KVGhlcmUgYXJlIGNs YXNzZXMgb2YgYXBwbGljYXRpb25zIGZvciB3aGljaCBpdCBpcyBub3QgcGFydGljdWxhcmx5IGJv bGQsIHNpbmNlIHRoZXkgZG9uJ3QgZnVuY3Rpb24gd2VsbCBhdCBhbGwgd2l0aCBUQ1AuDQoNClRo ZXJlIGFyZSBhbHNvIGNsYXNzZXMgd2hlcmUgdGhlIGZhbGxiYWNrIHdvdWxkIGJlIHRvIGEgZGlm ZmVyZW50IHN0YWNrLiAgRE5TIG92ZXIgUVVJQyBtaWdodCBmYWxsIGJhY2sgdG8gRE5TIG92ZXIg VExTIGlmIFVEUCBpcyBibG9ja2VkLCBmb3IgZXhhbXBsZS4gIFFVSUMgZG9lc24ndCBuZWVkIGEg ZmFsbGJhY2sgdGhlcmUgYmVjYXVzZSB0aGUgRE5TIHN0YWNrIGhhcyBvbmUuDQoNClRlZA0KDQoN CllvdSBjb3VsZCBhbHdheXMgdHVubmVsIFVEUCBvdmVyIFRDUCBvZiBjb3Vyc2UsIGJ1dCBmcm9t IGEgdHJhbnNwb3J0IGxheWVyIHBlcnNwZWN0aXZlIChhbmQgYSB0cmFuc3BvcnQtdmlzaWJsZSB3 aXJlIGltYWdlIHBlcnNwZWN0aXZlKSwgdGhhdCdzIGEgVENQIGZhbGxiYWNrLg0KDQo+IEkgZG9u 4oCZdCBoYXZlIGFueSBudW1iZXJzIG9uIHRyYW5zcGFyZW5jeSwgYnV0IGdpdmVuIHRoZSByZWFj aCBvZiB2b2ljZSBjYWxsIGFwcGxpY2F0aW9ucywgeW91IGNhbiBwcm9iYWJseSBzYWZlbHkgYXNz dW1lIHRoYXQgVURQIHdpbGwgYmUgc3VwcG9ydGVkIHRocm91Z2ggbW9zdCBuZXR3b3Jrcy4NCg0K V2hlbiB3ZSBsb29rZWQgYXQgdGhpcywgYWRtaXR0ZWRseSBhIGZldyB5ZWFycyBhZ28sIHdlIHNh dyBVRFAgYmxvY2tpbmcgb24gcGFyIHdpdGggdGhlIFFVSUMgZmFpbHVyZSByYXRlcyByZXBvcnRl ZCBieSBHb29nbGUgaW4gMjAxNSAtIE8oMy02JSkgb2YgcGF0aHMuIFRoYXQncyBvbmUgbmluZSBv ZiBhdmFpbGFiaWxpdHkgcGF0aHdpc2UsIHdoaWNoIGlzLi4uIG5vdCBncmVhdC4NCg0KPiBUaGUg cHJvYmxlbSBhZ2FpbiBpcyBpZiBvbmx5IHNvbWUgVURQIGlzIGFsbG93ZWQgdGhyb3VnaCB0cmFm ZmljIGluc3BlY3Rpb24gb3IgYXQgbGVhc3QgcG9ydCBudW1iZXJpbmcuDQo+DQo+IEl0IGNhbiBi ZSBhIGdvb2QgdGhpbmcgdGhhdCBhIFFVSUMgdmVyc2lvbiBpcyBkZXRlY3RhYmxlIGlmIHRoZSBh bHRlcm5hdGl2ZSBpcyB0aGF0IGFueXRoaW5nIHVua25vd24gZ2V0cyBibG9ja2VkLiBUaGF0IGlz IHRoZSBiaWcgdW5rbm93bi4NCg0KQXMgSSBzYWlkIGluIG15IG90aGVyIG1lc3NhZ2UgdGhpcyBt b3JuaW5nLCBJIGRvbid0IHRoaW5rIHZlcnNpb24gbmVnb3RpYXRpb24gZ3JlYXNpbmcgaXMgdXNl ZnVsIGF0IHRoaXMgdGltZSBiZWNhdXNlIHRoZXJlIGlzIG5vIHJlYXNvbmFibGUgbW9kZWwgb2Yg YSB3aXJlLXZpc2libGUgdmVyc2lvbiBkaWZmZXJlbmNlIHdoZXJlIGFuIG9uLXBhdGggZGV2aWNl IG1pZ2h0IHdhbnQgdG8gbGV0IHRocm91Z2ggb25lIGdyZWFzZWQtdmVyc2lvbiBhbmQgbm90IGFu b3RoZXIgZ3JlYXNlZC12ZXJzaW9uLCBiZWNhdXNlIHRoZSB3aXJlLWltYWdlIHByb2ZpbGVzIGFu ZCBzZW1hbnRpYyBwcm9wZXJ0aWVzIG9mIHRob3NlIHR3byB2ZXJzaW9ucyBhcmUgYnkgZGVmaW5p dGlvbiBvZiBncmVhc2luZyBpZGVudGljYWwuDQoNCkF0IHRoaXMgcG9pbnQsIGdpdmVuIGNvbm5l Y3Rpb24tYXZhaWxhYmlsaXR5IGFzIHRoZSBtZXRyaWMgdG8gb3B0aW1pemUgZm9yLCBpdCBzZWVt cyBsaWtlIHJlZHVjaW5nIGZlYXR1cmVzIHRoYXQgbWlnaHQgYmUgbWlzdGFrZW4gZm9yIFFVSUMt ZGlzdGluZ3Vpc2hlcnMgaW4gdGhlIHdpcmUgaW1hZ2Ugd291bGQgYmUgdXNlZnVsLCBhbmQgdmVy c2lvbiBncmVhc2luZyBzZWVtcyBsaWtlIG9uZSBzdWNoIGZlYXR1cmUuDQoNCj4gV2lsbCBpdCBo ZWxwIHRvIGJlIGlzIG9wYXF1ZSBhcyBwb3NzaWJsZSwgb3Igbm90PyBTb21lIG9mIHRoZSBzY2Vu YXJpb3MgSSBwb3N0ZWQgZWFybGllciBzaG93IHRoYXQgbm8gbWF0dGVyIHdoYXQgeW91IGRvLCBz b21ldGhpbmcgd2lsbCBnZXQgaW4gdGhlIHdheS4NCg0KVGhpcyBhbGwgY29tZXMgZG93biB0byB0 aGUgdGhyZWF0IG1vZGVsLCBhbmQgdGhlIG1vZGVsIG9mIGluY2VudGl2ZXMgZm9yIG9uLXBhdGgg ZGV2aWNlcy4NCg0KSSBwZXJzb25hbGx5IHRoaW5rIHRoZSBjb3JyZWN0IGRlc2lnbiB0YXJnZXQg aXMgdG8gcHV0IHRyaXZpYWwgUVVJQy1kaXNjcmltaW5hYmlsaXR5IGludG8gdGhlIHdpcmUgaW1h Z2UsIHNpbmNlIHRoZXJlIHdpbGwgYmUgYSBsb3Qgb2YgcHJlc3N1cmUgdG8gZGlzdGluZ3Vpc2gg UVVJQyBmcm9tIG5vdC1RVUlDIHRyYWZmaWMgcmVnYXJkbGVzcyBvZiB3aGF0IHdlIGRvLCBhbmQg aWYgd2UgZG9uJ3QgcHV0IGdyaXBweSBiaXRzIGluIHRoZSB3aXJlIGltYWdlLCB0aGUgZGlzdGlu Z3Vpc2hpbmcgZnVuY3Rpb25zIHdpbGwgZ3JpcCBvbiB0byB0aGUgc2xpcHB5IGJpdHMsIHdpdGgg ZGlmZmljdWx0IHRvIHByZWRpY3Qgb3V0Y29tZXMuIEkgcmVjb2duaXplIEkgYW0gaW4gdGhlIG1p bm9yaXR5IChvZiBwZW9wbGUgd2hvIHNwZWFrIHVwKSBvbiB0aGlzIGlzc3VlLCB0aG91Z2guDQoN CkNoZWVycywNCg0KQnJpYW4NCg0KPiBPbiAxNSBBcHJpbCAyMDE5IGF0IDExLjIwLjI1LCBCcmlh biBUcmFtbWVsbCAoaWV0ZkB0cmFtbWVsbC5jaDxtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaD4pIHdy b3RlOg0KPg0KPj4gaGkgTWlra2VsLA0KPj4NCj4+IHBlcmhhcHMgYSBiaXQgbGF0ZSB0byB0aGlz IHBhcnR5LCBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBwcm9jZXNzIHlvdSBlbnZpc2lv biBieSB3aGljaCB0aGUgVENQIGZhbGxiYWNrIHdpbGwgZ28gYXdheS4NCj4+DQo+PiBPbmNlIGl0 J3MgaW4sIGl0J2xsIGdldCB1c2VkIGluIGEgaGlnaCBlbm91Z2ggcHJvcG9ydGlvbiBvZiBjYXNl cyB0aGF0IHRoZSBhdmFpbGFiaWxpdHkgcmlzayBvZiB0dXJuaW5nIGl0IG9mZiwgYmFsYW5jZWQg YWdhaW5zdCB0aGUgZmFjdCB0aGF0IGl0IGFscmVhZHkgd29ya3MgKGFzIGl0J3MgcHJldHR5IG11 Y2ggbWFuZGF0b3J5IGZvciBkZXBsb3lpbmcgaW4gdG9kYXkncyA5NSUtVURQLXRyYW5zcGFyZW50 IEludGVybmV0KSwgd2lsbCBnbyBhd2F5IHZlcnkgc2xvd2x5IGluZGVlZC4NCj4+DQo+PiBDaGVl cnMsDQo+Pg0KPj4gQnJpYW4NCj4+DQo+PiA+IE9uIDExIEFwciAyMDE5LCBhdCAxMDoyMCwgTWlr a2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxm akBnbWFpbC5jb20+PiB3cm90ZToNCj4+ID4NCj4+ID4gSW4gYSBub3Qgc28gZGlzdGFudCBmdXR1 cmUsIGEgZmFsbGJhY2sgdG8gVENQIHdvdWxkIG5vdCBiZSBhIHZpYWJsZSBhbHRlcm5hdGl2ZSBm b3IgYSBudW1iZXIgb2Ygc2VydmljZXMuIFRoaW5rIFdlYlJUQy4NCj4+ID4gSWYgUVVJQyBhbmQg b3RoZXIgZW5jcnlwdGVkIHByb3RvY29scyBiZWNvbWUgZG9taW5hbnQsIGp1c3QgYmxvY2tpbmcg ZXZlcnl0aGluZyB3b3VsZCBsaXRlcmFsbHkgYmxvY2sgZXZlcnl0aGluZy4NCj4+ID4gT2YgY291 cnNlLCBodHRwKHMpIGFzIHdlIGtub3cgaXQsIGl0IHdpbGwgY29udGludWUgdG8gbGl2ZSBvbiwg YnV0IG1hbnkgbW9iaWxlIGFwcHMgd291bGQgbm90Lg0KPj4gPg0KPj4gPg0KPj4gPiBPbiAxMSBB cHJpbCAyMDE5IGF0IDEwLjAzLjE0LCBNaXJqYSBLdWVobGV3aW5kIChtaXJqYS5rdWVobGV3aW5k QGVyaWNzc29uLmNvbTxtYWlsdG86bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20+KSB3cm90 ZToNCj4+ID4NCj4+ID4+IEhpIE1pa2tlbCwNCj4+ID4+DQo+PiA+PiBJIGd1ZXNzIGl0IGlzIG11 Y2ggbW9yZSBsaWtlbHkgdGhhdCBhbnkgb2YgdGhvc2UgYWN0b3JzIHdvdWxkIGp1c3QgYmxvY2sg UVVJQyBhbGwgdG9nZXRoZXIgKGFzIHRoZXJlIGlzIGFjdHVhbGx5IGEgZmFsbGJhY2sgdG8gVENQ KS4NCj4+ID4+DQo+PiA+PiBNaXJqYQ0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4g77u/T24g MTAuMDQuMTksIDIxOjU3LCAiUVVJQyBvbiBiZWhhbGYgb2YgTWlra2VsIEZhaG7DuGUgSsO4cmdl bnNlbiIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgbWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5j b20+PiB3cm90ZToNCj4+ID4+DQo+PiA+Pg0KPj4gPj4gTGV04oCZcyBzYXkgQ2hpbmEgbWFrZXMg YSBkZWFsIHdpdGggR29vZ2xlIHRvIGFsbG93IHRoZWlyIHNlYXJjaCBlbmdpbmUgKGEgbm90IGVu dGlyZWx5IHVucmVhc29uYWJseSBwcm9wb3NpdGlvbikuDQo+PiA+PiBUaGUgR3JlYXQgRmlyZXdh bGwgb2YgQ2hpbmEgKEdGQykgaXMgcmVjb25maWd1cmVkIHRvIGFjY2VwdCB0cmFmZmljIGZyb20g YSBzcGVjaWZpYyBJUCByYW5nZSBmb3IgUVVJQyBwcm90b2NvbCB2MS4NCj4+ID4+DQo+PiA+Pg0K Pj4gPj4NCj4+ID4+IEdvb2dsZSBsYXRlciB1cGdyYWRlcyB0byB2Mi4gR0ZDIGlzIHVwZGF0ZWQu IExhdGVyLCBvdXQgb2YgaWdub3JhbmNlLCBzb21lIG90aGVyIGRlcGFydG1lbnQgd2l0aGluIHNh aWQgY29tcGFueSBkZWNpZGVzIHRoYXQgaXRzIGJyb3dzZXJzIHNob3VsZCBhbGwgdXNlIGZvcmNl ZCB2ZXJzaW9uIGFsaWFzZXMgYXMgYSBydWxlLiBHRkMgYnJlYWtzLiAoQXNzdW1pbmcgR29vZ2xl cyBzZXJ2ZXJzIGFyZSBub3QgbG9jYXRlZCB3aXRoaW4gdGhlIGRlbWlsaXRhcmlzZWQNCj4+ID4+ IHpvbmUgYW5kIHVzZXJzIHVzZSBDaHJvbWUpLg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBBbHRlcm5h dGl2ZSAxOiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0byBkZXBsb3kgZm9yY2VkIHZlcnNpb24g YWxpYXNpbmcuIENoaW5hIHJlamVjdHMgdGhlIGRlYWwgYmVjYXVzZSB0aGV5IGRvIG5vdCB3YW50 IHRvIHN1cHBvcnQgcmFuZG9tIHRyYWZmaWMgdGhyb3VnaCBHRkMuDQo+PiA+Pg0KPj4gPj4NCj4+ ID4+IEFsdGVybmF0aXZlIDI6IEdvb2dsZSB1cCBmcm9udCBkZWNpZGVzIHRvIGRlcGxveSBmb3Jj ZWQgdmVyc2lvbiBhbGlhc2luZywgYW5kIENoaW5hIGRvZXMgbm90IHJlamVjdCB0aGUgZGVhbCwg b3V0IG9mIGlnbm9yYW5jZS4gTGF0ZXIgc29tZSBkZXBhcnRtZW50IGluIENoaW5hIEdGQyBvdmVy c2lnaHQgcmVhbGlzZXMgdGhlIGRlYWwgYW5kIGZvcmNlcyBHb29nbGUgdG8gcmVtb3ZlIGZvcmNl ZCB2ZXJzaW9uIGFsaWFzaW5nLCBvciBzaHV0IGRvd24NCj4+ID4+IGl0cyBzZXJ2aWNlLg0KPj4g Pj4NCj4+ID4+DQo+PiA+PiBBbHRlcm5hdGl2ZSAzOiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0 byBkZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcgYW5kIENoaW5hIHNheXMsIG9mIGNvdXJz ZSwgd2UgdHJ1c3QgZXZlcnl0aGluZyBmcm9tIEdvb2dsZXMgSVAgcmFuZ2UuDQo+PiA+Pg0KPj4g Pj4NCj4+ID4+IEFsdGVybmF0aXZlIDQ6IEdvb2dsZSByZWFsaXNlcyB0aGF0IGZvcmNlZCB2ZXJz aW9uIGFsaWFzaW5nIGRvZXMgbm90IHdvcmsgaW4gdGhlIGdlbmVyYWwgY2FzZSwgYW5kIG1ha2Vz IGEgc3BlY2lhbCBjYXNlIGZvciB1c2VycyB3aXRoaW4gYSBjZXJ0YWluIGdlb2dyYXBoaWNhbCBh cmVhLg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBEaXNjbGFpbWVyOiBJ4oCZbSBub3QgYWZmaWxpYXRl ZCB3aXRoIEdvb2dsZSBhbmQgdGhpcyBtaWdodCBub3QgYXQgYWxsIGJlIGhvdyB0aGluZ3Mgd291 bGQgd29yaywgYnV0IGl0IGRvZXMgaGlnaGxpZ2h0IHNvbWUgb2YgdGhlIGNoYWxsZW5nZXMuDQo+ PiA+Pg0KPj4gPj4NCj4+ID4+IE9mIGNvdXJzZSwgdG8gYmUgZmFpciwgQ2hpbmEgaXMgbm90IHRo ZSBvbmx5IGdvdmVybm1lbnQgZW50aXR5IHRoYXQgbWlnaHQgaGF2ZSBhIHZlc3RlZCBpbnRlcmVz dC4gTGV0J3MgdGFrZSBhIGZpY3Rpb25hbCBleGFtcGxlIG9mIFVTIGEgcmVhbCBlc3RhdGUgaW52 ZXN0b3Igd2l0aCBoZWF2eSB0aWVzIHRvIHRoZSBlYXN0ZXJuIGV1cm9wZWFuIGJsb2NrIHdobyBz b21laG93IGZpbmRzIGhpbXNlbGYgZWxlY3RlZCBhcyBwcmVzaWRlbnQgbmVlZGluZw0KPj4gPj4g dG8gZmluZCBsZXZlcmFnZSBvbiB0cmFkZSBuZWdvdGlhdGlvbnMgd2l0aG91dCBlZmZlY3RpdmVs eSBodXJ0aW5nIHBlcnNvbmFsIGZpbmFuY2VzLiBJdCB0dXJucyBvdXQgdGhhdCBibG9ja2luZyBj ZXJ0YWluIGRpZ2l0YWwgc2VydmljZXMgZnJvbSBzYWlkIGVhc3Rlcm4gZXVyb3BlYW4gYmxvY2sg aXMgdGhlIHBlcmZlY3QgdG9vbCBpbiB0aGUgdHJhZGUgbmVnb3RpYXRpb25zLi4gQWR2aXNlcnMg cG9pbnQgb3V0IHRoYXQgdGhvc2Ugc2VydmljZXMNCj4+ID4+IHJ1biBoZWF2aWx5IGVuY3J5cHRl ZCBvbiB0aGUgZGFyayB3ZWIgd2l0aCBwZXJwZXR1YWwgY2lyY3VsYXRpb24gb2YgSVAgcmFuZ2Vz IHNvLCBpZ25vcmluZyBhbnkgbGVnYWwgY29uY2VybnMsIGl0IHdvdWxkIG5vdCBiZSBwcmFjdGlj YWxseSBwb3NzaWJsZS4gRXZlbnR1YWxseSBzb21lb25lIGZpZ3VyZXMgb3V0IHRoYXQgdGhlc2Ug c2VydmljZXMgYWxsIHVzdWFsbHkgYXJlIGF0IHRoZSBmb3JlZnJvbnQgb2YgdGVjaG5vbG9neSBh bmQgY3VycmVudGx5DQo+PiA+PiB1c2UgUVVJQyB2My4yIGFuZCBuby1vbmUgZWxzZSBoYXMgZGVw bG95ZWQgdGhhdCB2ZXJzaW9uIHlldCwgc28gaXQgd291bGQgc3VmZmljZSB0byBhc2sgTlNBIHRv IHRhcCBpbnRvIHRoZSBiYWNrYm9uZSBhbmQgZGlzcnVwdCBzcGVjaWZpYyBwYWNrZXRzLiBPZiBj b3Vyc2UsIHRoaXMgZW5kcyB1cCB0YWtpbmcgZG93biB0aGUgQmF2YXJpYW4gbG9jYWwgZ292ZXJu bWVudCBlbGVjdGlvbiBwcm9jZXNzIGluIEdlcm1hbnkgd2hlcmUgdGhleSBhcmUNCj4+ID4+IHRo ZSBmaXJzdCB0byB1c2UgYSBuZXcgZGlnaXRhbCBlbGVjdGlvbiBzeXN0ZW0uIE5vdCB0aGF0IHRo ZSBpcyBhbiBpc3N1ZSwgc2luY2UgdHJhZGUgbmVnb3RpYXRpb25zIGFyZSBhbHNvIHJ1bm5pbmcg aG90IGluIHRoYXQgYXJlYSwgc28gdGhhdCBpcyBqdXN0IGFuIGFjY2lkZW50YWwgYm9udXMuDQo+ PiA+Pg0KPj4gPj4NCj4+ID4+IE9yIGFuIGVuZGxlc3MgbnVtYmVyIG9mIG90aGVyIGRldmVsb3Bt ZW50cyBvdmVyIHRoZSBuZXh0IGZldyBkZWNhZGVzIGlmIHRoZSBwYXN0IGZldyB5ZWFycyBpcyBh bnl0aGluZyB0byBnbyBieS4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4g Pj4gT24gMTAgQXByaWwgMjAxOSBhdCAyMC4xMy41OSwgR29ycnkgKGVyZykgKGdvcnJ5QGVyZy5h YmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4pIHdyb3RlOg0KPj4gPj4NCj4+ ID4+IFRoYW5rcyBNaWtrZWwsIEkgZG8gdW5kZXJzdGFuZCB0aGF0IHZhcmlvdXMgYWN0b3JzIGlu dGVudGlvbmFsbHkgZHJvcCAtIGJ1dCBhcmUgeW91IHNheWluZyB0aGVzZSBhY3RvcnMgd291bGQg c3BlY2lmaWNhbGx5IGNob29zZSB0byBibG9jayBhIG5ldyB2ZXJzaW9uIG9mIFFVSUMgLi4uIEkg ZG8gbm90IHVuZGVyc3RhbmQgdGhhdCBhc3NlcnRpb24uDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IEdv cnJ5DQo+PiA+Pg0KPj4gPj4gT24gMTAgQXByIDIwMTksIGF0IDE4OjI1LCBNaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNv bT4+IHdyb3RlOg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gQ2hpbmEgYmxvY2tzIGFzIGEg cnVsZS4NCj4+ID4+IFJ1c3NpYSBpcyBydW5uaW5nIGFuIGV4cGVyaW1lbnQgdG8gYmxvY2sgdGhl IHJlc3Qgb2YgdGhlIGludGVybmV0Lg0KPj4gPj4gVVNBIGJsb2NrcyBuZXQgbmV1dHJhbGl0eS4N Cj4+ID4+IEVVIGJsb2NrcyBjb29raWVzLg0KPj4gPj4gR0IgYmxvY2tzIGl0c2VsZi4NCj4+ID4+ DQo+PiA+Pg0KPj4gPj4gU28gYmxvY2tpbmcgaXMgbm90IGxpbWl0ZWQgdG8gd2hhdCBhbiBvcGVy YXRvciBjb25zaWRlcnMgYmVzdCBmb3IgYnVzaW5lc3MuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+ PiA+PiBPbiAxMCBBcHJpbCAyMDE5IGF0IDE4LjU5LjE1LCBCb3JkZXIsIEpvaG4gKGpvaG4uYm9y ZGVyQGh1Z2hlcy5jb208bWFpbHRvOmpvaG4uYm9yZGVyQGh1Z2hlcy5jb20+KSB3cm90ZToNCj4+ ID4+DQo+PiA+Pg0KPj4gPj4gSSB1bmRlcnN0YW5kIHdoeSBwZW9wbGUgd2FudCB0byBjb21lIGRv d24gb24gdGhlIHNpZGUgb2YgcHJldmVudGluZyBvc3NpZmljYXRpb24uIEJ1dCwgdGhpbmdzIGhh dmUgY2hhbmdlZC4gVGhlcmUgYXJlIGEgbG90IG9mIG1vcmUgbmVnYXRpdmUgY29uc2VxdWVuY2Vz IG5vdyB3aGVuIHBlb3BsZSB1bm5lY2Vzc2FyaWx5IGJsb2NrIHRoaW5ncy4gSSB0aGluayBvcGVy YXRvcnMgd291bGQgcHV0IGEgbG90IG9mIHByZXNzdXJlIG9uIHZlbmRvcnMgdG8NCj4+ID4+IG5v dCBkbyBpdCBub3cgYW5kIHRvIGZpeCBpdCBpZiB0aGV5IGRpZCAiYnkgYWNjaWRlbnQiLiBPZiBj b3Vyc2UsIEkgYW0gb25seSBvbmUgb3BlcmF0b3IuIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGVhciBm cm9tIG90aGVycy4uLg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gSm9obg0KPj4gPj4NCj4+ ID4+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogUVVJQyA8 cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBC ZWhhbGYgT2YgUm9iZXJ0byBQZW9uDQo+PiA+PiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEwLCAy MDE5IDEyOjUyIFBNDQo+PiA+PiBUbzogRyBGYWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVr PG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+Ow0KPj4gPj4gcXVpY0BpZXRmLm9yZzxtYWls dG86cXVpY0BpZXRmLm9yZz4NCj4+ID4+IFN1YmplY3Q6IFJlOiBJcyAiVmVyc2lvbiBHcmVhc2lu ZyIgYSBuZXcgYmVuZml0IG9yIGEgbmV3IG9ic3RhY2xlPw0KPj4gPj4NCj4+ID4+IFdBUk5JTkc6 IFRoZSBzZW5kZXIgb2YgdGhpcyBlbWFpbCBjb3VsZCBub3QgYmUgdmFsaWRhdGVkIGFuZCBtYXkg bm90IG1hdGNoIHRoZSBwZXJzb24gaW4gdGhlICJGcm9tIiBmaWVsZC4NCj4+ID4+DQo+PiA+PiBD QVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6 YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3Ug cmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4+ID4+ DQo+PiA+Pg0KPj4gPj4gWW91J3JlIGtpbmRhIGJldHdlZW4gYSByb2NrLWFuZC1hLWhhcmQtcGxh Y2UgZWl0aGVyIHdheToNCj4+ID4+DQo+PiA+PiAtIFdlJ3ZlIHNlZW4gaG93IG11Y2ggZnVuIG9z c2lmaWNhdGlvbiBpcyBpbiBUQ1AgYW5kIEhUVFAuIElmIHRoZSB0aGluZyBpcyBvYnNlcnZhYmxl LCBpdCB3aWxsIGJlIG9zc2lmaWVkIHNlZW1zIHRvIGJlIHRoZSBsZXNzb24uIEEgbG90IG9mIHRo ZSByZWFzb24gd2h5IFFVSUMgd2FzIHN0YXJ0ZWQgaW4gdGhlIGZpcnN0IHBsYWNlIHdhcyBiZWNh dXNlIG9mIHRoZSBpbmFiaWxpdHkgdG8gaW1wcm92ZSBUQ1AgZHVlIHRvIHRoaXMgb3NzaWZpY2F0 aW9uLg0KPj4gPj4gLSBPVE9ILCB0aGVyZSBpcyB0aGUgZmVhciBvZiB1bmtub3duL3Vub2JzZXJ2 YWJsZSB3aGljaCBtaWdodCBjYXVzZSBvcGVyYXRvcnMgdG8gYmxvY2sgdGhpbmdzLCB3aGV0aGVy IHByZWRpY3RhYmx5IG9yIG5vdC4NCj4+ID4+DQo+PiA+PiBNeSBvcGluaW9uIGlzIHRoYXQgaXQg aXMgYmV0dGVyIHRvIHN0YXJ0IHdpdGggcHJldmVudGluZyBvc3NpZmljYXRpb24sIGFuZCB0aGVu IGlmIHRoYXQgcmVzdWx0cyBpbiB0b28gbGFyZ2UgYSBwZXJjZW50YWdlIG9mIG9wZXJhdG9ycyBi bG9ja2luZyB0aGluZ3MsIHRvIHJlLWV2YWx1YXRlLg0KPj4gPj4NCj4+ID4+IE15IGd1ZXNzZXM6 DQo+PiA+PiBJUCtwb3J0IHR1cGxlcyBhbmQgdHJhZmZpYyBwYXR0ZXJucyBhcmUgc3RpbGwgb2Jz ZXJ2YWJsZSAoZm9yIGJldHRlciBhbmQgd29yc2UpLCB3aGljaCBpbXBsaWVzIG9wZXJhdG9ycyB3 aWxsIHN0aWxsIGhhdmUgc2lnbmlmaWNhbnQgdG9vbHMgZm9yIG1hbmFnaW5nIHRyYWZmaWMuIEkg YmVsaWV2ZSB0aGF0IHRoZXNlIGFyZSBhY3RlZCBvbi9tYXRjaGVkIChNTCBvciBub3QpIHJlZ2Fy ZGxlc3Mgb2YgYW55IG90aGVyIGRhdGEgcHJlc2VudGVkLiBJbg0KPj4gPj4gb3RoZXIgd29yZHMs IEkgaGF2ZSBhIGRvdWJ0IHRoYXQgc3RhdGluZyB0aGUgdmVyc2lvbiBpbiBhbiBvYnNlcnZhYmxl IHdheSB3aWxsIHByZXZlbnQgdGhlIHVzZSBvZiBzdWNoIHRvb2xzLg0KPj4gPj4NCj4+ID4+IE1v c3QgcHJvYmxlbXMgSSd2ZSBzZWVuIGFzc29jaWF0ZWQgd2l0aCBpbXBsZW1lbnRhdGlvbnMgcmF0 aGVyIHRoYW4gcHJvdG9jb2wgdmVyc2lvbnMgKHRob3VnaCB3aGVuIHRoZSBsYXR0ZXIgaGFwcGVu cyBpdCBpcyBwcmV0dHkgc2V2ZXJlKS4uIElmIHlvdSBiZWxpZXZlIHRoaXMgYXNzZXJ0aW9uLCB0 aGVuIGFjdGluZyBvbiBwcm90b2NvbCB2ZXJzaW9uIGlzIGxlc3MgaW50ZXJlc3RpbmcgdGhhbiBh dHRlbXB0aW5nIHRvIGFjdCBiYXNlZCBvbiBpbXBsZW1lbnRhdGlvbg0KPj4gPj4gZmluZ2VycHJp bnRzLg0KPj4gPj4gLT1SDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IE9uIDQvMTAvMTksIDE6NDggQU0s ICJRVUlDIG9uIGJlaGFsZiBvZiBHIEZhaXJodXJzdCIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YNCj4+ID4+IGdvcnJ5QGVy Zy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+IHdyb3RlOg0KPj4gPj4N Cj4+ID4+IE9ic2N1cmluZyB0aGUgdmVyc2lvbiBvZiBhIHByb3RvY29sIHNlZW1zIGxpa2UgYSBt YWpvciBkZXNpZ24gZGVzaWduDQo+PiA+PiBkZWNpc2lvbiBmb3Igd2lkZXIgdXNlIGNhc2VzLiBT bywgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZQ0KPj4gPj4gbW90aXZhdGlvbiBmb3IgdmVy c2lvbiBncmVhc2luZy4NCj4+ID4+DQo+PiA+PiAoMSkgSSBrbm93IHRoZXJlIHdlcmUgaW5zdGFu Y2VzIHdoZXJlIHNvbWUgZWFybHkgdmVyc2lvbnMgb2YgUVVJQyB3ZXJlDQo+PiA+PiBibG9ja2Vk IGR1ZSB0byBhbiB1bmluaXRlbnRpb25hbCBtYXRjaGluZyBvZiB0aGUgaGVhZGVyLiBJcyB0aGVy ZQ0KPj4gPj4gZXZpZGVuY2Ugb2YgaW50ZW50aW9uYWwgYXR0ZW1wdHMgdG8gYmxvY2sgdXBkYXRl cyB0byBwcm90b2NvbHM/DQo+PiA+Pg0KPj4gPj4gKDIpIFRoaW5raW5nIGFib3V0IG9wZXJhdGlu ZyBhIG5ldHdvcmsgdGhhdCBjYXJlcyBhYm91dCB1c2VyIHN1cHBvcnQgYW5kDQo+PiA+PiBwcm90 ZWN0aW9uIGZyb20gdW53YW50ZWQgdHJhZmZpYywgSSB3b3VsZCBleHBlY3QgdGhhdCB0aGVyZSB3 b3VsZCBiZQ0KPj4gPj4gY2FzZXMgd2hlcmUgdHJhZmZpYyBwYXR0ZXJuIGFub21vbGllcyBhcmUg Zm91bmQgYW5kIHRoZSBhcHByb3ByaWF0ZQ0KPj4gPj4gdGhpbmcgd291bGQgYmUgdG8gdHJ5IHRv IGRldGVybWluZSBpZiBhIG5ldyBwcm90b2NvbCBoYWQgYmVlbiBkZXBsb3llZA0KPj4gPj4gYW5k IG1vbml0b3IgaXQsIGlmIG5vdCwgdGhlbiB0aGUgbmV4dCBtb3N0IG9idmlvdXMgdGhpbmcgY291 bGQgYmUgdG8NCj4+ID4+IGJsb2NrIGFsbCB1bmV4cGVjdGVkIHRyYWZmaWMsIHRoYXQgc2VlbXMg bGlrZSBhIGRlY2lzaW9uIHRvIGhpZGUgdGhlDQo+PiA+PiB2ZXJzaW9uIGNvdWxkIGluY3JlYXNl IG9zc2lmaWNhdGlvbiBmb3IgbmV3IHZlcnNpb25zIGluIHRoZXNlIGNhc2VzLi4NCj4+ID4+DQo+ PiA+PiAoMykgU2ltaWxhcmx5LCBpZiBhIHRocmVhdCBpcyBrbm93biB0byBpbXBhY3Qgb25seSBh IHNwZWNpZmljIChvbGRlcikNCj4+ID4+IHZlcnNpb24sIGl0IHdvdWxkIHNlZW0gdG8gbW90aXZh dGUgYSBkcm9wIG9mIHRoYXQgdHJhZmZpYyB0aGF0IHNlZWtzIHRvDQo+PiA+PiB1c2UgdGhhdCB2 ZXJzaW9uLCB3aGlsZSBzdGlsbCBwZXJtaXR0aW5nIG90aGVyIHRyYWZmaWMuIEZvcmNpbmcgdmVy c2lvbg0KPj4gPj4gZGV0ZWN0aW9uIHRvIHVzZSBwYXR0ZXJuIG1hdGNoaW5nL01MIHdpbGwgbGVh ZCB0byBsZXNzIHByZWRpY3RhYmxlDQo+PiA+PiBvdXRjb21lcywgb3IgYmxvY2tpbmcgYmFzZWQg b24gYWRkcmVzcywgZXRjLg0KPj4gPj4NCj4+ID4+ICg0KSBUaGlzIG9iZnVzdGljYXRlcyB0aGUg bW9zdCBiYXNpYyBwaWVjZSBvZiByZXBvcnRpbmcgaW5mb3JtYXRpb24gdXNlZA0KPj4gPj4gZm9y IHN1cHBvcnQuIEl0IGhpZGVzIHRoZSBleHRlbnQgb2YgZGVwbG95bWVudCBvZiB0aGUgY3VycmVu dCBwcm90b2NvbA0KPj4gPj4gdmVyc2lvbiBhbmQgcHJldmxhbmNlIG9mIG9sZCBpbXBsZW1lbnRh dGlvbnMuDQo+PiA+Pg0KPj4gPj4gKDUpIE9uIHRoZSBzdXBwb3J0LCBpZiBhIHByb2JsZW0gb25s eSBlbWVyZ2VzIHdoZW4gYSBwYXJ0aWN1bGFyIHZlcnNpb24NCj4+ID4+IGlzIHVzZWQgd2l0aCBh IHBhcnRpY3VsYXIgYWRkcmVzcywgdGhlbiB0aGlzIGhlbHBzIHBpbnBvaW50IHRoZSBpc3N1ZXMu DQo+PiA+PiBNYXRjaGluZyBjbGllbnQgdmVyc2lvbnMgdG8gc2VydmVycyBpcyBtdWNoIG1vcmUg b2YgYW4gaXNzdWUgaWYgdGhlIHVzZXINCj4+ID4+IGNvbW11bml0eSB1c2VzIGEgd2lkZSByYW5n ZSBvZiBzZXJ2ZXJzIChsZXNzIHNvLCBJIGV4cGVjdCBmb3IgbWFqb3INCj4+ID4+IHByb3ZpZGVy czogZ29vZ2xlLCBmYWNlYm9vaywgZXRjLCBldGMpLCBidXQgc2lnbmlmaWNhbnQgd2hlbiB0aGVy ZSBpcyBhDQo+PiA+PiB1c2Ugb2YgYSBkaXZlcnNlIHNldCBvZiBleHRlcm5hbCBzaXRlcyBhbmQg c2l0ZXMgd2l0aCB0aGVpciBvd24gbG9hZA0KPj4gPj4gYmFsYW5jZXJzLCBldGMgYW5kIGEgbmVl ZCB0byBtYW5hZ2UgaW50ZXJhY3Rpb25zIHdpdGggTDIgc2VydmljZXMuDQo+PiA+Pg0KPj4gPj4g SSBhbSBpbnRlcnN0ZWQgaW4ga25vd2luZyBpZiB0aGlzIGlzIGxpa2VseSB0byBiZW5lZml0IG9y IGJlIGEgbmV3IG9ic3RhY2xlPw0KPj4gPj4NCj4+ID4+IEdvcnJ5DQo= --_000_1F436ED13A22A246A59CA374CBC543998BA3EF85ORSMSX111amrcor_ 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 MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuYWlybWFpbG9u LCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9v bjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgY3VycmVudCBjb25uZWN0aW9uIHNldHVwIGhhcHBl bnMgZnJvbSBjbGllbnQgdG8gc2VydmVyLiBWZXJzaW9uIG5lZ290aWF0aW9uIGRyYWZ0IHN0YXRl cyB0aGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj50aGUgY2xpZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBtYWludGFp bnMgYSBsaXN0IG9mIFFVSUMgdmVyc2lvbnMgaXQgc3VwcG9ydHMsIG9yZGVyZWQgYnkgcHJlZmVy ZW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEl0cyBJbml0aWFsIHBhY2tldCBpcyBzZW50IHVz aW5nIHRoZSB2ZXJzaW9uIHRoYXQgdGhlIHNlcnZlciBpcyBtb3N0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBsaWtlbHkgdG8gc3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+VGhlIGluaXRpYXRvciBvZiB0aGUgZ3JlYXNlZCB2ZXJzaW9uIHZhbHVlIGlzIGNy dWNpYWwgZm9yIHRoaXMgZGVmaW5pdGlvbi4gSXMgdGhpcyBhZ3JlZWQgdXBvbiBhbHJlYWR5PyBJ ZiB0aGUgZ3JlYXNlZCB2ZXJzaW9uIHZhbHVlIHdhcyBjaG9zZW4gYnkgYSBjbGllbnQsIHRoaXMN CiBjYW4gZ2V0IGluY29uc2lzdGVudCB2ZXJ5IHF1aWNrbHksIHNvIGdyZWFzZWQgdmFsdWVzIG11 c3QgdW5pdmVyc2FsbHkgY29ycmVzcG9uZCB0byBwYXJ0aWN1bGFyIFFVSUMgb3BlcmF0aW9uYWwg dmVyc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZvciB0 aGUgbWlkZGxlYm94ZXMgZG9pbmcgbG9hZGJhbGFuY2luZyBhbmQgZmlyZXdhbGwsIHRoZXkgbmVl ZCB0byBpZGVudGlmeSBhbmQgY2xhc3NpZnkgaW5jb21pbmcgcGFja2V0cyBiYXNlZCBvbiB0aGUg SVAsIFVEUCBhbmQgUVVJQyBoZWFkZXIgZmllbGRzIGZvciBlZmZlY3RpdmUNCiBvcGVyYXRpb24u IFdlIGFyZSBhbHJlYWR5IHNlZWluZyB0aGF0IHRoZSBsZW5ndGggb2YgY29ubmVjdGlvbiBJZCBj YW5ub3QgYmUgZGVjaXBoZXJlZCBpbiBzaG9ydCBoZWFkZXIgcGFja2V0cy4gV291bGQgdGhlIHZl cnNpb24gbnVtYmVyIG5lZ290aWF0aW9uIG9wZW4gdXAgbW9yZSBpc3N1ZXMgbGlrZSB0aGlzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWFuYXNpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMTUsIDIwMTkgODo1NyBBTTxicj4NCjxiPlRvOjwv Yj4gVGVkIEhhcmRpZSAmbHQ7dGVkLmlldGZAZ21haWwuY29tJmd0OzsgQnJpYW4gVHJhbW1lbGwg KElFVEYpICZsdDtpZXRmQHRyYW1tZWxsLmNoJmd0Ozxicj4NCjxiPkNjOjwvYj4gR29ycnkgRmFp cmh1cnN0ICZsdDtnb3JyeUBlcmcuYWJkbi5hYy51ayZndDs7IHF1aWNAaWV0Zi5vcmc7IEJvcmRl ciwgSm9obiAmbHQ7am9obi5ib3JkZXJAaHVnaGVzLmNvbSZndDs7IFJvYmVydG8gUGVvbiAmbHQ7 ZmVuaXhAZmIuY29tJmd0OzsgTWlyamEgS3VlaGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEBl cmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJcyAmcXVvdDtWZXJzaW9u IEdyZWFzaW5nJnF1b3Q7IGEgbmV3IGJlbmZpdCBvciBhIG5ldyBvYnN0YWNsZT88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5zL1RMUy9UQ1AvIGZpcnN0IGxpbmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4xOSBhdCAxNy40NC40NCwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAoPC9zcGFu PjxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5t aWtrZWxmakBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4pDQogd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9ImJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlN1cmUs IHRoZXNlIGV4YW1wbGVzIGFyZSBjaG9zZW4gZXhhY3RseSBiZWNhdXNlIHRoZXkgZG9u4oCZdCB3 b3JrIHdlbGwgd2l0aCBUTFMuIElmIHlvdSBhcmd1ZSB0aGF0IFRMUyBmYWxsYmFjayBkb2VzbuKA mXQgYWx3YXlzIHdvcmssIGl0IGlzIG5vIGdvb2QgY29taW5nIHVwIHdpdGggZXhhbXBsZXMgd2hl cmUNCiB0aGV5IGRvIHdvcmssIGVzcGVjaWFsbHkgd2hlbiBpdCBpcyBub3QgY29udGVzdGVkIHRo YXQgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIGZhbGxiYWNrIGlzIHZhbGlkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5TaW5jZSBRVUlDIGlzIFFVSUMsIGFueSBjbG9ha2luZyBh cHBsaWVzIHRvIGFsbCBhcHBsaWNhdGlvbiBjbGFzc2VzLiBZb3UgY2Fu4oCZdCBhcmd1ZSBjbG9h a2luZyBpcyBub3QgbmVlZGVkIGJlY2F1c2UgSFRUUCBhbmQgRE5TIGRvZXMgbm90IG5lZWQgaXQg ZHVlIHRvIGZhbGxiYWNrLiBCZXNpZGVzLA0KIGl0IGlzIGFuIHVucHJvdmVuIGFzc3VtcHRpb24g dGhhdCBjbG9ha2luZyBpcyBub3Qgd29ydGh3aGlsZSBmb3IgY2FzZXMgd2hlcmUgZmFsbGJhY2sg aXMgcmVxdWlyZWQuIElmIGJvdGggcGVlcnMgYWNjZXB0IFFVSUMgYW5kIHRoZSBuZXR3b3JrIGdl bmVyYWxseSBkb2VzIG5vdCBibG9jayByYW5kb20gYXBwZWFyaW5nIFVEUCBjbG9ha2luZyBjb3Vs ZCB3b3JrLCBhbHRob3VnaCBpdCBkb2VzIG5vdCBndWFyYW50ZWUgcHJpdmFjeS4gUGFydCBvZg0K IHRoZSBjb25jZXJucyBhcmUgdGhhdCB3aGVuIHJlY29nbmlzZWQgYXMgUVVJQywgb25seSBjZXJ0 YWluIFFVSUMgdmVyc2lvbnMgYXJlIHBlcm1pdHRlZC4gVGhhdCBjb3VsZCBoYXBwZW4gZHVlIHRv IGJyb2tlbiBzdWJzeXN0ZW1zIHdoZXJlIHBhY2tldHMgZ28gdG8gYnVja2V0IEEgb3IgQiwgd2hl cmUgQSBpcyBRVUlDIGFuZCBCIGlzIGV2ZXJ5dGhpbmcgZWxzZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+RldJVyBJ4oCZbSBub3QgY29udmluY2VkIHRoYXQgdGhpcyB2ZXJz aW9uIG5lZ290aWF0aW9uIGNsb2FraW5nIGlzIHdvcnRod2hpbGUgb3IgZXZlbiBiZW5lZmljaWFs LCBJ4oCZbSBqdXN0IHBvaW50aW5nIG91dCB0aGF0IHdoYXRldmVyIHlvdSBkbywgaXQgaGFzIGNv bnNlcXVlbmNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29w X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gdGhlIHNw ZWNpZmljIGV4YW1wbGUgb2YgRE5TIGZhbGxpbmcgYmFjayB0byBUTFMuIFRoYXQgbWlnaHQgbm90 IHdvcmsgaWYgUVVJQy1ETlMgaW50cm9kdWNlcyBhIGhpZ2hlciBsZXZlbCBvZiBwcml2YWN5LiBB IGZhbGxiYWNrIHdvdWxkIGJlIGEgcHJpdmFjeSBsZWFrLiBPZiBjb3Vyc2UsIHRoYXQNCiB3b3Vs ZCB0aGVuIGJyZWFrIHRoaW5ncyBvbiBhbm90aGVyIGxldmVsLCBzbyBpdCB3b3VsZCBiZSBhbiBv cHQtaW4sIGJ1dCBpZiBjaG9zZW4sIGZhbGxiYWNrIHNob3VsZCBiZSBkaXNhYmxlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pk1pa2tlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5PbiAxNSBBcHJpbCAyMDE5IGF0IDE3LjI5LjIyLCBUZWQgSGFyZGllICg8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPnRlZC5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPikNCiB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SG93ZHksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9u IE1vbiwgQXByIDE1LCAyMDE5IGF0IDQ6MTUgQU0gQnJpYW4gVHJhbW1lbGwgKElFVEYpICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwuY2giPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5pZXRmQHRyYW1tZWxsLmNoPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KIHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQomZ3Q7 IE9uIDE1IEFwciAyMDE5LCBhdCAxMToyOCwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+bWlra2VsZmpAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jmd0Ow0KIHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IFFVSUMgaXMgbm90 IGdvaW5nIHRvIGJlIHVzZWQgb25seSBmb3IgSFRUUC8zIGFuZCBJIGRvbuKAmXQgc2VlIGhvdyBU Q1AgZmFsbGJhY2sgd2lsbCB3b3JrIGZvciB0aGUgZ2VuZXJhbCBjYXNlLjxicj4NCiZndDs8YnI+ DQomZ3Q7IEEgbG90IG9mIGdhbWVzLCBWUiBhcHBsaWNhdGlvbnMsIHN0cmVhbWluZyBzZXJ2aWNl cyBldGMuIGFyZSBnb2luZyB0byBidWlsZCBzZW1pLXByb3ByaWV0YXJ5IFFVSUMgdmVyc2lvbnMs IG9yIGF0IGxlYXN0IHVzZSBRVUlDIHdpdGggY3VzdG9taXNlZCBhcHBsaWNhdGlvbiBwcm90b2Nv bHMgd2hlcmUgVENQIGZhbGxiYWNrIGlzIHNpbXBseSBwb2ludGxlc3MgYmVjYXVzZSBpdCBkb2Vz buKAmXQgc3VwcG9ydCB0aGUgZnJhbWluZyBuZWVkZWQgYW5kDQogaWYgaXQgd2VyZSBwb3NzaWJs ZSwgd2h5IHdvdWxkIGFkYXB0IGFuIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sIHRvIHdvcmsg b24gVENQIGlmIHlvdSBkb27igJl0IGhhdmUgdG8gLSBvZiBjb3Vyc2UgeW91IGhhdmUgdG8gaWYg aXQgZ2V0cyBibG9ja2VkIC0gaGVuY2UgdHJ5IHRvIGF2b2lkIHRoYXQuPGJyPg0KPGJyPg0KU28g eW91IHNlZSB0aGUgZGVwbG95bWVudCBzdHJhdGVneSBmb3IgdGhlc2UgYXBwbGljYXRpb25zIHRv IGJlICZxdW90O3plcm8gYXZhaWxhYmlsaXR5IG9uIG5vbi1VRFAtYWNjZXNzaWJsZSBuZXR3b3Jr cyZxdW90Oz8gVGhhdCBzZWVtcyBib2xkIHRvIG1lIHVubGVzcyB5b3UncmUgdGFsa2luZyBhYm91 dCBRVUlDIGJlaW5nIHVzZWQgYXMgYSByZXBsYWNlbWVudCBmb3IgJnF1b3Q7YXBwbGljYXRpb24t cHJvdmlkZWQgdHJhbnNwb3J0IGxheWVyIG92ZXIgVURQJnF1b3Q7LCB3aGljaA0KIGlzIGNlcnRh aW5seSBhIGJpZyBwYXJ0IG9mIHRoZSBtYXJrZXQgYnV0IG5vdCBhbGwgb2YgaXQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgYXJl IGNsYXNzZXMgb2YgYXBwbGljYXRpb25zIGZvciB3aGljaCBpdCBpcyBub3QgcGFydGljdWxhcmx5 IGJvbGQsIHNpbmNlIHRoZXkgZG9uJ3QgZnVuY3Rpb24gd2VsbCBhdCBhbGwgd2l0aCBUQ1AuJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGVy ZSBhcmUgYWxzbyBjbGFzc2VzIHdoZXJlIHRoZSBmYWxsYmFjayB3b3VsZCBiZSB0byBhIGRpZmZl cmVudCBzdGFjay4mbmJzcDsgRE5TIG92ZXIgUVVJQyBtaWdodCBmYWxsIGJhY2sgdG8gRE5TIG92 ZXIgVExTIGlmIFVEUCBpcyBibG9ja2VkLCBmb3IgZXhhbXBsZS4mbmJzcDsgUVVJQyBkb2Vzbid0 IG5lZWQNCiBhIGZhbGxiYWNrIHRoZXJlIGJlY2F1c2UgdGhlIEROUyBzdGFjayBoYXMgb25lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGVkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WW91IGNvdWxkIGFsd2F5cyB0dW5uZWwgVURQ IG92ZXIgVENQIG9mIGNvdXJzZSwgYnV0IGZyb20gYSB0cmFuc3BvcnQgbGF5ZXIgcGVyc3BlY3Rp dmUgKGFuZCBhIHRyYW5zcG9ydC12aXNpYmxlIHdpcmUgaW1hZ2UgcGVyc3BlY3RpdmUpLCB0aGF0 J3MNCiBhIFRDUCBmYWxsYmFjay48YnI+DQo8YnI+DQomZ3Q7IEkgZG9u4oCZdCBoYXZlIGFueSBu dW1iZXJzIG9uIHRyYW5zcGFyZW5jeSwgYnV0IGdpdmVuIHRoZSByZWFjaCBvZiB2b2ljZSBjYWxs IGFwcGxpY2F0aW9ucywgeW91IGNhbiBwcm9iYWJseSBzYWZlbHkgYXNzdW1lIHRoYXQgVURQIHdp bGwgYmUgc3VwcG9ydGVkIHRocm91Z2ggbW9zdCBuZXR3b3Jrcy48YnI+DQo8YnI+DQpXaGVuIHdl IGxvb2tlZCBhdCB0aGlzLCBhZG1pdHRlZGx5IGEgZmV3IHllYXJzIGFnbywgd2Ugc2F3IFVEUCBi bG9ja2luZyBvbiBwYXIgd2l0aCB0aGUgUVVJQyBmYWlsdXJlIHJhdGVzIHJlcG9ydGVkIGJ5IEdv b2dsZSBpbiAyMDE1IC0gTygzLTYlKSBvZiBwYXRocy4gVGhhdCdzIG9uZSBuaW5lIG9mIGF2YWls YWJpbGl0eSBwYXRod2lzZSwgd2hpY2ggaXMuLi4gbm90IGdyZWF0Ljxicj4NCjxicj4NCiZndDsg VGhlIHByb2JsZW0gYWdhaW4gaXMgaWYgb25seSBzb21lIFVEUCBpcyBhbGxvd2VkIHRocm91Z2gg dHJhZmZpYyBpbnNwZWN0aW9uIG9yIGF0IGxlYXN0IHBvcnQgbnVtYmVyaW5nLjxicj4NCiZndDs8 YnI+DQomZ3Q7IEl0IGNhbiBiZSBhIGdvb2QgdGhpbmcgdGhhdCBhIFFVSUMgdmVyc2lvbiBpcyBk ZXRlY3RhYmxlIGlmIHRoZSBhbHRlcm5hdGl2ZSBpcyB0aGF0IGFueXRoaW5nIHVua25vd24gZ2V0 cyBibG9ja2VkLiBUaGF0IGlzIHRoZSBiaWcgdW5rbm93bi48YnI+DQo8YnI+DQpBcyBJIHNhaWQg aW4gbXkgb3RoZXIgbWVzc2FnZSB0aGlzIG1vcm5pbmcsIEkgZG9uJ3QgdGhpbmsgdmVyc2lvbiBu ZWdvdGlhdGlvbiBncmVhc2luZyBpcyB1c2VmdWwgYXQgdGhpcyB0aW1lIGJlY2F1c2UgdGhlcmUg aXMgbm8gcmVhc29uYWJsZSBtb2RlbCBvZiBhIHdpcmUtdmlzaWJsZSB2ZXJzaW9uIGRpZmZlcmVu Y2Ugd2hlcmUgYW4gb24tcGF0aCBkZXZpY2UgbWlnaHQgd2FudCB0byBsZXQgdGhyb3VnaCBvbmUg Z3JlYXNlZC12ZXJzaW9uIGFuZA0KIG5vdCBhbm90aGVyIGdyZWFzZWQtdmVyc2lvbiwgYmVjYXVz ZSB0aGUgd2lyZS1pbWFnZSBwcm9maWxlcyBhbmQgc2VtYW50aWMgcHJvcGVydGllcyBvZiB0aG9z ZSB0d28gdmVyc2lvbnMgYXJlIGJ5IGRlZmluaXRpb24gb2YgZ3JlYXNpbmcgaWRlbnRpY2FsLjxi cj4NCjxicj4NCkF0IHRoaXMgcG9pbnQsIGdpdmVuIGNvbm5lY3Rpb24tYXZhaWxhYmlsaXR5IGFz IHRoZSBtZXRyaWMgdG8gb3B0aW1pemUgZm9yLCBpdCBzZWVtcyBsaWtlIHJlZHVjaW5nIGZlYXR1 cmVzIHRoYXQgbWlnaHQgYmUgbWlzdGFrZW4gZm9yIFFVSUMtZGlzdGluZ3Vpc2hlcnMgaW4gdGhl IHdpcmUgaW1hZ2Ugd291bGQgYmUgdXNlZnVsLCBhbmQgdmVyc2lvbiBncmVhc2luZyBzZWVtcyBs aWtlIG9uZSBzdWNoIGZlYXR1cmUuPGJyPg0KPGJyPg0KJmd0OyBXaWxsIGl0IGhlbHAgdG8gYmUg aXMgb3BhcXVlIGFzIHBvc3NpYmxlLCBvciBub3Q/IFNvbWUgb2YgdGhlIHNjZW5hcmlvcyBJIHBv c3RlZCBlYXJsaWVyIHNob3cgdGhhdCBubyBtYXR0ZXIgd2hhdCB5b3UgZG8sIHNvbWV0aGluZyB3 aWxsIGdldCBpbiB0aGUgd2F5Ljxicj4NCjxicj4NClRoaXMgYWxsIGNvbWVzIGRvd24gdG8gdGhl IHRocmVhdCBtb2RlbCwgYW5kIHRoZSBtb2RlbCBvZiBpbmNlbnRpdmVzIGZvciBvbi1wYXRoIGRl dmljZXMuPGJyPg0KPGJyPg0KSSBwZXJzb25hbGx5IHRoaW5rIHRoZSBjb3JyZWN0IGRlc2lnbiB0 YXJnZXQgaXMgdG8gcHV0IHRyaXZpYWwgUVVJQy1kaXNjcmltaW5hYmlsaXR5IGludG8gdGhlIHdp cmUgaW1hZ2UsIHNpbmNlIHRoZXJlIHdpbGwgYmUgYSBsb3Qgb2YgcHJlc3N1cmUgdG8gZGlzdGlu Z3Vpc2ggUVVJQyBmcm9tIG5vdC1RVUlDIHRyYWZmaWMgcmVnYXJkbGVzcyBvZiB3aGF0IHdlIGRv LCBhbmQgaWYgd2UgZG9uJ3QgcHV0IGdyaXBweSBiaXRzIGluIHRoZSB3aXJlIGltYWdlLA0KIHRo ZSBkaXN0aW5ndWlzaGluZyBmdW5jdGlvbnMgd2lsbCBncmlwIG9uIHRvIHRoZSBzbGlwcHkgYml0 cywgd2l0aCBkaWZmaWN1bHQgdG8gcHJlZGljdCBvdXRjb21lcy4gSSByZWNvZ25pemUgSSBhbSBp biB0aGUgbWlub3JpdHkgKG9mIHBlb3BsZSB3aG8gc3BlYWsgdXApIG9uIHRoaXMgaXNzdWUsIHRo b3VnaC48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KPGJyPg0KQnJpYW48YnI+DQo8YnI+DQomZ3Q7 IE9uIDE1IEFwcmlsIDIwMTkgYXQgMTEuMjAuMjUsIEJyaWFuIFRyYW1tZWxsICg8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwuY2giIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+aWV0ZkB0cmFtbWVsbC5jaDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPikN CiB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgaGkgTWlra2VsLCZuYnNwOzxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgcGVyaGFwcyBhIGJpdCBsYXRlIHRvIHRoaXMgcGFydHksIEkn bSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIHByb2Nlc3MgeW91IGVudmlzaW9uIGJ5IHdoaWNo IHRoZSBUQ1AgZmFsbGJhY2sgd2lsbCBnbyBhd2F5LiZuYnNwOzxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgT25jZSBpdCdzIGluLCBpdCdsbCBnZXQgdXNlZCBpbiBhIGhpZ2ggZW5vdWdoIHBy b3BvcnRpb24gb2YgY2FzZXMgdGhhdCB0aGUgYXZhaWxhYmlsaXR5IHJpc2sgb2YgdHVybmluZyBp dCBvZmYsIGJhbGFuY2VkIGFnYWluc3QgdGhlIGZhY3QgdGhhdCBpdCBhbHJlYWR5IHdvcmtzIChh cyBpdCdzIHByZXR0eSBtdWNoIG1hbmRhdG9yeSBmb3IgZGVwbG95aW5nIGluIHRvZGF5J3MgOTUl LVVEUC10cmFuc3BhcmVudCBJbnRlcm5ldCksIHdpbGwgZ28NCiBhd2F5IHZlcnkgc2xvd2x5IGlu ZGVlZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IEJyaWFuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IE9uIDEx IEFwciAyMDE5LCBhdCAxMDoyMCwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+bWlra2VsZmpAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0Ow0KIHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IEluIGEgbm90IHNvIGRpc3RhbnQgZnV0dXJlLCBhIGZhbGxiYWNrIHRvIFRDUCB3b3Vs ZCBub3QgYmUgYSB2aWFibGUgYWx0ZXJuYXRpdmUgZm9yIGEgbnVtYmVyIG9mIHNlcnZpY2VzLiBU aGluayBXZWJSVEMuPGJyPg0KJmd0OyZndDsgJmd0OyBJZiBRVUlDIGFuZCBvdGhlciBlbmNyeXB0 ZWQgcHJvdG9jb2xzIGJlY29tZSBkb21pbmFudCwganVzdCBibG9ja2luZyBldmVyeXRoaW5nIHdv dWxkIGxpdGVyYWxseSBibG9jayBldmVyeXRoaW5nLjxicj4NCiZndDsmZ3Q7ICZndDsgT2YgY291 cnNlLCBodHRwKHMpIGFzIHdlIGtub3cgaXQsIGl0IHdpbGwgY29udGludWUgdG8gbGl2ZSBvbiwg YnV0IG1hbnkgbW9iaWxlIGFwcHMgd291bGQgbm90Ljxicj4NCiZndDsmZ3Q7ICZndDsmbmJzcDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyBPbiAxMSBBcHJpbCAy MDE5IGF0IDEwLjAzLjE0LCBNaXJqYSBLdWVobGV3aW5kICg8L3NwYW4+PGEgaHJlZj0ibWFpbHRv Om1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPm1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+KQ0KIHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmbmJzcDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBIaSBNaWtrZWwsJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJz cDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIGd1ZXNzIGl0IGlzIG11Y2ggbW9yZSBsaWtlbHkg dGhhdCBhbnkgb2YgdGhvc2UgYWN0b3JzIHdvdWxkIGp1c3QgYmxvY2sgUVVJQyBhbGwgdG9nZXRo ZXIgKGFzIHRoZXJlIGlzIGFjdHVhbGx5IGEgZmFsbGJhY2sgdG8gVENQKS4mbmJzcDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE1pcmphJm5ic3A7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNw Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmIj7vu788L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDEwLjA0 LjE5LCAyMTo1NywgJnF1b3Q7UVVJQyBvbiBiZWhhbGYgb2YgTWlra2VsIEZhaG7DuGUgSsO4cmdl bnNlbiZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+cXVpYy1ib3VuY2VzQGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+DQogb24gYmVoYWxmIG9mIDwvc3Bhbj48 YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPm1pa2tlbGZqQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsgd3JvdGU6Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IExldOKAmXMgc2F5 IENoaW5hIG1ha2VzIGEgZGVhbCB3aXRoIEdvb2dsZSB0byBhbGxvdyB0aGVpciBzZWFyY2ggZW5n aW5lIChhIG5vdCBlbnRpcmVseSB1bnJlYXNvbmFibHkgcHJvcG9zaXRpb24pLiZuYnNwOzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IFRoZSBHcmVhdCBGaXJld2FsbCBvZiBDaGluYSAoR0ZDKSBpcyBy ZWNvbmZpZ3VyZWQgdG8gYWNjZXB0IHRyYWZmaWMgZnJvbSBhIHNwZWNpZmljIElQIHJhbmdlIGZv ciBRVUlDIHByb3RvY29sIHYxLiZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEdvb2dsZSBsYXRlciB1cGdyYWRlcyB0byB2Mi4gR0ZDIGlz IHVwZGF0ZWQuIExhdGVyLCBvdXQgb2YgaWdub3JhbmNlLCBzb21lIG90aGVyIGRlcGFydG1lbnQg d2l0aGluIHNhaWQgY29tcGFueSBkZWNpZGVzIHRoYXQgaXRzIGJyb3dzZXJzIHNob3VsZCBhbGwg dXNlIGZvcmNlZCB2ZXJzaW9uIGFsaWFzZXMgYXMgYSBydWxlLiBHRkMgYnJlYWtzLiAoQXNzdW1p bmcgR29vZ2xlcyBzZXJ2ZXJzIGFyZSBub3QgbG9jYXRlZCB3aXRoaW4gdGhlDQogZGVtaWxpdGFy aXNlZCZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHpvbmUgYW5kIHVzZXJzIHVzZSBDaHJv bWUpLiZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBBbHRlcm5hdGl2ZSAxOiBHb29nbGUg dXAgZnJvbnQgZGVjaWRlcyB0byBkZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNpbmcuIENoaW5h IHJlamVjdHMgdGhlIGRlYWwgYmVjYXVzZSB0aGV5IGRvIG5vdCB3YW50IHRvIHN1cHBvcnQgcmFu ZG9tIHRyYWZmaWMgdGhyb3VnaCBHRkMuJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJz cDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEFs dGVybmF0aXZlIDI6IEdvb2dsZSB1cCBmcm9udCBkZWNpZGVzIHRvIGRlcGxveSBmb3JjZWQgdmVy c2lvbiBhbGlhc2luZywgYW5kIENoaW5hIGRvZXMgbm90IHJlamVjdCB0aGUgZGVhbCwgb3V0IG9m IGlnbm9yYW5jZS4gTGF0ZXIgc29tZSBkZXBhcnRtZW50IGluIENoaW5hIEdGQyBvdmVyc2lnaHQg cmVhbGlzZXMgdGhlIGRlYWwgYW5kIGZvcmNlcyBHb29nbGUgdG8gcmVtb3ZlIGZvcmNlZCB2ZXJz aW9uIGFsaWFzaW5nLCBvciBzaHV0DQogZG93biZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IGl0cyBzZXJ2aWNlLiZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBBbHRlcm5hdGl2ZSAz OiBHb29nbGUgdXAgZnJvbnQgZGVjaWRlcyB0byBkZXBsb3kgZm9yY2VkIHZlcnNpb24gYWxpYXNp bmcgYW5kIENoaW5hIHNheXMsIG9mIGNvdXJzZSwgd2UgdHJ1c3QgZXZlcnl0aGluZyBmcm9tIEdv b2dsZXMgSVAgcmFuZ2UuJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEFsdGVybmF0aXZl IDQ6IEdvb2dsZSByZWFsaXNlcyB0aGF0IGZvcmNlZCB2ZXJzaW9uIGFsaWFzaW5nIGRvZXMgbm90 IHdvcmsgaW4gdGhlIGdlbmVyYWwgY2FzZSwgYW5kIG1ha2VzIGEgc3BlY2lhbCBjYXNlIGZvciB1 c2VycyB3aXRoaW4gYSBjZXJ0YWluIGdlb2dyYXBoaWNhbCBhcmVhLiZuYnNwOzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBEaXNjbGFpbWVyOiBJ4oCZbSBub3QgYWZmaWxpYXRlZCB3aXRoIEdvb2ds ZSBhbmQgdGhpcyBtaWdodCBub3QgYXQgYWxsIGJlIGhvdyB0aGluZ3Mgd291bGQgd29yaywgYnV0 IGl0IGRvZXMgaGlnaGxpZ2h0IHNvbWUgb2YgdGhlIGNoYWxsZW5nZXMuJm5ic3A7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IE9mIGNvdXJzZSwgdG8gYmUgZmFpciwgQ2hpbmEgaXMgbm90IHRoZSBv bmx5IGdvdmVybm1lbnQgZW50aXR5IHRoYXQgbWlnaHQgaGF2ZSBhIHZlc3RlZCBpbnRlcmVzdC4g TGV0J3MgdGFrZSBhIGZpY3Rpb25hbCBleGFtcGxlIG9mIFVTIGEgcmVhbCBlc3RhdGUgaW52ZXN0 b3Igd2l0aCBoZWF2eSB0aWVzIHRvIHRoZSBlYXN0ZXJuIGV1cm9wZWFuIGJsb2NrIHdobyBzb21l aG93IGZpbmRzIGhpbXNlbGYgZWxlY3RlZCBhcyBwcmVzaWRlbnQNCiBuZWVkaW5nJm5ic3A7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgdG8gZmluZCBsZXZlcmFnZSBvbiB0cmFkZSBuZWdvdGlhdGlv bnMgd2l0aG91dCBlZmZlY3RpdmVseSBodXJ0aW5nIHBlcnNvbmFsIGZpbmFuY2VzLiBJdCB0dXJu cyBvdXQgdGhhdCBibG9ja2luZyBjZXJ0YWluIGRpZ2l0YWwgc2VydmljZXMgZnJvbSBzYWlkIGVh c3Rlcm4gZXVyb3BlYW4gYmxvY2sgaXMgdGhlIHBlcmZlY3QgdG9vbCBpbiB0aGUgdHJhZGUgbmVn b3RpYXRpb25zLi4gQWR2aXNlcnMgcG9pbnQgb3V0IHRoYXQgdGhvc2Ugc2VydmljZXMmbmJzcDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBydW4gaGVhdmlseSBlbmNyeXB0ZWQgb24gdGhlIGRhcmsg d2ViIHdpdGggcGVycGV0dWFsIGNpcmN1bGF0aW9uIG9mIElQIHJhbmdlcyBzbywgaWdub3Jpbmcg YW55IGxlZ2FsIGNvbmNlcm5zLCBpdCB3b3VsZCBub3QgYmUgcHJhY3RpY2FsbHkgcG9zc2libGUu IEV2ZW50dWFsbHkgc29tZW9uZSBmaWd1cmVzIG91dCB0aGF0IHRoZXNlIHNlcnZpY2VzIGFsbCB1 c3VhbGx5IGFyZSBhdCB0aGUgZm9yZWZyb250IG9mIHRlY2hub2xvZ3kgYW5kDQogY3VycmVudGx5 Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdXNlIFFVSUMgdjMuMiBhbmQgbm8tb25lIGVs c2UgaGFzIGRlcGxveWVkIHRoYXQgdmVyc2lvbiB5ZXQsIHNvIGl0IHdvdWxkIHN1ZmZpY2UgdG8g YXNrIE5TQSB0byB0YXAgaW50byB0aGUgYmFja2JvbmUgYW5kIGRpc3J1cHQgc3BlY2lmaWMgcGFj a2V0cy4gT2YgY291cnNlLCB0aGlzIGVuZHMgdXAgdGFraW5nIGRvd24gdGhlIEJhdmFyaWFuIGxv Y2FsIGdvdmVybm1lbnQgZWxlY3Rpb24gcHJvY2VzcyBpbiBHZXJtYW55IHdoZXJlIHRoZXkNCiBh cmUmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGUgZmlyc3QgdG8gdXNlIGEgbmV3IGRp Z2l0YWwgZWxlY3Rpb24gc3lzdGVtLiBOb3QgdGhhdCB0aGUgaXMgYW4gaXNzdWUsIHNpbmNlIHRy YWRlIG5lZ290aWF0aW9ucyBhcmUgYWxzbyBydW5uaW5nIGhvdCBpbiB0aGF0IGFyZWEsIHNvIHRo YXQgaXMganVzdCBhbiBhY2NpZGVudGFsIGJvbnVzLiZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBPciBhbiBlbmRsZXNzIG51bWJlciBvZiBvdGhlciBkZXZlbG9wbWVudHMgb3ZlciB0aGUg bmV4dCBmZXcgZGVjYWRlcyBpZiB0aGUgcGFzdCBmZXcgeWVhcnMgaXMgYW55dGhpbmcgdG8gZ28g YnkuJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IE9uIDEwIEFwcmlsIDIwMTkgYXQgMjAuMTMuNTksIEdvcnJ5IChlcmcpICg8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+KQ0KIHdyb3RlOiZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgVGhhbmtzIE1pa2tlbCwgSSBkbyB1bmRlcnN0YW5kIHRoYXQg dmFyaW91cyBhY3RvcnMgaW50ZW50aW9uYWxseSBkcm9wIC0gYnV0IGFyZSB5b3Ugc2F5aW5nIHRo ZXNlIGFjdG9ycyB3b3VsZCBzcGVjaWZpY2FsbHkgY2hvb3NlIHRvIGJsb2NrIGEgbmV3IHZlcnNp b24gb2YgUVVJQyAuLi4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGF0IGFzc2VydGlvbi4mbmJzcDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgR29ycnkmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE9uIDEwIEFwciAyMDE5LCBhdCAxODoyNSwg TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptaWtr ZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWlra2Vs ZmpAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KIHdyb3RlOiZu YnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsm bmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IENoaW5hIGJsb2NrcyBhcyBhIHJ1bGUuJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgUnVz c2lhIGlzIHJ1bm5pbmcgYW4gZXhwZXJpbWVudCB0byBibG9jayB0aGUgcmVzdCBvZiB0aGUgaW50 ZXJuZXQuJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgVVNBIGJsb2NrcyBuZXQgbmV1dHJh bGl0eS4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBFVSBibG9ja3MgY29va2llcy4mbmJz cDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBHQiBibG9ja3MgaXRzZWxmLiZuYnNwOzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBTbyBibG9ja2luZyBpcyBub3QgbGltaXRlZCB0byB3aGF0IGFuIG9w ZXJhdG9yIGNvbnNpZGVycyBiZXN0IGZvciBidXNpbmVzcy4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBPbiAxMCBBcHJpbCAyMDE5IGF0 IDE4LjU5LjE1LCBCb3JkZXIsIEpvaG4gKDwvc3Bhbj48YSBocmVmPSJtYWlsdG86am9obi5ib3Jk ZXJAaHVnaGVzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5qb2huLmJv cmRlckBodWdoZXMuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KQ0KIHdyb3RlOiZu YnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsm bmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIHVuZGVyc3RhbmQgd2h5IHBlb3BsZSB3YW50 IHRvIGNvbWUgZG93biBvbiB0aGUgc2lkZSBvZiBwcmV2ZW50aW5nIG9zc2lmaWNhdGlvbi4gQnV0 LCB0aGluZ3MgaGF2ZSBjaGFuZ2VkLiBUaGVyZSBhcmUgYSBsb3Qgb2YgbW9yZSBuZWdhdGl2ZSBj b25zZXF1ZW5jZXMgbm93IHdoZW4gcGVvcGxlIHVubmVjZXNzYXJpbHkgYmxvY2sgdGhpbmdzLiBJ IHRoaW5rIG9wZXJhdG9ycyB3b3VsZCBwdXQgYSBsb3Qgb2YgcHJlc3N1cmUgb24gdmVuZG9ycw0K IHRvJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbm90IGRvIGl0IG5vdyBhbmQgdG8gZml4 IGl0IGlmIHRoZXkgZGlkICZxdW90O2J5IGFjY2lkZW50JnF1b3Q7LiBPZiBjb3Vyc2UsIEkgYW0g b25seSBvbmUgb3BlcmF0b3IuIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGVhciBmcm9tIG90aGVycy4u LiZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IEpvaG4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0mbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBRVUlDICZsdDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7IE9uIEJlaGFsZiBPZg0KIFJvYmVydG8gUGVvbiZuYnNwOzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTAsIDIwMTkgMTI6NTIg UE0mbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBUbzogRyBGYWlyaHVyc3QgJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IDwvc3Bhbj48YSBo cmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5xdWljQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgU3ViamVjdDogUmU6IElzICZxdW90O1ZlcnNpb24gR3JlYXNp bmcmcXVvdDsgYSBuZXcgYmVuZml0IG9yIGEgbmV3IG9ic3RhY2xlPyZuYnNwOzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgV0FSTklORzogVGhlIHNl bmRlciBvZiB0aGlzIGVtYWlsIGNvdWxkIG5vdCBiZSB2YWxpZGF0ZWQgYW5kIG1heSBub3QgbWF0 Y2ggdGhlIHBlcnNvbiBpbiB0aGUgJnF1b3Q7RnJvbSZxdW90OyBmaWVsZC4mbmJzcDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IENBVVRJT046IFRo aXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8g bm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUg dGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLiZuYnNwOzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBZb3UncmUga2luZGEgYmV0d2VlbiBhIHJvY2stYW5kLWEtaGFyZC1wbGFj ZSBlaXRoZXIgd2F5OiZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgLSBXZSd2ZSBzZWVuIGhvdyBtdWNoIGZ1biBvc3NpZmljYXRpb24gaXMg aW4gVENQIGFuZCBIVFRQLiBJZiB0aGUgdGhpbmcgaXMgb2JzZXJ2YWJsZSwgaXQgd2lsbCBiZSBv c3NpZmllZCBzZWVtcyB0byBiZSB0aGUgbGVzc29uLiBBIGxvdCBvZiB0aGUgcmVhc29uIHdoeSBR VUlDIHdhcyBzdGFydGVkIGluIHRoZSBmaXJzdCBwbGFjZSB3YXMgYmVjYXVzZSBvZiB0aGUgaW5h YmlsaXR5IHRvIGltcHJvdmUgVENQIGR1ZSB0byB0aGlzIG9zc2lmaWNhdGlvbi4mbmJzcDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtIE9UT0gsIHRoZXJlIGlzIHRoZSBmZWFyIG9mIHVua25vd24v dW5vYnNlcnZhYmxlIHdoaWNoIG1pZ2h0IGNhdXNlIG9wZXJhdG9ycyB0byBibG9jayB0aGluZ3Ms IHdoZXRoZXIgcHJlZGljdGFibHkgb3Igbm90LiZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgTXkgb3BpbmlvbiBpcyB0aGF0IGl0IGlzIGJl dHRlciB0byBzdGFydCB3aXRoIHByZXZlbnRpbmcgb3NzaWZpY2F0aW9uLCBhbmQgdGhlbiBpZiB0 aGF0IHJlc3VsdHMgaW4gdG9vIGxhcmdlIGEgcGVyY2VudGFnZSBvZiBvcGVyYXRvcnMgYmxvY2tp bmcgdGhpbmdzLCB0byByZS1ldmFsdWF0ZS4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZu YnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE15IGd1ZXNzZXM6Jm5ic3A7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgSVAmIzQzO3BvcnQgdHVwbGVzIGFuZCB0cmFmZmljIHBhdHRlcm5zIGFyZSBz dGlsbCBvYnNlcnZhYmxlIChmb3IgYmV0dGVyIGFuZCB3b3JzZSksIHdoaWNoIGltcGxpZXMgb3Bl cmF0b3JzIHdpbGwgc3RpbGwgaGF2ZSBzaWduaWZpY2FudCB0b29scyBmb3IgbWFuYWdpbmcgdHJh ZmZpYy4gSSBiZWxpZXZlIHRoYXQgdGhlc2UgYXJlIGFjdGVkIG9uL21hdGNoZWQgKE1MIG9yIG5v dCkgcmVnYXJkbGVzcyBvZiBhbnkgb3RoZXIgZGF0YSBwcmVzZW50ZWQuDQogSW4mbmJzcDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvdGhlciB3b3JkcywgSSBoYXZlIGEgZG91YnQgdGhhdCBzdGF0 aW5nIHRoZSB2ZXJzaW9uIGluIGFuIG9ic2VydmFibGUgd2F5IHdpbGwgcHJldmVudCB0aGUgdXNl IG9mIHN1Y2ggdG9vbHMuJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBNb3N0IHByb2JsZW1zIEkndmUgc2VlbiBhc3NvY2lhdGVkIHdpdGgg aW1wbGVtZW50YXRpb25zIHJhdGhlciB0aGFuIHByb3RvY29sIHZlcnNpb25zICh0aG91Z2ggd2hl biB0aGUgbGF0dGVyIGhhcHBlbnMgaXQgaXMgcHJldHR5IHNldmVyZSkuLiBJZiB5b3UgYmVsaWV2 ZSB0aGlzIGFzc2VydGlvbiwgdGhlbiBhY3Rpbmcgb24gcHJvdG9jb2wgdmVyc2lvbiBpcyBsZXNz IGludGVyZXN0aW5nIHRoYW4gYXR0ZW1wdGluZyB0byBhY3QgYmFzZWQNCiBvbiBpbXBsZW1lbnRh dGlvbiZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGZpbmdlcnByaW50cy4mbmJzcDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtPVImbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNw Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgT24g NC8xMC8xOSwgMTo0OCBBTSwgJnF1b3Q7UVVJQyBvbiBiZWhhbGYgb2YgRyBGYWlyaHVyc3QmcXVv dDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPg0KIG9uIGJlaGFsZiBvZiZuYnNwOzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Z29ycnlAZXJnLmFiZG4uYWMudWs8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IHdyb3RlOiZuYnNwOzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgT2JzY3VyaW5nIHRoZSB2 ZXJzaW9uIG9mIGEgcHJvdG9jb2wgc2VlbXMgbGlrZSBhIG1ham9yIGRlc2lnbiBkZXNpZ24mbmJz cDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBkZWNpc2lvbiBmb3Igd2lkZXIgdXNlIGNhc2VzLiBT bywgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IG1vdGl2YXRpb24gZm9yIHZlcnNpb24gZ3JlYXNpbmcuJm5ic3A7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAoMSkgSSBrbm93IHRoZXJlIHdl cmUgaW5zdGFuY2VzIHdoZXJlIHNvbWUgZWFybHkgdmVyc2lvbnMgb2YgUVVJQyB3ZXJlJm5ic3A7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgYmxvY2tlZCBkdWUgdG8gYW4gdW5pbml0ZW50aW9uYWwg bWF0Y2hpbmcgb2YgdGhlIGhlYWRlci4gSXMgdGhlcmUmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBldmlkZW5jZSBvZiBpbnRlbnRpb25hbCBhdHRlbXB0cyB0byBibG9jayB1cGRhdGVzIHRv IHByb3RvY29scz8mbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICgyKSBUaGlua2luZyBhYm91dCBvcGVyYXRpbmcgYSBuZXR3b3JrIHRoYXQg Y2FyZXMgYWJvdXQgdXNlciBzdXBwb3J0IGFuZCZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IHByb3RlY3Rpb24gZnJvbSB1bndhbnRlZCB0cmFmZmljLCBJIHdvdWxkIGV4cGVjdCB0aGF0IHRo ZXJlIHdvdWxkIGJlJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgY2FzZXMgd2hlcmUgdHJh ZmZpYyBwYXR0ZXJuIGFub21vbGllcyBhcmUgZm91bmQgYW5kIHRoZSBhcHByb3ByaWF0ZSZuYnNw Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoaW5nIHdvdWxkIGJlIHRvIHRyeSB0byBkZXRlcm1p bmUgaWYgYSBuZXcgcHJvdG9jb2wgaGFkIGJlZW4gZGVwbG95ZWQmbmJzcDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBhbmQgbW9uaXRvciBpdCwgaWYgbm90LCB0aGVuIHRoZSBuZXh0IG1vc3Qgb2J2 aW91cyB0aGluZyBjb3VsZCBiZSB0byZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGJsb2Nr IGFsbCB1bmV4cGVjdGVkIHRyYWZmaWMsIHRoYXQgc2VlbXMgbGlrZSBhIGRlY2lzaW9uIHRvIGhp ZGUgdGhlJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdmVyc2lvbiBjb3VsZCBpbmNyZWFz ZSBvc3NpZmljYXRpb24gZm9yIG5ldyB2ZXJzaW9ucyBpbiB0aGVzZSBjYXNlcy4uJm5ic3A7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAoMykgU2lt aWxhcmx5LCBpZiBhIHRocmVhdCBpcyBrbm93biB0byBpbXBhY3Qgb25seSBhIHNwZWNpZmljIChv bGRlcikmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB2ZXJzaW9uLCBpdCB3b3VsZCBzZWVt IHRvIG1vdGl2YXRlIGEgZHJvcCBvZiB0aGF0IHRyYWZmaWMgdGhhdCBzZWVrcyB0byZuYnNwOzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHVzZSB0aGF0IHZlcnNpb24sIHdoaWxlIHN0aWxsIHBlcm1p dHRpbmcgb3RoZXIgdHJhZmZpYy4gRm9yY2luZyB2ZXJzaW9uJm5ic3A7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgZGV0ZWN0aW9uIHRvIHVzZSBwYXR0ZXJuIG1hdGNoaW5nL01MIHdpbGwgbGVhZCB0 byBsZXNzIHByZWRpY3RhYmxlJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgb3V0Y29tZXMs IG9yIGJsb2NraW5nIGJhc2VkIG9uIGFkZHJlc3MsIGV0Yy4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICg0KSBUaGlzIG9iZnVzdGljYXRl cyB0aGUgbW9zdCBiYXNpYyBwaWVjZSBvZiByZXBvcnRpbmcgaW5mb3JtYXRpb24gdXNlZCZuYnNw Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGZvciBzdXBwb3J0LiBJdCBoaWRlcyB0aGUgZXh0ZW50 IG9mIGRlcGxveW1lbnQgb2YgdGhlIGN1cnJlbnQgcHJvdG9jb2wmbmJzcDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyB2ZXJzaW9uIGFuZCBwcmV2bGFuY2Ugb2Ygb2xkIGltcGxlbWVudGF0aW9ucy4m bmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICg1KSBPbiB0aGUgc3VwcG9ydCwgaWYgYSBwcm9ibGVtIG9ubHkgZW1lcmdlcyB3aGVuIGEgcGFy dGljdWxhciB2ZXJzaW9uJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgaXMgdXNlZCB3aXRo IGEgcGFydGljdWxhciBhZGRyZXNzLCB0aGVuIHRoaXMgaGVscHMgcGlucG9pbnQgdGhlIGlzc3Vl cy4mbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBNYXRjaGluZyBjbGllbnQgdmVyc2lvbnMg dG8gc2VydmVycyBpcyBtdWNoIG1vcmUgb2YgYW4gaXNzdWUgaWYgdGhlIHVzZXImbmJzcDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBjb21tdW5pdHkgdXNlcyBhIHdpZGUgcmFuZ2Ugb2Ygc2VydmVy cyAobGVzcyBzbywgSSBleHBlY3QgZm9yIG1ham9yJm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgcHJvdmlkZXJzOiBnb29nbGUsIGZhY2Vib29rLCBldGMsIGV0YyksIGJ1dCBzaWduaWZpY2Fu dCB3aGVuIHRoZXJlIGlzIGEmbmJzcDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB1c2Ugb2YgYSBk aXZlcnNlIHNldCBvZiBleHRlcm5hbCBzaXRlcyBhbmQgc2l0ZXMgd2l0aCB0aGVpciBvd24gbG9h ZCZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGJhbGFuY2VycywgZXRjIGFuZCBhIG5lZWQg dG8gbWFuYWdlIGludGVyYWN0aW9ucyB3aXRoIEwyIHNlcnZpY2VzLiZuYnNwOzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgSSBhbSBpbnRlcnN0ZWQg aW4ga25vd2luZyBpZiB0aGlzIGlzIGxpa2VseSB0byBiZW5lZml0IG9yIGJlIGEgbmV3IG9ic3Rh Y2xlPyZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgR29ycnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1F436ED13A22A246A59CA374CBC543998BA3EF85ORSMSX111amrcor_-- From nobody Tue Apr 16 00:47:08 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE79120330 for ; Tue, 16 Apr 2019 00:47: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, 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=fH5p8BFc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3J4s9sdV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEmxbSYHPndY for ; Tue, 16 Apr 2019 00:47:03 -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 77EC81202CE for ; Tue, 16 Apr 2019 00:47:03 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1C68D22270; Tue, 16 Apr 2019 03:47:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 16 Apr 2019 03:47:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=7hHRmFk+lbcBGGQ+Mu5ywGEDGD/YgL 1w9zMBgxot7KA=; b=fH5p8BFcIOnyZalDdbZ2hrBGqbBRWXUHdS5byjedHWvpoO w9HA3u+I8OE7ejhHgVP6v8jRq7WaSgrpbPxHlKm6u30gU3836XVKuIWRQyGwc6Zn iWnZxj99E5mUaFOp0YY1rnDUPJlQ0dZlvxtcg/iDzSeSX5L20aLfSHaFsWlHuV50 nAMNNdz84juhEtgHhEvaWxPfP/MIeOmVzFqxh2yjYZg5psvZ6BeXAsFlL6cfCTUt /wOgXTHJhet17+rEFe8iFbQ0cc7N49fvGSoRHLfFSMW0G91CzWUrL7H5qWHgZ7Vf bojLa5M6aWGm/tAq0gaGSzqUxXjjcrvPD52zdAjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7hHRmF k+lbcBGGQ+Mu5ywGEDGD/YgL1w9zMBgxot7KA=; b=3J4s9sdVXz8+oMCBvwtVxS oV4WnIaEPe05JT8HC7qD53+kKlAvPcNCM2Z19gKMhUSb6uL9wNgIfIggwalkbKwg dLlMY0ySywVv9TzTAYnyisMsa3EONlk14L7qR/l/inpq/8zY2lDJlbIMU1x6fFNZ qSsJloxt++lnqgcPmzHIUQR7EkdNgv13Ygw+QiLFnSQ38owNiP7dm2sRvvRm3jG7 iYaa9vGl2U3L+qQdA4M03ebwioFE49D/JdK5V0U8oZrQf4zP1MzLFNfTKugQuJpx R327r8hdFjtyO5ncmDLb8SXbt1tQ0VuFte/l28k22srmM3jh75INdQ0K/JuMNHJg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfedtgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 4DE1D103CB; Tue, 16 Apr 2019 03:46:59 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Consensus Call: Remember Fewer Transport Parameters for 0-RTT #2464 Message-Id: <62ACEC8C-B8C9-494F-B4A4-B0CE22F1D026@mnot.net> Date: Tue, 16 Apr 2019 17:46:55 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 07:47:07 -0000 Regarding: The editors believe that this PR resolved the issue: ..... and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 16 00:47:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FD1120350 for ; Tue, 16 Apr 2019 00:47: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, 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=mFLm8Mw7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=6f+UIiPf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw3ZcDJNpsuo for ; Tue, 16 Apr 2019 00:47:07 -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 0936D1202CE for ; Tue, 16 Apr 2019 00:47:07 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2A1322223C; Tue, 16 Apr 2019 03:47:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 16 Apr 2019 03:47:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=/1tVmhFVc68EXwSiftthlQ2sIcoJwd iDXM4Cfvscq2w=; b=mFLm8Mw7DPuy5mVLs9qJb+c7KUFZsSSLJxtjRhRkdKYnoB BeDBkksldYwbnTFn5vAQtVDb4vQfvMRego/xONxdRaJhAgfGaEWSQOaggiDsE7Rq m8PVE8SUoGe6bRlY5H95iLS8NgvLJU2i6M7tSzSZjG6m44lEU5IQLbuOKXIAW0Gs NPpztMu5tiYd5ZA3ae+wSTG14kM/iZf5a1801kNP7lCNXBQM5f29oeJJjI3lMErJ gSxGFUukytjo7ZZskRpidSdyHIrwcyKeQGVXusOLtz/kwVekuUYHmorrasbnRYfa I04hN2Vfi857nW5XjDpYr8tYipz4JFTa8YiVhjfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=/1tVmh FVc68EXwSiftthlQ2sIcoJwdiDXM4Cfvscq2w=; b=6f+UIiPfES1HMjn49YbbQz mlKGOkImoR/Jg/tqnHF4QNHEpwQDunZ2PN+gTIRm3rrZSbv7HKPKJ7POFew8buoE n/FDTGQ/rDqwkMqk1AZqEnwBzff+oy0+lud7KO2AJf+8APsq1+ifHUl23B4q6RQc GN4hSue3qlkj2tS0aWFY0+FTCkhKhImjSIpNRNfJnHGzlhbk1bikXcPO79fs0g1X nzabXkOj4nkp+ndy6kXTVRvFrcmWwZ/SP/7Rull3D+ns6KtwcwNdUIcrZEA52TZa Crbm1RdYH6N+VPr0Nd7/+tuTRwKIvsMEEWJE3Gzy4On3FAQiY6YJJyCk3+fKIVaA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfedtgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgepud X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id CE130103CC; Tue, 16 Apr 2019 03:47:04 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Consensus Call: Remove size optimization for Initial packets #2522 Message-Id: <5DC2E80E-0E67-47B3-9C71-3A8CF8DD46FB@mnot.net> Date: Tue, 16 Apr 2019 17:47:04 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 07:47:11 -0000 Regarding: The editors believe that this PR resolved the issue: ..... and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 16 00:52:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4A812033D for ; Tue, 16 Apr 2019 00:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=Zm8qBBfM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1yzqoqNZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8A29RTOOWdr for ; Tue, 16 Apr 2019 00:52:37 -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 C41D9120334 for ; Tue, 16 Apr 2019 00:52:37 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B98862223C; Tue, 16 Apr 2019 03:47:29 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 16 Apr 2019 03:47:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=k4JlGdBxJTWkxUYVx0CdBOdWUAub1w ZcfGs6R3VNloY=; b=Zm8qBBfMmK6NDS5/r8asX7DZels7Z3xKo13RK9/SDsQOa1 /6dIR4iUwBcv6Yy4/+tzz4FuigpKnG+4f3BwviftGOxoIlxpQ0RU6V3Rb5KJCoig awBTB5q7JWdx7b3q4T9yVamiurGZI8VIB3oiTkIynVMMc3SE84Br0UoCix+y0upW 12f0cT5maSmSeLxRcvzHQR8n8hP12ZSPZDZz6JINOWuhqIKEXkzN818tVVw3yNW6 QPFuvHnCYHfZ6OrvQDUs9/7gp1NWVzGV11kpao6rTvJtsr5U30QhCIhyhhvYwLoB 3oZg3ZhHlp8UDccXhqKkYO/SfvXSEFJFPXekdpCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=k4JlGd BxJTWkxUYVx0CdBOdWUAub1wZcfGs6R3VNloY=; b=1yzqoqNZnPFokYz3Ja3eHI PQUllfWdRR0Zi1MNGELYSyITUO+oWsUiy5qIWq2tS3pGoFUlXU6RZ4gU9tj+LD0r iipT1l70TOHgElvI+zGQgKOzGu/uRHnlzWJC3bDuMB9/1ScYGxNzTl8/5fakpVJz kdDBx3ZHyWQ+R0X818Da+CTMCXsqdUkDd1dnDXE1ezRnxuq2HCYDuQ0u2lZHXpJB Q/mPUceIBxCdaZQ0R3obEh7CBaYhckt8hJCud94x8V2l+O4r9+EpQEdZnF2/N5k2 H4bJ1S6ovIVlItbzm0tUKvA3dy8PNUiQyoqB9Pyl8JDo4ZR6hDiHdrsLlp+QhFbQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfedtgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgepge X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F6C4103C9; Tue, 16 Apr 2019 03:47:28 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Consensus Call: VN packets may be dropped more often when the QUIC bit is 0 #2400 Message-Id: <96D1B775-F34B-442A-BE49-C8F811891641@mnot.net> Date: Tue, 16 Apr 2019 17:47:27 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 07:52:39 -0000 Regarding: The editors believe that this PR resolved the issue: ..... and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 16 00:52:49 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A48120346 for ; Tue, 16 Apr 2019 00:52:40 -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=WiDlSBuX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kWsW04ck Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqZfN1oMfzqq for ; Tue, 16 Apr 2019 00:52:37 -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 C3FE9120150 for ; Tue, 16 Apr 2019 00:52:37 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CA36222237; Tue, 16 Apr 2019 03:47:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 16 Apr 2019 03:47:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=AxOuphxEmNzJpCV/UUSMOEy0CiC5YT QsMguFTnvraC0=; b=WiDlSBuXd9QLchEB5+SfG+/z46hUg9IfOWS/ySXhben9ck soj6H17gadm3er4/M/4O7+kDirT74H32ilcmqR55TnvgwMYk43ohzATxbx/ZFjxw 3IILOWi1HMGNKteKqibHqq/Aj+PI4v+iVaxStDMibcozT9Noak7yLjq9ALjdpTqY QsWhWfpWYbgwtcsw+WJ3pqne4bZEntHMyaVGvZsTHbRekwL03tRa01hTApTxpYcB 5s7lfi+cfR0eIiyU1swNvOc9tukIjzqPB3Ns56fX7N9uuXRfmeevI2emYUC+7hzT 5nZYYEYTDf6byTbEC5I7U1LLBBSiuhVNR/Vsu5WA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AxOuph xEmNzJpCV/UUSMOEy0CiC5YTQsMguFTnvraC0=; b=kWsW04ck1Ed7a6FLR9NrkR ODpHEL0g6BIIm3yvzWNVUmEvwCuVN4Urtml3JC/G+2WLfVgbkIeM3HXEodolNEe/ n0ii1+OH3wKyp1IYYevThxfsXFI8a2HQnO0aHZ0oS7xiJrkmsHfOFh0mutkS83EY Q8YKP4Yz9LFjeXm1dDTysg18Hi5ysqUbO8Y4S4q3qgy9pu0XYamJic671pNL1cyI 5z/uxF4MDjdeGSxTYKssLizUDhQoJxE2btJC9vc7jI5IMQQPKkK8nhcgKCb0iEEu 9JhMN060co300Xujl5G33ZpU+qdStG7rRG/SxFoiei1kkF9z1GJ5g33G3g/elXXw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfedtgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgepvd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 6427A103CB; Tue, 16 Apr 2019 03:47:14 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Consensus Call: Are transport parameters mandatory? #2528 Message-Id: Date: Tue, 16 Apr 2019 17:47:13 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 07:52:42 -0000 Regarding: The editors believe that this PR resolved the issue: ..... and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 16 00:58:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A68120334 for ; Tue, 16 Apr 2019 00:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 C7DA2l71QDMt for ; Tue, 16 Apr 2019 00:58:25 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092D512014D for ; Tue, 16 Apr 2019 00:58:25 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id b8so6414653uaq.7 for ; Tue, 16 Apr 2019 00:58: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:reply-to:from:date:message-id :subject:to:cc; bh=aR12ojx1JmEuxfSNMhRQF79IFEMW9HHjpWsk3LdwKpQ=; b=nKhXS0cOmCDJYK222ihG9VXucTc5U5oXcPKRK5dfVQRXCMIldYNfn/HONuEPN0qNUo wTiALp0VA7DQHi//Gywa2oZ6P0gnZDimpafjnxL9zmCtkWyJU3CJsWd8bxsXM3mFMemn OJk+vSPEQXIMsLP16SxLN9DGCNPNJHPC+Bl78/L3rELAG2HHGwWzE8RE0JxSyFmigIns rXNRk8Mq0AsDDg+72MgeH4WdScQKDmDlOgOeBOHXWRd3ZnTPZ0NuVai0RkkBK50MQUKX q4cPkF1LOqAdf1jRo4NYu/QMLUxcBLG3gg96Wf208eCspFv8MLBET6ZtzStCvZ0Wvg9f vqvg== 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:reply-to :from:date:message-id:subject:to:cc; bh=aR12ojx1JmEuxfSNMhRQF79IFEMW9HHjpWsk3LdwKpQ=; b=YpvsBLFa3fj5zgGpifH8aAhcKdzad8IB9faGBXy0KOq50cShgbSwkzBN6FQf1v8Yzq s3cL+BtBbtTRe/oWECQBwnKyIqk9A/OnT0WBw6BoMdND6jpjeYaFBW1jSgCDTTVgHLkJ 05t/07VSr4tEz8GIAliyDt42dd0KgJgoNqo7SgAs1qr18rvY5XzdQFZR5WLKd2LNBvcU iNUFLZkWMG4uUmh2I1N0lffvXmmk1z3nGi1k8vdKGcTiHALBnSujagrXplcUrjEf3In3 iw8YtHZ5tSJyxccU25kdaNGUgy3meGiD+XRcQPCU2bPro/oSM8sgDr0nem8X3HLudJ8p 9FPg== X-Gm-Message-State: APjAAAXuuQc4eJE2B2CIeokY2O6vkdVIffBBK6UIaZd7L+BReX3+NXC3 7hLpULhwrj6ZCblyHzWTDigjiIVehuRar8VCJgU= X-Google-Smtp-Source: APXvYqyH+VowLXJY8e7G6eRs1Rt3d4YrWLO5OVRj6VCSWPL3f78t/iXEjDdnMDfqOJtPIR2z5lQs/IOaMdMuOwPHb7E= X-Received: by 2002:ab0:2b98:: with SMTP id q24mr4675768uar.122.1555401503067; Tue, 16 Apr 2019 00:58:23 -0700 (PDT) MIME-Version: 1.0 References: <62ACEC8C-B8C9-494F-B4A4-B0CE22F1D026@mnot.net> In-Reply-To: <62ACEC8C-B8C9-494F-B4A4-B0CE22F1D026@mnot.net> Reply-To: dirkjan@ochtman.nl From: Dirkjan Ochtman Date: Tue, 16 Apr 2019 09:58:11 +0200 Message-ID: Subject: Re: Consensus Call: Remember Fewer Transport Parameters for 0-RTT #2464 To: Mark Nottingham Cc: QUIC IETF mailing list , Lars Eggert Content-Type: multipart/alternative; boundary="00000000000012d4550586a12225" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 07:58:27 -0000 --00000000000012d4550586a12225 Content-Type: text/plain; charset="UTF-8" The issue link is wrong here, should be: https://github.com/quicwg/base-drafts/issues/2464 On Tue, Apr 16, 2019, 09:47 Mark Nottingham wrote: > Regarding: > > > The editors believe that this PR resolved the issue: > > > ...... and discussion so far seems to support consensus to do so. If you > object, please do so on the issue or in response to this message; absent > any pushback, we'll declare consensus at the end of the week. > > Regards, > > -- > Mark Nottingham https://www.mnot.net/ > > --00000000000012d4550586a12225 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The issue link is wrong here, should be:



On Tue, Apr 16, 2019, 09:47 Mark Nottingham <mnot@mnot.net> wrote:
Regarding:
<https://github.com/quicwg/base-draft= s/issues/2624>

The editors believe that this PR resolved the issue:
<https://github.com/quicwg/base-drafts/= pull/2467>

...... and discussion so far seems to support consensus to do so. If you ob= ject, please do so on the issue or in response to this message; absent any = pushback, we'll declare consensus at the end of the week.

Regards,

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

--00000000000012d4550586a12225-- From nobody Tue Apr 16 01:02:41 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70C812034D for ; Tue, 16 Apr 2019 01:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ZCUs5acH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=4tjian+/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zplVzoEJGey1 for ; Tue, 16 Apr 2019 01:02:38 -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 02B0A120150 for ; Tue, 16 Apr 2019 01:02:38 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DFE092227E; Tue, 16 Apr 2019 03:47:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 16 Apr 2019 03:47:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=KAuoVP6uf5aHHzPrA0jY8KVA+fAOOj YSbSl+G77lby4=; b=ZCUs5acH5r5mSFPol5NjsYDwUfsNcdKs9sB3H+KcmFBLIT wGkY0QypOSjfbVuZzURPCnSRj3Uto0LncjuUZfwVtP4QSbBAv81pP1sr7xEVIuvZ yKFAhjKttyqUTUW/IGR0e4M302cWKaoWGWIYeJhmlTeIv0d2DoeNKPaP8vAX5tcN UsVePcKzKSC1Vy0pGKtOKQgDUxLUOQZZyXKj1iwjlkOT4kHWBq+nIhL/QC5pOrTj 5bqWuu6tT7w1NNw8qQjmJdZqa+JLrkWWwlJgTbghn9lUpisp7SiPgy9tDlwslxE3 80H6Q5oUg26zHenX7E7eM0sK9xTjh7B17jVu7dVg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=KAuoVP 6uf5aHHzPrA0jY8KVA+fAOOjYSbSl+G77lby4=; b=4tjian+/+dTFiW28mwfY84 78KJhJU6xSlmxSI4jIATOT9culq2ZJ/mWvJIWUA8wR7GvrRlwWoZNFkiAYuouIB6 N96MeW9mQHMYZRYAFmo18wVir1DFVtXfBgs01I4KMqj58OdmK6QmFO+InEof+qBe 2EEz4MpY8ifnHpxP/Ufysy/l9jDumpULJlLCRbZEPOUrSocNm80JNre70XSw2vpK wsQ09alKJjLIyCj5t2MDI5G8XEi4I3jHINS2dZHbIrSAv63x2QeF/p4dox/qwUG9 AxrgHvikQZ352/z7N4j3deG+ZtbCzpXAX/kNsD1CfKVxNxzvg5XR4VHw6GB6PaOQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfedtgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgepfe X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 8043A103CB; Tue, 16 Apr 2019 03:47:22 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Consensus Call: rate-limiting of CID issuance needs to be allowed #2436 Message-Id: <1F1C9731-8860-4ADF-8258-C0F65A973D0D@mnot.net> Date: Tue, 16 Apr 2019 17:47:21 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 08:02:40 -0000 Regarding: The editors believe that this PR resolved the issue: ..... and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 16 01:04:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80807120151 for ; Tue, 16 Apr 2019 01:04:25 -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=IlObVDM4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vutbJ/fR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfSDJz4u6eZQ for ; Tue, 16 Apr 2019 01:04:24 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A711120150 for ; Tue, 16 Apr 2019 01:04:24 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5425A220E4; Tue, 16 Apr 2019 04:04:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 16 Apr 2019 04:04:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=i MGCpGkDB//tdTUK4tCdZw/+QWGRunaPGrMsWizr6pU=; b=IlObVDM4AtHe/ClB+ 2FfxzpgFlKwT61vF11v0+7OhfvFNuV/PYJw1EDPl0V2pit4lZkrW8V9Qb2j8QCFG SQrXC6T8acSnwb5rKm2WI83dOMttDXl/TzRJO8MrHflnvTYAQ1Y8hZB9N3pvMBld K79o65yLRXc5FALof3EC6qjwiW09Fifezr1FC3cVkCiiWUYb1RLERo3P+Lt5Btr6 UISggrmg6mIUirgcGU6XVTKWyweIIso59nk9EO7WwYe0TN11/Lb74FUzNi+DKccx jJ9bhd366T+RNf8ygOun4nHXQ7nzGTKG8FpFKw+H2aPIyqNw4ZZR6pkUSXsONf05 ug8Sg== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=iMGCpGkDB//tdTUK4tCdZw/+QWGRunaPGrMsWizr6 pU=; b=vutbJ/fRCNpHuU3t/4oM00xmd5vbpeDNkpG0lEPWN3zlEBK4JrF+e7iI/ V5LQn93HsIDEAPIyVB81/Yq42aR8a/nFdc4KC7ARO1HhP3IDLDoiif9PDwOiuEQs 08oiPkPyW7665v45hakCcEAmUsmddnttdTA5l4/qzaUVWppkns+Zeg2CRjZwtET8 YcliUASGfBElYSDG6nqTZwk4fPbAJSeHIM4b+lB1Vf1CJBmML2/u4qqupitYjFys IYAXh51n6Fh+arylU35V1ZtGRYZKTmixiWMPZrG7MPV9omVZiCY2fo872/k49d/c 62pgO85pHYlrnOwGEf5UGyNzwwT9g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfedtgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 73E70E407B; Tue, 16 Apr 2019 04:04:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Consensus Call: Remember Fewer Transport Parameters for 0-RTT #2464 From: Mark Nottingham In-Reply-To: Date: Tue, 16 Apr 2019 18:04:16 +1000 Cc: QUIC IETF mailing list , Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: <62ACEC8C-B8C9-494F-B4A4-B0CE22F1D026@mnot.net> To: dirkjan@ochtman.nl X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 08:04:26 -0000 Thanks. > On 16 Apr 2019, at 5:58 pm, Dirkjan Ochtman = wrote: >=20 > The issue link is wrong here, should be: >=20 > https://github.com/quicwg/base-drafts/issues/2464 >=20 >=20 > On Tue, Apr 16, 2019, 09:47 Mark Nottingham wrote: > Regarding: > >=20 > The editors believe that this PR resolved the issue: > >=20 > ...... and discussion so far seems to support consensus to do so. If = you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 16 03:51:12 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAB61205B5 for ; Tue, 16 Apr 2019 03:51: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, 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=uhasselt.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8MaaWl4ra2J for ; Tue, 16 Apr 2019 03:51:07 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1F812003F for ; Tue, 16 Apr 2019 03:51:07 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id a28so15648971lfo.7 for ; Tue, 16 Apr 2019 03:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:from:date:message-id:subject:to; bh=VTIQiG6Y63i0gtdGZ17qHJ9b+31XC1tf6aqqHpj0mPk=; b=JJULjdpN6Z4k24mXclu/tcr1qNhVCinijiQ51gxvFjn+XMmO9PiTO+mmXCDGeNrotf PAojAX5FmHgirB32Hau2I8FB/BuejbDSnQo3GUv1f42sliOT7PW70tBv3wLpIOcV9tWa B7lh3pnGcjz+qpz4Kw7kFje/+ZQAdbG0lLiEU= 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=VTIQiG6Y63i0gtdGZ17qHJ9b+31XC1tf6aqqHpj0mPk=; b=Dw+V5RNj8HxfhFEC1zQrmac4hM6cvCWBL9I+Ja2yyr3/h6s9K59+eRIrkVOVxSqZAc V1QEViPwKC9LjgzhkJ8N4hk2VAGrDU4yRM1UGwvvlRP3uSg5GEUj28NAMidaMXSwgoXG iCKr6xqoX/EX9WY0Un7kL277RdSH5QJzM9ySKmkzrHuywx7l2vvvw8xQzu8l7LiXHq6E pszerUbZ6Z1pBSbaja50TVe4PgGAFK45zkAmHSuPsUZ3nbzF48aDD6x8SJTjikQHwwgj SG2crM6V4zgIdE+CoMhlSCddVYEMFdPr0+hP2Bo57VcQYIiD/wwFbaHWZeZXIrPCopXi uuDA== X-Gm-Message-State: APjAAAWk62ODK3PwgJT5F9G+15UhUzTvWYSkBYzbpZl1u6ilLqLhEBDf JfRCGQ3hy2YQqHruq6wj2dN1Xhpfall454VL+UC6AA/+3Iw= X-Google-Smtp-Source: APXvYqzEeqHUmg07G+7x9f9ro6+Gd1ZwCPj2kuktO4PVEwxjz7Vw4z2MEUrgUgk+BxaAjNPSUcW+xQ8XqZmHbYban0k= X-Received: by 2002:a19:f81a:: with SMTP id a26mr11829332lff.63.1555411864760; Tue, 16 Apr 2019 03:51:04 -0700 (PDT) MIME-Version: 1.0 From: Robin MARX Date: Tue, 16 Apr 2019 12:50:53 +0200 Message-ID: Subject: QUIC logging and tooling : moving towards qlog To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000add14d0586a38b7f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 10:51:11 -0000 --000000000000add14d0586a38b7f Content-Type: text/plain; charset="UTF-8" Hello everyone, In Prague, there were three separate presentations focusing on logging and tooling for QUIC and HTTP/3 (video: https://www.youtube.com/watch?v=LiNLz1QuT0s&feature=youtu.be&t=3190, slides: https://datatracker.ietf.org/meeting/104/session/tsvarea). There seemed to be a lot of interest in moving this forward. The currently agreed upon approach is to focus on creating a single logging format and schema. This will make the creation of reusable tools easier. As a basis for this, the qlog proposal was chosen. Per recommendation of Brian Trammell, we have created two I-Ds for this: 1) The high-level schema: this is (semi-) protocol agnostic and could eventually lead to a BOF for a more general wg on this topic. For now, we focus on the QUIC/H3 use case. 2) The concrete QUIC and HTTP/3 event definitions: event semantics for these protocols. These documents and examples can be found at: https://github.com/quiclog/internet-drafts We welcome new collaborators and co-authors for these drafts. There are also several issues in the Github repo that could use some insightful comments. In the quicdev slack, there is also a #qlog channel. --------------------------------------------------------------------------------------------------------------- Even though qlog will be the basis for the "standard" format, several implementers have started logging in the quic-trace format as well ( https://github.com/google/quic-trace). To help the transition and show that qlog is/should become general enough to support the use cases from other formats, we have written a small quic-trace to qlog converter webpage: https://quic.edm.uhasselt.be/qtr-to-qlog/ This tool ingests the binary .qtr quic-trace protobuf files and converts them to json-based qlog. It also includes a rudimentary version of the quic-trace visualization/tool, as a simple example of how to ingest and process qlog in web-based tools. In time, Victor Vasiliev also plans to add qlog support to the quic-trace tool. Jari and Marcus of the spindump tool also plan to add qlog support, as will Maxime Piraux for quic-tracker. Finally, Dmitri and Stephen from Litespeed already integrated basic qlog support in lsquic, which can be seen live at https://http3check.net/. We doubt Wireshark will add qlog output directly, but we also wrote a pcap-to-qlog converter for an early version of qlog. We expect most implementers will not log qlog/json directly, but write automated transformers from their (binary) formats into qlog. The qtr-to-qlog and pcap-to-qlog examples shows that this is a perfectly valid approach as well. -------------------------------------------------------------------------------------------------------------------- At this moment in time, the original qlog tools (see https://quic.edm.uhasselt.be) are not yet compatible with the new qlog format. This is something we will be working on in the next few weeks. We welcome any and all feedback and ideas for tools and logging amenities. With best regards, Robin -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --000000000000add14d0586a38b7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

<= div>In Prague, there were three separate presentations focusing on logging = and tooling for QUIC and HTTP/3 (video:=C2=A0https://www= .youtube.com/watch?v=3DLiNLz1QuT0s&feature=3Dyoutu.be&t=3D3190,= slides:=C2=A0https://datatracker.ietf.org/meeting/104/session/tsvarea).

There seemed to be a lot of interest in moving this fo= rward. The currently agreed upon approach is to focus on creating a single = logging format and schema. This will make the creation of reusable tools ea= sier. As a basis for this, the qlog proposal was chosen.=C2=A0
Per recommendation of Brian Trammell, we have created two I-Ds= for this:
1) The high-level schema: this is (semi-) protocol agn= ostic and could eventually lead to a BOF for a more general wg on this topi= c. For now, we focus on the QUIC/H3 use case.
2) The concrete QUI= C and HTTP/3 event definitions: event semantics for these protocols.=C2=A0<= /div>

These documents and examples can be found at:=C2= =A0https://github.co= m/quiclog/internet-drafts

We welcome new colla= borators and co-authors for these drafts.
There are also several = issues in the Github repo that could use some insightful comments.
In the quicdev slack, there is also a #qlog channel.=C2=A0

=
----------------------------------------------------------------= -----------------------------------------------

Ev= en though qlog will be the basis for the "standard" format, sever= al implementers have started logging in the quic-trace format as well (https://github.com/google/quic= -trace).=C2=A0

To help the transition and show= that qlog is/should become general enough to support the use cases from ot= her formats, we have written a small quic-trace to qlog converter webpage:<= /div>


= This tool ingests the binary .qtr quic-trace protobuf files and converts th= em to json-based qlog.=C2=A0
It also includes a rudimentary version of t= he quic-trace visualization/tool, as a simple example of how to ingest and = process qlog in web-based tools.=C2=A0

In time,=C2= =A0Victor Vasiliev also plans to add qlog support to the quic-trace tool. J= ari and Marcus of the spindump tool also plan to add qlog support, as will = Maxime Piraux for quic-tracker. Finally, Dmitri and Stephen from Litespeed = already integrated basic qlog support in lsquic, which can be seen live at= =C2=A0https://http3check.net/. We d= oubt Wireshark will add qlog output directly, but we also wrote a pcap-to-q= log converter for an early version of qlog.=C2=A0

= We expect most implementers will not log qlog/json directly, but write auto= mated transformers from their (binary) formats into qlog. The qtr-to-qlog a= nd pcap-to-qlog examples shows that this is a perfectly valid approach as w= ell.=C2=A0

---------------------------------------= ---------------------------------------------------------------------------= --

At this moment in time, the original qlog tools= (see https://quic.edm.uhasselt.be= ) are not yet compatible with the new qlog format. This is something we= will be working on in the next few weeks.=C2=A0

W= e welcome any and all feedback and ideas for tools and logging amenities.= =C2=A0

With best regards,
Robin

--

<= td style=3D"font-weight:bold;font-size:16px;color:rgb(231,59,43);line-heigh= t:1.1em;padding:0px;font-family:Verdana,Geneva,sans-serif">Robin=C2=A0Marx<= /td><= /tr>Kantoor=C2=A0EDM-2.05
PhD resear= cher - web performance
Expertise centre for Digital Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2=A0
www.uhasselt.be
Universiteit Ha= sselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
=C2=A0
3D""
--000000000000add14d0586a38b7f-- From nobody Tue Apr 16 06:26:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EE312016D for ; Tue, 16 Apr 2019 06:26: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] 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 LG8RVYUJ6eWM for ; Tue, 16 Apr 2019 06:26:03 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4F512016B for ; Tue, 16 Apr 2019 06:26:03 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id D3C1D300B9 for ; Tue, 16 Apr 2019 16:26:00 +0300 (EEST) Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 7134788963F for ; Tue, 16 Apr 2019 16:25:24 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_CF211722-2E60-49B0-974D-B59E240A92DA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Doodle poll for Second-Quarter 2019 QUIC Virtual Interop Event (was: Re: Doodle poll for Spring 2019 QUIC Virtual Interop Day) Date: Tue, 16 Apr 2019 16:25:23 +0300 References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> <41ADF962-1ED0-429F-8414-8E86023DA280@eggert.org> To: QUIC WG In-Reply-To: Message-Id: <1E09B8AD-F6AE-4787-8D90-96909572E690@eggert.org> X-MailScanner-ID: 7134788963F.AFB82 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 13:26:05 -0000 --Apple-Mail=_CF211722-2E60-49B0-974D-B59E240A92DA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, May 1 was the choice with the best attendance per the Doodle. Lars --Apple-Mail=_CF211722-2E60-49B0-974D-B59E240A92DA 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAly118MACgkQHbmKvSnu NPiLYA/9FVmk4wiWrtXMsNdzmLqkomcV+4cKetMUD78wQtT3YOD5gBFzoJvS4KHx 7XuWqjqWT3R4ng8RhBPxFGxYcitM3gi9Jgnw7Z9tLqfRNY+i78dC6vLIJF3mTOeW XaL3/ANy73oU2frlkzJFXR0Yc2GvSXEdwqp6aFjiiiN/4cHf8etpaQbvs+3QgtcO BridQ3eEWoMf3TtC/kFgBABKWNTJ06cFxejFtDcyyCdl29pTQMFQeOI3+2Ny/ReW cm6CO1EZdyO278SyEAwLn0+Q1pLV2bQpmPoq3bHEuI30mYBkNaCFNpPsXy12NN/E Lyghzz4wykHJ6oLjyyTa9Tin2gq3nSwYXOSiRSaTTIUePZ1fDV93h/JH4BL8Jj6M UZlcshn9cA9V4YlKt2ZGBlYviw9QbXooxjSvfWskEf9u46M4jtha391JoUKFg55Q brgzJzc+bMAv+O4YRFKICCzwn/WpgUkV/bn264glv9wS1qbQwLwLBAPmeZrFgbuk DQTtd8Lw5sKgHYTxjEpn6vKKFp4wPu3be1n4Fa7t02Iry9OfUdDBRnKMWxQh5lLj y+i+LNspYpYp3N4tLyjEjbwZwtusPhqKMIR24BVgyFIKd3RRti327bzTYy5ISHJ9 jI9iYkYM8CpT2Br7JVlGs8ovYPvHbsFrQqre8LdXLycEQlNT0jM= =h8TE -----END PGP SIGNATURE----- --Apple-Mail=_CF211722-2E60-49B0-974D-B59E240A92DA-- From nobody Tue Apr 16 13:02:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6EA1204A3 for ; Tue, 16 Apr 2019 13:02:15 -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 2VpcPjAd8_dY for ; Tue, 16 Apr 2019 13:02:12 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245FB120496 for ; Tue, 16 Apr 2019 13:02:12 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id k45so18981515edb.6 for ; Tue, 16 Apr 2019 13:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=qn62C0hWkeqqdnrg31SbgeVsnUWGLPRvY75hNIu49ow=; b=BDHTRhimwbJwSKL/9T9X2LYiPuUg2/dP11KHo+ylbn3UAEg5p7kCi9U/HjW/FRS9bf yNPCC0bqRIMe/sUWpRp0Ij6wMjmkAFvvH1jjh6jv3udT24ksxWyeenRw/YFQXTI37OC5 cBXiGn0eRnKev2SRwHVoqyek4jH0MU+Gi5d7jB8uVaAkVY825CjqD/onFjL7LeciX3dm YWeHQ3Qj2jA+FSwb+g+ml3Rz54U0aKheJSOMoHVM4wTtasFQef8tCc/tdHV2AIx/PFur /IsinxowyF7euOhOn3AN8CcK6SOyodb1Hn12buDtzodCdne8rGhtbKRkQEnbNm3A3bF6 pzcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=qn62C0hWkeqqdnrg31SbgeVsnUWGLPRvY75hNIu49ow=; b=auNiLQfTivccMCp96j1pEwpF06teTiPycDLtH7bmc/BlVUC1LFfK7oIRV7R1D5nf3L TZLGifS4juStEifIQauZ/dkw7MV8g4PIBIiw0Qv/ub5KeKpYdnjYqbXhS6LmSceVgAuY uxAzkYhqszEGz/6GkYNlH+TGf2/yje+ZXiHSzG6IRVlWxfuf9SyJdyJzwP/bPzJqv0Xa Su3C7rtkGVqVdv5uGOb7yWHXMQzW89OgUqXeBRieFKShRzUoJviET2dYNxWn6qllR9NY NAuVtGsTs4ABHoGqLIESs9JFtIUPVoMgJ0OpEg4ihEBWb63F3WCENfP8HOkfdGGfY08z InWQ== X-Gm-Message-State: APjAAAU2A6nqBA99RokdIsdkr7wv7mGHszrYLyxhTexD+IgBrZ2XqX4N Bgl8dclnsXDsMSYbDD5Myi8= X-Google-Smtp-Source: APXvYqxqYHgGAJ0FcKCZxbfyaO7JXa+5VuJno0tunbeLJq7d9TOPfFnJ+yU5tITck73XPXisDD2I5w== X-Received: by 2002:a50:95cc:: with SMTP id x12mr17484506eda.229.1555444929934; Tue, 16 Apr 2019 13:02:09 -0700 (PDT) Received: from VI1PR10MB1773.EURPRD10.PROD.OUTLOOK.COM ([40.101.76.245]) by smtp.gmail.com with ESMTPSA id c18sm9676876ejo.35.2019.04.16.13.02.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 13:02:08 -0700 (PDT) From: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Robin MARX , IETF QUIC WG Subject: Re: QUIC logging and tooling : moving towards qlog Thread-Topic: QUIC logging and tooling : moving towards qlog Thread-Index: AWcyV1lkV7s2tMkEzF0cgz+ld2Wo7NuEbyIc X-MS-Exchange-MessageSentRepresentingType: 1 Date: Tue, 16 Apr 2019 20:02:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-Hashtags: #NewslettersPlus 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_VI1PR10MB1773F50DF40CCEC2499B02C4AC240VI1PR10MB1773EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 20:02:16 -0000 --_000_VI1PR10MB1773F50DF40CCEC2499B02C4AC240VI1PR10MB1773EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I haven=92t studied qlog yet, but if you settle on a protobuf derivef JSON = format, it would be good to make it FlatBuffers compatible as well. I=92d b= e happy to help with that. ________________________________ Fra: QUIC p=E5 vegne af Robin MARX Sendt: tirsdag, april 16, 2019 12:51 PM Til: IETF QUIC WG Emne: QUIC logging and tooling : moving towards qlog Hello everyone, In Prague, there were three separate presentations focusing on logging and = tooling for QUIC and HTTP/3 (video: https://www..youtube.com/watch?v=3DLiNL= z1QuT0s&feature=3Dyoutu.be&t=3D3190, slides: https://datatracker.ietf.org/= meeting/104/session/tsvarea). There seemed to be a lot of interest in moving this forward. The currently = agreed upon approach is to focus on creating a single logging format and sc= hema. This will make the creation of reusable tools easier. As a basis for = this, the qlog proposal was chosen. Per recommendation of Brian Trammell, we have created two I-Ds for this: 1) The high-level schema: this is (semi-) protocol agnostic and could event= ually lead to a BOF for a more general wg on this topic. For now, we focus = on the QUIC/H3 use case. 2) The concrete QUIC and HTTP/3 event definitions: event semantics for thes= e protocols. These documents and examples can be found at: https://github.com/quiclog/in= ternet-drafts We welcome new collaborators and co-authors for these drafts. There are also several issues in the Github repo that could use some insigh= tful comments. In the quicdev slack, there is also a #qlog channel. ---------------------------------------------------------------------------= ------------------------------------ Even though qlog will be the basis for the "standard" format, several imple= menters have started logging in the quic-trace format as well (https://gith= ub.com/google/quic-trace). To help the transition and show that qlog is/should become general enough t= o support the use cases from other formats, we have written a small quic-tr= ace to qlog converter webpage: https://quic.edm.uhasselt.be/qtr-to-qlog/ This tool ingests the binary .qtr quic-trace protobuf files and converts th= em to json-based qlog. It also includes a rudimentary version of the quic-trace visualization/tool= , as a simple example of how to ingest and process qlog in web-based tools. In time, Victor Vasiliev also plans to add qlog support to the quic-trace t= ool. Jari and Marcus of the spindump tool also plan to add qlog support, as= will Maxime Piraux for quic-tracker. Finally, Dmitri and Stephen from Lite= speed already integrated basic qlog support in lsquic, which can be seen li= ve at https://http3check.net/. We doubt Wireshark will add qlog output dire= ctly, but we also wrote a pcap-to-qlog converter for an early version of ql= og. We expect most implementers will not log qlog/json directly, but write auto= mated transformers from their (binary) formats into qlog. The qtr-to-qlog a= nd pcap-to-qlog examples shows that this is a perfectly valid approach as w= ell. ---------------------------------------------------------------------------= ----------------------------------------- At this moment in time, the original qlog tools (see https://quic.edm.uhass= elt.be) are not yet compatible with the new qlog format. This is something = we will be working on in the next few weeks. We welcome any and all feedback and ideas for tools and logging amenities. With best regards, Robin -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 [https://www.uhasselt.be/images/nieuwsbrief/dcm/UHasselt-liggend.jpg] --_000_VI1PR10MB1773F50DF40CCEC2499B02C4AC240VI1PR10MB1773EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I haven=92t studied qlog yet, but if you set= tle on a protobuf derivef JSON format, it would be good to make it FlatBuff= ers compatible as well. I=92d be happy to help with that.

 
Fra: QUIC= <quic-bounces@ietf.org> p=E5 vegne af Robin MARX <robin.marx@uhas= selt.be>
Sendt: tirsdag, april 16, 2019 12:51 PM
Til: IETF QUIC WG
Emne: QUIC logging and tooling : moving towards qlog
 
Hello everyone,

In Prague, there were three separate presentations focusing on logging= and tooling for QUIC and HTTP/3 (video: https://w= ww..youtube.com/watch?v=3DLiNLz1QuT0s&feature=3Dyoutu.be&t=3D3190, slides: https://datatracker.ietf.org/meeting/104/session/tsvarea).

There seemed to be a lot of interest in moving this forward. The curre= ntly agreed upon approach is to focus on creating a single logging format a= nd schema. This will make the creation of reusable tools easier. As a basis= for this, the qlog proposal was chosen. 

Per recommendation of Brian Trammell, we have created two I-Ds for thi= s:
1) The high-level schema: this is (semi-) protocol agnostic and could = eventually lead to a BOF for a more general wg on this topic. For now, we f= ocus on the QUIC/H3 use case.
2) The concrete QUIC and HTTP/3 event definitions: event semantics for= these protocols. 

These documents and examples can be found at: https://github.com/quiclog/internet-dra= fts

We welcome new collaborators and co-authors for these drafts.
There are also several issues in the Github repo that could use some i= nsightful comments.
In the quicdev slack, there is also a #qlog channel. 

----------------------------------------------------------------------= -----------------------------------------

Even though qlog will be the basis for the "standard" format= , several implementers have started logging in the quic-trace format as wel= l (https://github.com/goog= le/quic-trace). 

To help the transition and show that qlog is/should become general eno= ugh to support the use cases from other formats, we have written a small qu= ic-trace to qlog converter webpage:


This tool ingests the binary .qtr quic-trace protobuf files and conver= ts them to json-based qlog. 
It also includes a rudimentary version of the quic-trace visualization/tool= , as a simple example of how to ingest and process qlog in web-based tools.=  

In time, Victor Vasiliev also plans to add qlog support to the qu= ic-trace tool. Jari and Marcus of the spindump tool also plan to add qlog s= upport, as will Maxime Piraux for quic-tracker. Finally, Dmitri and Stephen= from Litespeed already integrated basic qlog support in lsquic, which can be seen live at https://http3check.net/. We doubt Wireshark will add q= log output directly, but we also wrote a pcap-to-qlog converter for an earl= y version of qlog. 

We expect most implementers will not log qlog/json directly, but write= automated transformers from their (binary) formats into qlog. The qtr-to-q= log and pcap-to-qlog examples shows that this is a perfectly valid approach= as well. 

----------------------------------------------------------------------= ----------------------------------------------

At this moment in time, the original qlog tools (see https://quic.edm.uhasselt.be) are not yet compatible with the new qlog = format. This is something we will be working on in the next few weeks. = ;

We welcome any and all feedback and ideas for tools and logging amenit= ies. 

With best regards,
Robin

--

Robin Marx
PhD researcher - web pe= rformance
Expertise centre for Di= gital Media
 
T +32(0)11 26 84 79 - GSM +32(0= )497 72 86 94
 
www.uhasselt.be
Universiteit Hasselt - = Campus Diepenbeek
Agoralaan Gebouw D - B-= 3590 Diepenbeek
Kantoor EDM-2.05
 
3D""
--_000_VI1PR10MB1773F50DF40CCEC2499B02C4AC240VI1PR10MB1773EURP_-- From nobody Wed Apr 17 08:42:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3DA120135 for ; Wed, 17 Apr 2019 08:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 t1EXInkJy0Ah for ; Wed, 17 Apr 2019 08:42:41 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E5512037C for ; Wed, 17 Apr 2019 08:42:40 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id k17so27891790wrx.10 for ; Wed, 17 Apr 2019 08:42:40 -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=vSmeHPm1wKpMe3oloYmybZsS8+utgmLVWK8J5MgJ0vs=; b=V+bl9tkyVlZ1QNLkTlMrJ+e9UvLzCLDXyqMFA/afJ+PkZR2CPMmXHVIaflcT6ZBgoX tH7RZb6mgBKdJhw1eLBBr7gDO5NBGY6V3bGi/S0TQAyi0pJyVRlmZ7TQRbmyWJwt+xlv wofrWseINC9VutpzleN3fajTgKGXJvlEknDHSZiHlPb2ZOMN/QHiu302RXu1hFrOGCCu 3IZXAWefdTuCrqYaC6b0LeIUWalKBqL4YpvbuA0NlZEDwpegjRSmyEOB7BkESJRh4DQ6 /iISDPy05eccAaDCZoooDOrBgPKAg4FhDsASSt0ypOEF0+v5SwcSTE5htLXEcBmMx2wF UuDw== 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=vSmeHPm1wKpMe3oloYmybZsS8+utgmLVWK8J5MgJ0vs=; b=B6CDWtV+D2Un8Q2PdECtEzvGYWvER9fRJABPy89c++hmfatGvUCkt2SFf9/OtUqlWn M7XrQ/CFHVcM8lUMjsEqiEcECi0Sop1K16JzEfV59XmkHGsRj1m02VlonXBzUgXVEToY 8fXNbmqaXv7rHc5LUJH/+Q2BKJxIk2f8Dv3Ypwazq4IZvlA4zbdz2MkMyputpmVtLd0g gPESi+003Y+J0idy/zO1229QVUa0MNY62qTLPxoADbgAgG1fg8Mw2n3ydojD2lOpPgkt LK+gcdcNpvOzV7rF0GuNDoKvOPSP+tkiD56LV0SRFq2RVxW1Y+tjkjBmTAtEIC4Hzhyh TZbA== X-Gm-Message-State: APjAAAUFodTQ7JQ6LWp1UeKAI7JxtBhMbIKb0yxR4NyEokOc30f8hHxh 5/Cs5eLtFqhquX3BnU0EoGT+0HMEaRjLB7l6/5DgPIY/iZE= X-Google-Smtp-Source: APXvYqw5KXETA+YSmmuZEYYSLcG3yM86qG8Umx1VG3Rj/8uL5p4a63NQMfbYOeIOo872Kh3URJrrVdznqRKQGQZbJok= X-Received: by 2002:adf:eb87:: with SMTP id t7mr3555232wrn.39.1555515753397; Wed, 17 Apr 2019 08:42:33 -0700 (PDT) MIME-Version: 1.0 From: Ian Swett Date: Wed, 17 Apr 2019 11:42:20 -0400 Message-ID: Subject: Some notes about WebRTC and QUIC To: IETF QUIC WG Content-Type: multipart/mixed; boundary="000000000000ed2f1f0586bbbbc8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 15:42:43 -0000 --000000000000ed2f1f0586bbbbc8 Content-Type: multipart/alternative; boundary="000000000000ed2f1c0586bbbbc6" --000000000000ed2f1c0586bbbbc6 Content-Type: text/plain; charset="UTF-8" When in Prague, I organized a small WebRTC over QUIC lunch to discuss what it might look like and what the goals are. Attached are some notes from the conversation. Thanks, Ian --000000000000ed2f1c0586bbbbc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When in Prague, I organized a small WebRTC over QUIC lunch= to discuss what it might look like and what the goals are.

<= div>Attached are some notes from the conversation.

Thanks, Ian

--000000000000ed2f1c0586bbbbc6-- --000000000000ed2f1f0586bbbbc8 Content-Type: application/pdf; name="WebRTC over QUIC lunch notes.pdf" Content-Disposition: attachment; filename="WebRTC over QUIC lunch notes.pdf" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_juld4alq0 JVBERi0xLjUKJb/3ov4KNCAwIG9iago8PCAvTGluZWFyaXplZCAxIC9MIDQ0NDI5IC9IIFsgNzIy IDE0MyBdIC9PIDggL0UgNDAwNTggL04gMiAvVCA0NDE0MyA+PgplbmRvYmoKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKNSAwIG9iago8PCAv VHlwZSAvWFJlZiAvTGVuZ3RoIDU4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9EZWNvZGVQYXJtcyA8 PCAvQ29sdW1ucyA0IC9QcmVkaWN0b3IgMTIgPj4gL1cgWyAxIDIgMSBdIC9JbmRleCBbIDQgMjAg XSAvSW5mbyAxNSAwIFIgL1Jvb3QgNiAwIFIgL1NpemUgMjQgL1ByZXYgNDQxNDQgICAgICAgICAg ICAgICAgIC9JRCBbPDNkMmI4ZThiNDliZmZkMjcyYjNhNjJmNmY3OWMxNmVmPjwzZDJiOGU4YjQ5 YmZmZDI3MmIzYTYyZjZmNzljMTZlZj5dID4+CnN0cmVhbQp4nGNiZOBnYGJgOAkkmE6AWEZAgrEf RLwGEgJWQEJyOoirDiQy60HqOhmYGNMPgRQzMBJBAADbVAdBCmVuZHN0cmVhbQplbmRvYmoKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKNiAwIG9iago8PCAv UGFnZXMgMTkgMCBSIC9UeXBlIC9DYXRhbG9nID4+CmVuZG9iago3IDAgb2JqCjw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9TIDQ4IC9MZW5ndGggNjYgPj4Kc3RyZWFtCnicY2BgYAKiSwzMDAz83xgE GKAAzGYCiTKwLOhUZmAwmM4AopAAOxQzMLxm4GdgsLXZm8B8VqhBvVGxgQEAjUILFQplbmRzdHJl YW0KZW5kb2JqCjggMCBvYmoKPDwgL0NvbnRlbnRzIDkgMCBSIC9NZWRpYUJveCBbIDAgMCA2MTIg NzkyIF0gL1BhcmVudCAxOSAwIFIgL1Jlc291cmNlcyA8PCAvRXh0R1N0YXRlIDw8IC9HMyAxNiAw IFIgPj4gL0ZvbnQgPDwgL0Y0IDE3IDAgUiAvRjUgMTggMCBSID4+IC9Qcm9jU2V0cyBbIC9QREYg L1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSA+PiAvU3RydWN0UGFyZW50cyAwIC9UeXBl IC9QYWdlID4+CmVuZG9iago5IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg NDA4MiA+PgpzdHJlYW0KeJztnd2O47gRhe/7KXwdYLXiryQgCDDdM73XCRrIAySZBQJsgGzeH4hs yxbZ1ueukih6JpkMkN21RiJZJIunqk4VzaEd//xkxv/rBnv4229P/346/hKNPf3w+z+e/vqHw7/G X5sunP7u5Z/jXzWH45+//HI4/8vvvz79/Is7/Pqf0xd6Ew+mDfH4ia93frHG2PMvfx7/pK2bxobt HQg7fHyIp68PsV378elTz29PP7/6g/NNjIe3r09mno728Pbb09jQT8YOh7e/H/7Ytu7Tnw5v/3xy tulMa+3xr5x+9/3pdzM0tvMmhPlBgAfu/MCGprVddH5+0J0fmMbEwZv++sBGeKN1pwdDE20fTXTX B8FC42E4P+gaZ3tjA4yjm1+YhmGa4NuuM2G5cTdOyXUc/tzd2AwhdmH+luvTcfhhHuBL8qnWGBh5 8kbWePqGfz096Jo4DMG6+Y1AAzTLv/tIkno+Pfjytt/SC61vbAzjhCYrcBpygXbN2G4Yxv/1uO6j nVo1ZzH0jQnGtN28KM15ifmm7cyQzrIJ9Mancp9y9MDTgxd4MIn1tnF/fsONwo3GD+79ilF8yl1W a9eF2PpZe0y7yzd930Yf5k95GocnIU7re+GNvs66sbZPF07V5dpfWrWeJN3B3OADTwLF+ffd/SlQ PAhxUmPvlI/5fJHqSTjhA+GYGMdxBTOEVEityT7ykYThI7TYJ2W+IFBa0ys2VKRpPm8P0zah96NC dwJRq1dG+0oPUCYB+us/k5Kxc3fbIVkBmcro4rJayt7IejXMR6Vrz7KyjW37zrc3oOYsK5vI8DXp bfRx+UECUNIP5aNI2+5Hfb4s3FFWy8NIH7ghEa7zye56gV7B5somPBGUbC5S9b2ir57agM7i4HCO XugBTtKw3HQ2RYmccNT2FdaTX/4d5UrCoCVue9p3n2DM2flqQX2IugqLSb++s0GkayZr2wQrmGqJ /LK2v0j21mjTLCtzC6hJIFjR2kgHnQjWtvbWUFnYjC/z4ELnEs1voW3qKy0OpSx4GobphdGmiS7C mZr2KMDvqB1oCB0t19c6+K4bbaFgzrbQe/BRBVyOi+kyCx2CC4Q2oELRuEAMqcdCtNknA3YBjaot Hh73Z+W4V2Aq0u0Ztui6VmJV6aU+eVhM40c83badsnkZpsM39EcwTEiX2sUSNUsHJGvZTFKJnwjh 1gcqR3N00jJUn+YEAbWqH7uaLUHB2cJjJltDD2MJbk0ztLv69bFtxq66PtXC5XS/NY1zqPbDpcHJ 9WvHvrhxdyf7+fmyso/e1+H2PFh4MokuNOMERO9uPJq3D+58K0zTY1rr3e2aWXgFWwkOx4IfCxaf 8Ncue7hzvXfuxhWy8MpzTF7xqaKIl/M4Rt/GWzx7HqbtE7z0ST8YngAcDPfMYjNZn8OQANvnZJrN jYNyoXUjaiOVC7/CcsEO35l92Vo2N06Y20Zw9B5lH3CJ8apUd5ilwrsFPjUdCbo9Sd162V1rhmCb s8AT5VkVqffussvIDYx4jlFbZgxmGBed9+Rq5FgDHbTYNiFykbsow/YSZ9g2vzg7UhHb0/xhJAW9 zixzNAZSibTDTSx0wfWKyIqEq/VjXXXa0fIMCWr4MrUcwtBa8/Hv0ACbJuRVJrzKdsB09Lqmd84G gbcZfBjTeXi77xDt4+DIOiffE20ummbUEOC8DQ4aRpPoBVqgicYvZV4BiR9O7cPKvCf9ED9uAvsK L+TbJGui0OjUXkzyt6EG0Ic/Su0rVFbgDUX/0hf4XetiLCcjddPoKK/m9eyObyaQpiaQcu2l1RUu QVoVr/QlDI5jOF3fKWJN6NGBPlhdBcwMhGvV6JVdnldb6L3LcyJ2LTjGcSSMaAgCdfBCsdODPJvs CqWW2ZaIdTaxc0MTfOz7dC/X0iDGjv91dEedmzVtpWa9T5vFXYdLcuLWKHZdFs3PQi8Y3tFaWwX3 r74N/pQ6tITqVGJEi+gsadu5pULRcJEVxlCrB2yTNw5gy10Ot/cRXb22IahKS81BV1dQjtAs0UY5 RETIXLADNFEtODEug3gOTsxapypK81ddh/QyxFaExlhzoduHjGi1F2xHgNHd+q01jF+JopCRSlFB qqXFYBdn6nl5GDL/XKpqkT2FVDKl3azXgoj2UPsTyUfLo2T7Va3Utujy7O/T2PZnq2HT1NW9h0Ck LVySuGBwnl+UOIK/BIPm85R8OeT7QWYgEsO0fl71Vs8o26nTjkdNSkC5xlZwZQn4VlVLEtWQeclT DSraWBmxEmcaaUsw1ZMpuKDVleQXUZQrmzey7a+pEDv780x/iY3OsK0qWIxuSaYSeFAwdFjBcacP maqTcGRBl6xTnJaCIlFDyG8KV8t0nTaGdIdbSRE1Oo1A45hKCsGNY4jhrBDiQxTCBrJEhjpkW6lg +p3e8cW7D91SEki3k3NNhDFEEuEH6uHxxpOEb2T+OAJReltD4JLYmsiV6dQ0+z1TqeEmyV3B7ZDY m+AA3SWCP1UuWEDq6M3kEJeto+q8Nc1pDSQKr2ogxLcPCYTMzeazlmq/bNbSjCmctRUqdgV9DvgD IjqALFpK5xfGovUUNhl+A1tHFvAQQJ5cy5HiEKlFUa4xf4ocTOpojjZRFlsQxLCwZZEjSe0lVfta 1Ccm85HoKFWHeNS2OcqPPqTNiNF79Hhw6KzScga5txIyoZHwvNQ+KfrQg22l0PUj7HTGpcdaTVvJ X+N7jqkd6lDbCjcJlb3hcJ7a2aNmYzHv6VkPPNSIhGsHUeGigpSvFWmj2xgE2YMVcFxvayAnYJOJ lWKJcodbuZOHikBos+f1Sl7r/dfykSUu2xJxiv0Nu25oYmeOFLdZPVc9FGb6xYq6AKj7RVkp2yhX mKej9pDz2aZmTNTwkLMtWtDuU2eFBcJpeCKQ4YfxOK2lqE7yL+djomoWeHTpfU8igzrTdYz6iEyn L7Qi8rDK2CJa5vN3qP2jb6zpjykS/iHxVH8N2mAtyjWON3pQI3NUr/3LxX/VvWWBaKO5K45iDH+p WZUiIjVqCUnNvg+UxP6BztY27eBOO/UhgU5/9ftztJvXPtJhKeFGT6DVW5HlNj3yKwpuoxqbvpwW xDiupDTQgrG4f93d8Sg8Frpw6VKvucHC1SfH3BCcCFayepeWMju7Shoh5uWpKz+vCMGrrbAaLjC9 gYRJI2ggKWumav1A7IEioilmsWzIod4UX9tCnZAl7mAYTRmu0BOQlT40PU1bEsKVtcDhJLS89Alz +nT5UrGsO+PbVGI6fVBhFIJdXbUwQjm38jqjAV3vu+ONGE3jhhPYCQ8JBYYdfM136xCG7j26Cs1o 9/kh9e+tKETIJc/0Ffq4ehzX27vztWJrCQVrR6O0O0eUZ/nWXEbHvfOAVq1/t5Y0fC3Gn+gP0SPs Gpj8h/WsF8g2x7O+chrdKIG++2H594J3N1QvYJUWOSlFStu/gBVVZ9s4Eylj+pkmgmNB6iBRRixJ Gs94JSnG11ZiU9MJ1QX39Pe7UBreB4z9/RlgoRuH1x/P6/kMq0rjjv7SbFUa99zsmhP7x7lVx+uL fkvRvTzaEghqojP1CHe10k7lExPrMbLrjthu5e600dPgS2nkgnn/2lwfXMeI6vUc8mKEYy0jXF+A QUkt1ybf6xnn/IbSIfujaMKGeavFaI++bc4x8fmAr+oIiJdWV1xNqj/Z9Z/SwwpB7WchA7MGcimY QK2/8VJfwZ05/jLq6/djEwsTtYpZxepSUGrQ8cNaXmEti/iX36y57AffuHAqTThr+rrmcv8Yc/na LNYvQUU6XTNUgMuuLoHNmlpd8mENwV5/XQmRPvRHJEtdW5QwHyAUiN7mxpY5JJOmswvstxBI9DdJ aMvn4YfIWqb7h5Ulu2TshLRh8hBgMLtklq+a4aH1tytds2oTFxfGivwDNT9mZSLe/v5l5y8ZxvMR UtMg667xYK5bjg7g7JJmWbkOylmQuTVlBYO3OGuyTN60aqDorNMf/kVrR5XCCzXsZnWxKW1gFsuy UjhQX2ZX4LSTmXXUdIViTxkOch+rcTb3ZPoj7atIfVCsXVbwGI8QQe6jqCDo3h7jgjUM1cgMC6lp I0dJn2ybppeVC0zoq5QIyN27VIVJN0roHBVJSNFfulOyV3apUIdT2t1S/+Q4shTLmpXA/fVd4eqs 2Az2VBhgRlVVsdyVocCFV7lajL7II575Dw5yGD/2ycdTkm73GNZG9xjWxtwsI1Ht/Wkr0ma0ALVK eeZH3ozBZR5E3Fb94Su6kRMpkEBp/I6yj/ThEEEheJGQ2Omnj+mo/Ufo9lNHPeBDeLqvPJTXXr+1 SwkQYRmOlNCYPelbs96fpi5OrCa3yCw35+e5yAGp7efJyEy39JUVwt2lTiFWoWmdxI9YilFSKxc7 hr7p/YnY0VUndpwRT3wM4om7ZJbceaInvWKtKvIFqOsK1wA3jOoEPC5RisU3wuOSXUOPJycVkcbi yHRCYixIn0da7O51fWKompCYOSRlN0XpM3S14y7GhaTTvxRpqQIFuBSHVe/5oQa2+LQygvvHztl3 7ktlrJNlyjgytSei/VCqekoyg9uPI+e5ONbGhPeHR91wCbN29XlJJ5xyje6Wu9n+f8Uzwz4Q7C4V kRZV+9lSMQF9JtpYiSiZIQcKkp0tiltqtZOha/UI4emrOquTYg3MqAE0in29A/XVlqk+Q0GZ8cS+ om1qn3ZdvpS1ZUTUOHXv7Bhax7XuE/BDM4UlqpN9TkZ63z7ESJ+b1V/5pj+ZRDVzN5Z801vJSF3l BwWTVLZlkKxAqlsOLlHoQ2aMU5fohefL7/J0RXVtNyrbWCxYIsEom0owoLUKE/3sJaf7/8vN5qWq fbG/m0xG3Lr6E1kfKllxA7hk4LVpRruX5kOwI7klWRJYWeEdfTBLOvYZdqlquPdXAkl1O1V0C4fg EBDCDfVdG+pLbGvhbDvi7OF86Xlfnf9zZGL11xgc1+JXV7fnFxD2SRyjsuuj6H6AFTC8QqH8FTZA rUKS1tmmt6eKQv1jIrX9YyK1c7P2Wpvxhp2IdgqqM3I33slakV0kLyPNqVPdOYVRm71htMaNNqNO uIUloFp9MQwHJQAl62H1BhJ7LlaMcz+sTK++8DLwvcqlNiLdXo3AtRfGapG5nkip5rJ9QBdSRLJX gHkRZS21G8tVfdZee1hMzZSq37O7KGSejyxoff8aEI29XaognK0U1u3aEUudy030jyk30T+m3MTc LGfdUQKA+QwPGPxnd8fGDnKrtlHkCyKpFRS2Tbd95f5GMPmLFf/Tu+TKcdsoyC1zRUro8xsxTZrx CpmwIk+xTBzqOlDqgPL+1HY6kssVEiwHdrQBDPVWISCC8lYDbdvP+jrL5JSx17fVH2VGqfKaDoYQ ak7f7pSJGkVRHwb+WEqlDLpHcybi0DXmfN12X5I0Ma5+07tD1x7M8e9/PX3pv7O8481lbmRzdHJl YW0KZW5kb2JqCjEwIDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgxIDE2Nzgw IC9MZW5ndGggNjIwNyA+PgpzdHJlYW0KeJztWgl0XNV5/t+9M5IsjYxsnCAsg648eJcl44XYwoBs LUheZUt2JMMhepp50jwYzQyzSLYKjoBAjFjiuGxJSOpQUvbkmZDWoZQ6LU0ICUlKKFDq5BiSEgqG BiIbbI08/e59b0ajxWxpctpzPOP/vf/999+Xe98cmTQiKqB+4rTI161HUv8y+HuiyS8RuZivJy7K 6mbGiM78ApFGnZGu7l/d+K0HiaYeJHInuoI7Or8tvo7nuXOhZXXA0P2/3rbz74E/ATgvAEL+v+dB Fw0Czgl0x7e/8PS1P4Cu5USFe4Nhn0506BdE06G/8N5ufXvEPTcnhfVi8IuQ3m2cYT3ZDf1B+CAi USNy47bnjhMVt4CnkqTv7tc636yj7Z87beURKskj+dn3A+Pv5P0nG94sGNxwrL/w6UnT8DiJmJKQ oVCu/1i/dunkvMENw78rfNqhZz48ICm4PkJ59BXKh2QRVdNmiNa7E+Qm5iLkDB/Wb4O2mdpYBVXz G2gGf5gW86fA/zRN0Z6jakA5z6coL6eoFqImto0u0wLUxItouqsY64OUzy1awx+nFtdSauGXUxX/ Ge5n03n8CdyfoRbJr2Ruo2r2BHTdRhewB6nafQe1sHNgF7rknd0NHNnlM2D/DTqffxrPg4AkfALd fSH8fRp8EnbRRcrnl+FDO7nd+6Hvt4AbaFXOUXWvzq2n6vz5VJ2Th+d8wEo6V9LTkLOIprkCuBNt lfe8UGZtkgO2/Ou0Cvh5kidbfgKoA5ADiiZ1Sh1K9ik6T9Jcb9hrjj7Fn/s8YgsO3UV0fEACO5oS 7vqUYNembne1pG4nGtJtOH4T7tdL0N5PHiAaXkd0ol/SPf2w12/rde2GbsTP7wX+OvBL6UKXpXJZ 7faAtgc5rD3+DusY/hlrHd6lHUj+nrWfmMpm4Lln+LB26/HHid4vtyF5Nex4AIeBv4G7H7D/5PQh zFgSvX/0oWycvZsq4ZSaz95Inc6eP5F0V6dK3E2p+e6q1DT3zBNJdk9qMW9JzebLU/nuB1Oz3bem 8rUnU1/k81O72DPJl13Hky/zQ6mqnKWpKsT7MHRj3ofgw9EKejyJWUw24PkBovd+RHRsMt2QvJu2 J2+lpmQn1v4W9Hsg1wd8kR3X/4aOoTdGw/HFo+G9PaNB1i8NR46NhqE7RsP7542GocXZoJ2dnKzV Jsu0Dcn52j3Jr/NpJ7j2aPJLLCd5hHYPdWv1yZmw8552ebINdWlkLcMrWfnw6dqe5OnaAOLZPZSg 40M7MnrOSU77SHrWDZ/PzrH1IA8ZPWz18EZWO7xJ+0XyIJ95opKJ4YXsq8P3aU8kC9ilQ3O1E8MF 2gvHu9nbw0Ps0PBb2qHkfek5Uz07MoNq/jJz88HzVj3RrI2ZMcWLGVOznrYhecfoo7Sek6wr4E+l 0CdDPwf8I+LH+SDnNvkpfjwVlSBxm6boZPNIWgYasp9dQcjtTe1U8Fxqj4KO1Ncw+9vQg8V2v8ne OboVeJGtV9KGXoD8I7wI/NembmLHUzvxfBoPpXZJHtvP5FOo2XdwR98O5/DDqcskSBy0+xw4avNI 2nhwtUKmP3W3gt2wJUGHf3en/urk/iVt34ohsz11jePb/fDzbtz3TuibBTvWR/FN5u8k/t0A325w 8vdH+HdyuYnpvCe1B/ttMfZ4ue+CZ+hFwH9CF2Ym+Ur67r4hdSIbclrpcgkFl1FR/nNU5D6Ic6sB OvZjBrIhfWbdhfV3qboQZ6RnIKsvd2MWJKxU51y1+59Gg+xpCbCzDHaWFU535BntluAapMskuKOg AfJqMUuw5brWBneV0itniMb57PiY8SnL/mS81uR9g4rzk8jNyNlY+lHO3dzHPta5O4o26tx9Cefu wCfeE2yQtX1e4nbd2M3pczm5Aj1w0K73e3hfPIpz88iv8dq4wb6nz4T03p/e5+393J1LODNTswAH XSXU4Ho7lXK9TXe6t1Ab4E6Ju67D8wH7mU2m7/BHaamiz6A7c+YqXrWu5A5k5LZAbr6D5+ccp2Lc 8xRcR172PfoO5BsB10DfatwVQP9pDn6N9m0JqSexrnDYukbS0+uKP6HkV0BO4Pkq4NNhMw/3yRIH zGZ4I3BhV2TL6XuIcSUvoy/jvkYC+zGtytXpDNfvaAveCdtyOxDH9eTVWmmDBOhXwJfQ9eww+qGA KpS9B2knYlot9cuYWCHdD30mYCFsrYMvGptG/4Dnjexh2uCOwP4gzcfaLcj5U26i/5A0nkodkbpd D1EUOqcDhJOba/j7qRTbSr2gXQ+4gr2pdN+SM5/iDlSC7xK7ZuMBsZCso6pVFiBXmwGXssmp3wJS 4NHSNZwA1qi1LHDqKPviGqeG4yBnDzVm1zUNqOc7qGUY98cAz2TX8iRwVTbImjo9M51v1fa6XtOw V56Qe+eavB7E1k8v8aP0y5zVdADwImbvXu0xCvGt9BrgffxGuBn7zR/YIrqRN9AA7vfi+W7XU7QK 6w+67qDHAI8CooADgGcALwC+BXhA8ktZ6P2xm2lytn8F+iO5h+l5foAsqQv3F1x30Ws4F5K4r+an aZ/B/cfgvT13GlmSnlucSmZ0wR8btDmyz2VPsk+TX2s40Ye6L8nRaZWrkFayVjqI30d+92OAKDXl 1NBjOT8H4A0xa58eC+PfH46nanDOuVxz0H+XYD919nScy1WSJn+aOb/qpuG3LTBtOiCHMj/1NMYk z+iP/NVH/18+n9BTF3sd13b8PnSToM/TXnqBUtq5WrOma9u1ndoe9iP2MjvIn5i0eZLh4R6Pp8gz 17PEs8JT62nwrPds9bR5fJ6w5/OiUBSJaWK6OFvMFLPFIlElakVc3C8eLps5c+rMM2f9NIXf8rCx l75JL8LCZq0dFq6GhR86FjZN8ns0j9sz2TPVM9+zzHOBp96zxrPF0+pp93R6tosCWDhdFIsZQigL Kya0QNilCN2Gj7YSUAgknHouVXjsn499e/DcwUWDlYMVgwsH8UtjcM7g7MHSwZ8Am3r034h+M/U3 C+20/ObMV+O45rz64quhV9555ZZXlhy67eCd6Ih27WzonAG4XAvi6sBEH+y2aewydW23r5ofv90l FpiojPwMXszPZJ18Oi/hM/hZ/GxeygUv4zO5l5/DZ/HZfA6fy+fx+XwBL+cLeQWv5Iv4uXwxX8KX 8mWsiwWYyS5nV7Ag62YhFmYRdiWLshiLswTrYb1sO9vB+thfsKvY1Wwn+zzr5+fxz/DlfAWvYtew a9l17AvsenYD+yLbxW5kA+wmdjO7hd3KvsR2sy+zPewv2W3sdnYHu5Pdxb7Cvsq+xs/nK/kF/EJ2 N/yvZ2+yw+wt9jb7b/Z79g57l/2BDbIj7Ch7j73PjrHjbIgl2TA7wVKcuMYZ59zF3TyH5/I8PonX 8nxewD28kE/mp/EiPoXdxx5l32IWu599l/01b+DrqJO6KEAmXU5XUJB6cKI0sxYMsZ8Z7AH2IPsG e4g9zPayb7J72CPsb9g+ouqqTU0bN6xft3ZNY8PF9XW1NatXVV904QUrz69asfwz5y2rrFhYPnf2 rHO8M0uLp00pOq2wIH9SXm6O28WZRuV13vp2Yc1ut1yzvQ0NC+WzVwdBzyK0WwKk+tE8lmhXbGI0 ZzU4O8dwVtuc1RlOrUispJULy0WdV1jP1nrFfm3bplbgt9R624T1lsLXK9w1Wz0U4qGsDBKirjhQ KyytXdRZ9T2Bgbr2WujbV5Bf460x8heW0778AqAFwKy53sg+be6FmkLY3LqqfYzyCqVZi8+q0/1W 06bWutqSsrI2RaMapcvKqbFylS5hSp/pJrGv/MDAzfuLqKN9gcfv9euXtlpch9AArxsY+KI1ZYE1 z1trzev7bTFCNqxyb22dtcALZWs3ZwxolntWkVcMHCE4733r8GiK7lByZhUdIYnKEDNpwnoaJ/gG DxFfWZn05ab91dSBB6t/U6v9LKij5FGqrlzQZrF2uXIgvfKpLXKlP72SEW/3lslS1bU7/3oCxVZ/ h1hYjuyrf7PwD+vC4rPbO3wBedeNAW9trZ23llaruhZIte7EWrdvUSX49XYEYco0bGq1Kr0Ra5p3 tc0AgpA1MJtblYgjZk2rsajd50hZlXW10i9RN9BeazsodXk3tX6flqQO7VsqSr67hJZSm/TD+nQN ijK7bqDV32mVtpf40Z+dorWkzKpuQ/ravK1Gm6ySt8iadwjmypRFJYXYxnCnmWXkubPyRCsr4W2y WiCIely8q1dioQjlUo+yoqtXilathNJssOJwSGyUHjzwWTUNcolL0ZqGkrK2MvvzAS6VOD65Z1l5 WbqKQMj4ZNs5qWs2t3RonqgzarMcHKXU7TjoaJvYTyZz4RiGRJ4sZ0N6ic/C5ILGoEaRZBWLhUVN otVreNu86KHqplYZm8y1qu/aZu/aTdtaVbWdLmkZ9WSvL8+sOVj6KwbyvGubBySP11kiMdBoEZqv GmO2fOpSm1qPfWpgoN4r6gfaB/T9qf4OryjyDuxbu3YgUtcunWxFwvenHr+pxKq/uc0qag9oVVK/ t9E/4G1uXYk0yMO0OjbJNa30NJcoLXQVl+a6ykqvDJxRevVVZaVmoKx0705t71Xa3oCW455d6nbN Lp3MTi/lrKy0kmmRcFmppwBoWKss0KbQtNLenrLSM4qXlFZu1yqna5VnapU9WmWxJsmGv6xUIzD7 5Z8CsIWtfvSMKdouYc3cNODdblVv3r4vX+zC7rRl+z6mrbb4jLIyzZq6lta2rLZO13BvXm2xmlZa a63cvNaa1HRJ6z5Nu7WtZO1+bXc2AbvCrv0atViuXfsZblNrtl3Sul87Uy5eX/J90jSy1rZff0ub 1XSW5V/b3Gr1n9VmLZbI7rPaKBZbsGBBTH7UHbDAJiywP8Rf5+/it+thvCftpafpfroKsF1Rrk1Z oARcP3TvPDFAgWP95McJe4gvPfEqNWmHPtkL4J/q425wN8Hrl/C2dw99gV5HDBalFOVG+tfcV3El /kv+5okE+V2fA8f99HW6n73siK8+BafgFJyCU3AKTsEpOAWn4BScglPwfwCY/P9uvJ+/TpxyaXp1 gZtPclGuRi4sXfTsRc9qlc8W/frZcxctmVI2ZVbZlLJ+TsP9jE7g522yuF/9zYFohrY18weYxUSZ /4+XiycbZ8BXODinmVTt4K4sHjcVUoeD52TR8+hTFHbwSbQQvzBtPJ/upH0OXkClWoODe6hW63Lw wpzTtYccfDItyn1S/tXINQlP/ty3HVyjyXmbHZwBb3dwTrV5IQd3ZfG4aXreow6ek0XPo/l5P3Xw SbQt76iD52sVk5ocvIAuzN/p4B7alf+Egxd6ZhfUOvhkaj/j8gfE4kWLlov1pi8ajoU746ImHI2E o3rcDIcqxKpgUETNrkA8JqJGzIj2GP6Ki/VEXO82NxtdiaAeXR8OheM7IoZo7Na7zFCXWCgcBuFw bDWiMSgTyypWLNLHsTeGfBWb9a5AIqTHA2JNOBYwxdwWyVFrRg1fPBydVy42dl+hR0VzwAj5jbR2 Myb0kNgYMUKKuzMciuMSFfEAlIf8pk/EfFEzEl/YYgQTXYkK0RiXMh16zPALuLMlZPrCfqNc+CCp m6GYaIkmDKUrnIgHzZAhDfhFQIeQYYSE34iZXSEISyuJmCGwoIstjcp0RSAej1RVVvb29lZ0OzGa dogVvnB35YcsN0XD/oQvHmtGik2fEauUftTaBqPNgXCvD25v2NjSWN9Ys6qlceMGsbFerGusqdvQ XCdWXby5rm593YYWkZ/fEkCMUnun7jNkvDIdkWg4YkTjO0S4U0xYABWoiSLLsDp2iB3hhJT1hXuM KAJOIO12YuNGtDsm1egiCD9DMgtdUcPoNpAC0QaxgN6DBHbIjEIyPsod2V+9etQQhgllUeFXFQ7u EJ3RcPd4z2Qxw12GYu2FxIi834zFo2ZHIg4TcDccMqRP0kHllc8wYhPFWpFOUEaRbCLRowcTekdQ FjRmxCcW3BIKGrGYSoyKEPGq1JiheBgqYhHDZ3ai58ZlRXRF9VBchiNldb/flJOlp8eqXJLtdlIR jHEuaHabMkgYUSwhkYjIh04TPsxdNk/0hqNXxOJqWlVfKm3h3pCIJDqCJoYJhiFp16Zb3yEQGOoa 2SGzO5LG0ZZlnho7R4LVQzvElQkjJq3IrkCCoyEnpGh6f5DcsUA4EfRjq+gxjd6ReozKh+RD2Q1E 4LfLKvkyQcMtNZC++PiGkAHqjvedE6uXrl9sYGiQYTMEgW6Vm6p8OXlyUGNy3vLz66EqLWw3tRyB REzvMjKViQQNTJ3oMWMmugKR9hodAjjMxW2FE096d7BSEisd/RWSkp+/zuwzQn0dhh+MiVAXNhSM ldiQiPfhKYaMBKC408SohUSzCRuJTnBgz0X3f9boiGFmjI9vtUn6HQkmYsI/JysfmSqiNwU6W/ij YTn//jmJuIm+sRvKsNdGlT4eRWkSRhAL5aLHSJjA+uRCLBGMA4NrqGLskzmrR3W5d8j6pavnM+8M CWweUZ+OHVgEw9hPbo12myEg/vS8m7rYoZawTyGR9lIiFi63i2eIkAwhGpZ+mWEMrzCCMqnAPoGX cA6bBUL2m31Ii+mkJR5P6EFTyE1B7mxmPG7KfGa80OGHGUSC0p6EVUPpwSAqIwX6+sIf15sPPXUg lObXY5Ht9AAJvO8swnc5sPVkko+ieOuJATopDloNsChF1FUHxQQWogqsrKIgvgJ0U/01PQ4p+WTg buDeg6sfnBdDLoFVnbrBuRnULjwH8RyFRaktjNUdsGFAvhFcOjhM0LvwvBAwWoMYo2OrshZzPBO0 DDZXICL9I2hvxN0H/s2KGoDOkIoygLU1Kg8BZXEutWR01IIio/SBT2ZlHpWDuhGar1D+CGqGlAFN flzH+m6qLOnK041KYyhLd6fyOO5gUldc6bI99av6CGjwqaxHsLoQ0gYykVAZqVCc8YydDliKqToI JztbcJVawso76bnPsamrrEipFmhPYHXEr7CKIag4jEwEUmtAWZCWDBWLUHpjqidCjuV0LAnli3Ak dOVNY1bUFaqL4rBZRZX49qpvBTI3uo7mqCpWqAi6wf/HSTepzvfDS5/q5Wani2W2ZESVmXzUjoow quodhi2fk+0NqGwLIqsH1GBOJL4RVFnxelzXKXodKM24ykm6GB1Yh+96RW0BLR/fFtV9MdUFtuVO WPCpHKbpdndElO8R5Y3kFWp+xceYgJGKms4kp6vVofTtUD2Qtitz1qOs2RVOON2e3bFx9dyt+G1v ZMWDTj5DmV7oUloMcBpOFwhqc6zJ7upxOrAj06O2zfgHZCe9f/WqiZQUQ8UVcHz0Z81wUMXXqTLY /ZFylp7MMJ6MLK29jo2J7PuVr3E1tx1qmuwoOpxqhZwoO7MyOJIrn8rQSCY/zMeKcR003iMzM4U9 uModRIc3wcyExlRsH8ei3FuCys9YVseM1NCu70jXmOo57HgRU3p9oHY6+9yH94pQFF3h6eqk7eqw 4VcVsU8GfdxpVZ7hzt6dRmrwwZkLqp3EzFTSjmRES0g9RTIrMio7D3NxRs1T/SI76QrVFyNn68h+ OeKb3F1Cas4TqkamczLZEds2s+dGVkb2lV0xe14jTqel+39sN35QzOl+alS5GV9ZWQGp/Up1bsQy saT3CruDo+rsya5SlMa+P6R1x9SeKs94P9lvFXInNuDRRPNx8v5I67On3XBq4B81rWl94yttZ2vk hPQpnR++Q6QrqI/J/cTT/UE7ocz6xerZUJ0edObGttCd1TdV4EyfeekTNZY536SeesersZazd+r0 KSB7Slf72/iZiagp1x3pHtUzprNXJJyd0EBfCYduRxcf5eHHOdO7Ya8yw1k5xv+KDI+McR3W+tRa n3on8TsaE+pqOFNpx7hBdX6fsxZzeiTgeNypJP2OTLPqPqHe5jodHTFnL5MRf1ZFHHPOGePPEmtT Jt8RtX/H1GTPOUl/jJ9F3ZmRoHO2+NUZmD7/paaEkrb3m+wdyhgld/Kpj6uelVMjOYKORLnqGgM0 06H1ZSRiaubjDs3OWtSZzj9nZnXlefq9Iz1/Y2dPnlZ/UBnRnaz6lJTfmfCw837yX4rfVL7GstZH zndTye3IkvI73eVTO+GIVELtU+WjJs9QuUpXIarOm1jm7BNODxtq9/isM5vGmD3jT5dLw9l1jEyV /WpK7W4xx3RLXHWLrnSKzJtC+p3NVOtmpj/H50J38mGqaO2Mj85JOGuH0lUHznFm3bbQh2/4T56b P/63jm1prH5dvUlt/x+QnsFnZW5kc3RyZWFtCmVuZG9iagoxMSAwIG9iago8PCAvRmlsdGVyIC9G bGF0ZURlY29kZSAvTGVuZ3RoIDIyMyA+PgpzdHJlYW0KeJxdkEFqxDAMRfc+hZYzi8FJ1iHQTilk 0Wlp2gM4tpIaGtkoziK3r+yGKVRgg/z/E9/S1/6pJ59Av3GwAyaYPDnGNWxsEUacPam6AedtOrpy 28VEpQUe9jXh0tMUVNsC6HdR18Q7nB5cGPGs9Cs7ZE8znD6vg/TDFuM3LkgJKtV14HCSSS8m3syC oAt26Z3oPu0XYf4cH3tEaEpf/6axweEajUU2NKNqK6kO2mepTiG5f/pBjZP9Mlzctbibqnos7uM9 c/l/91B2Y5Y8ZQklSI7gCe97iiFmKp8fRPlvSWVuZHN0cmVhbQplbmRvYmoKMTIgMCBvYmoKPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aDEgNDgzMjggL0xlbmd0aCAyNjkxOCA+PgpzdHJl YW0KeJzsvQd4VNXaP/qutdee3jOZzEwmUzKZSUiABBIIgUCGEqT3kiCB0KRJCQFERQnSQ7WAgEoT lSpDKIaAgshRQRGPCiogoIIdQUU8kmTmvmvPJALH7zvf/3/vfW55yPDb76p7rfWut629JwEIAKih DATIGDFh2OTRe7svB4j9DCBm2YjpU92rJn80HaClFUCW8cDk0RMeSt76O0CDMQBicPSDDz9QsOfg +wD9fgLo9v6YUcNGnsi5uQLveAjRfAwWmCYYt2H6BiJpzISpM05sKg0AkBYA5g0PThoxjMxoNwUg 0AnzmycMmzFZ+YHmaazH8cA9cdiEUW+S0bkAGysB4rWTp4ya/OPOkq8A0rFeVQt87vSfPz06//Ka ofrc3xXxCuA/m75OTuV0X+uKd2/tqh1taKnohlkltidSA7zK24R6QHsD3NoVyjS0jJbX/4gpvERM wUsejAARKBggHdoBMA2OKwCVRbvQnHoE6acwhJVCLKKzPAEeEgdAAVkAg+g2mMkhJECA7YAp2HYb 5tsireJ9sX1/xEVELmIAwh4t644YhujL89j2AO+L95jM7yPRUhikcMEkcUC4FsdbJb4DDyDWYXoT +xq2yHJgAuY3Y7/DDCCbt8E+q2TbYDWWP4/1I7BsHdICzG/E9GDslxFNK+VLwcYpQoblDfA+i6Pr TRbehOasNPwlrqUQ79kFMR/H6IW0I6IrtolB2g6xgLwDC8k74U1YjxTm4PgLeDmiQ5R2wvvMw/o8 7JeE+TmYtuM8ZEj1CA8ihe6AHGqGQ0jTcf0DI+tGvANj+Jrr14Tzj87p3xGZY9fbgWO+jvDSnPAV pMrb5nY35tyFzkImlCEdj4hH9KYnYQLrBgT5tUa8AgIHSibn0wVEazYSemCe4Dz7inthLc8jukso Ddey52GDcANaYN0jslW4jpHI7yaIm5BOf4JGMh/MQvnqgPefjViH9/xOkoeR0A/Hb4w0k12RZGg+ YgmOda2OT5w3mJ+N+9oHx6rhGoP9+yLuw30pQzzI54Pjp3Oe830nA0I52PYythnMgeVxEnDtXCZ5 H94f7+WLyuGmvyhswjZLka+XkDJELJ9DHSQ5iwLr3sb72BAyRAKiMeIKYhNiPKIl4jVECo4NOK4g ySvKDJdNST5QNsR3kIc4N0lmI2tYJ+1nRGc2Ru/Fx/HIdsD4KDz8nlxfuMziXHbX3ZvrFJeZOirJ 93gu9+QXvk4uU/UUdY/9CPfxOUg6iLJVR7ne4Zy5Pqyi/WEh0rUox3O4zPL51VHOFy5rEk9QJ6I0 97a1Zkg6glQA8EZlfU4dreNFPR0Dm/GexbLhaFM2QCc2FToJT8Jwdh06CA2gsZiBZbgebBukP0If xRHIxL3sifk1d9HVHPLTZJx4BNe5Hfl5Gl5Anpaw0zSRnSaiuD38vQjkuLidPi6l/43eDXIkUscp x+11/6vl/zugZ8TtaDO3h38QT4fDuJ6nuE7IfyQZCHcdxfIKRBkiVZFGVivGk0p5fzDI0LchJrEA tBQDkM2O4P7Eop1HXcDy/uKXcFhYCovY6fDnpAzK6GmYL4+FYXQV2jQci56BORz8/kgn3yZHd8jc 3bJUR+vk9W7KbX5UplxIZah/H0RxOYqbiN9Rjl4kkTGyuX2W/APaaMT8iLyGb9XL53F4CeniOvm8 S07H3yWfmrvl8m4q+Ra073V6ivNYVLd+bh+5jeM2kts5bmfq2t9Nb+tfTrehHHM7fBIGRfU6MYou OMevorqPdhj3e2A4LOsYfkW2N7xFMIW3yJpi+jOEGH4F1z2j3qcWhENRf9qgzpdGykFd50fFTJgQ tWebJXvzKzwj+dEB0vyUsl0wS6zGfUcbKM13Q1QHkZ847/GsGHm+FpbgOmzCAtRHLEcM5jyR9gLA yv0C94nCSuQz90VLYY5wDuMF3jcTjJK/yIOBOPfjUhn6VE55mTgQNsl+hKasP9raIzCS7xVfB58P 33vFNNAqYtFOnIYmbCu2iQUVttsg8SAAr0hywfuOx7gIeSEfAXKU2R7Yht9vo9QnAKYoPzZLvJD6 YyzC5YvzAu8pi4U+UjzxI6wX+8NA1KGN8jLYKOuPOhcLW/AeL2G//nwu2M8u+euVcD/q10K0TQvR 5oAk/4PC1cJ2XM8MtOsIoQx5tB2sYhnycLy09g4sYmMXcP0RtoGfy4hsJdphHk+shHKWBvmy8bAU y5aKaCdx3MVYNhf1NwN1dxH2d0XtNuDYi7Cc983jsQyPEbi+yAMQIyuT4gCQ5sDjFBxf+B42Cl1g IcpxW8VK5MM8aIT+gqDsORFNIpDyj0exJAKpzBChxCMY4DGpPBM+otsENcot96EH2GwYywZAU6EJ 2JgRGrF/oq7+Cc8JehjKTsBzrBKW8DyLgRQhiOvfi7ElLz8FvXg5/Qjzq2EQy8X+C2EiGwqlwm6U vU9AxR7AvcZ+4jKUkyTs/yveNwryNQwSBqBuzcf0n+EdvJ00xt7wQA7WCRpJ/W6DNNc63DVn2hX5 1gX3FOfL03fMF+daP8+6Of7N/KR18vtiP96GPQd4ZgifR/giNNSbLoXtiA30LLQXusPDZAsamOeh I7mCeD6KndBJorsRvdHHNyMzEY1ZM3gNMRvTDZG+gdgVyWPs1gzOIebhvd9EuoefCzhoO2jOKZat Q6xGvFdXdzv4WH9XfjvEeLgzvw/KOMiNcC3H3e2Rz81xvOasNfITgbK4gkM2CwbJp+P+JWO5E+95 Vx7Hacr2wbj/NJ//BHIKMiQeRhC4fY11+4HU8j/A+duom9Oob/g/Nb//HeD+zkIUSfz9GWKjMqQj ZyAR6QCkA4RpMIMD840wX1jHT4KnXwlb4GmpvH7/IuUoK3ikhNZ3l9+dv3tf/1Oe7oGXbkedHNTL w1Mwl4PlYXvE3XnFcZjLIfsH1v3j3/Pslf+AQZAqrJXmBJKM3ZWX9USfiaBJOFe71GcJR33+FOoy greV+mthKYekuwi6F8Zy1Nc3Q/uNuI2vzTlfcUypvm5/6vbl7v3B+QXYB4hB6Cs+gAykfZG2raP1 8h21F3fIfO+IvNfnuS25clebv3TiL904xX3N39/z/09A3TmBeAfx9v/dY3Erw22EgduJ8xiH5GEc eRrjk/thDkAt2pKadMTLaIf6If0Uy9B7hxogtJg2YtlopC8AVP+O6SlYfjqCMGXxsCEaV9qwbH+0 ryJ6v76R/tXvAtxCibq1K9K/ehtiHKZ/QTyG6S+Qvol0Nbb/AfvNRXo0Ul87FPPTEYcw/yPmH0QU YHoF0likDRExCBP2X8XB45F/O4f+X07//vzxP6UYs4zAebr4My+kM+8+Q/yPad1+/gd691mjbv// E73tmcFdNMIHPDN9hXFf8Pazz393xqmjuJ+h28H6h2sxptTwOJrHsjx+luLHKJXOb1Ici+MCmOso j515/MpjZx6/It2IdKFMlObTn5/z+bxAcikSHJJCgLIP5jClKgCmbM6fwfLHoNACHiezyHLyFNlI guQ8CdNC+g49Tr8QiCAISsErPC6UC0uEjcIHTMN6ssFsKHuaPcteYC+yPewg+5x9Lx4Q3xJ/EG/I NLJ4mUvWUtZHNl42QVYie1w2X7Zatlm2VbZL9r7stOxP5zznn269O9btdCe6/e7G7gx3prulO9fd xt3BPck9y73Z/Yp7h0f0xHgsnkSP39PY088zxLPSsyWRJsoS9YmmxNhEe6IrsUFiWmKnxGGJo7zU a/B6fOCjPo3P4DP7rD6HL8nX0Jfly/U96CvzzfUt9C3xPe3b6Nvhq/BV+Q75jvne853yfe77xp/r D/jb+Yv9I/wP+Md/J35n/a7ldXq9STWtdlc3r86tblPdtrpDdc/qwurHqhdXr6wO1wyvzav9NVQT rgmH+RNq2CBxbgPZRU6SW8i5t5FznwlQz7m5yLllwouMMB3rzYawFWwVW8s2sVdZJfuMfScGxYPi h+L1KOc8soCs+G85d91Z5tzg1rhj3HFuN3IuFTnX1J0T5dw45NyLyLltd3Cur+d+z4p6zhmRc7ZE Z5RzxYkjJc65/wvO9arn3ArfBt+2es6dQM59hpxrWc+5Uf5x3xGJc+Q6qybIudTqFsi5QHX76o7V A6ofqS6vXlZdUzOktg1yroxzLvw1CubKsJmeoK8L6eHz9H3UCD1K5FPkITKeTKnZgPmxXGZDaaHU UINQCiZnwiMwHR6EMdAN2tR8UXO+5sOa92ou1XxUc4q3rFlTs7pmR81G/DxdM6tmbs0TNWNrMgG+ LgL46nzkqf6leYiVX95/ae6lP7/ccukhzL2GQLt6qfzSY19Ouzju4sOXqr5ueGnZxS0XV11YdWHT hcUAF17mfS/GXSi5gJb5QsaFwIXMC0nnO57PP597Pud88/OZ5zPONzifeD7+vPk8OffzuR/PfXfu yrmveK9zb587fO6NczjKuX+ce+ncrnP559qda3su6VziOc85p/2I/Zb9S8MbGOm9IX9Z/oL8eflz 8rXyNfLV8uPynfKN8vXov76XtRHxdCqM4LpLmt/5noJ+E8Ed+euCpS4vjIT/5kfogZbm72uWIdZh RNSD9WHFSIffXsuGIB6I4L/6Yb04WJ9orsd/N4+7evpZSn066b9tqfova7rdkRXgRZgL84QhsAq+ gfmwDBbDC7AVNmOIUI5snQNPw3X4BZbCs7AQjsJ5uAbrYBv8Br/CDdgEO+BdeBt2wnAYAStgJJyA UfAOHIcP4D14H07Ct/AA/BNOwYfwKoyGn+FJ+AQ+go9RVr+HH2ERjIOxMB4moPROhA0wCUpgMkyB UpgGU1GmH4LvYAZK98PwKDyGcv4abIRZ8DiUwWz4AX6CA2QVeZZQIhBGRKiGGrKarCFryXNQCyEi I3KigDB5nrxA1pH1aIs2EiVRETXRkE3kRbgJf5DN5CXyMnmFbCFbyTaynewgO8mraLOCZDepIHvg X3CalJPFZC/ZR/aT10gl0RIdOUCqiJ4YiJGY4BJ8SWKImRwkh0gssZAl5HXyBjlMjpA3yVESR6yw C4LERuzkLXKMxBMHSSBO8g/yNvwJt+Ar+Jq4iJt4SCJ5h7xLjpMT5D3yPtrMD4iXJBEf8ZNT5EPy T/IR+Zh8ghFCMkkhDUgqXIYr5DScgYvwOZyFc3ABPoUvyDVynfyCvupX8hu5QW6SP8i/yJ/kFkkj 1aSG1JIQaYh+DCihlAqUUZHKqJwqqJKqSCOqphqqpTqqpwZqpCYaQ82kMY2lFpJOMmgctVIbtdN4 6qAJ1Eld1E2XUA9NJE1IU+olmTSJ+qifJtMU2oCm0jS6kC4SDaKRXhNmC3OEecICYZGwVFguPC2s FNYIL6DnfEnYKmwXdgq7hN3CPuGA8LrwpvAP4bhwEnX1n8Jp4XPhC+FL4YrwvXBVuCb8Qn+hv9Lf 6A36O71J/6D/on/SW7Sa1ggqQS1o0LsQXNRm9hJ7mb3CtrCtbBvbznawnehVdrEg280q0DPvZfvY fvYa+pkDrAr99CH2OnuDHWZH2JvsKHuLHWP/YG+zd9i77Dg7wd5j77OT7AN2in3I/sk+Yh+zT9hp doZ9il7qc3aWnWPn2RfsArvILrEv2Vfsa3aZXWHfsG/Zd+x79gP7kf3ErrKf2TV2nf3CfmW/sRvs d/I1ucxusj/Yv9if7Barht1QQctJFuyD/fAWno72wF44Bk/Am7AAbVFPoY/QS+gt9BcGCAOFAqGv 0A9+J9/SI+xxOARr4Cpq5kvwFMmD5aQtmU6eRH/xNHkIKslMcpX8zErYFDablQqFwiDhfmGwUMTm smnsITaPTWfz2cNsAVvIFrFytpgtYTPYM2wpW8aWo0d+UvLJz7HnMaZZh5HNaraGPcbWsw1sI3rq F4VmQnPhN4GfEWUAdS+KCcULvcvsYKXARJlcoVSpNVqd3mA0xZhjLXFWmz3ekeB0uT2J3iSfPzml QWpaw0aN0zOaNM3MatY8u0VOy1a5rdvkBdq2a98hv+N9nTp36dqte4+evXr36duv/4CBBYWD7h9c NGRo8TAYPmLkqAdGjxk7bvyDEyZOmlwypXTqtOkPzXj4kUdnPvb4rLLZT8yZO2/+goWLyhcvWbps +Yonn3r6mZWrnl29Zu1zz7+wbv2GjZte3PzSy69s2bptu7Bj56u7grsr9uzdt/+1ygNVBw+9/sbh I28efevYP95+593jJ957/+QHpz6Ef3708Senz3z62ednz53/4sLFe7HjvdjxXux4L3a8Fzveix3v xY73Ysd7seP/LHYMtG0byGvTOrdVy5wW2c2yMps2yUhv3KhhWmqDlGS/L8mb6HG7nAmOeLvNGmeJ NceYjAa9TqtRq5QKuUxkAiXQMN/bsdgd9BcHmd/bqVMjnvcOw4JhtxUUB91Y1PHONkF3sdTMfWfL ALZ84K6WgUjLQH1LYnDnQm6jhu58rzt4soPXXUkG9S7A9NIO3kJ38KqU7i6lV0hpLaY9HuzgzreO 6eAOkmJ3frDj9DHl+cUd8Ha71ar23vajVI0awm6VGpNqTAXjvJN3k7g2RErQuPyWuykotDipoN3b IT9o83bgMwgKvvxhI4O9ehfkd4j3eAobNQyS9iO8w4PgbRfUp0lNoL00TFDWPiiXhnGP5auBxe7d DY+UL6k0wPDiNM1I78hhgwuCwrBCPoYxDcftEIx75LL1ryze3NS+YMHttfFCeb51rJtny8sXuIMb ehfcXuvh18JCvAf2pb6OxeUdceglyMSufd04Gp1XWBAk83BIN18JX1VkfaO8+bykeJw7qPS2844p H1eMW2MvD0Kfhz0VdnvgQPgS2PPd5f0KvJ5gXry3cFgHx24zlPd5eI8t4LbdWdOo4W6DMcLY3Tp9 NKHR3p4YVV8npaTmPNW1Tz1nCZ+RtzMKRNA9wo0zKfDimlrwy6gWUD6iBTbDn0KCvYIjcUfGBpXt i8sNLXk57x8UfRgjlv+Otr3Ye/WnO0uGRUtkPsPvwJNcTupFDevr0sG0tGBqKhcReXvcU5xjGynf rFHD6ZXU651scCNB9kEv5O2wwpbpyH6Ph2/w4soADMdMsKx3QSTvhuHxFRBITysM0mJec6SuJrY/ rymrq6nvXuxFSd4rnfpigwp//T+9wRKTP6ZlkFj+m+pRkfqufb1dew8qcOeXF0d527XfHblIfYv6 umgqGNO+QIin0RSNF6RaFMrB9Y15pkATZD78J5OEemSlXIFSKZUQd8egobhT5Fqo8nj+h50qw9d5 L4n81S06zWDLtDvzre7I3zE9TbmAE2Z+2rXfoPJy1R11KGqRATtHCUo89CvwuNsHoT9qpg//VYaP tOAojA8GkGXteQOUv0hRNHtHw/houhB/uHQ2atgRDV15eUevu2N5cfmwynDZcK/b4C0/QI/So+WT 84vrBKcyXLU4PthxSSHyagxp2aitF/RCHFxDhBECuPCajuiJGIpYjliPkEnteMkkxCzEYcR1qSYg xFU8lRmoRLJYInvGPdhUyg6LZAcXSdk9AwsjtHvvCO3QOdKsZaRZk6xIceN2EZrcMEJNvqZlnKq0 TY+0tWDo/iGCwmS8EnoM9ISACzYIsRBEUEEWLQkIpj1J/qbrDwsMMBwQCIalrvARgVRojU3bqmiY XgMTuOjP9Gqkhl7dozM2Xd+2C/0KdiEOIwT6FX6+pF/CLHoJNUCP1zzEesRhxCnENYSMXsLPRfxc oBew1ReQjshDDEWsRxxGXEPI6Rd4NdDzXJ+kK0/nISg9j1cDPYfLOodXPT2LqbP0LE7t44rsnKYH pERaejTh8kUTcfHRhMnStJJ+VPFnA1cl/XqPO821oW0G/QSCCIqDfYI3/wTciF6IYsRkhAxTZzB1 BsoQKxAbEEGEDPucwT5nsM8JxPuIM5CBCCB6IRT0wwocppKeqvC3c7W10A/oOxCHTD1J35Xo+/Rt ib5H/yHR40idSE/QtyucLmirxnrAPgakBqTpWC/SN/ckmVzhtkZ6GNnjwms6Ig/REzEUsRwho4dp YsVIlwlvchBOKABbVsD3En0ZNikgMM4V8LdHGXPzi79la0zhZb17vZ8G/KvWYJZf/MuewhS/+Ocu wRS/+B+ZjSl+8T84HVP84h85DlP84h80FFP84u/ZD1N4qaTrXktKdmX3HE/cbfX0IeTSQ8ilh5BL DwGjD/EP/Mn43J6rSE1Fjq0NpDVIdZVVkbJDpKwPKdtEykaRssdJ2WxSlkvKhpCyNFLmIGVOUhYg ZQdJC2RFGQnsvSObE7CSshOkbCcpKyVlflLmI2VJpMxNsgOV1FPROVMi+RLZ05brFdLWbZrqcY4e 5KgHxdqDan8Yr6cQYSkXwEbuxEhjm5PTxD2peZF845ZNJ7XtRN/Cjm/hNrwFFxEMN+gtFKO38CZv 4Q30eM1DDEUcQVxDhBEybJ2IE18uXfV4TUfkIYYiZiGuIWTSdK4hKEyKTnGXNLH06KR78hx9Cz+J +PFQTyDB4DCkGToJyx1E7yQ9nWEnzQYLP+WbjAojntb2/6H91x9aULZV0mV0OSTgRqyI0uUVfya4 KsnqCv9BV9tY8iw4GUodyQE/8SFtAaVSvhk4FJxmgYNuR9q0wjEAu+kr/A1dVUTHe+13/em47Pre UUkx+Z3joOtTdyUjFa7TWLJ9v+sTxyLX8fRKBZYc8lcSJFVuqekBRwvXzhNS09lYsbbC9Tgn+12P Oe5zjXdIFaMiFUNKMRfQu/r4B7k64f06OIa7AqV4z/2uPMcQV26kVTPeZ78rA6eQFkmm4mQbOKRB vU7phv2zK8mYQEP5KnmBvKe8ubypvKHcI3fJE+TxcrPCpDAodAqNQqVQKGQKpqAKUJgrw5cCafwB sFlm4IR/Z4AAk9IGyq/8WTG3a0RBoQsEY4SutGvfdqRr8MgI6DrcHbzZ11tJVOhARW87EjR1ha79 2gVbpHWtlIf7BLPTugblve4v2E3IskIsDdKFlQS9XyUJ86J58TxUPQCEGOctjec0Zd7SwkKwWqbn WfNMbYw5HTv8zaU4ek3768d6RzohuKpr34LgtoTCYFOeCCcUdg0+zWPZA3h+vp7f4QAepZEUFhwQ 2pBf8/vwcqFNh8LCrpVkgNQO3OQXbIcS84vUTuEEN28HboUz0m5tpJ0P+2O7JE6wnVIJPqmdT6mU 2jHC2+0uTcrvsDspSWoT54ZSqU1pnPv2Nid82Mbnk9pYyuCE1OaEpYy3CbaRmjgc2MTpkJoQOzik Jg5il5oM+KtJerTJovomi6SRBPJXG0ekjfZSXRvtJWyT9j/9GdUuLY3saVU4YjA/BxR780chioOL p4+xBsuGu927RxRGDwj+4uEjxnA6bFSw0DuqQ3CEt4N7d6vBf1M9mFe38nbYDYPz+xXsHhwY1aGi VaBVvndYh8I99/XKyr5jrEX1Y2X1+pub9eI3y+Jj3Zf9N9XZvPo+PlY2Hyubj3Vf4D5pLJBkvFfB bgW0K8SwU6J7qFqF8loc7ylsZzFMbiMJbyuP9fH4Ksa/2KfGKFyDJzotglc1atuoLa9CneJVOn7Y i1ZZH2/lia8iW6JVBiw2ettB2tRppdPAmj+2Q+RfKf5g0dRpnOGRa1rpf/WDdfl4butQOhWgazC1 b9dgHsa5u+VyLC3mSwq2rCtTq/Mx3IwUNsbClrxQEOob8rJcXqZURhv++/5Pi9L2XAvK6ME9JOAk U6G0UAg6u/ajaAr6RaPqKgyXuHsoLcQFlpI0Ulp3D2naEEkDX28dpk6LpqJ8mBqlkV7YpbSOHfU/ 2AdNlVgFNoRdfAVszA9WgPC3iO84DY0Nf8frOaU/YOPKKAC2wE4yFnbCYThKrgN/sncA9gKPeDrA 8zATnoEF6MUGYcki6IMfEcufIbbwXkiHjejHNsJJbDsQHocqsBBr+HuYBfOEj7HXPNBCIrSFXjAJ lpJu4WkwGC6yOZAN3WAiTCZl4YLwsvBT4c3wEhwQ3g3XghrsMAI/J8M/i5+Fz0Mj7LES1sBF8pRy HwRwlDJs+QJMgbVCESPh0eFbOAMPPIRzYNAdTpIjNA3vPgq+JVYyU2iPd3kxHAwfw1YOKIIxsBaq SDNyH/WIg8PdwyfBgmPMwLuugQrYj59KeB3OEo14Pbw5fB1s0BA643r2wgfkiBCqnR3K44xGLjWA HKyZBG/AO/Ah8ZI36SRRIzYVA+Ij4U/ADE2gP872Fez5DfmDPo6fWcLbrGO4HeiQL09ybsM/4Eti J+mkJxlAG9BJdJ0wBRQ4YhP8jISxyO/VePcLKDX7qYaeEl5k21m1LCF0KazDHfHDc/ACvEm0uFI3 KSVPkDPka9qeDqXP0a+EZ9hW9pF8GK56CEyApbAd/iAm0oL0JveTMWQmWUCeJGvISfIh+Y62pf3o eHpNGCOUCK+zdvjpy0rZHHG+uFj2XaggdCz0z9Af4abh+dAb5WE2zn4lrMOVHYBT8Dl+LsJXRCRq osMPf+rbnzyKn8fJUrJJega9F0f5kHxFvkcP9DuppuhYqYzG86es+PHSKRhQPkOfp6fw8yH9if4p xAmJQprQTMgVCoVJOKsFwgr87BO+ZHZ2ioWRz03FVeJ6cYu4XTzK36fJn0CX/n7Ni7WptRdCEFoY WhWqCO0NfwmxuIfoLPAIlYuzH4afcbjfq1DidsHHRIO8s5NU0oZ0Q84MJeNICZmBnJxL1pKXpLm/ Sg4hlz4l13DOWuqQ5tyYNqPtaE/8DKGjaAnGXk/RvfQMvSXIBbWgF2KFVOE+oUgYJUwVHhZWCUHh feEL4SvhplCDnzBTMRdLZH6Wxu5jQ9k0to59y74VB4vviVdkKtkE2XxZpewXDGLayHvJe8uL5Mvl ++WfKIr5U1TYB6/d/qqDXBJmC/nCPlhGM5kNTywfoDwPhZFCd4qSSreQhfQxspcmiTNkrWgr0gOu 49H+Gfo2XU9v0lZCd9KV9IVx/DdV+Y/MzPhvfueyt+AqO4Rr+wDvPEOmIY/TazINVBDp96bJP4QM lia8B2eFi0TONsI5piJx5Cp9ReiFUvA6ayMWgEd4Hl4VSshjsI/mA6iqFUtQjnuQbWgX+pGm5F9C GKPeHihF2cLXMAfG08/gKurxQniWjGSjYRlkkpnwLbyMWtFAnChLlcWS43QsK6cxZC9QtpX/PjNJ IoJohrmkSFgru0Y/h2lwiqnggrADZ3+Kvip0Z9fFPmQMasBjMB9KwrPhYbGAfURGg0AGgI9dQus2 U2jKPEhnoVUZjDZtP2p3FdqBtkJ3LLGi5HRDueiPFmItflajnWAoQWNRxweiFfsA9sr60UoYLeoI Wh0A9l6oDwwKvwxrwqNhYvgpaIT2YEF4Jt5xC1yB5bCFzAs9CpPx5Pg56nY3sSM9JXYMN6Ll9HPa l666c3+R2z5ihR/w8yp0hDbiQShnn0JfyAsvCZ9G6U5BC7sGhmN8ehlX+TOO0Ek4ApmhHnR3uKMw Gdd7EXqHXwm7iArGhB+EnnAIXpKLMEyeFh3gwf8F/ITzGYec74KoABBSEZMRO3DdDjSMLRCfAcgT ARTTI1Aei0A1OQL1XgCN4d+hpRHohgPoxwAY5gMYJyL+hcceHDvmKIC5ACAW44bYFQBxPRDrAGyD IrB3QPwM4FgC4OyEZ9OzAG5s41EBJGYBJCVF4Hvmv8C7ESSXA6S8AdDgMkAa+tCGOJ9GgwEavw+Q fgQgYyRAkwBAZjvENwDNzADNUwCysawFri9nGUBLHDcXvWvruQBtcK4B5Ed7N0CHSwAdcYxOC/8f RNX/Neic9P8+dEG+d30EoFsK/9sW93AP93AP93AP93AP93AP93AP93AP93AP9/D/AVAivXAR+bf6 5dBuLyWXZfJKuiYQAyK7LIBKzi4TsClk4mUqHKJNQEnWkMZgTTPczK3N7WG4kdu9NhfyMG2owUuT DI/RY/ThhQCDGrdwpCbAv2TvZkf4u/6Zod60WPwYDNA6oErWEzCY5AqDoZJk7oH1OgXSgFG+XjcE BIPgFgRhh/GFJXyootqbVw03r+I4eTgEKSJ+aszKbp6dKZPjJ9ZAyMWVH3QfdGj2w8mtvWkkLdT7 EPkX0f18trb6w8LyVQdfD7lC7rvG16TQFANVqgwETEo+A9V6gfAZ6GG9MESvc+mobofp78eP8YIx K9mPn0xLnCXWQGtnk7S0xNbJj8w+NKj7qVBvcol8eejAqvJBH1XXnv059GtIgaMHhBH0NI5uhfmB LmqiVsWTeBVTKTX81+LkMjWhVv49ZzkwQRFn0srlMpF/81n64rNWozYzuaAgKpmoBjC4zcR8WCaC +iVZJVkZ0IovQcAYkwU222ScMe5LWvcbtZf5xhTl5qTnmuJy8B8xRignTTKgKCbbEodLkMmbZ8fJ 5JY4uT9ZJk9unu0PNF7fKYY8KZhHz2s865HWk2a07NmlxfSpTWeznctaNNjXYcTKrIbLUnXNFvbv uXBpl/7LG9v47k6Bq6wl2w9qaBFwwUQl/VMhTBTlMuVEXOWfIpmYR3tSSm2agYOkKRZ1v5F7Nddw OTcX0m+g8NxokuEzepp5jJlGT6zHSEmohCzfRpaHSq6Sp7ZwuiU0EcfZFrpA5sBJUEGPfSoU2+3I gl4BPxFyKSUqkgsqKmAGZC3kLXvCUJgEs2ADivgG9cbVuJs3im5cNuC4KLb8arhqqL2KnEGOZDbL jDVzDjTP3n+y18CmOc2FkydLFvu724bdj+O2JZV0HJ2AmtIwYJtMJwu0O+mOQ3qB2sXJ2MDGJi/l K7tcZPgG0rtfRR6XoLA088S2pQ1I5b59nEtVeFmAsxfAF7BSPtncyBR3AduA9RuYNMubRUUob1cj k6o6efKk9F2Z8Lc0ByVIgL4HQAhfqDDn0MrwhYDbnPOsQKiwXtglUGE6EDP/dUyC7VTCd0C/Q7ne ioOzPY/gnXMNN64aIrK8QGycVvSY4RiX6bS0WJJJyNYVoQKb+NMtM/9dzv7hb5lRPIL6kgD79src NoOjMny9grrVb4QvgQVhQujDlwLDmWwBXaheqD+uE5VytZXmx3SL7WJrH98vZnDsYFuf+PHy8eoR MQ/GjrcVxz9MH5JNVz+iXyBbLV9lOG49S8/IzqjP6e12JxPNTq02rlQZ8HizMpQElAYlVa5wGUuh MnwkoMNSNwRwaiuc7yyW2JSGmllUksaZxdlFikqgCFrwH4KIMZiaZza1WEyopDJvYrI/xmDJbNrc aPB7E+Wy/uM/3jC9Ymq7cR9v/OThJw9snTlz69bHZ3Ypoh8TRlrvGLonFD4bCoXe2rn6NfJC6Nlr 18kYMu7nsfP5XlxEBlUjb1RQGnALAa0xazybRZfTNQq2gxElyEQqKEWioeSESpq7ia8ICLdDdo0Y 0OqzxLolZYjELQZEKtrUVSSXzIOIFJWkpUlri9jYPK7AOXyFUJTm8RplMnkzlNRMWr237cf9nv0q fSp7tM1M16v3nRjK55eL+y3H+Tnh20DzVmIr2UHxsOyg/B3FcYe8s6ZQ0083XjNS94jpkZhFpkOm K/Yr8dftmsPq12JovMFhSDA4DbI3wtdBjhusQKoMXw/YnSqDQiY74bCbHQ67wmFHmVPYHYLWaaik m/f0NBJjJbHu0zrNIjgr6cGAnlCNqjTuY5wP309ykM4GNxhIi4DGuC+PDqWT6CzKaBVNAhdZvjuy oSidN9O4kEpuJe9qbdFlY53xWqBrnKZDgY3oK9TtcgsoIkVTfLEefzZypHnzZlm4vZIi496jSqOT kMmZvCabxvleXHtty5pHn3ieHIj51z8/vtnplaObBjt37mybO+LI48euPDD+6efLY059/sPOgm2H Ni8c1gQ5OSD8DbMgJ9Pg40CKqLVo87XztSzfONA4PV7oY3nQMM480jJN+7B5vrbcvCj+Ja1KdAv8 629q/ivPTE68Wg3hDArgzQ4S/uUGLWm2V6OJZdYquhlsdEwgKdbpEJmzgdZUOtQ9yU3dZfJSv6QD fgJ+g5/6VzSyVpIWFbaPSRX/W+EoOeq/lKFhJXlqd50+3IhqxI2iiFLUIv9y0tHMcUZG+IhShJxD QSIl6AS4Rkgsk2fXJ+u4x9kn51fwJvoH7HWtHD9r16bHMruZTerSyvnjxi4x7/X88OqME+MfGPnE itB3Z94MkznWNQuCT8zcaF5HZzw24om5c9373hldMXLo842dry87Evr9G2QDtywe8WWUzh8CCV3t DyeUJ6yKeSXmLc0Zzbl4hTLGqku1C8oMMUNdhQIoIDMNMapYU0zMCZ3erIsx6/Ra5GggRqdyxgZ0 G9BX6/SBWBIb6zCh4L2mZ+Rjzm0Ux4CXOR1a41DDJMMsw3IDMyBnrRJnrQSsBiu1rnCbDpFmoCcr cV9aVOj2/R2HXXdy+C8eczeCnM27ijwuMiLQoVxeoGicJqKcgiSnkoiSkqLbWY38jUEvJyCPIdYs R9vk7/967JoHn9i7c8nAJSlbl9HPa1/rOffJI0QxdemNd2tJmaF88bFNayt65lnoLztC0weHbv7z nScrLnFdH4a6bhFfAS1MDuiOaQnDf1TBlIIWuBpmUMKUGm2pIFC+8J6S4gnUrleUKn+EnmQoGUqF PCSTyCw0fDZddK3cR5fkdr9xtYfhJrdC3Gtwncwx5kQUkK8JvZsMBJnc29xkyh4m7FsSutq1uf6A 8MRvi9itnUtWhkyh6spzO8kP5J3n63yKTbJLqfBGIKulvZsl4L3fMtD7gPCgZYJ9tPcR+2POJfbF zrWWrfZD9h8s37hvumNaW9ZZdlqElg1GymgyFwkvioTV45a5U5w9dUP5/jsS0e6Qj3vxbadj9vJd d1WRHFCjuTHeteMN0SO22Av7fKXGerdiDBipcUXaO3er0dXbN/hqdDehiHt2aT/b0GZZyTLcQKSA GoPhGnc1fiJtc6yZb/nknZaZw/o+1qs5aX5wwv4aIn97+dVHH/ll046z9L2Xps6o2DrzsY2kr+GR id1mfTZZYx0wnig+u0gMa0NfY+z4bWjPq4eFrOf2H3t+ya5dnIcHcNPnM78Us7cIuJkIMrmSynKZ kEtkDCOKdMgDyj3NRkU05inhe4d+n29cDv5rkhGDgYWAOIDBhVB48mTNKxhkUBjE/6I/xhhOSIS5 gXTciXg60z4zng63j4qn4zXDdHQQOg/aXNdBR+NtCjkDQ7LRCNoGZuJEzu8KeD2JnlyXypWbmOjO 9XicMMQ5UTUkblySYYgbXcQ4L4//kLc8pEYm5/JgrFYKxm7mSly+bJQsVBH+QBEG+814rM/Z/Jdd Ytws6aicL4B8RpyWJkkHW2x+qHSt9YDtj/c+JTBoTkFzO608ScYmmcZ1b9kq7aXhLceuX7HGcvLs Dy8Xb5rao0vxg6Fn+YrDtXgCKhSrkJc64gyMSDdkGEYrxiiLDQuFFYbj4tuyI4brBrVCLCQDaC/D GHXQ8JvmN+1vOiXTMC3TCWqVUmQMTb1CJpdrMK2QaeQYrLnlGjMWUEFwM40ZWyidoqhwygRZJZ0c UIJC832A/1JtFVEDIeqASeOGUXKhTy92il1kwgpGWCUhAXUvzRH5RY2wQkM0PG/Qy0/J6Sx5mZzK n9af+TSyvTYE/rPiFtttBhRaa16u/WreZYm7V3mgh+ZoQWNrWtR7og7nLDAcO6Y7dmyBGKHI8q5B dd+uQWfvQQV7mV5QyKvQ80P4X1ziC8mUkiIvhohewSPEeAR+VhBo5j9pwRfba5/b+Dn5ZU3HREem WHWrIzkU6kAHkVUHHlq6GGV0FUrU98hfI0aRqTA70Iuxjt4B3ge8pcq5StlY+zRxsrJUPUeco5Yl W5SCNTnVaUlQKmNMztTUBg3AkeBELrmcTiMorH5ZP59fY2+Y4HRLkVRRWqvBkjBJp9Gb3a/WhQ0I lCQULDz+GHO434u4PZQoPF7c5td01Es8TSNBg9+LJ9emEVHD9Crq3/Je6QOj5y0fWPbmktDTpPXs Fl26dnxiXegcmTDE335Qy34rl4R2ilWFB0YNeTkz+VDZ6N3FTYQ+RssD3TtPalC9Qa5pMb5jn4eb cBv9QPhbcTrqVQJUBopH0HEJqJ9NtSNgMkxNKIO5CStgrbhdeEl7QNirfUf7IVxO+C3BqDMlGBMS hFRZijHV4Xbdpx1gHhg7wDZGHJ/wqGmxaa2wRrfWsYVspluMp3UxYAa7wWywM34oqEjJIdy2Jafk GPRAWHyMUyPEO5nS4Nd3Ab+bEGJ3xfndCqKwOUcMjp7IuKkvinARI4eIHqalFfGgmkwhcTLmTUxC 7piSUAXxvMgVksaaTdzGsb1HW4feunI19Olzu0j7o+dJw1aHM48+vfXrwRO+mf/iV5Q2uVb9Jpn4 0RXSf/el9xpteGpT6NqTB0Pflx9Cq7MOdXAQyoge+TM34He7SHtFZOONBqceFDhRJVHaXQmG6L47 /9p3bkrqN71JRvuHA82FeLlCphAVTMFkNqvdSmVqlUalVQmyWIvZEmMRZPFCnIeYdHixKhweYlEZ PZCWhmtNxZ/ZRBKSODzcm2LNFEXE52kaDSyTUTDWkT+3D3q8cGppj0eePDkvtJvkPPlSk/zuzz7Y Y2fofbEqNqHb8NCpY6+EQluHNd3ZvEn+9y9/80eqk0vBJtQF/k1hNdwfiJWJToVCLgeB8YWqlE41 KOR8zxwGU5a8n9DFrXJrqcquZcroqjWt7o9sFD8SSFt143La3QKPZ0bpAB3BJpZUs05IqzktzBWr dobydoS0O/lMtuBM5uFMlNA1kCrNZLmc1E8GJ/I8RqFqSu3q+tFVrQbfNfrlSEDAPePdI28Rvqi5 QoO1vfioLXfWPoB3mIA6cAB1wAefBfLjzfGxtDiZDFHEEJOQlAQeUxz1AY5OZHFOneBxypSE+JN9 SW60oNSdXIwxy5SyZJKc4HeriMrmH3F/ndR2NxShKHTHKfBQV5JdzgwpG4l5c3i8gqLRgXnjHXaH zSHINH6DL9bv8it8zO/1WbUJHrDoYzzY2BzjlmMuUfR5iEONMmI24sWp9HggScCL9L1ylBX0Xbn1 3xLnUoNa0sxnvENLLHHyxhTVhD+oMpsYKkq2UehGJywPfbjhs9D6vXtIr3PrCXnKv8szfP+keUcf 8rRYQOiTj19vQ/N2kNpLU0oPkCGfnSGle0dXPpMxuax777k9F64/FvpX2bBsYuQ7uRl1J1GSqTEH QMtVPiY2iwlOpWqD6kMVVYmUqhWoDG65XFZUpiVaqo5sKBe1WGyLcuXWEre2l7ZYO1nLWhVa04pK 8BAmKVfRTb6z0uOCnKJ0ScNIWiZ/RoPw4nXzUXrr6NFamVhV+zIddKsj3VPbHW9+GKc2G2clwDP7 uDxRftrd06K1dOrdk5kVoY0yIjSlQYR6fRGa4IxQqz1ySk7XGrLc4gpxl4iygL51OWyAILB0DM57 4VH8OogmNxauwOE2sTOFkmloP7igogw9a1FhyZTc2qK6feJHaS6omcbDR7m3wrlmh78VhkkeqnvA MIqOlk2l02QLtQuNMiXFSNEe8DCnXqn0q1QKv7rIHUPcMYGYXjHFMSyG+KGrab804FVDUclN7m1R /q7mRR+wccvYvBkOZuYhor/VLvnkEZ3HpRwtfPOJN0+SDdYtM9uXPi78WmOrPDHuAt9N9JZiH76b ZF6giZCYnaNQtkxWNZM1V92nGijMFz4V5NNVnwufq4QUcQkrF7exHxSiipFm7AyjSn7sVJo8WYKb X9AN7NHkmHjpHswropRxmiDRI3tMFl5+IdDahiP5fK0VSputNUqrUqVUqESBMbeoMosi5lCAZBjQ yFQqECkjVK5WgEIlUDUBVklbBvQZItkgBsUj4iWRiV0UvEydISduDFWCckFeSefjkdgdNWRbpLgF I+uSqzw65aqUy8UsN5cDtZfHLPysj9SaxjAhVxhyFbkYo1gxRonHGOUAsPBnLQolF1X3CyMBozIR V9LQlsM4EuNzUH4u7Ldg0pIj4wtVm3IUieYcFjDn8IXv82EyNue2X/co5OpNSqYUQQkKDRcU4iH4 T25cdZR+RuS1a+gTYai9eR0lvgH9tPbVmtX0mx9CLLp7LBV3T4TMgIZQ1EIRFG4eydFXAjo5FaKm VHab+/qmKGLBI0LpicVRPkLB/G0nNlwNINPj/QxkWmAWUL3CTOMVbLpmvuZdjaDUdNZ01gsNmE/b UFcg3M+ma2foFmgVaioqcrTNdT1pV6GDPKDorm2nU62ma4RV8lWKLcIrcpmJ6nW6DJHixlKFRqvN EBWYVGj66PuQAIakCv732tRarU5nAIWSFpvKTNRURbfgAblJhehWVJImAZVGqXIHNLPURF1FB2Ds rMYaWomBrFJPwK2fbCCGSjrgNbdYLJaJglhJt+wxctti449gi3KtuHQpVsW0vT5zuQgjV5QAw20f O8azXBoWPCZFsEhQuf4KVV8HTbgaFOEzGMufkSLVrkEN1qVIIqIN/2u3TsVLpV8n0oY/2e/J0TX0 5GgrMZmdo2uaLSX3NcLSRlE5KMRYF3dfCgOIJa55NvGgrSNeYlxNksj9GRZbMzwuiwdDA3aFCsSq 6l+f7NTrOaHmVkf2XnUzdqnazU9pI9DbfSF+AjqIh1mBYruemA1mc3xcfDxjBmZWx6nj2da4/bq3 dUJcnDWeuhMCxp4xPeMC9gKxQDnQ0N84NGZQ3FDrAPvA+MVxa6jB5hQEk1OtjPW70VXbyxJIgt7P xcnmuD2AK+IR3O2PQzF8izGApynjwYzkm7INeFIFYxbFAA5GkIWk+Xuk4/a9of2HT4WqtrxLEj49 R+If/v7JD0Kf0hNkAnnhaOil8xdDG/a9Swa9EfojdIpkkfg9RP106ApEojdWi1KqBSsMDDQbZRxv pl0NXc33G+43M7XGicIGcdZIXGHyK+xuO8F/dqs2qg2224P4kqKb3a/WxxURhxON2uOcGGxSj8eI 6fpYjDZ4qvuDTxX+HDoeWkgePbSuqFuTuaFFYpXONGr/hIOh2todAlkya/CcWC3OtCC8TPwZ9yQW Uogp8NRQ/3o/tVmzY6nawVw8NDC7zF5ZqtgoLs3fSsyNa+nvJnaL6+wvEvt7C/yTxEeFR8QlwhJx JawVNsN24TSctlyBK3FXrHaHmAapYiuRFYlPWVf5T/uZz5Lqz7Lk+DtbOzvyXfnerv4BigJj/9hB jkEJA1wD3QMTx4oPxI73P+pf5ljmP2c977fFoiRWxOega/4k0Do+hwqWFEGe4rda8IiPxy67SHkG xCSnUy9QRZJTrrT7Y7pQuzu1LJWmevxuVEdbgzvFoXsknJfi+WgwFJcDxkzDccPxSHwPU7iwl0zx RV4C3Ra+cJHB0uZRWTFywcn2J7PfF0zJWffCi/94J3RoV5DkH+fyM7H2my0TtqPYfB76isSfHzP4 /lEvFKUtyHn0/iNk8NnPyciqN0Mvnd0Xurg0veh5klNBVE+HPg1h49AHya1suDsb0ffhcQqlKJF0 C+hNah0xNXcMcj2gmOBipsrwV3tM9iyk1/ckJmcZeT4hOcsQpfooxfrP9iT4I/XY3hClvD5Qigmf rouji7uverBjgmOKcobuYf081UL9s9qt+kr9d7pv9QadRuM26s1Go96o1yhN8dRjt6hkJqNBqxGt SqUlzm5zxsWBJ1GSaKtVr9cpnH7d87Iid9LkpLIkISnRGpVsL/dzdSEzboXtspWfVbhViwo4FuMR VXrAHXm+Lda/kIn+AI9kAipFQJ+jN7Q0mlpyA0VKJHOmQ4dmt+UY0eeZELqAI8eAzs2Q6ELUe7XC 2468eKiJ8QqNKeqOV9Ij6XmkZyMtP/b+Iyc+7p7Sv1v4xtH+Ewc28nT9kmyct6rHsy+GMsSqnu8+ /PyZBF9Sj2mhEtJk7pIWanntNCEz++H7xkjvQwaHv2U/YmyfAaHA8yOEEaxUmMqYL7mZkONoL3SW d0vId3VI6pjcVyiUD04YmLIoRpei9SfRJCHZ11yf5e3gy08f5B7g7e97UD1OO173gHmU9WH1I9pH 9I8ZpiWV+uYL5epF2nL9UsO8pDm+p7Sr9Ktinb4knVYtevCkGK+Qy5hAZcSXlIhleKCJb7QcbcxV CzQyEDfpRYrJZLKCyDCeCwZ8jZxOiyA6Gynj/fYuSj80IA3sTT1+E/Gb+kkWtUn94eLyVcOdp2L+ IB1xgz9IN/K3qTnRhwvSQ8GSmGwnzWwaPSsmJfv9zbIiT9Kj5+VYc5yFxUm7wRXNP/g17dB3H5u0 rW+vwa1CD/YeO/rxX5958c/5YpV+59bgxpwW5POCskfmV7/wTui3NeRTw8SlA9uVdsgf7Y0blpb9 4qhJb44c+/5s3eJls+/vmZk5PqXVvunTTpVO/R7XkIFWuUp6rtUzoBWpE9kD0p/OUlbS0j3uyOOl 12RuQtMFImB6H4kcC7BWsX9NxCJz0TXUXi76xiC9Mc2re8nfTHpFGxNKYOWheFG7c+et37gUbESf x88iZigJqPz6AlagOK5gFh7CW/CkkcVaKTqyLorp+pfF7/RyDVAjf0DtkCnNflrkthC3pZeFFlsm W8osgkUrnfN4XyX2VRXF8uiBv9su4gc+DLYjbk5yEKglBIPsiHuT4m0p9Day4qMjQ9WffBC6Nfno fTsfO7NfrKrZ/UWo5sVlRPu90LOm4vC+4Uel96V4EgaxI85dBb8HOqWLJBVSBJ8qXZOhKdYsUixS rtAc0VzXqN2aXhrK8EiFJ3alWyGa8WyFpww3Fc2UikpCxe/dKoyaRinIKKrgs1en5PRSkDLFCgXm CQloaSAlZygly+l6SikvMbrFXiLNwEhpBYbP10URo6WFe9TFWyLRUgl/F8hhNURe3dptV62R17e3 PdWLRERmjHoqQI9s+6VCaSKcYNBYGf5ZeicqBUcp2Ky5FBwB/8tAUpSAHtZDMiOxTiahbWvf/Yg8 1tiV2IgsebsWz0nVn5ZNnjGDNZDOSzYA+XRup8mSQIcG4Dc2MPmtOdDcmGNqbu0M9xk7m+6zFsBA Y4FpoNWwWrFaTwWGoaZMjrxSqTUapVan12vMMSYT/1vAVvR6uXtEsLo51ZiMnAYGxSqUbjxpUDzv mQkBq6hQOGOt5thYq0mjVDpjTZg0GTV6vdtgNBsMRpNSo7DGinqjAeVKjNWIgtWgx2ObQkHRTltN JqMRFPa4OLuhrZL0Bjdo8BqLCIBIeu9380diNlslWbw7arPttu61GJnW2m211h75ozp8U2+56yJT brb5s9Q65OQs6H57nHonQUu8QGc4dgwvucfqUrdfcG/0uDdGvoUmlbUyfDOyYT4sTP1rw6Kxrw5L 9mgCYqCFtIdT+AbGRDYwxoQkJhMDVv6YlpB1oUffuZhkb6EicT981NPraPTNW6GJB0PvJcvjzKHj qBJ5z678MUm4UGsP/fTb4r3CqxjJFi1xj7qv+kXpb3dENUNDsvbjcVRgrfBI+e0eUxw/On4b0GGC 2fAi8IuS+1+rdNr8LNAREywFLyY/a6BIVaXr2BgyRjZGfUHGRCYIMoVcKZMpZYLSrVKbVSq1TJAp BTclqEtEplHLCBotoq6ktoBSpVIKFE2YrpJaA0qNsk9AVaaiqkqyL6BVqzVuEPr0pMsljdpXQbgd s+7X6o56uBal3eSWDE13hHzDLRkeMm7kGiNbuKBxmgJ1SOQ7xRML+HNxA166BuOQ1Q7+RFyhUWpY VfgGCOEb0kugQm7yieSdldKpE4Fn6gu7bdzx/vWHDTzGvzTLSFvVvvcT8fTKbzeEOL6qfY1OELqH Os6cWbqC7KrZU8v/q+fwl6GxaFZ/BAHseIrM498vARtr31b6WkDdd0sENMEutjU09okneAzeJfwd c7A2kALZJCGwTKlVptq09tQG2tRUPAvGZse3TO2cWqQtSh2nHZtanFGund9greU5+1Zt7Mu2bSn7 bQdTjtlOpXwU+0WKooOFuOJc1rSGqVk5LKdhZ9ap4QBFYdoDirFp0zULNMc1f2r/TDNmZ+kIM6Qn ZcU19ZitQxtMakAbONJ1ebrluvW6sE5cr9ulu6YTdDqHEFdJtwUs1pVmh0MO+cmqpg5B3WCYYRj4 PEmV9P6AITnAX3K7/Rn+XX7R3ySHW02X05uVkXMkh27IITlxPmtietJh2SkZdcnyZFTWpAV/O8ff H6FZvFl09UZu7ZUr3BtcrnvhjbUlkcd/de+8+etuPNb5pCcx3CtnS59mWcmRF0ttqOSmLbGxZkuc 1y/wN0yR93fYSMgdeWDcrkP3lXZqNv7saJKZv3DWwwlB68QPFy3c1sugjEs85IgbfmzS4KYTxo7Z 5E+Y07/j9nk9Zvcw67T2JJ9qYqPWhSXWksVdA8O6NJ5xvXpe6xbkixSHIaV7eqfi+3u2fgh3cD7u oIuf9SEBzgR2EFGjTxKbifmimOcKuqjLlejIdLRzTHatcMlaxuRacu3dLN3sRYoibYG+yDLEPk7x oHaMfqJlov2I63PN2biztq9ifor7yfZ1wiVX2GVzi+n6dHOGmKcPiN30vcQHxLMJv7NbBo0hVsdk FOIdaClUsQ6d2pr0oZoY1AF1sbpMzdRTiTETMgUfpUcIRlAbSJBcJ8xF8khPIhCb877s6KviKfwJ 7A0eG5VEDxx50quXiJqUTIESjxc9MwZDeI4zgDcxWcBYqP6NOGn0yt4pu4fvKgmEfn390Hia1f/J 6TtemjZ9h1hV+/vynstPlIauhc68QFYd7r/45Hsfvn0SLVOv8HfCVZR6O5wM3KfUEJejfUz7uL4x feOKY4rjnqPPCWu1mw2b7RqF1qYaR8cK48RpmsnaMu3Lmn3K/ap9Go1FM1/zNRV0iUP1k/Sz9IKe cGHtnCE9WSyGybACNsAluI7hgV6vxpDK5FDLrQ6mduiJPkmXGI+zSFKnudDgoP/o7IhNOiUnLnme nMqbxGcdk6KoEv4qeUr0zwMeQAVHI351yo2rU+qeVBtz0g0YVBZdrgsiSRwXUjyhS19fqo8cObOE 3N0J1149G/pjyveLdp537bLNGrRw2+a545aReXGvnSIJRLWD0Nm7NsaPf/Ctj88cfQIlqyNy6WL0 DdyZwHYVZVqfNkvbQSs2MzdzDKT9VH3MfR2j6UhxlHKEudhxxPWJeDrmC9uVmCvma3E/2q5IEmRx udLsXOy62rkMyhvTJG1jS0vaTNuV5ms7mjs7BqoGaEdrr8i+tdwiN3QGEivo1AY9SpZabgQULUFt zSTgM+p9BsOHRmIwBozFxjIjM041JR2Wn5JflIfljPOup1yQ25xZvaKC1Z0/JpS+qZd7WYr4OP4S La7UnmZcqVGrIwzjD+3Mf4mW0GLUsVmnp437ZE7xqvQ9te4d06a/tOXRGRvnr1tS/eJ6IpT3bkt1 tzpS0/sn3nz77PvHkGddURudKFmxyLMLgZEucMTS/kKRWKTsrx4ljBcnKUepFQYwEANNNn0u3jLf tMubmFramjjamrrb2zp6mwbb+jiGmSbYhzlmyGbE3qQ3rQawEL02Lq6XhYe4gsWhX2HYYKAGA4t3 qOTABU9JVsagcMUFtFLcm5yaFdQSrd3FH9X6/FmcBhK4ZXQRlyXTkCQPJKVm3cayqC6mda+93MNQ gn6vJE2KkmujX2DIrS3JjX4HIPJchZRMqRO2yEMhs9wjhc7E45fsojCkquHPB74PXSPm86eJjtR8 p6qYN2JJ7VnaW9NiwKKZW8mAuBf3EhfaAg1JCV0I/Wlw76oaQ1bObz/mZR49xKB7KsOTYRzsCTjN SqK3pdsybAHbZNtzmue1W7UKuzZFG7QdsTEbX12K3ZWVoNAKGr1DRWJpmjmGCTJQrTcTczgmwOJ8 DAT6FJFeX+xp0iJLeo2hcriyVuBYL1pth0gVeOAmUQF3+3iM5m7ekIuB89WiiNvn3yrLMUbeB5kN RplSLlOgSzHgUR+MMn08SSNpqbNnkzQUrCmZRm+zTP4NBJQr1EOuhrGZsV5jxfr1MfY507sNjm/R tE+HU6eEtUtKxmd1HGh6QdWxePiSmgdQhtqFegs/oAzx77pcDxSr1aK5odpn7qbON8uUCbaEhmq/ uaE3R93c3EXd0TxAXqAeo76l+j1W1/j/aO1LwOMoroSrunv6mp6ZnkNz6Gwdo8OSJVuHZQmBxvjG WAJLJshY4PFoJI09hzQzsixsjAkEk4SAQzaLyfFjjnBsDl8y2BxBCYRNOBazgWQDH+B8mASSkHgT r/+wjqT/VXXPaIydZHf/tTzdr6urXtU76tV7Xa9nyuuqLiu/rOrKqr11++uERaWLajrrVphXlC6v 6S3trYkIodJQzaa63XVvVX1Y+vvyP1TZPW4+7xhzaLK60ClQC6ZqEAAS+7UbTaETiGjXTYElpsJC m7y8rFCR3XlN/ibZ7/We8GDVE/Bs8uz2cJ60DftRWUnFc7bXbO/ZZm1cia3T1g1W0Vdbly4lE7K2 i07IMyQMHiWh4VmSAXXKyJE5pUdjo2DFPGT7lK6dVXpyDJmZnpbMTogzZ3oOHjA3Lk3fdIfXircd fPt0/PUvPXPjI+G393//N/c9ctPOx7574/bHrs2/2t84sKH14Bdxxzv7ML5z3+6/bPnza9u/zc57 feq5V55/8XmQ/h6E2A9p9HnoOHKDWljyPM1+roVdzj5l4WhOXoXH1+wR7YrdxZowshWaBJdZVvxS oGlR86yEpyQsddFw1dO8qPmg+7SbGXHvdx90z7o5N+PyG5tmUPk0ycfVgLMnEYe68lZe5TWSNclz ntHaM3pOaoe+BhIXk6qblbcKfiuvFGCLCIqGyC7iLai2X99S0xPu7OV2yhU+z75nctfUtu+tmRzb etWXOmAZ/OM9/Q9/Y/oG5oE9O3ruumn6adCxO2CKddB9NgHdFOjvlvZK+6WD0pT0nnRaEpBUIo1I u6X7jaKT0qwkl0iwVgkcw4LfvQu8exPPybzgNyH6Nd0HuSnuJMdPcac5BnEadwKuOK5LzFCY7KDZ qEAZzsQ9ROTJUZpQBFTcMTk5yf32tdfO5XGV596CyT/74MzVuJ2O0YHuC6zlTH7TJVyT6XaTySOa TALHMZzJibDFzLAuhbObzAIZl5kXCu22vTDvIWZTFItflveacYm509xtZs0+p+u7pSszCkn3frtU EqSNos619GGnw3jYqYdmTU17VFFPD7CKqq1SVOUCLFmFAqQLgSRqN+VhPQOSPD8gOXm3T84Mly0q aV002bTk3tXcR6+//smO+6yr7+E2ntv/wtoBYt2A/+yf6X7dK4F8gb+G3yCxNsufTGd5dj07LjMO XnPSYOj0EUcVCY5OT8LZYaIFpbQgcBuU8BwERHyrtBK4w8+Xr5XH2TH5LfZ9XniEx+V8peAX2/jF Uqel29LH9fHXCn3STdyE6T7pRf5fuZ/xp/iPhP/LfyLmOWTZxLIcQ7bwJBEuIP716xt3LMf59c08 GSTPiRjkS36bRzSbkcyRr6c0lYlwCpRr1H/J3wtLj9mPGD/4fQjikG7QN59i+WXpysE5vtPHY6OZ 52NGgAzLs6eNPJ/gMjt4ZCtPAAmIHSw9gs7Qx5pSXVGbJBYVdZDNucNFZI/ujcMaPR0q1R9g9tG9 mFFkfCMcPzt1uLQNZvPUYTc5vXtYpTt7cKJXCj0dMmf2crCxM+h4h8Oiyw29uVwd9ACtzh72ksa/ O1SgV8f9fdRZpdt+TRgiaAEUGv/TRzNb8HPvzjxwMwTLz+CDM9umB5iSG2fIewG3ghq0Uu2+8zgy waLUuljfvG5u0c8LFurnMn1zO+AHq2QzlZjuN71n4rrhcNrElphGTLtNsyaO/B4lw+qGhmCiBicf VqD7EZ4CN5TJsTpcdk7W1uqzkhrfJKWEUHDrpLHDDZaRr4SVqBy9eBxJEJgvMVvAMp7iTkm/9Hyg md40ndUYj6iVS94CTWLZ8uJCPq/QDFMQ8+X5PlU+4cfkt2sYP8xFq38vTfXuP+r17y3ABQAFfIhp KvfjEwgTf5kpQURbWOSr8B/D24/MTVSIEaZPkRj8TP80faYCYQHd9O3UVcnuyc3WsCouZ6VLsRdg hyUvYy5pAjxQl0cfq3pojje1mXRxzrWeDzQ+smXbvSW7Xvo//3SkfONlI/8wee3Albe0c5Vf7bph 87VPHXhiuor5ZvSG9q8+PH0vc3j79qu+9uXpXxjryK+AW270SsBpYnkn85h6TH2f/bXzNHvWyXNk zi4EBk6oeJ96wnvSO+vlNNFldbkdsKBg3m2RLVbFWmGmq4oZw39zl5cKkqwq3tNeZsS733vQO+Xl vCzTlOc2FhbHBQuLJ7OonOnQI11YVuiT2A5i4rLripu3S7IoCzLLq5V23lqAbbLDYBhJTIHJQ3U6 b5ER4uYwbM+DY+9seuAqVZ6ct3VV6lGu8t4Dy0fWNt40nWJuj8eW3PPKNMnQWgb+cBXwxIJ86AeB focg+5SV/CrxGr5PHOIjotistjva3S3e5eoaxxr3cu9G00Zpndrv6Hev88ZMMWlAjTli7gHvOM6T eJPlOrbX1Ctfp0TZsCksRxXZU8gJdlA5VwXNgXJW+JsXCBgJqqCBa7vwPaJoUO4jzi/A1goUgCpE 0Ri0MJ84vvrbIKO1/Wf7++deCCHRAX1E02PqkTabNksczHGn2qpnXlPPN9cXWfbw53/0Nnbv+O0X 35v5+PjhPbcfPvK5PYcZJ666a9vML6df/e1ncTG2vPLyK6//6OWXoOs9MxGuFPjiAC/vtcC3FHW+ eqm6RuU6tYMaU6LVKOVFjXmNRZcXjWh7NbHd015wheeKgj7xOmWjZ2PBFnGrElFjnq0FU9pPXe94 38n/afEp16nik9qs5i7natXavBauXV3BXaFuUD8w/7ZoRjXbrRA5kGCdd0Owjqy+ihMyVuWAvEne LXNyGjubmCaHH6GLhuslEK7ji8Xr+g5hW2647sxMMneei+Y0V9nZHFbtebj9nuE7TmwZe2/Hhrvr 7Y9s2/7tR9OpQzMR07NfuPrqO2f3PTRz7otXtk+fYx9+9YWX33z5pZ8Dv1bNRNiTwC8VFaLvB/aZ mVpmnvcSZg0zofCdeZ2+Nb69xfuLTc3O5oLO4mXOZQUQzBeEnKGCTcW7i9/g33T8iv9I+Y1XrWHK lNq8NqZFWc2sUDYwEeYXytve990f+X5V8BfGhjmLKx/iTivvgnAKWT3WJkSiThtWbQHbJttuG2dL 2y8SdRYVn+fn6k7umY4L+YNGsd0I0hcZnu15IWfdvHvXPzvzh8RPd/1o9MHp0u9sTz1yYNvYQzMR RrykC9djYf/MrY/c9Z9L2e+++urz//zGz/6ZeBOfA3fpReCOHd0auKTBiVUOl3PN3FKuhxvk0hwv 2UVJlCxOu2RBrIjNVA2QLFXvFbFYpjmxkymz/1Uv1bHyhayXekrtP5Mk+XuEKPLkmrpKSP3JHivN r+hPkuwHXf563COArfjcg5dFOq+7/rLLL7/kelcxV/nA6Kr2R6tWdm5KTr9Bxt85+yF7CMa/AP8i sIMrc5W1S1dIyyquKQuX7ZTukm6reMT57bofshbJk+/1LFhT9zOPqYBZzzBqI5a9G8WN0kZ5o3mj stGyRdwibZG3mLcoWyyTlZNVNrKXVlGzqGKD3GceqByoTpenK3ZXfEX+hnJP9b11X13wsPy48lDV w9VHKn9U6S4iiT6O4rYNYpVfkbl8rTKPM9cX5ZPAqLDE1+nr9t3gO+B7zcfbfCW+hO89H1fiu9vH +J5m1kPEj0j8pJJMGBWfAC8Jq5ghybRHXO5mmlRbbLU3Y1y/sShaxBQV5glcYb25JB/nV/gCTm+z 7xhz3WGhYh7UfLKw7cQ8PC+/kbSqhGh+U+NUI9PZuLuRaVQxxhVIq7CVvZd1rhZmAvjRteQtvWQX Nfokhj9TazwuGoUwvhaseZJO3OSpbIqjR18KAlXzi8sh0Ky0qw7VqbJ8mUUrQFK1UIBN8+FQ7ILL Umt5ASortyhiDbjB1VWSzNdyBahELSKLhp7YSA80tWpe7S23kChllLj5c6+xVFVW1UNct6j1gv1N +COpGjTQ6zxs+/yOndtb/F958b7uJYvnfbnnpmc32A8qqcjOLW53Q8Ftz917TeTFm177Bb60cGsy vOzScq+/cfUtXSsnqktqV+0Y8q7buK61vLDIKVc0Ldm5ccP9n/kO0bSK2T8y80z3IQ/afRzJJHWw kjjTU4ElAOz2QYSjWGTMIrcq1dpkMJWs2aaWoTJscfgVPCuIy6Xlm4QRYbewV+AQrDH7hYPClHBC 4IWnmC3IixcdGtQnC31dFKK6U8QKfEx2QIkVgICCZk/019b6PfqzJ/KkwN5qJ08H6O4jo+Zf2bE5 WnfbbUeOHnXWVhc/cL96WfhBJnQnFqIzX7pz+itr6/IJLbfCrDlJv1P42eMonzz3AQ+R0ZxukrRw OlDjcDXXOnGF6HQr2Ok2w4S3Azmoye33eqiL4cFTHuzpyqfTnrgY+afzmZH8/fkH82fzuXyIb7MG gbxTqUknIBLkpC5fNmz9OONddEzTR2ydHW3GSz6gUvmcarXYLGT/jmRVg4/BKQXIItr14GnevFvA IpKNDv0hXFUlDaA8c8mPbOfON69/qFs1T5rt8auvvuuSyW9Mrop1t6SYe6aPfGnhyqt77r6DaYNg EaN8EsMDL2R8/ZMtEKKX2dtkMpst9jYJ3KtmkRyYY7O/OQJnbJxlstckFZc2o2o4wNWHAQm8beSG A1y9FThaXd+MNDjYlBpULVXKbahFXoVWytfga5g+8VppEA8yETEibUfjeJyZELdL4/IevIe5nf28 cIf4BembaJ/0Zfk76EH5WfSkcEj+CfqR/BZ6U/4del8+h87IdTIyyV7klqtRpdwqdyOIbEwBh7vZ FABHUYYgyy/JLkmSEctAPEV3NCEOQ7K+PckLssQibGpQsFImBgIBiNkZ6RguOBqAsIAxARSQNCaA y8y/+VeabJrvm+6f7s/3fnyq33ilJxt82dsuyJYjCY1zGSU0qSSzW+iEKOd7M9Hvn/KXeGt/d3wm zlVO3zaU6N3G3EGid33370mQiIM5FFBtLjyPq5GZK+zX2e+ys3ain1JJabNaWKRHt4HvllQ0c7wi OfkCyecwcYjjzZLZKjpU5GRdQqFYYC4C580vzBNrrc2oRWgXL7EuY1fyAWGtuMa81LbSfoXjOts6 x1ZhQBxyTPA3CmnxOP+U7QnHf/DnpGqzvRpVW6qs1bYqR4NrMWp1jIu3i/vYe5VH8WPMY+ZHlKPo Cf4p648hKv6F9CH3oe3XjjP8f0qFDpZuQQsmSZZFs6LIqt0O82vNERNyaMdmVwcGZZtVe94uiJpg dzhqTQKEyoJVVhS/xeqyWKyi3WarlUUXNCf70oYUEYMFByfa7IrVIttljnVYFIXk9ROxOmwk9012 nVUtmCRX77awlmP40YCsdcs4Id9M9i+Z9QGp244T9pvtJB1ifcCsmvAmGg+yIPhHj+KzzrODdFnw rT3T3+8Fsw//iQL0ey++J21ohJ0e/wtb0oJV7SAfApPPmoMlPddOWjRFY56ZPYkwfKyzJybRApvm ODZ7Ei82/vWtOdjcAyG5OHvikEDejIOC0p41B5voPoc4e/KQoOmlDiNZk6QsnXjCphHc4rHZE4eF BQTjYbSYeUrvKYs8285D29lnTx6RNU5D+s4rNvKf3njC0YbqHDRl7pCTbrzqETDN3yRKTnXc6aH7 4WwVi9fMPP3U451c0+PH72+59IkDM5NPP17zc1D6r5+yv8TEp/e9/CozeO4tZufRv7xGfnkE7NG/ g/arePxJmwPbynx6GvETvrYNtn/k/lG8z/o125Rpip8SXrZJtoC7LZ91SnmWfLUFt5tvwXeZxQbH Z7g+oc98rfVevE/eZ36SOab82PyS9RX1LfZN6XXL2+oHssPB86wgShLmeYnsjJttNjC6FmyzWVQz 2GzGYmYVVeZtjE1WX0QvSozqR5ILIYllLC9asMWvsC5FYWUJwneGVy2ghUjudmDHassupUy2BXlp V0AGQ/JkgL+K301fQ1sasGrsLqasGwhdbd/5gvECNrUtYFrUD9QzH9P05DkVo98ZYChQv/GKa5vN tkekiqMf4US0KfuUZ9LqLWoz0+TrojalzNPGwodcHy5tU+nj+7w2XFbaJgUKs4nYfTRmJQ9kwD41 eYilaiXPY9gqbMO3zdz3y4fqC+v8R34+82X8xXfeap/5iKnGM5+sXHB507kZZfpf8BV9M/3EepXO XM3+HuSXj/ccsRViGxnFw4Vt1a5rbAdkNmAJAEO16gXNKjkIiuRwW7yOKnOVUmVZpCyytFjvs5ur HdXOVe4+R5+zLy/iiDgjeRP8NsuE/UbXjXmfs3zBfqfjTufnXfvkx8zPqE/bn3L9Rv616z8s0+on rtnCYjABigr2BCy/z+V0+h2yCy5sChgMv1l2mc2y0+FQFDPPFvpsqFAtZBoKnytkCo8xnUdtzoAj 4DrG9AbMnY6Ag7nB8ZyDcRzDlz9hw2VoeYFMbjlsmjkQ0JQFSrfCXqXMKowCNY402IBYpnOyQNsJ xiPfp06TFwRBqiTN2queOeUjXzHwcb5X/ZhCyEucm4yIxdzndkTGe6hAwTJYYUZ6YUY+jZTZD5F5 9kOcMx9ds+8+0doml7W2WWERPprXZjeyEPvItxmQhHrc76zStwVaaaaKsQSRV/TLy252XVLXscpj rzSZZ2I/fKe2rKT2/cmZ6JKKBTuvaZ4ZelytrijYaiviqqfvG7tl5zZm67kfH7i8r4fIuRrm6Rsg Zyu+I2BxHGN+IjIO3KinqPxLQAIAX1ZMH8T+MHAFADVMtdSgtuE2eTVewawQV0vd6kbcy/SKG6Sr 1CgOMSEIQXbgtLhD+iL+nPh56RN8hrzwWolrxFqpTfyW+HMsEO19Us1rZsACSSRptwpccaZdkhlR lv2YgQWCweTNUCZoqgUS5aAFWWqtMnMM2yZhkTDxJP+hDglllv1WjKwB6ybrbutpq8maRvIujA8g 3I0SaJY8SrOp6VIyRecevJLg9BTd3TJeoP0AvNMP6Mao4QGo1hdq9fcjRvuR8YrE0RpcKZJ4RmeL SJgEVz98krCH8Eh/vWm0j6a2EDP+7mEboc44ffhkQZskugsuJcv9YQ8p+nNAdrcxLvjku+dmcFML 5stJpiAWFjWV5lUzD6eunelmB6Z/kJjYgn97Dyvy94xPX79D+vrsrP58yfQ8U4nWgTgFdBeErAh5 A2aWKebiq2oZlik9zpShGuJxtrRAsHQpd5aJm56nOx+rAuXgWAkdsMIjXjBx5CfchA7ufpZ+ucrd dBPfhI4xFUdE/TtazvSvnT47nVkziYUjYbD+VjT5ypVLnzn+DHf21VfpO9E97J+YDaafIjNEG/8W 2Hg/hI7MH4Q/OJn3hPeczGvCa07mOeE5J3NAOOBk7hfudzJ3C3c7mV3CLidzTjznYqJi1MVsEDe4 GEVUXIzLKQoexWZGrO0TK/sJY7UwWOmwoA4LJl9l0+BMCDcLdwusgJ2LXR1Wi9IBbkTAk99sHcPC YrGDwaiDZe9mMOPzjj6aSTAmyU0Q1pMvz6AQ6iQJ9RBFqvrX3ND9GviP9LxvlBwdHcWjxj/cj/PK 6YvWHp4XSnNg7PqBNu+6utZmFv9DBuJeeP1bt3dcVbPCc91n5iDg1Er2I6bL9BPKqbcDXZRTp8XT LgaL2MWcFE46mRPCCSczJUw5mYPCQSfzoPCgk7lHuMfJfFb4rJMZEUacTFgMu5gescfglE0xs8j1 bSfhjWIBllmBWVj8tkAKFmBgIIM6MLbaOhTgV5XFc5miWAi7LGMMw3YgYFkVItl9Wyi3SForeerV QVkF8+cUfcHtY/2rgDLn85mV5dPoKPBN3ytyCfp3BTXlwJ/5QUntdXWLWth/ywDcn4FBl1xds9J9 Q88cRCzWbvZP+GqqVbsCi3aId4qMRcTTAn5X+IPAPEte8v668D2B2SBEBUYUQFmATmwGSsXF5Isa 7sYs1ZY8AXBREjvIe5KgE8o3J+Z0AqgjxPXjU4iQ3EHUgFCVoYmQkyvtJReTMfQQZT/Cl1LJpgOV PxXeF5hDwvMC80cRf0V8QGRS4mdFZr0YhmBGxCLIyxBPMc4OG2VlQYVx3jANGUznfiETyigp0dJc hu+8GG/Jby2sYLvo75OTfzPGb5UTTsv4MgNmkNX0rgGz6HrTlAFzOXVMyGv6vQHzyMoXG7CAXuDr DFhElcJOA5bQFywPG7DM/ZD2TGAz2mytN2AFDVr3GrCFn+RPG7AVbbSepb+WSv7dbFtnwBAc2v7d gBkkOJYYMIsaHI0GzOXUMSHFsdqAeagfNGABbXYMG7CInE7VgCW03F1hwDITtL1uwGa00B0xYAU1 ub9mwBZ2g+MlA7aiejf5/irMsTA2xX2OwiaAVY+Zwjwp9xRQWKDlVRQWKdxKYcmQkQ7rMtJhXUY6 rMtIh7mcOrqMdFiXkQ7rMtJhXUY6rMtIh3UZ6bAuIx3WZaTDuox0WJcRgeUces2UlpUUVnLKrZT2 z1BYJbR4hijsBNjhGaOwK6d+HsFjwO6cch9tu4fCBbQvHWdRTp2SHLiC1v8qhedR+CEKz6fwIQKL OeMXc/pScsqVDC29aAKNoDAaREEUgrOGHodPLxqm8FpYVePwSRu1NLQUrpIAk2MQyiO0hgYlUWhf D9AyWh78/8TUkB2ZhnrgThSNZeukoGw1nPX+FqI2+FuA5htQIy1dAi2icF4HbYZgDGnaah3gS8En ibbBcYCOIQ73wiiWHUkS+tWgVtDoSa8fAQ5p0IK0JxjjqI72Qu4EaU8hA1cQSvSWMYqRUDAMo49R jBG4k6a1h2lfhOtpo4cUpTBE26bp/TjFQs5kTAk6hohBywjFTUYUoqNK0d7IHVJ/gJ718Y/R3jTa Q+6oIhR/Gu7H6fU4xT1s9B426iYoLr3vTHmU4k4bHAnBlc6ZT9dLA84w5UoEzjrukFEyRjlNZDWn JQkqlyTlaJS2JyMl2hEzWmV6CNH224xeIwal5J7OzTkuDEJNgk0vneNrxOBuwqAkQuuP0as5qaao xkbp6C6uE5mZk8rSQu7FKL45HEnoZ6sx2qDB/xDVac3Q+wzPBmjfQ7RUbz8OdyKGDEmdKMhe15EE HIfg3jaD2zqGubkcpLLStUOjPAwZ9Eeo1KK0zgidZ7o2xmlLnZJc7Y5kNUuD+9sNycToaIhu6nJL GTM5mh1HjF7NaW/6U/Ym9Sn6QkYfmymGMcrpgfN0M4xGoTzD2TH6S3cZCgepbmtUB7ZT3qao3qWp NIayUidj1+c7mUt12dmUMrRszh7pd2NUIkF0I22vj5rgDdG7c5qm9z5AuTVCZ8lElopM36T9OL0f pJxIGn2QOaRzMU3bZ0acwT5CdShGbWhmbPUX2NX286RG7N0Q1X8i3XZ0jdFfxtYSW7kYjhrE1Wup DJJ0PujzqCYH11rQ67mr71E9TxrzPkaxb83K+H9q83W5DBmWMGzYtzk7pWNdD+uBhq6i7TVUSftb C8du6HuQam6GY0Q3U5Tbwwa2etQF9Xph9VgBn6VAEYG7oZS0XwHHK2n5cijpgSOZAyuBi8vhby0t 7UUWJNNPL9Xa1EV0WsuW6yPWJTdiyHZuLlzIH33NSwAPklQ7hmntDD0Zy5/Rp8307gTUH8v2Gcra UJ13Y7TtnO0LG7ODWKg5e63biYhhm1OG7RiiWMJZ20t422f0RqzINsNmb86uenqf6b/BmYxujWet YNiY2eHs3ElSO5U27MagofcX41dmthOOhXOwzFmLC/sbMPSL6PJmaoH1UW82JBM3MF9MQlWUqvM5 pVv+C7Xiwp4zNpRYyyD1aILQa9TgdsqwVX+t73qq+/Ecez5xgSzChjeTO3P0VSJIRzRCOUvWrQid b39f5pqhi/EcG5rpl8z+AcrpSM5qlczxuOqytZM5ejvnI/xtTpHRxSj+jF4lzsM3TuW/lUoz15pk 7PBczQTU1e3MGOU4wT+cpUcfV652xwzLrfNfn1Ujhn7MWfjzdehvUTSnH6sp7RdKLuPjkbUtbHiC OjW6XxmiUo1/SgbJT/F7DjOhL0Et/4BhV7dRH2wc5Xpxf1/6GXz6nAwbvsb5K3IG34Vy1Lk15xmH KM4L53FGYsFP8XrwvzXaOS5f2MP5fsX5Iwob3nIaVsgMBrLKLIHS+YisjYtRM2qF9VCD40K4mg/x RjN8FiASc65Ha4yaC+ivzjbDnw63oib4kFaLUAvEJuRDsA9Tn2QE+muAv3H6V0/X9vNnfIhavr+2 ThBoGZ2d41m90FfBiGFtyZjWUQutr6Fdhp+VMDx4Mj/1lTRJ70SoBHrgOLduEK0ikRXxE/57426g 9WPQVwMc09RCEFk10LXnBqoluj9Rn635v9vDOPUB9Lrh/5VeMvcaPqWPWdy9EyPhwWAorD2u9Q6H tbWJeCINRdrSRHIkkQymI4m4NhIN1WvLgung36nUQJBpPYnoGClJaavj0G5hW9uC+XBorNeWRKPa usjQcDqlrQunwslt4YGliXg6HCNIkhNaKgiNoDwyqA2EU5GheJ22JBkJRrUQ1ApG4GYskQxrw2Ox YDySSmuh4WAyGEpDg1Q6Ekpp6eFgXIN7E1piUItALyPJ8EA4FE6lEsmUFowPaEHAPxYa1iIGqkhc S4/Fw9p4JD0MzcNQmhggrQkcDUIf0D4Ig8mUpcfD8XQkDLVDAIwlJ+o1ypLEtnAyCOSlk+FgOga3 SIPQGJCYIp2lEoMwTDqEwbFoFEA6Vug+loBOIvGBsVSakppKT0TDuZwgwkmRXsLJWCROayQTWwFt EMYfGoOO4nRkA5HgUILcHx+OAIXD4egIcCShDUW2hWkFKuWgFgV2aLEw8C4eCUH14MhIGNgYD4Wh E53dEcIsLbwdiImFoxMa0JYCIUcJjlgkStmbNvQmZfQXghabw9pYKjygczM8OkYGOxYi/NcGE0Ay YASi0ulIfIiQngyD3NOpOiKmFLCM6hFcxoJDwRsjcUAdTofqdKZB84FIaiQanCBdkNbx8HhqJDgC Q4MqAzDEdCRFEJPqI8lELEGx1Wd0tV0nbV14aCwaTLZfA+2I1jbWL27UqtdGQskEkVENrbW2l54e 03qTIPtYMLmVUPy3NB9oGQIlDIO+UZ2Cqut7tKuCaa1S612rdQ8O1tOBhaOp8PgwVKvv6u5dvWL1 0iW9q7u7tO4V2pWrly7v6lmuLVm5bvnytcu7ei2yRe4dBlFkOE3EQhADcUB1mkohOx6YeYmhZHBk eIL2Q5Sf8GnzhDaRGCMtQ0RDYXRj8QGqfaAToFBUr0EnIqDNUD04lAyHifbWa33QbDgIqpPYTKYe tEyfNxjCrXGigmEQdphIJxkOpUE3BoH3c+MiYk8MhWkVqhbZdiBO0PjNY2lADcNMwCzMIagqlRkU KH+WFdnGREO1bcHoWHAzaGUwBVqV27peWx+nej6RoQJoMoQDUyKopUbCochgJHQh5RpwMU41lLQN DgxEiIxBc5LUcNWR4iTlLbUInxpUNBKLEIKgE1pvPJHcmtIVm+owLUyMg86MbY5GUsOkH8ClszsG yg3jB1GNTGi6whscOr8jyo/Vg3PEEYs3OhZO0W7AVobCybhBQdIYN62cGk6MRQdAV7dFwuO6ibuA fFIPJBkGqzEwZxazNMKwqDEOpedkTAgLGqMevDhaOuRsA8NWGIign2C6nVRY37NEm69VL25urdFa Fy6ev6B5wQJJWr8GChcsXNjcDMfWplatdVFLW0ubRR5Op0faGxrGx8frYxnBhxKx3DkR1pYlg+OE FzAFYVCAaV1iM8zQLrBZCTDwdWSSJiOhSFDrCdK5kYIVa3HjX8HdMJyORRti6XgwFm6IpW4IEjtR Twr/iw3Gw1EoDf/9JuSqweAjrQ3OUIKGwcQBiVNHF0JAbIHFfAtcf0Rdgcz9HuosEpeIOC0D7NfY Q+yz7HPwOc4+xX4nB1eQOgaZ619S3OHz+gqfh43i44q5hdwabiV3KRzboHaQhogDhjsyjA/iB1hE XTzyECZJ3TOCA6H/B3WybT5lbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMzIxID4+CnN0cmVhbQp4nF2S3YqDMBCF7/MUuexeFDVV2wUR+kPB i/1h3T6ATcZuYI0hphe+/SYz0sIKKl/OnMzRSXJsTo3RniefbpQteN5roxxM491J4Fe4acMywZWW fiF8yqGzLAnmdp48DI3pR1ZVnCdfQZ28m/lqr8YrvLDkwylw2tz46nJsA7d3a39hAON5yuqaK+jD Tm+dfe8G4Ana1o0KuvbzOnieFd+zBS6QM0ojRwWT7SS4ztyAVWm4al6dw1UzMOqfviXXtZc/ncPq TahOU5HWkbId0qYg2hNtkYQgOiNtjkjFK1JOWkHalrRziQmWXo/Oz6AHLMtKSrCjnuTNTtSMthc5 UYqvPKMESx4KmVPrnCoLspdUeaBvPERNxA64WNBiSYu7JSuliz8uDvgxFXl3LgwETwFOIs5AG3gc FDva6Ir3H0JSpg1lbmRzdHJlYW0KZW5kb2JqCjE0IDAgb2JqCjw8IC9UeXBlIC9PYmpTdG0gL0xl bmd0aCA3MTMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL04gOSAvRmlyc3QgNjEgPj4Kc3RyZWFtCnic xVRNT9tAEL33V8wRDtnvL0sIKZAGoooWEVoOKAcTb1OriR05jtT8+8464N3QUKlVpR5sr3dn3ryZ NztcAwNuQHLgFrQG7nBhgGcgMguCgVT44aAN7gjgihkQEl0Ef3d2BvS2qYvt3DdwMv1e5vR2NIaV 1adwft4dX9wA/Vg3q3wJdJ4D7/fzjR/XVQt02JT58uYe6Mhv5r4q8qoNBxt4DGEZ3MEM6PtqXhdl tQA6KXzVlu1ucA10un1qd2sP9B7fDD/156pEQw9cdp7dAdAu0C+Br/Jtm6/Ko4HlXwfmbwW+rLf4 I4B+KIsQw3WGfYZ7h9t84TcvHsNAq4WMaSKsVAox8vW1LxffWrBcEycYyvZMv4WB4JxknUB0vMwX G1B7BhcX9Q8MODBGEa2ZdTCQQhHLLJOosHBEIhJwJi3hLJMu8AmO43LpUXKxTynsfMxXPpFs0ubL cj6sFkuPNnTa+tUXUMgscwphkioEkk25buvmNx1wORlNdxsEmVRfawhGn5rCN6H8Jy/lPwV65xfl pm12cDIs6id/GvRYr5d+FarAEL9Duq+vJqObfB2Vw1I9BJqv+GCPd/n1oqJzMAnkxYGS9AHLyPCx OvgwENYS1xVvFpTHSkkpCcMS89CCjyBdRrhheMG0k2RflegUjePeASReOYeX0hCuhVR4I0NvJga4 95icMzDGkCwT6BhXVgjkYPE2x1VixxnCITOwPXC0i8E0S9FjTNfnwBKEJPoR1KPRj5xmShKnrDEH mc1wDSblYIMmgWDcSooWUzh2GlPtVwEp/sUEZ4Avl3o7HTTuDTrHY+FwP+Y3gyy0yr6kXBxKiKLb DIcwSzupe0TCafZ6RAgslHDYcsmIMIYRo5SWyYhwXBD9xnjgyrzMj2c7HkgbbXA2cIkDo1sezgb2 ejb0U/XfzIYe7j/NBvHHsyGoOtsr9BN9++GdZW5kc3RyZWFtCmVuZG9iagoxIDAgb2JqCjw8IC9D b250ZW50cyAyIDAgUiAvTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIC9QYXJlbnQgMTkgMCBSIC9S ZXNvdXJjZXMgPDwgL0V4dEdTdGF0ZSA8PCAvRzMgMTYgMCBSID4+IC9Gb250IDw8IC9GNCAxNyAw IFIgPj4gL1Byb2NTZXRzIFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdID4+ IC9TdHJ1Y3RQYXJlbnRzIDEgL1R5cGUgL1BhZ2UgPj4KZW5kb2JqCjIgMCBvYmoKPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzNzkwID4+CnN0cmVhbQp4nO2d0Y7kthFF3+cr5jmAZVKU KAkIAnjWO35OsEA+ILENBHCAOP8PRNPd001650zXldhkZ3ezgGOrV6JIkaxbt24V/aNb/3zn139M S//4j98e/vPwciX6/nDh958f/v6nx3+vV7tpPPzd4/9/d/rb/vHlz99+ejz+y++/Pnz/U3j89b/r Q7wb4+Ps4/Ff1gf9Qhfd4UrvfX+88tf1T/oavuvHUm8y3qgJP/aHJpbodrRwet7Tp4fvn4d1RLoQ Hj/98uAvX8k9fvrtYYnrf/j1n5/++fhn5/rpL4+f/vXgx25w/bDE8PK3Dr8MHw6/DN0U5iGE+fzD GI+3uC7GwcV+vNyCv4zz8RffzdHHZQiGp73TDr5aj834wy8fP910cP2ydN4t6xulY+xCwbb90MVx Wf8349ft+6lVy8Nry+H8JQbnvHPT5UuMp483zy4O4/zHrxrWN4t+WJKZ+MPhh7nzo/duMtxx+tpv 3DHQD8/wqNMQDp2b/DKNl36EAXs4q63jmIwTtH5aalMX+tknSwNfl8fKHfvRd72bp8kljQd1sAbq OTfCt6TfsA9vD0l0w9uja7ohHZI4xD9uI4cnuSXdkjz84J6SDzh9vose2wiD4UnpB1z8+Xp/3g3H eejH5dLCE3Qb5xT2Lv1Is/PQi2ykZmgcv7f7AK+VdTz7TBO00b99faB3giVDE+0pUqdpQmEXcJjg lagL2EAY09kxL5eXDa+jt4x9DDHZv47PWrppGtdH9VdnIK4vGD/6bjxK4mioDdPz+YV4QSSvtEKT q03jAqJBlVcDL9F0H3iBmteGlUwL76PP1PQHdcBhSY+LODPGarhncn3nwstLpfCnOvCKry0j+GBM hLhrUu9gbIeQyDLZbDimlzteDgyibaFubBgpBI8M4OCtvIe3wv4xCs4MzzTAFrl87iWaFzPvbIZd wYStNiDEbMxX13k7+pDhrAmv58BONXzYtmXW8pBnTahGHV5pGOE6GSWcZipc4ckBXWCzh3MAsL2M DzMXOrkhc2LdPCaIciZE2X+ARnIXJb0F36sfEhAahhme1c+XGdV/hFu48wuNO0Ij09qzLHtfknd6 HwjE0HfzCYjEZkBkbtVycNNbkyr1bNCuM9pANIXetYw2NkAdCxxOm9hAYrFhzzzK3l+at3mUWQ8R YeK4E3iQyUP8UIQSvIPdgm7IhzClbGTWhDkb0TPSKQqi4YjAKob7EDHRc1TQYnJPLQQIvWh4++8X c7x1QoMoM7KQtyKcxikkzsXzuZHepRtKM6aoAuZrjrwmbIUwGX5ZRnE/YCdx/nDzCL5O06EO3RO7 eXExZIijItbx/ct/hXOI72SVqjQ9DFnT+RTKfH8d69Ad+dTOGnmCW7h1MvkM2pCNQSgpB+Zo1ycu lAxvNrap2VJDUAQFdEyBhgv61i6AYoE/OZqBUbWAB4wp7rNNxIRg7EENJfDoybwQ0zNqpKQYASSj DZ7e+nDIhMMVbreGPRiD65Z5OKhdQgvNyckWDu1s4UXvQr6vKQyfmRb/I1gK9uIjNN5Y9EFdLxdG sZl62FVxBeb7c9qLTNqBjyKD+6PouO4SrpisGEZEKJTAw0To46namgzRdXGexmxh1t+OYrvt6Nw0 o2Y9TKrvR+wYYOsy4cd7CIJ87DntLtyGTE/Kgp7G9IDKdekPkoNktLdh1BN/oCeZVJjpLklwzuY1 mDRluoammNNljH7bQtC6GvHmzDbQsxYjemNRXhX0HsfOT36eM8NRPWrXLF44uKo8FkY/7pLFYtNO sVV0gE5WqcZ37d14dkiHduTs0I6cvTSNPiFDw4KBXfQidXcY7YAuWyyGMXFt7pUSW1RblvhnDjpA /FOQz0Uf2cJ62nqtWmvS9hCYy0SRyXU272TE0y3dFhovqatD0FYKufP0IM6F4gkwL/GTynyIzqwU EwfK/PY72jLZadCdqPuTLJqUPtloEL0mt1xMJbF1lKrIBSffHcmyoQl3f8QrZ55uS4bgHoFQBgww wVQW1LFjoON8mZZCH0N2JTCKmQTbbKbNpLlPr8uaXBKoGYAE0kK2CMAuM5I10RJ83PUXkqGehbez ofR8E4KYDmJrysrVTTapCC1yRwC+ucxOxxe7AlD3gi/KpfCIglTZH3tW5wxpIpAKlWelPmc4nbqe ei/Oa9dPoKdJhPAIes5sq05VcBS+WLLAhtRE6oYOk5AGKom4ZFTHAIpMFYEMXR5mcdstD0Izb/Gz LLJB3NYsQizbq97Flm1DVRV1WMP68/BKe7eI5Jxo77kd7T3fB+2NG2E53QO6bJl9NSW3cTd0X7VU Kra+fdl4A0OaDXtOsnRX5WB5Y5OdM3JiccBldTgJvXRy+/ntpvHDkcdTTClgmkvFgjR7fAKZzccK VbKnhT6eSPPT8wsGJIrVXBA1+rJvfnpQFR9oCF04ZTANLdQXR5M9uh3MbwUxBftTpj08K3mW+u82 AeUH+CHLQc72UvQkTfSyyQI/v30Dr1eiaor5OjIbrSaIyqwcs28G+SLtsqZB4j5T7JIq8elkNIFu GxrJxvWHFKanmjmV+NM/KSgtVXt3h1nLcpE5dNkthi0TgKSOc7zusH8JdO2tJxgzqVdK/dWiWPsT xzo20eAd4cU5pp1x4bYUXnTWaeZ8hOt6fWKKRDP9KWc16LzohkSu+/akTA1XZPDCau9e10y7RMqx XSLlpenGBN5tFBT7ah7VjvnEfZHy/5sFLrsVjMnfT34U2ExT7I2CKwHis+E6FLx9Fv3ty0erFay+ iKIFujZALWGUcQ4Zc5guhwgp75gxbXAG8EG6vrXck1QJBZaNk2Wm9/ghaklTqrguSzjXdhrbyUPG izxE9x/0kt3F0mv0Y0821Nm+F5WwBXeoiosN+Q1k/eE6Ih41pejm9ZgsbJ8tSEs4Aql0RHnZxkyF QTHAiXjBpK2Rx08FGGiN9nAeFnhBy6qmgGZ23TAGH7Ldt77/3U5Ac2n6nYrAWeGJ1AHHcBX77F9r 5mgWhs96oZ6DpXp+xtOd0jtUpQemN2ShJhv83lVzLcO6ssXgkbpJ9RPjEMr6J9RjoAnQ5f6Um/Dl 1d6znKuyB17tCl2itS9WK0U9s6XY2V96umzBea9SVjR6KpdAgyEftCW757je+mqIZPKxeznwNWS4 pLobHt03SFQFEu060mGfHhepNr5D9pRVHa0s1LWV8tylUVKP39O1Guphr8WOPth4tOCVWHh6Cogt oJkcD6If2VnVVx67Po6H3Tm2q7EU29VYinUL4H/thcOuyGZ3sZhqWVyT4FSXs+XeOL4tFi4gL0yt QoA+pnwedrH0lBx7+aSEYtEyqDpO1nWqJhJ/X4idOFnxQAecUKW4XZuS2HYeoM1amg4KlAW6tkWc RmTlQ+1VIHoHarb1Nc8OXGwnZ4vt5GyXpr9BhLuCCLjCSajFpk9lmWSrW67WEivjnmATkXM81QQ5 PYRAXzQzxOkhi3pVm/tLSKzBZluC0buMOrrYcpakXOfxfXNbpcz2sPZjCAdtd2whKjoUu47NCnzH M4O7gRLt6+WtrJihG14TV2IT2vmAWibXDLVMhoro+vEhJetSUCrPhpJFiKXAh2pbf2ihH1DWh6EB 1QSh6pRl8pTnpqIKxDN48hLiEw7pq9ioZlrQOHbT6Uj3qR3XOrXjWi9N9yP4AAUT4Hj9mcQ5JiEu yw4xyofpiLI8mMuuyUE7fCkQSZaTyCBVePIEQjeH0H+e/fo5kKUNDA9u5xOQ9ROWfA8/UP8y/JRe pzjSCT1dSX/LvsWOs2j3CCTkk89vX4D05podNMTMLOserYUYsrwscup8qPvlUX+oNkspUUQVwPVr ye5mVc3NjzTTxVCGmiC2gL5ebVg/hcAksM+Ao5rwiZTaczU4Mvm5Cyck1q5c/nQhEEhHjFAlq+qS gRuqOYB3yFKefE/LWHDEMIjeZLK7QhUGdNA2nHuHrgpHzRD50JrtFwAy6rHmBU8bVCWmYu6TTtib TgTOJEBUUUkvnWWJtNqIcznIW6gaUTGpVw3Va0nMVahsYrmTAnQ+vVwatczM03V19Gi2lgvxp8TR nhB/zch8nLvolkOl6KlJhnM8NN3kiOz1lrRprBqzAUjI5wcSTpIrMOnMd4X9V99mbWfvZP0Dnl73 5sTcmV250nIlR5u/qJaf0VuwmBYbvFWVgSonxdO1mGS82GE2alFQ+VX1I+s2qCdTnnEfByRzOtiN p1GcBcXy31U4h9Uci3lKenKFLsCgtaXXh4FOZGREdkP7+gGTn7phxYBjBjBqwqojtjmrFvSKKxtK sVC8SpcpWpZSuTDWzqxxufwyOlli5lEF2T4G3EsdKiRb+WLbrNw1fWroTYgRCUaSejVGPShRjulT Ebdas6accrFYnxuel2wRhJqYjW9h4zbgou/G5SggnZroEg+czdxEl3jANZem80BHnBJkqhe11iv3 ErC5Vea+CauLfgtbYLFmHEcgN5Ts2FNHZoMlNOmM5ANS8AYS2FvwWbb3Y3yJkIcBPdmkm2LFm3J8 xO0Np99Ft5mq59y+TFKx8dbPCvnqjL+rJzuJw2r8/bHawtxEAXy0wP11ZoHgp2V6ZKaR65mg5tRy +FWxrdo0meUoBC1U+dB73JIttUVtVD2l3Mnvakq2sNAKpiRAS2lD+WzQPSnxNipF/m7lirI1c/l1 PYGYY7ihGkOzkxPw6E5y1Ldy5QpMEJXFsma21KFb8gLdrIGuc7rW2E3uWKl4bqJDPeKB4ToeQJuM 9eN1KcMeRXd2rGYPP1SWaBvKwN3eHOhBlPszE3I5UVNNQVOi/TW1+rvHXe+k6FVXbEPYQFU3ouSH zd2Phx8OG906UOLaylSJ9KRvNP1X4qnLqEA/W3VbnliVyIHrO/dKHjRRex7BwuU8GzyKU86I3wAW VBTBtQPkSj6QE6sXYuUzxktF7jmPgE6Ug87hdaQb1LPv9pXW3WU49T4UOxjHkD5pSwzRBQ678HZ6 YI4p9bkY3M7ia/LU+HpSQ7I5kHbOBcOSoL0MRaC7MLoJj+xC6KbzHWWlyQcYpZpJIONyFhTMzepC zSBl+B/X7zdHZW5kc3RyZWFtCmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9YUmVmIC9MZW5ndGgg MjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0RlY29kZVBhcm1zIDw8IC9Db2x1bW5zIDQgL1ByZWRp Y3RvciAxMiA+PiAvVyBbIDEgMiAxIF0gL1NpemUgNCAvSUQgWzwzZDJiOGU4YjQ5YmZmZDI3MmIz YTYyZjZmNzljMTZlZj48M2QyYjhlOGI0OWJmZmQyNzJiM2E2MmY2Zjc5YzE2ZWY+XSA+PgpzdHJl YW0KeJxjYgACJsY5VQxMDIwPgAS/GAMAFKsCJgplbmRzdHJlYW0KZW5kb2JqCiAgICAgICAgICAg ICAgICAKc3RhcnR4cmVmCjIxNgolJUVPRgo= --000000000000ed2f1f0586bbbbc8-- From nobody Wed Apr 17 08:48:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D649120365 for ; Wed, 17 Apr 2019 08:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, 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 (1024-bit key) header.d=fb.com header.b=iMi+XplI; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=i6BQl/uQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oxcqVutTtQn for ; Wed, 17 Apr 2019 08:48:30 -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 1723B120110 for ; Wed, 17 Apr 2019 08:48:30 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.27/8.16.0.27) with SMTP id x3HFlgdL030966; Wed, 17 Apr 2019 08:48:24 -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=pMJmunSAi/WBqqfD8DyHnUVJNiLSFHEDhsck0YntKbg=; b=iMi+XplIi4z/rC4DIAv7zKXxD8tc2P9dZlFaE6enn0/OTOVIQ/rUY2IOuKbbhdpmo5ap 90XYiQEHpQpmgjlDAuTR4aEo2osx4h4kLVakCa75ybf5pLzloXTjFCsOLIA7YYt9bCmk utM3D7wVnPPXXAjawpeyN30F/MvYknWk73g= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0001303.ppops.net with ESMTP id 2rwm8mbmfg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Apr 2019 08:48:24 -0700 Received: from frc-hub03.TheFacebook.com (2620:10d:c021:18::173) by frc-hub05.TheFacebook.com (2620:10d:c021:18::175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 17 Apr 2019 08:48:23 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5 via Frontend Transport; Wed, 17 Apr 2019 08:48:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pMJmunSAi/WBqqfD8DyHnUVJNiLSFHEDhsck0YntKbg=; b=i6BQl/uQvKhXn0kucfrgo4z+auxrKD8h/lDRGBigCVa6wQxoZpgZLMNPzOjjXhr79hE9WI+iS4NE7B7Cyjg2xUgMESF3ON0OYWW//nLZqFj+ryBIHDxTxrNAVQQUHAfVYfMRjo3zWqiZw0dNwf+Qm5r6uLixAzZbqrG/cyEilBc= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2790.namprd15.prod.outlook.com (20.179.158.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Wed, 17 Apr 2019 15:48:22 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7%2]) with mapi id 15.20.1792.018; Wed, 17 Apr 2019 15:48:22 +0000 From: Roberto Peon To: Ian Swett , IETF QUIC WG Subject: Re: Some notes about WebRTC and QUIC Thread-Topic: Some notes about WebRTC and QUIC Thread-Index: AQHU9TRBIGSSNQIoxkqkWoJwCF+AV6ZACjaA Date: Wed, 17 Apr 2019 15:48:22 +0000 Message-ID: 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.18.0.190412 x-originating-ip: [2620:10d:c090:200::1ab6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ac2b5777-0314-4efc-16ac-08d6c34c1ef1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR15MB2790; x-ms-traffictypediagnostic: BYAPR15MB2790: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(346002)(376002)(136003)(189003)(199004)(53546011)(102836004)(99286004)(6506007)(46003)(83716004)(71200400001)(71190400001)(97736004)(229853002)(478600001)(186003)(76176011)(6436002)(68736007)(2616005)(476003)(11346002)(446003)(8676002)(81156014)(6486002)(8936002)(81166006)(486006)(6246003)(2906002)(105586002)(4744005)(6116002)(110136005)(256004)(106356001)(54896002)(58126008)(6512007)(6306002)(5024004)(53936002)(14454004)(14444005)(33656002)(25786009)(316002)(86362001)(5660300002)(7736002)(36756003)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2790; H:BYAPR15MB2312.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pkMWa4e8gyXSf+KB8EGA95ersLcHZArDL0gDhpnOCrYFi+XyI1Q0Io2voDfTfWMZZljeL3T5rRuMairg07ZQec4SsohoxxPsyOgGeK6qFTsexONsX6O4qA9awNQUIfzBbGrigyn7Z4pFr5LR9SkzM7bjmb0sghP7JMOnugPlOK2ap1FZjDZZggcJ/iOTwNg2qYZnAgNkqXbQrvUhwqFIzwm1nKPfkqSaoIjMa57mtkGU6Em7/QCb8wsd/aZFtH4FNVHln/RNtI4lXPjj7Knfj8qUMHs7W4RW73ArpolJiPdl61mVZ6bw3IFbmH6fyowbgz8ctw5+/MiHXNMuM34/yjSFjbV9d3f7/l47u166KtvSCYdi0x76/cHVf+haAj8Hzp7OLO/9j+mYqg/MDd6JN65+zV3p76VM2oRI9Qy7GY8= Content-Type: multipart/alternative; boundary="_000_B317901993B043398CCC5BCA63D0ED60fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ac2b5777-0314-4efc-16ac-08d6c34c1ef1 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 15:48:22.1729 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2790 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-17_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 15:48:32 -0000 --_000_B317901993B043398CCC5BCA63D0ED60fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIElhbiENCg0KV2VyZSB0aGUg4oCcQ2hhbGxlbmdlc+KAnSBpbiBhbnkgcGFydGljdWxh ciBvcmRlcj8NCg0KSXQgd291bGQgYmUgcmVhbGx5IHF1aXRlIGludGVyZXN0aW5nIHRvIGdldCBh IGdvb2QgZmVlbCBmb3IgdGhlIHNldmVyaXR5L2ltcGFjdCBvZiB0aGUgbGFjay1vZi1mZWF0dXJl cy9jaGFsbGVuZ2VzIQ0KDQotPVINCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0 Zi5vcmc+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDE3LCAyMDE5IGF0IDg6NDMgQU0NClRvOiBJ RVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBTb21lIG5vdGVzIGFib3V0IFdl YlJUQyBhbmQgUVVJQw0KDQpXaGVuIGluIFByYWd1ZSwgSSBvcmdhbml6ZWQgYSBzbWFsbCBXZWJS VEMgb3ZlciBRVUlDIGx1bmNoIHRvIGRpc2N1c3Mgd2hhdCBpdCBtaWdodCBsb29rIGxpa2UgYW5k IHdoYXQgdGhlIGdvYWxzIGFyZS4NCg0KQXR0YWNoZWQgYXJlIHNvbWUgbm90ZXMgZnJvbSB0aGUg Y29udmVyc2F0aW9uLg0KDQpUaGFua3MsIElhbg0KDQo= --_000_B317901993B043398CCC5BCA63D0ED60fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDIgMyAzIDIgMjt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgSWFuITxicj4NCjxicj4NCldlcmUg dGhlIOKAnENoYWxsZW5nZXPigJ0gaW4gYW55IHBhcnRpY3VsYXIgb3JkZXI/PGJyPg0KPGJyPg0K SXQgd291bGQgYmUgcmVhbGx5IHF1aXRlIGludGVyZXN0aW5nIHRvIGdldCBhIGdvb2QgZmVlbCBm b3IgdGhlIHNldmVyaXR5L2ltcGFjdCBvZiB0aGUgbGFjay1vZi1mZWF0dXJlcy9jaGFsbGVuZ2Vz ITxicj4NCjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+UVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgSWFuIFN3 ZXR0ICZsdDtpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPldlZG5lc2RheSwgQXByaWwgMTcsIDIwMTkgYXQgODo0MyBBTTxicj4NCjxiPlRv OiA8L2I+SUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5Tb21lIG5vdGVzIGFib3V0IFdlYlJUQyBhbmQgUVVJQzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiBpbiBQcmFndWUs IEkgb3JnYW5pemVkIGEgc21hbGwgV2ViUlRDIG92ZXIgUVVJQyBsdW5jaCB0byBkaXNjdXNzIHdo YXQgaXQgbWlnaHQgbG9vayBsaWtlIGFuZCB3aGF0IHRoZSBnb2FscyBhcmUuDQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0dGFjaGVkIGFyZSBzb21lIG5v dGVzIGZyb20gdGhlIGNvbnZlcnNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLCBJYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B317901993B043398CCC5BCA63D0ED60fbcom_-- From nobody Wed Apr 17 08:52:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD64120406 for ; Wed, 17 Apr 2019 08:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 hGTYWH3MKHdB for ; Wed, 17 Apr 2019 08:52:52 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DFA120399 for ; Wed, 17 Apr 2019 08:52:52 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id k11so32643613wro.5 for ; Wed, 17 Apr 2019 08:52: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=DY11UCrKqb70GYUKVgYH7N1F7NrNFcl7EwyD1dhQMiA=; b=M5JiJu6+8ddqujydXJdVqPx1U0LRG6J6Zt7GY0GBOojtGZkmbpo7y0UvgfVhHB9E1T dVkTbjBDNYHWq0jE8+XCrSmbrIhp4v2hcVIr+UQSEk9ZF8K1dKsIPC2RlLyMp08uoMb8 ZNAy26PImBef7iRVQMqg9BgwbPZ4ZUAofdty6dnHSUj/URiKqgrpPGX8kF+rQELfqa+y wliSx1Ta2piax41zXpQ6t5sFXqLEK+FWvvp/qP1kRmjHTWzkHwEz6ZLo9fiAv+ZsOY42 x7n0p+RMxgoJjyj39lcM6n7OSAK39czsJ4MejPNJwFPILKj1vX7Vkn1GoWveQp8KyVpH SE3g== 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=DY11UCrKqb70GYUKVgYH7N1F7NrNFcl7EwyD1dhQMiA=; b=ATpA7mk/Mun89bC2GqjvtzxpQUJ6W4biKm8TxHj6FPk6ovCnHUndIFoO4ZH0OgjRux WppZEsm9LgU6r5gAfrPDxlAe6JqWUF5kIrNhaqHR8ucEydss+gIVnlCWVnlxm4GURQcD +SrW6TiLYAFUV4ZYy24FLhcMALeYp0iWiCUpoNp+ENWpefOXDG53yLN8tSi8uOIu64d3 SjJOz+c9L3qstUQfmC/MgFHBKlra4TTVe+eaJ9GCRd5ycwrC14f78qHtxg/mX53o0tgq RIMqm9icRXppO2bPO6y+CwRz0Ab1fL3ER7NQ/xMHCVHBfGTNI7DQGIVpswj/3dBRZpYe hSwg== X-Gm-Message-State: APjAAAXAokUoMV8+b/jM10qrfeIpd/enxTZR6tbL+72dnfVjivs13x6c 4A4SowYY+tu2sLpmfdnZ+yZx4zPIex/RFFbR+MjO9g== X-Google-Smtp-Source: APXvYqz0OgpPtWxgjztYIWmPNlCz12aCCvpNmfBT5q1QYzHC1TQNE1/fOW0/Q9witmFMaob4Uv2BBItnEcq6poTssI4= X-Received: by 2002:adf:eb87:: with SMTP id t7mr3595110wrn.39.1555516370453; Wed, 17 Apr 2019 08:52:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 17 Apr 2019 11:52:38 -0400 Message-ID: Subject: Re: Some notes about WebRTC and QUIC To: Roberto Peon Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b459e90586bbe030" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 15:52:55 -0000 --000000000000b459e90586bbe030 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The challenges were not in any particular order. Based on my experience, it's absolutely necessary to tune QUIC's ACK behavior for realtime traffic, because they send lots of smaller packets, so it's easy to send as many bytes of ACKs as data with a bit of loss or reordering. Conveniently, that's not overly difficult and I believe i should be possible to create a fairly simple extension to add the necessary features. On Wed, Apr 17, 2019 at 11:48 AM Roberto Peon wrote: > Thanks Ian! > > Were the =E2=80=9CChallenges=E2=80=9D in any particular order? > > It would be really quite interesting to get a good feel for the > severity/impact of the lack-of-features/challenges! > > -=3DR > > > > *From: *QUIC on behalf of Ian Swett 40google.com@dmarc.ietf.org> > *Date: *Wednesday, April 17, 2019 at 8:43 AM > *To: *IETF QUIC WG > *Subject: *Some notes about WebRTC and QUIC > > > > When in Prague, I organized a small WebRTC over QUIC lunch to discuss wha= t > it might look like and what the goals are. > > > > Attached are some notes from the conversation. > > > > Thanks, Ian > > > --000000000000b459e90586bbe030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The challenges were not in any particular order.

B= ased on my experience, it's absolutely necessary to tune QUIC's ACK= behavior for realtime traffic, because they send lots of smaller packets, = so it's easy to send as many bytes of ACKs as data with a bit of loss o= r reordering.=C2=A0 Conveniently, that's not overly difficult and I bel= ieve i should be possible to create a fairly simple extension to add the ne= cessary features.

On Wed, Apr 17, 2019 at 11:48 AM Roberto Peon <fenix@fb.com> wrote:

Thanks Ian!

Were the =E2=80=9CChallenges=E2=80=9D in any particular order?

It would be really quite interesting to get a good feel for the severity/im= pact of the lack-of-features/challenges!

-=3DR

=C2=A0

From: = QUIC <quic-bounces@ietf.org>= ; on behalf of Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
Date: Wednesday, April 17, 2019 at 8:43 AM
To: IETF QUIC WG <quic@ietf.org>
Subject: Some notes about WebRTC and QUIC

=C2=A0

When in Prague, I organized a small WebRTC over QUIC= lunch to discuss what it might look like and what the goals are.

=C2=A0

Attached are some notes from the conversation.

=C2=A0

Thanks, Ian

=C2=A0

--000000000000b459e90586bbe030-- From nobody Wed Apr 17 09:06:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D167412044D for ; Wed, 17 Apr 2019 09:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, 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 (1024-bit key) header.d=fb.com header.b=cNtcEK3F; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=hY700JMu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6RayZlmp-Pj for ; Wed, 17 Apr 2019 09:06:54 -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 8529E12039C for ; Wed, 17 Apr 2019 09:06:54 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.27/8.16.0.27) with SMTP id x3HFw6CH008001; Wed, 17 Apr 2019 09:06:51 -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=+R5030OD6X9V8iaiTJ4IZV/yt5x/8OVQOVhPB2nBUKk=; b=cNtcEK3Ft5JcabHusezlTMDgBZGCVed8/NYWLzdZaoKzvpqbrW8x4ff4ehmGjMeahtB8 C0q0it9Vug3yWqyAKxBUUWa+ulPeQKpDss8IJyN1SGpWSEaZ1hy4u9hLnbyqGsyvuj/n kZMbEeh6nRjdlPfVXWH+sIzFSlLW7iJXoio= Received: from mail.thefacebook.com (mailout.thefacebook.com [199.201.64.23]) by m0001303.ppops.net with ESMTP id 2rwm8mbpqc-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Apr 2019 09:06:51 -0700 Received: from prn-hub01.TheFacebook.com (2620:10d:c081:35::125) by prn-hub03.TheFacebook.com (2620:10d:c081:35::127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 17 Apr 2019 09:06:44 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5 via Frontend Transport; Wed, 17 Apr 2019 09:06:44 -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:X-MS-Exchange-SenderADCheck; bh=+R5030OD6X9V8iaiTJ4IZV/yt5x/8OVQOVhPB2nBUKk=; b=hY700JMuMmJs0EIO98UdimhNnY6fal+flS2j7xOGZbO+T8/CgN1PJuTC/4ttqHzV2TVF2COd7dEl1whMan6EL42iQ2s4oOpDXa/q2rHV5ymnAQTMCYETqODxncrV7A0X2cE5Gh5SIP2KGqS2BWK7TFnt7/2ULEkJD+Mpk0oNImE= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB3288.namprd15.prod.outlook.com (20.179.57.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Wed, 17 Apr 2019 16:06:43 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::91d3:bc32:a475:76d7%2]) with mapi id 15.20.1792.018; Wed, 17 Apr 2019 16:06:43 +0000 From: Roberto Peon To: Ian Swett CC: IETF QUIC WG Subject: Re: Some notes about WebRTC and QUIC Thread-Topic: Some notes about WebRTC and QUIC Thread-Index: AQHU9TRBIGSSNQIoxkqkWoJwCF+AV6ZACjaAgAB2iwD//46VAA== Date: Wed, 17 Apr 2019 16:06:42 +0000 Message-ID: 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.18.0.190412 x-originating-ip: [2620:10d:c090:200::1ab6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70dfdab4-ae47-43f5-4538-08d6c34eaf0c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR15MB3288; x-ms-traffictypediagnostic: BYAPR15MB3288: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39860400002)(396003)(376002)(366004)(199004)(189003)(82746002)(102836004)(53936002)(6116002)(316002)(68736007)(5024004)(14444005)(58126008)(256004)(6246003)(4326008)(229853002)(6916009)(33656002)(105586002)(36756003)(186003)(14454004)(53546011)(6506007)(86362001)(76176011)(83716004)(5660300002)(6436002)(2906002)(46003)(99286004)(97736004)(71190400001)(106356001)(8676002)(71200400001)(81156014)(25786009)(6512007)(486006)(81166006)(446003)(11346002)(2616005)(236005)(8936002)(7736002)(476003)(54896002)(6306002)(6486002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB3288; H:BYAPR15MB2312.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QKCjGDBup7M2/b3zpB6c6NZgadlAW9Ry9MqkWQHwHuB0RbfxsqRotZfqFCQLEo6/5WhOkRw9sZHwL9PO0yrjxYdaKi3T/lbpIKN6JktmV51wcquLAi4WbPZJwW2fwfQTDjxBB53+7kaY5TNxqXtuoP8X7jpXXII1UHm3NmdCkReledCCueTS7e+mg9YanXE8xOnaupKV/jMmHMm08r1XKN+j63IVmD/ZsFaIO2wVYRIsjtujpJf9kuE0o58088ZT9UXHq1unR1qg0TNiXJgbTUaCMGzfp3j+doDbVbzQ9StFJm6liMBfpYRCM61IClz9Xk/+WCG13Vg1IqQJX9hMHSPF5SfMxeALN7ghgDTIaZliFGBPibQk5jyQevC0WndvLZqdiB6bUTaFl9FsbhEJRHwcGLg6UIMkObbEgUZVAH4= Content-Type: multipart/alternative; boundary="_000_F73F272BDCDE4B6DAA85650666ACC8ACfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 70dfdab4-ae47-43f5-4538-08d6c34eaf0c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 16:06:42.9344 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3288 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-17_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 16:06:56 -0000 --_000_F73F272BDCDE4B6DAA85650666ACC8ACfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFrZXMgc2Vuc2UuDQoNCknigJlkIGltYWdpbmUgdGhhdCBJ4oCZZCB3YW50IG15IGNoYXJhY3Rl cnMgYWNr4oCZZCBuZWFybHkgaW1tZWRpYXRlbHkgZm9yIHRoaW5ncyBsaWtlIHNzaCBldmVuIHdo ZW4gdGhlIHJhdGlvIG9mIGJ5dGVzL2Fja3MgaXMgcG9vciwgYnV0IG15IFZvRCB2aWRlbyBjYW4g YnVuZGxlIGFja3Mgb24gbG9uZ2VyIHRpbWVmcmFtZXMsIGFuZCBjYW4gcmVhc29uYWJseSBkbyBo aWdoZXIgYWNrcy9ieXRlcyBwcm9wb3J0aW9uYWwgdG8gdGhlIGNsaWVudC1idWZmZXIgdXAtdG8s IEkgZ3Vlc3MsIEJEUC4NCg0KV2VyZSB5b3UgdGhpbmtpbmcgYWJvdXQgcGVyLXN0cmVhbSBoaW50 aW5nIG9yIHBlci1jb25uZWN0aW9uIG9yIHNvbWV0aGluZyBlbHNlPw0KLT1SDQoNCg0KRnJvbTog SWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBBcHJpbCAx NywgMjAxOSBhdCA4OjUzIEFNDQpUbzogUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQpDYzog SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFNvbWUgbm90ZXMgYWJv dXQgV2ViUlRDIGFuZCBRVUlDDQoNClRoZSBjaGFsbGVuZ2VzIHdlcmUgbm90IGluIGFueSBwYXJ0 aWN1bGFyIG9yZGVyLg0KDQpCYXNlZCBvbiBteSBleHBlcmllbmNlLCBpdCdzIGFic29sdXRlbHkg bmVjZXNzYXJ5IHRvIHR1bmUgUVVJQydzIEFDSyBiZWhhdmlvciBmb3IgcmVhbHRpbWUgdHJhZmZp YywgYmVjYXVzZSB0aGV5IHNlbmQgbG90cyBvZiBzbWFsbGVyIHBhY2tldHMsIHNvIGl0J3MgZWFz eSB0byBzZW5kIGFzIG1hbnkgYnl0ZXMgb2YgQUNLcyBhcyBkYXRhIHdpdGggYSBiaXQgb2YgbG9z cyBvciByZW9yZGVyaW5nLiAgQ29udmVuaWVudGx5LCB0aGF0J3Mgbm90IG92ZXJseSBkaWZmaWN1 bHQgYW5kIEkgYmVsaWV2ZSBpIHNob3VsZCBiZSBwb3NzaWJsZSB0byBjcmVhdGUgYSBmYWlybHkg c2ltcGxlIGV4dGVuc2lvbiB0byBhZGQgdGhlIG5lY2Vzc2FyeSBmZWF0dXJlcy4NCg0KT24gV2Vk LCBBcHIgMTcsIDIwMTkgYXQgMTE6NDggQU0gUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb208bWFp bHRvOmZlbml4QGZiLmNvbT4+IHdyb3RlOg0KVGhhbmtzIElhbiENCg0KV2VyZSB0aGUg4oCcQ2hh bGxlbmdlc+KAnSBpbiBhbnkgcGFydGljdWxhciBvcmRlcj8NCg0KSXQgd291bGQgYmUgcmVhbGx5 IHF1aXRlIGludGVyZXN0aW5nIHRvIGdldCBhIGdvb2QgZmVlbCBmb3IgdGhlIHNldmVyaXR5L2lt cGFjdCBvZiB0aGUgbGFjay1vZi1mZWF0dXJlcy9jaGFsbGVuZ2VzIQ0KDQotPVINCg0KRnJvbTog UVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+ PiBvbiBiZWhhbGYgb2YgSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0 Zi5vcmc8bWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBXZWRuZXNk YXksIEFwcmlsIDE3LCAyMDE5IGF0IDg6NDMgQU0NClRvOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogU29tZSBub3RlcyBhYm91dCBX ZWJSVEMgYW5kIFFVSUMNCg0KV2hlbiBpbiBQcmFndWUsIEkgb3JnYW5pemVkIGEgc21hbGwgV2Vi UlRDIG92ZXIgUVVJQyBsdW5jaCB0byBkaXNjdXNzIHdoYXQgaXQgbWlnaHQgbG9vayBsaWtlIGFu ZCB3aGF0IHRoZSBnb2FscyBhcmUuDQoNCkF0dGFjaGVkIGFyZSBzb21lIG5vdGVzIGZyb20gdGhl IGNvbnZlcnNhdGlvbi4NCg0KVGhhbmtzLCBJYW4NCg0K --_000_F73F272BDCDE4B6DAA85650666ACC8ACfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDIgMyAzIDIgMjt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFrZXMgc2Vuc2UuPGJyPg0KPGJyPg0KSeKAmWQgaW1hZ2lu ZSB0aGF0IEnigJlkIHdhbnQgbXkgY2hhcmFjdGVycyBhY2vigJlkIG5lYXJseSBpbW1lZGlhdGVs eSBmb3IgdGhpbmdzIGxpa2Ugc3NoIGV2ZW4gd2hlbiB0aGUgcmF0aW8gb2YgYnl0ZXMvYWNrcyBp cyBwb29yLCBidXQgbXkgVm9EIHZpZGVvIGNhbiBidW5kbGUgYWNrcyBvbiBsb25nZXIgdGltZWZy YW1lcywgYW5kIGNhbiByZWFzb25hYmx5IGRvIGhpZ2hlciBhY2tzL2J5dGVzIHByb3BvcnRpb25h bCB0byB0aGUgY2xpZW50LWJ1ZmZlcg0KIHVwLXRvLCBJIGd1ZXNzLCBCRFAuPGJyPg0KPGJyPg0K V2VyZSB5b3UgdGhpbmtpbmcgYWJvdXQgcGVyLXN0cmVhbSBoaW50aW5nIG9yIHBlci1jb25uZWN0 aW9uIG9yIHNvbWV0aGluZyBlbHNlPzxicj4NCi09Ujxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SWFuIFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29n bGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEFwcmlsIDE3LCAyMDE5IGF0 IDg6NTMgQU08YnI+DQo8Yj5UbzogPC9iPlJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0 Ozxicj4NCjxiPkNjOiA8L2I+SUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogU29tZSBub3RlcyBhYm91dCBXZWJSVEMgYW5kIFFVSUM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBjaGFsbGVuZ2VzIHdlcmUgbm90IGluIGFueSBwYXJ0aWN1bGFyIG9yZGVyLiA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpCYXNlZCBvbiBteSBl eHBlcmllbmNlLCBpdCdzIGFic29sdXRlbHkgbmVjZXNzYXJ5IHRvIHR1bmUgUVVJQydzIEFDSyBi ZWhhdmlvciBmb3IgcmVhbHRpbWUgdHJhZmZpYywgYmVjYXVzZSB0aGV5IHNlbmQgbG90cyBvZiBz bWFsbGVyIHBhY2tldHMsIHNvIGl0J3MgZWFzeSB0byBzZW5kIGFzIG1hbnkgYnl0ZXMgb2YgQUNL cyBhcyBkYXRhIHdpdGggYSBiaXQgb2YgbG9zcyBvciByZW9yZGVyaW5nLiZuYnNwOyBDb252ZW5p ZW50bHksIHRoYXQncyBub3Qgb3Zlcmx5DQogZGlmZmljdWx0IGFuZCBJIGJlbGlldmUgaSBzaG91 bGQgYmUgcG9zc2libGUgdG8gY3JlYXRlIGEgZmFpcmx5IHNpbXBsZSBleHRlbnNpb24gdG8gYWRk IHRoZSBuZWNlc3NhcnkgZmVhdHVyZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDE3LCAyMDE5IGF0IDExOjQ4IEFNIFJv YmVydG8gUGVvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZlbml4QGZiLmNvbSI+ZmVuaXhAZmIuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIElhbiE8YnI+DQo8YnI+DQpX ZXJlIHRoZSDigJxDaGFsbGVuZ2Vz4oCdIGluIGFueSBwYXJ0aWN1bGFyIG9yZGVyPzxicj4NCjxi cj4NCkl0IHdvdWxkIGJlIHJlYWxseSBxdWl0ZSBpbnRlcmVzdGluZyB0byBnZXQgYSBnb29kIGZl ZWwgZm9yIHRoZSBzZXZlcml0eS9pbXBhY3Qgb2YgdGhlIGxhY2stb2YtZmVhdHVyZXMvY2hhbGxl bmdlcyE8YnI+DQo8YnI+DQotPVI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+UVVJQyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTxhIGhyZWY9Im1haWx0bzo0MGdvb2dsZS5jb21A ZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEFwcmlsIDE3LCAyMDE5IGF0 IDg6NDMgQU08YnI+DQo8Yj5UbzogPC9iPklFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+U29tZSBub3RlcyBhYm91dCBXZWJSVEMgYW5kIFFVSUM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5XaGVuIGluIFByYWd1ZSwgSSBvcmdhbml6ZWQgYSBzbWFsbCBXZWJSVEMgb3ZlciBRVUlDIGx1 bmNoIHRvIGRpc2N1c3Mgd2hhdCBpdCBtaWdodCBsb29rIGxpa2UgYW5kIHdoYXQgdGhlIGdvYWxz IGFyZS4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkF0dGFjaGVkIGFyZSBzb21lIG5vdGVzIGZyb20gdGhlIGNvbnZlcnNhdGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcywg SWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F73F272BDCDE4B6DAA85650666ACC8ACfbcom_-- From nobody Wed Apr 17 16:48:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC06120254 for ; Wed, 17 Apr 2019 16:48:17 -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 CBlcF6bLh0Fn for ; Wed, 17 Apr 2019 16:48:14 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 A957612024C for ; Wed, 17 Apr 2019 16:48:13 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id h21so224526ljk.13 for ; Wed, 17 Apr 2019 16:48:13 -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=i2V7UZr0jXCgVqJHsvj77DOdNXwzl03NDUqYMgVgP7k=; b=cesSo3c/+hWV5xcSKw6bVKSgD/5gxIcXLumTLYbGVcp3XmtIuH1cE/0xDJNh7JOfq2 Oev7ZOIWoVYSnBP8SCP2A8h5lWe7kMO+QxJ1/zk65ufS+p612FI+GFUlaJzGFTPsASS+ xekmg18bvdT9CueM/yevYsQHQPPViHhZlF1nXxtkWWRxQ436aV/yz5YmGcHv3rrXQGkr pxsaqNFgqdl7i7AMbHqEpbBTTVMRn2aiXkk7S1pO/WJPxb9IWa5fRiMZd6udYWozKwc2 epLhG/N76KvO+VF5IV23SJMXcC8/dQ0XaQULvN/vR77rB10OiUp9ComsxTbcmb+2Nnk7 r6tQ== 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=i2V7UZr0jXCgVqJHsvj77DOdNXwzl03NDUqYMgVgP7k=; b=C4uIVPrJ138kzxi3hjWBTdTsgzobWXkuOR9ongBYWYn68yfcK4jy6JrZ2J8WwazCIM j1JtLyCcSro+gAodqtX4kiYPPyHx48TkhZ/+IGJXke5GH4Q+zHD8n1CtDjc993+sXNRH UVDVNZJonKHtURDBcUZnjE26PhG0ni4RAvMcZLHeSjR4WmPEYol3j6fVkHgE1KtDYSa6 y1L+ZUxoSDcxKn6U4dtldEPtyf30/ENpMVEMPBOc2elRy2roPBK9DicB0bcz8y/oQlIF //OotPjz2a/dgRUx/zphrPj7S++32SP1Cw8VPZ/19+qpLnUjR8ylDugKDBQCAuoD78Hz JQIw== X-Gm-Message-State: APjAAAUJkECCwQS4d+MRL9TK4g68rIJQdU/icKc9Yfp5VPNLieGjena+ AYKohx4/p/Sd37LP9t1E0Tg+XaXBLZUgGT4ca5o= X-Google-Smtp-Source: APXvYqz3fxxkr8Bs2+g26G6MROT0aDzz0HUSNX5EWGGf4jGnve2rLv2ZXsii2ZPs58MoB6mRnv1DDSo1Ua9N+bCyaF8= X-Received: by 2002:a05:651c:114:: with SMTP id a20mr33840875ljb.53.1555544891822; Wed, 17 Apr 2019 16:48:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Thu, 18 Apr 2019 08:47:59 +0900 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: Robin MARX Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b5964f0586c28437" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 23:48:18 -0000 --000000000000b5964f0586c28437 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you for your efforts. quic-trace has already become an indispensable tool for us when testing quicly. I am excited to see a common logging format emerging; it would help us use other tools, and more generally, foster the development of tools to analyze what is going on, that'd help the QUIC stacks mature. One comment regarding how the frames are being logged. I'm not sure what the `class` definitions in the event logs are, but I assume that they represent particular form of JSON objects. I think it might be worth considering to log the frames of QUIC as they are (either in binary or hex-encoded binary), with the exception that the Stream Data field of STREAM frames would be omitted. I suggest this because in my view, the binary encoding described in the transport document is what we are already standardizing; I'd prefer using that for logging rather than having a separate schema just for logging. If we are concerned about the introduction of QUIC extensions breaking the analysis tools, the QUIC stacks can log each QUIC frame as a different hex-encoded JSON string. That'd allow the analysis tools to ignore unknown frame types. WDYT? 2019=E5=B9=B44=E6=9C=8816=E6=97=A5(=E7=81=AB) 19:51 Robin MARX : > Hello everyone, > > In Prague, there were three separate presentations focusing on logging an= d > tooling for QUIC and HTTP/3 (video: > https://www..youtube.com/watch?v=3DLiNLz1QuT0s&feature=3Dyoutu.be&t=3D319= 0 > , > slides: https://datatracker.ietf.org/meeting/104/session/tsvarea). > > There seemed to be a lot of interest in moving this forward. The currentl= y > agreed upon approach is to focus on creating a single logging format and > schema. This will make the creation of reusable tools easier. As a basis > for this, the qlog proposal was chosen. > > Per recommendation of Brian Trammell, we have created two I-Ds for this: > 1) The high-level schema: this is (semi-) protocol agnostic and could > eventually lead to a BOF for a more general wg on this topic. For now, we > focus on the QUIC/H3 use case. > 2) The concrete QUIC and HTTP/3 event definitions: event semantics for > these protocols. > > These documents and examples can be found at: > https://github.com/quiclog/internet-drafts > > We welcome new collaborators and co-authors for these drafts. > There are also several issues in the Github repo that could use some > insightful comments. > In the quicdev slack, there is also a #qlog channel. > > > -------------------------------------------------------------------------= -------------------------------------- > > Even though qlog will be the basis for the "standard" format, several > implementers have started logging in the quic-trace format as well ( > https://github.com/google/quic-trace). > > To help the transition and show that qlog is/should become general enough > to support the use cases from other formats, we have written a small > quic-trace to qlog converter webpage: > > https://quic.edm.uhasselt.be/qtr-to-qlog/ > > This tool ingests the binary .qtr quic-trace protobuf files and converts > them to json-based qlog. > It also includes a rudimentary version of the quic-trace > visualization/tool, as a simple example of how to ingest and process qlog > in web-based tools. > > In time, Victor Vasiliev also plans to add qlog support to the quic-trace > tool. Jari and Marcus of the spindump tool also plan to add qlog support, > as will Maxime Piraux for quic-tracker. Finally, Dmitri and Stephen from > Litespeed already integrated basic qlog support in lsquic, which can be > seen live at https://http3check.net/. We doubt Wireshark will add qlog > output directly, but we also wrote a pcap-to-qlog converter for an early > version of qlog. > > We expect most implementers will not log qlog/json directly, but write > automated transformers from their (binary) formats into qlog. The > qtr-to-qlog and pcap-to-qlog examples shows that this is a perfectly vali= d > approach as well. > > > -------------------------------------------------------------------------= ------------------------------------------- > > At this moment in time, the original qlog tools (see > https://quic.edm.uhasselt.be) are not yet compatible with the new qlog > format. This is something we will be working on in the next few weeks. > > We welcome any and all feedback and ideas for tools and logging amenities= . > > With best regards, > Robin > > -- > > Robin Marx > PhD researcher - web performance > Expertise centre for Digital Media > > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > > > --=20 Kazuho Oku --000000000000b5964f0586c28437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for your efforts.

quic-trace has already become an indispensable tool for u= s when testing quicly. I am excited to see a common logging format emerging= ; it would help us use other tools, and more generally, foster the developm= ent of tools to analyze what is going on, that'd help the QUIC stacks m= ature.

One comment regarding how the frames are be= ing logged.

I'm not sure what the `class` defi= nitions in the event logs are, but I assume that they represent particular = form of JSON objects.

I think it might be worth co= nsidering to log the frames of QUIC as they are (either in binary or hex-en= coded binary), with the exception that the Stream Data field of STREAM fram= es would be omitted.

I suggest this because in my = view, the binary encoding described in the transport document is what we ar= e already standardizing; I'd prefer using that for logging rather than = having a separate schema just for logging.

If we a= re concerned about the introduction of QUIC extensions breaking the analysi= s tools, the QUIC stacks can log each QUIC frame as a different hex-encoded= JSON string. That'd allow the analysis tools to ignore unknown frame t= ypes.

WDYT?

2019=E5=B9=B44=E6=9C=8816=E6=97= =A5(=E7=81=AB) 19:51 Robin MARX <robin.marx@uhasselt.be>:
Hello everyone,

In Prague,= there were three separate presentations focusing on logging and tooling fo= r QUIC and HTTP/3 (video:=C2=A0https= ://www..youtube.com/watch?v=3DLiNLz1QuT0s&feature=3Dyoutu.be&t=3D31= 90, slides:=C2=A0https://datatracker.ietf.org/meeting/104/s= ession/tsvarea).

There seemed to be a lot of i= nterest in moving this forward. The currently agreed upon approach is to fo= cus on creating a single logging format and schema. This will make the crea= tion of reusable tools easier. As a basis for this, the qlog proposal was c= hosen.=C2=A0

Per recommendation of Brian Trammell,= we have created two I-Ds for this:
1) The high-level schema: thi= s is (semi-) protocol agnostic and could eventually lead to a BOF for a mor= e general wg on this topic. For now, we focus on the QUIC/H3 use case.
2) The concrete QUIC and HTTP/3 event definitions: event semantics fo= r these protocols.=C2=A0

These documents and examp= les can be found at:=C2=A0https://github.com/quiclog/internet-drafts

We welcome new collaborators and co-authors for these = drafts.
There are also several issues in the Github repo that cou= ld use some insightful comments.
In the quicdev slack, there is a= lso a #qlog channel.=C2=A0

-----------------------= ---------------------------------------------------------------------------= -------------

Even though qlog will be the basis f= or the "standard" format, several implementers have started loggi= ng in the quic-trace format as well (https://github.com/google/quic-trace).=C2= =A0

To help the transition and show that qlog is/s= hould become general enough to support the use cases from other formats, we= have written a small quic-trace to qlog converter webpage:

<= /div>

This tool ingests the binary .qtr quic-trace protobuf files and converts= them to json-based qlog.=C2=A0
It also includes a rudimentary version o= f the quic-trace visualization/tool, as a simple example of how to ingest a= nd process qlog in web-based tools.=C2=A0

In time,= =C2=A0Victor Vasiliev also plans to add qlog support to the quic-trace tool= . Jari and Marcus of the spindump tool also plan to add qlog support, as wi= ll Maxime Piraux for quic-tracker. Finally, Dmitri and Stephen from Litespe= ed already integrated basic qlog support in lsquic, which can be seen live = at=C2=A0https://http3= check.net/. We doubt Wireshark will add qlog output directly, but we al= so wrote a pcap-to-qlog converter for an early version of qlog.=C2=A0
=

We expect most implementers will not log qlog/json dire= ctly, but write automated transformers from their (binary) formats into qlo= g. The qtr-to-qlog and pcap-to-qlog examples shows that this is a perfectly= valid approach as well.=C2=A0

-------------------= ---------------------------------------------------------------------------= ----------------------

At this moment in time, the= original qlog tools (see https://quic.edm.uhasselt.be) are not yet compatible with t= he new qlog format. This is something we will be working on in the next few= weeks.=C2=A0

We welcome any and all feedback and = ideas for tools and logging amenities.=C2=A0

With = best regards,
Robin

--
=

www.uhasselt.beUniversiteit Hasselt - = Campus Diepenbeek=
Robin=C2=A0Marx
PhD researcher - w= eb performance
Expertise centre for Digital Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2=A0
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
=3D""
<= /div>


--
Kazuho Oku
--000000000000b5964f0586c28437-- From nobody Wed Apr 17 17:28:47 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338BC120033 for ; Wed, 17 Apr 2019 17:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 H-7wLc0xfUVd for ; Wed, 17 Apr 2019 17:28:44 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCFF8120026 for ; Wed, 17 Apr 2019 17:28:43 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id h4so210388uaj.9 for ; Wed, 17 Apr 2019 17:28:43 -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=C12QgcDauwV4wdGzf8GSMBAhtfanUMSwt9mJo/elRts=; b=Q0d7RvmVB36WfjY/n07gxmoYiKqxttL/AiKBB1M70zxhnx2bcu1lcI9xbitrEdHyA1 etdz9X3Wz9Q9PcPRHtswDh2pzgvL5cvj2rFaYpTZF4IVRjlFcmSjcfWGYhuIG01Djf2x 6JPHotXkvjgmW4IRBSSjcZOiirRIKMQb6gZ6U1VbgSx7eQ1gd4pWz6R7La0H061YuHwr Wvp4Z7w2LP2E2YwgAzsgN+ajsxX8qDF4k644/sBTU79KSNAsRbt+LTsQASLYgk0o1mvC g5zQHpYHIDiLLYO26RRc+r/lYJHAuiDSi7/blMibEkl3AHVIqLJd7W4SawRwwDnnU54k 8YpQ== 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=C12QgcDauwV4wdGzf8GSMBAhtfanUMSwt9mJo/elRts=; b=X9fYMSDZdpytpigvwBHj4Q191+mcLwLJSYN4TQyXwML70XN7I/BAtPjnz30aB9ckDw crwSZWSbS8gR0+WMEO7FeSdYWwZkbZK7tz3JR4cdRezT/yZWbhihpeIGR9nhzcxG1O3J OMRPDxlMqcLkBUFIjUqGYdj3I5OobRtgLQbgdGvz19Vc40iHsZsoxkEAityJfyrDaIkW SKLvldw0OmmNxmZ2Rm/1O8MIRGn6jEPcv5BmosQ1RNgRfEgfLUq8VCslBIXnv3BGBYWa ILC1hdN+3r2OcMS/Bw5VgXQAIu8sCdEBXNUUd8jCvJ9sBZYj8geYSze+eum6aOPrnu1M K0eA== X-Gm-Message-State: APjAAAWZoSsyxTNO3EC0KYPuhgk24V6OmESurOgt/LwdqnmxuaLLAreW XYJo4X0PD1rx43jtz77nG2PMesMBkFQIm87SCOg= X-Google-Smtp-Source: APXvYqxi+HsvjscoCcQtc5KMRtsoUnyUa5+3kSjxYJ1NkADtOzIy+hcgFFirxg/RemNRwzXvBLdklujTFJIfHieXy3s= X-Received: by 2002:ab0:348a:: with SMTP id c10mr43259095uar.79.1555547322806; Wed, 17 Apr 2019 17:28:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Thu, 18 Apr 2019 01:28:32 +0100 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: Kazuho Oku Cc: Robin MARX , QUIC WG Content-Type: multipart/alternative; boundary="0000000000009b7fbf0586c315bd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 00:28:45 -0000 --0000000000009b7fbf0586c315bd Content-Type: text/plain; charset="UTF-8" Hi Kazuho, Responding to some points inline. This is just my opinion so I stand to be corrected by Robin. On Thu, 18 Apr 2019, 00:48 Kazuho Oku, wrote: > > I think it might be worth considering to log the frames of QUIC as they > are (either in binary or hex-encoded binary), with the exception that the > Stream Data field of STREAM frames would be omitted. > I can see the appeal of that. However, part of the attraction of logging is that it can give further insight into applications. I had in mind logging in the HTTP/3, which in my implementation is a few steps removed from QUIC frames or packets. More so, much of the time my logging only cares for HTTP/3 frame payload, not complete frames. But perhaps the intent of your suggestion is to compliment the other logs, not replace them? I suggest this because in my view, the binary encoding described in the > transport document is what we are already standardizing; I'd prefer using > that for logging rather than having a separate schema just for logging. > As I understood it, logging adds detail not present in wire image. And it does so in a way that could be compatible with general purpose datastore, analytics etc. > If we are concerned about the introduction of QUIC extensions breaking the > analysis tools, the QUIC stacks can log each QUIC frame as a different > hex-encoded JSON string. That'd allow the analysis tools to ignore unknown > frame types. > I think the current intention is to place unknown data handling burden on tools. For example, a tool focused on congestion control analysis probably has no interest in HTTP/3 fine details. Lucas > > --0000000000009b7fbf0586c315bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kazuho,

Responding to some points inline. This is just my opinion so I st= and to be corrected by Robin.

On Thu, 18 Apr 2019, 00:48 Kazuho O= ku, <kazuhooku@gmail.com> = wrote:

=
I think it might be worth considering to log the frames of QUIC as the= y are (either in binary or hex-encoded binary), with the exception that the= Stream Data field of STREAM frames would be omitted.

I can see the = appeal of that. However, part of the attraction of logging is that it can g= ive further insight into applications. I had in mind logging in the HTTP/3,= which in my implementation is a few steps removed from QUIC frames or pack= ets. More so, much of the time my logging only cares for HTTP/3 frame paylo= ad, not complete frames.

But perhaps the intent of your suggestion is to compliment the other logs,= not replace them?=C2=A0

I suggest this because in my view, the binary encoding d= escribed in the transport document is what we are already standardizing; I&= #39;d prefer using that for logging rather than having a separate schema ju= st for logging.
<= br>
As I understood it, logging adds detail not pres= ent in wire image. And it does so in a way that could be compatible with ge= neral purpose datastore, analytics etc.


If we are con= cerned about the introduction of QUIC extensions breaking the analysis tool= s, the QUIC stacks can log each QUIC frame as a different hex-encoded JSON = string. That'd allow the analysis tools to ignore unknown frame types.<= /div>

I think the current intention is to place unknown data handling burd= en on tools. For example, a tool focused on congestion control analysis pro= bably has no interest in HTTP/3 fine details.

Lucas=C2=A0
=
--0000000000009b7fbf0586c315bd-- From nobody Wed Apr 17 17:55:41 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0B61200A3 for ; Wed, 17 Apr 2019 17:55: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, 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 zHwS_HrX9iHN for ; Wed, 17 Apr 2019 17:55:37 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 A57A9120033 for ; Wed, 17 Apr 2019 17:55:36 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id l7so358216ljg.6 for ; Wed, 17 Apr 2019 17:55:36 -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=TqoHyVEsAXVIl5oS8T15xykRKFadGJ99JyY98CUFcRw=; b=PJwuhVBNuQy75zCWb3oOF0tzIMyQDzMs/0PzW9qvRmAUuE2c/Ia8vIlSOXYI5DcB8L aGdyM+oa+bA/ctGHSR0EwrkYRZ2cEMnc6nIw74ZUMKH8Awcrmwu+Jh8QH6aVNm05DKzs nLwR1+6ds4xUBWkrxKWBJGeu2CGJID0hsGe4KcbRxdzkFRM1bvP5NAS0CL5/+gu1agn1 qWrXrvCEOptQ4ROEVJEKrxfQJ235ex/rC1pxrv0i5H6oqp0opN8bWeDAEJ2fSlcgvBYl x8sIO9gTi0jys/Gso/3bm/YINPv36RfDFx7I8cg9it2rgGpistdWmX60ynUfSerODfZ1 WwcA== 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=TqoHyVEsAXVIl5oS8T15xykRKFadGJ99JyY98CUFcRw=; b=b4y/L60zAC3iDruPSjQ8uMuGrvk3wktx7hAr7fciDh+skjH+aRP7gqUAQByAHhwhz/ LBc1L9sF5NYxQVgWg5Lxm0SMygpialg7uyJWfLcQGnEnFJjddj08dkrWASooC7Aq0sdw pRE8aA8faJpgPycJrmXNKdXdQ3q5IKQB3PPrbLe7fqPlbSezzy+oYzdl3lv3ilYOb/P2 Ju0+5B+7fn+dNceO6zNM+n04bZuswJ1wlARmgG/lwEUvcaq9/EGMIIvSYzmcdBKtUgDf zmrQXHRBawq5RbAvFd9KkWMQzKbh0NoC/1cNbzBvsypa4mGDsmhauupiZSvgNU+EvDC2 9KXw== X-Gm-Message-State: APjAAAVxJeD3fPUetAQr7/td6J2poGsJ2MRQ7URDS93dnVi7yjj6H6Id 2GsjKiec0Z0Tnx6CF/v/qfpoMg1DZAy4NeKwS4c= X-Google-Smtp-Source: APXvYqz7V/oOWMAG1Dx0FHl0LU01jfCmCd9E6T5+me0J/OvFod+/P6vKprGXS6vvUpeA7od0UjaKD7tif/3i2NstJ+k= X-Received: by 2002:a2e:500d:: with SMTP id e13mr52094998ljb.169.1555548934650; Wed, 17 Apr 2019 17:55:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Thu, 18 Apr 2019 09:55:22 +0900 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: Lucas Pardue Cc: Robin MARX , 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 00:55:39 -0000 2019=E5=B9=B44=E6=9C=8818=E6=97=A5(=E6=9C=A8) 9:28 Lucas Pardue : > > Hi Kazuho, > > Responding to some points inline. This is just my opinion so I stand to b= e corrected by Robin. > > On Thu, 18 Apr 2019, 00:48 Kazuho Oku, wrote: >> >> >> I think it might be worth considering to log the frames of QUIC as they = are (either in binary or hex-encoded binary), with the exception that the S= tream Data field of STREAM frames would be omitted. > > > I can see the appeal of that. However, part of the attraction of logging = is that it can give further insight into applications. I had in mind loggin= g in the HTTP/3, which in my implementation is a few steps removed from QUI= C frames or packets. More so, much of the time my logging only cares for HT= TP/3 frame payload, not complete frames. I think I might have caused confusion due to specifically talking about QUIC frames, but I think the same argument applies for H3 as well. I think we can log the HTTP/3 frames as they are in binary or as a hex-encoded binary (with the exception that we'd omit the payload of DATA frames (and possibly also HEADERS frame)) in the log format. > But perhaps the intent of your suggestion is to compliment the other logs= , not replace them? My point is that it would be easier to use the wire-format defined in QUIC or HTTP/3 when logging what is being transmitted. We need to log other sorts of information (e.g., packet loss timer firing), so using the wire-format does not help everything. But at least, it would remove the requirement on QUIC stacks to support two ways of serializing what is transmitted (the two way being the QUIC wire format and the log format). >> I suggest this because in my view, the binary encoding described in the = transport document is what we are already standardizing; I'd prefer using t= hat for logging rather than having a separate schema just for logging. > > > As I understood it, logging adds detail not present in wire image. Yes, logging information only known to the endpoints do help (even though traditional tools (e.g., wireshark) don't). I think it's beneficial to define a format that can log not only what's being sent / received but also what's happening within the endpoint. > And it does so in a way that could be compatible with general purpose dat= astore, analytics etc. What I am suggesting is to log each frame (either QUIC frame or H3 frame) as binary or binary encoded as hex string. I think it would be compatible with general purpose datastore. For QUIC, I'd assume that we'd generally be building tools specifically for the protocol, so I think using the wire-format does not make things complicated on the analytics side (it's just about dealing with binary-encoded information rather than JSON). OTOH, for HTTP/3, if your intent is to use the same logging format for HTTP1, 2, 3, then I can see your point on using a wire-independent logging format. Though, even if that is the case for HTTP-level logging, I'd still argue that it would be worthwhile to allow QUIC / H3 stacks to log the QUIC or the H3 frames using the wire-format. There's no reason to require each stack to implement the logging format. Allowing the stacks to log using the wire-format would lower the entry bar of the stacks supporting the analysis tools. > >> >> If we are concerned about the introduction of QUIC extensions breaking t= he analysis tools, the QUIC stacks can log each QUIC frame as a different h= ex-encoded JSON string. That'd allow the analysis tools to ignore unknown f= rame types. > > > I think the current intention is to place unknown data handling burden on= tools. For example, a tool focused on congestion control analysis probably= has no interest in HTTP/3 fine details. > > Lucas >> >> --=20 Kazuho Oku From nobody Wed Apr 17 18:19:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112A71201A2 for ; Wed, 17 Apr 2019 18:19: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, 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 ZgYRMcEbdSgt for ; Wed, 17 Apr 2019 18:19:39 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E89F12012B for ; Wed, 17 Apr 2019 18:19:39 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx63.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hGviC-0005FK-HH for quic@ietf.org; Thu, 18 Apr 2019 03:19:37 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp03.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hGvi7-000677-OS for quic@ietf.org; Wed, 17 Apr 2019 21:19:33 -0400 Received: (qmail 24249 invoked from network); 18 Apr 2019 01:19:28 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.204]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Apr 2019 01:19:28 -0000 To: Kazuho Oku , Lucas Pardue Cc: Robin MARX , QUIC WG References: From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Wed, 17 Apr 2019 18:19:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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: QUIC logging and tooling : moving towards qlog X-Originating-IP: 168.144.250.223 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5heXGUEY33L3SuqRq/B1/dh602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViSraoJozywxSbEIO9kEwGfM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB4lampmfDNuiABFovtjnMdR/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaIaRz7MMaWWw7JDSyG1BzB5Xm29FvKBMMcnR+zcXohpXPu2C9SFfeUt z792LEJeS82AImxrekFydH4DojSCKJXVXfdz0+Q1eHsqtFQKXUaZ+h596SWGosiQ15/fAFUBngWU swziTuoonQBgr0dS5AZLiwQzKw+6v3CaIMG6s7LqJMEaAjvMQ8PpHTv+phcQ8cJSyaRgIwuFZktu hI3SFVkn41VGQ9dyOzhAHYEBJ6b30q9wrXR95ml+vhO0u+ei8NHtOuTWXXIj0TpQpfUxR/zG6R7c 5DuoFFC0ovGkX5FQgj5Gegm2Di+XkC+U0gjMGGJKY/Dheomgy+3OjALoDXcGrNLMkKiSx4DbX99P +gh4iWPT5m4OdqWMdE0b4Joz08+J+cv73CChOPjKA0/DVd830vHLIFSGGMV7x6CHvZpJG/9P/4OG qJ5dkO1xTEy0joEwyGTHIAoNFX+jcW7DGmdEezpuI9IICsCKA/p66v7fhw== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 01:19:41 -0000 On 4/17/2019 5:55 PM, Kazuho Oku wrote: > Though, even if that is the case for HTTP-level logging, I'd still > argue that it would be worthwhile to allow QUIC / H3 stacks to log the > QUIC or the H3 frames using the wire-format. There's no reason to > require each stack to implement the logging format. Allowing the > stacks to log using the wire-format would lower the entry bar of the > stacks supporting the analysis tools. I am a bit concerned that the proposed logging formats are rather verbose, using text encodings and lots of detailed events. That useful when debugging basic interop issues, but we are somewhat past that. As QUIC is maturing, I expect to see a much greater emphasis on debugging performance issues: software performance of course, but also performance of recovery and congestion control. You need good traces to debug the recovery and congestion issues, but you lose if turning on tracing slows down the system so much that the behavior under traces does not reflect normal behavior. And I am concerned that using verbose formats will do just that. -- Christian Huitema From nobody Thu Apr 18 00:18:58 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5A31200B8 for ; Thu, 18 Apr 2019 00:18: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, DKIMWL_WL_HIGH=-0.001, 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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEnOA3TMQEL9 for ; Thu, 18 Apr 2019 00:18:53 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140084.outbound.protection.outlook.com [40.107.14.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694B3120117 for ; Thu, 18 Apr 2019 00:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=38v+dBK2eygSOjuWy8K7CrUTl3Nlwvd7ZC9P5FdOWQc=; b=BeNv6HAVEEb8p7t2+ClXsl9A4M6NthQkUNT8B2PQ7EswfFMzd1+03PhXCd16zWaOOhdGVFAI2mHLMTJcuIF4mmafGUCl15+ZdtuKGdfe+RAB+un6wnc7jYsrYc2GDT/6kwMXuTg84lOJZ/seDTnKMATQp/fyPb2kM5lc/RMivEg= Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB1036.eurprd07.prod.outlook.com (10.162.27.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Thu, 18 Apr 2019 07:18:48 +0000 Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::8085:df69:92b4:8bbb]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::8085:df69:92b4:8bbb%4]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 07:18:48 +0000 From: Ingemar Johansson S To: Ian Swett , IETF QUIC WG CC: Ingemar Johansson S Subject: RE: Some notes about WebRTC and QUIC Thread-Topic: Some notes about WebRTC and QUIC Thread-Index: AQHU9U/7HIw+32S3fkeM+SnZYZfyQKZBeYfA Date: Thu, 18 Apr 2019 07:18:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 76bd77ee-fc0a-49e7-9461-08d6c3ce199e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB1036; x-ms-traffictypediagnostic: HE1PR07MB1036: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(366004)(396003)(136003)(199004)(189003)(97736004)(26005)(606006)(6246003)(8676002)(52536014)(33656002)(478600001)(5660300002)(25786009)(99936001)(99286004)(110136005)(6436002)(476003)(71200400001)(81156014)(316002)(14454004)(107886003)(229853002)(71190400001)(8936002)(4326008)(486006)(81166006)(55016002)(2906002)(11346002)(256004)(966005)(5024004)(76176011)(6116002)(102836004)(54896002)(186003)(9686003)(236005)(6306002)(3846002)(446003)(86362001)(68736007)(53546011)(7696005)(53936002)(790700001)(6506007)(7736002)(74316002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1036; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: RoyJz1iInF55H4HK0tYVQjZwbExPGrdXyYigtCrkqAsw6BIAxi0MGvDzOiEdjVWQeZQWCG/OemTl0PsPQxVFYIYAVpEffGiWWyXC7rmYsnYykPHSAk73lEuiF6BD0w7Obr3zLrCmy9Inp0CZChpCe/GYVkZJqbPeEcbgcKrZh6dDrtMqvhsRcJ0KTVFHawLX7UlsrunSyY3MXGPH3/PxwZEY+UOTvdbUhydfNs1DbgmZAUBNd8Yc0Q1EXMfP2ITUlP75sTuQRQ42nTQsOSL6yzNZWBoL1Zd4anBfqOUfucJu4pFm/1tZ7919W4mhIDZ8ON/hEVqlcX47DGGUiIh0JlRlqRQt1xrMFJ+cfuqTrY6xLMu70yagCwjMxCTL2zSG4NiMFyAahOWjkgkUEPyc037tyRKAJYSWMVKt2ICfH+o= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0015_01D4F5C7.B9107EB0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 76bd77ee-fc0a-49e7-9461-08d6c3ce199e X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 07:18:47.8195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1036 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 07:18:57 -0000 ------=_NextPart_000_0015_01D4F5C7.B9107EB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0016_01D4F5C7.B9107EB0" ------=_NextPart_001_0016_01D4F5C7.B9107EB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi =20 And thanks for sharing the meeting notes. I believe that there are = benefits with WebRTC over QUIC, especially the possibility to run a = unified congestion control has some merit given simulation studies that = I have run.=20 =20 For what it=E2=80=99s worth.. During the development of SCReAM = (https://tools.ietf.org/html/rfc8298 ) I have collected some experience = in how SCReAM works and what it requires in terms of feedback for = optimal function. SCReAM is congestion control for RTP media, SCReAM has = built in support for prioritization between media streams. The observant = reader may make the observation that SCReAM resembles LEDBAT quite a lot = and that is quite true, SCReAM however also adds the interaction with = the media coders, stream queues and ECN/L4S support. Mixing small and = large packets (voice, video) does not seem to be a problem in = simulations, but sofar SCReAM has only been used for the transmission of = video at bitrates ranging from ~200kbps to 50+Mbps. I don=E2=80=99t believe that it is possible to take SCReAM and put it as = is into a WebRTC over QUIC solution but perhaps some ideas can be = stolen. =20 =20 A few observations: =20 Timestamps : A receive timestamp for each packet is not needed for the = function of SCReAM. It is sufficient with a receive timestamp of the = last received RTP packet. The current implementation ( = = https://github.com/EricssonResearch/scream) implements = = https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-02 = which reports timestamps per packet, the issue is that it increases the = feedback size quite a lot. An earlier version of the SCReAM code = generated feedback packets that were just 48bytes, the size with the new = format is 128 bytes or even more. =20 ACK rates: A low bitrates it is possible with feedback as seldom as = every 50-100ms, at higher bitrate more frequent feedback is required. = For instance, at 50Mbps or beyond, feedback is transmitted roughly every = 2ms. =20 Stream scheduling and prioritization: SCReAM implements an RTP queue per = media stream, something that is best referred to as a credit based = scheduler picks RTP packets from the queues in a priority fashion ( = = https://tools.ietf.org/html/rfc8298#page-24). This approach seems to = work well according to tests we have done. The RTP queues are mostly = empty but serves as shock absorbers for instance when link throughput = drops quickly. =20 Regards Ingemar =20 =20 =20 =20 =20 From: Ian Swett =20 Sent: den 17 april 2019 17:42 To: IETF QUIC WG Subject: Some notes about WebRTC and QUIC =20 When in Prague, I organized a small WebRTC over QUIC lunch to discuss = what it might look like and what the goals are. =20 Attached are some notes from the conversation. =20 Thanks, Ian =20 ------=_NextPart_001_0016_01D4F5C7.B9107EB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi

 

And thanks for sharing the meeting = notes. I believe that there are benefits with WebRTC over QUIC, = especially the possibility to run a unified congestion control has some = merit given simulation studies that I have run.

 

For what it=E2=80=99s worth.. = During the development of SCReAM (https://tools.ietf.org/html/= rfc8298 ) I have collected some experience in how SCReAM works and = what it requires in terms of feedback for optimal function. SCReAM is = congestion control for RTP media, SCReAM has built in support for = prioritization between media streams. The observant reader may make the = observation that SCReAM resembles LEDBAT quite a lot and that is quite = true, SCReAM however also adds the interaction with the media coders, = stream queues and ECN/L4S support. Mixing small and large packets = (voice, video) does not seem to be a problem in simulations, but sofar = SCReAM has only been used for the transmission of video at bitrates = ranging from ~200kbps to 50+Mbps.

I don=E2=80=99t believe that it is = possible to take SCReAM and put it as is into a WebRTC over QUIC = solution but perhaps some ideas can be stolen.

 

 

A few = observations:

 

Timestamps : A receive timestamp = for each packet is not needed for the function of SCReAM. It is = sufficient with a receive timestamp of the last received RTP packet. = =C2=A0The current implementation (https://github.com/EricssonResearch/scream) implements https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-m= essage-02 which reports timestamps per = packet, the issue is that it increases the feedback size quite a lot. An = earlier version of the SCReAM code generated feedback packets that were = just 48bytes, the size with the new format is 128 bytes or even = more.

 

ACK rates: A low bitrates it is = possible with feedback as seldom as every 50-100ms, at higher bitrate = more frequent feedback is required. For instance, at 50Mbps or beyond, = feedback is transmitted roughly every 2ms.

 

Stream scheduling and = prioritization: SCReAM implements an RTP queue per media stream, = something that is best referred to as a credit based scheduler picks RTP = packets from the queues in a priority fashion (https://tools.ietf.org/html/rfc8298#page-24). This approach seems = to work well according to tests we have done. The RTP queues are mostly = empty but serves as shock absorbers for instance when link throughput = drops quickly.

 

Regards

Ingemar

 

 

 

 

 

From: Ian Swett = <ianswett@google.com>
Sent: den 17 april 2019 = 17:42
To: IETF QUIC WG = <quic@ietf.org>
Subject: Some notes about WebRTC and = QUIC

 

When in = Prague, I organized a small WebRTC over QUIC lunch to discuss what it = might look like and what the goals are.

 

Attached are some notes from the = conversation.

 

Thanks, Ian

 

------=_NextPart_001_0016_01D4F5C7.B9107EB0-- ------=_NextPart_000_0015_01D4F5C7.B9107EB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3 MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J 0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9 7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP 9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6 Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8 TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3 OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO 30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3 0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5 S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT 05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT 9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx 5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+ i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xOTA0MTgwNzE4NDVaMCMGCSqGSIb3DQEJBDEWBBT3uh4IggIARMwZyAp+ Z43lUzM2nDBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAE0Of1uAqZ/UwKzHaV+3b3ziyoy602AYEfg7yx28 qHMAvQo/tGWQpJlEImM7m0OTk4FjWZ6mZ4gMstciQlMR39lpEYZ1LLx6yi2B2hUsAOw74FGKBCKj Yy3/IAxSjjvHnTAHg8XZ1EgVUHCTtvM1i2qFHmUFCOD0uTuuJ5Rvcisy3vKxhMQUc3lBrROL8vBO MJxtYe0hUpjOXb3WyQ4Lg35uE+nW5WMLcXpes5QAxTZpwqiZkH64ElhnRK4jS2IRjJtRtpunePfG 3fqWfUyq6JbYZVW+c4Q8YBzfarMveHUWKtKtQBZl0uoSIhGC7++qXWWRSUdxz902BAMcZmOrrQMA AAAAAAA= ------=_NextPart_000_0015_01D4F5C7.B9107EB0-- From nobody Thu Apr 18 03:40:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62D6120092 for ; Thu, 18 Apr 2019 03:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uhasselt.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0BLQElqeg7W for ; Thu, 18 Apr 2019 03:40:12 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A1612002E for ; Thu, 18 Apr 2019 03:40:11 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id v1so1253961lfg.5 for ; Thu, 18 Apr 2019 03:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TOHLKKLSWpsvD0N0DAkPeKLh2UxbECjxAhxKNUMEJZs=; b=QrkrjW1IetsacMeYlUcOjJyRGxBsYmOGUYdJ0bf+s3bxD/4j0/UPtlOfQ/5c/Pm/qq Jjw/G6VpUyh3qsrCGxVZ8WQYFA0ogruuNhp9Io4bHGDwn8rXshHdKIUnxlqIZ7tdc22I MGX/m5u1VLYzKv2kcL9v9PI0USbjOuwZINleM= 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=TOHLKKLSWpsvD0N0DAkPeKLh2UxbECjxAhxKNUMEJZs=; b=rBqQvSz1r3PS5+TrnsuvPb2Tt8L+dO3QVQDIsU1lz0G1TNGl6L5KrQKyHtNVRRvdeI ajKhIfpTxvVn0y3QVJUFp1wM0HLXG2mBHliDHGyqb5pmxOHEizjUVGYCldGIK/ZR7uK5 K06kvkDRJP3N63I1LDcLWZrPafjLFoAtgi45txsGjj6Cg+NG/II7jMblBg9HrN/FIHi5 Sid4QKwxG9QsOaM7RsBCNjOsk3xbqke3cCQiyUCGgBXEqRYCb7/mZKRkzlatS7CsCa2l JH+iU7UvNlxebfnuaZ8kcMbkwZ4ofMaL9Ia+2v303g+/Vg73XKUnmghDW6pn7JwNPH2r fOQQ== X-Gm-Message-State: APjAAAUqJ4taZdAWSXdpTnjWYhyffjRx6bxJ+RWXnP3beNkP1Mr/gGjZ pX8BC9Wb4K+nW7UiQ477vnkxmAnc6fG7bbUTPtKILA== X-Google-Smtp-Source: APXvYqzPeZAklPPQ+W8XdqDmR2z5tsFZRJREFxav1wNNfyK1iEuXgMmG6qni6tTby5a3mE39zexwsrGaSX0OuhyrddU= X-Received: by 2002:a05:6512:20e:: with SMTP id a14mr18499754lfo.14.1555584009412; Thu, 18 Apr 2019 03:40:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robin MARX Date: Thu, 18 Apr 2019 12:39:57 +0200 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: Christian Huitema Cc: Kazuho Oku , Lucas Pardue , QUIC WG Content-Type: multipart/alternative; boundary="0000000000004cd1760586cba0b9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 10:40:16 -0000 --0000000000004cd1760586cba0b9 Content-Type: text/plain; charset="UTF-8" Hello everyone, Thank you for the thoughtful comments. I think I can answer most of the remarks made with one statement: you can log whatever you want in whatever format, and then write a transformer into the qlog format. A better way to describe qlog is probably "*a common input data format for tools*" rather than a standard *logging* format. However, you can certainly use qlog as a basic logging format as well, which is exactly what quicker and (partially) lsquic are currently doing. When you need higher performance or don't want to write two serializers in the implementation etc., you can log in other ways and then transform to qlog for ingestion in the tools. This is usually relatively trivial and fast, e.g., see the quictrace2qlog and pcap2qlog converters we've already started (and what Jana is also doing for quicly iiuc), As you say, I don't think it's realistic to get every implementation to agree on how exactly they will log, whether it's a verbose .json or optimized flatbuffer setup. A few more in-depth comments: 1) I do not want tools to have to parse the binary wire image themselves - I envision many tool developers/maintainers will be students, interns or other non-QUIC experts. Having them write/extend a parser is possibly not the best idea. - The binary formats are sometimes quite non-intuitive (e.g., ACK frame) which can lead to mistakes in interpretation. - Each tool platform/language (e.g., web, C++, python, ...) would need its own frame parsing library (for JSON, that's usually readily available) - Parsing the binary in for example web-based tools (which I envision will be the largest group, as they allow ease of use and sharing), will lead to performance problems there. - As Lucas said, ideally the logs would go much further than just the wire image. I'm more interested in when and how exactly an ACK is processed, rather than just what came in on the wire. Taking that into consideration, the logs would contain two formats, one for binary events, one for all the rest, again adding to complexity. - That being said, the original qlog proposal had the concept of also logging raw values, and it's certainly possible to re-incorporate that as an optional extra field (see issue 11 ). e.g., you could just log the binary hex-string from the implementation, and then write a post-processing converter that parses the binary values and transforms them into the expected qlog fields. 2) The verbosity is indeed a potential problem, but it's manageable - As stated at the beginning, for high-performance tracing, you could only log the select events you want or use a custom format and post-process it into qlog for tooling - Even within the JSON setup, there are many ways to reduce the file-size and logging overhead (e.g., the technique used by the Netlog format, also discussable in issue 8 ) Logging individual events should not take more overhead than normal textual logging that is now also done to stdout - I agree that current (v1) stacks are going beyond basic interop, but this is meant to be more general purpose and long-term Think of teaching new people, implementing new features (v2, other app-layer besides H3), major performance-related refactoring, etc. For those use cases, a highly optimized format is in my opinion more of a hindrance than a more verbose format is to congestion control / performance evaluation - Just like with normal logging, qlog has the concept of log levels (e.g., Verbose vs Error-only), but then for categories. e.g., only debugging HTTP/3 right now, not logging any of the QUIC stuff. Smaller remarks: - The "class" fields are just because we are using TypeScript semantics (see issue 5 ). They do not mean that you cannot simply drop unknown frames. In fact, one of the key tenets of qlog is that you can add as many custom events as you want for easy extensibility. - Tools would be required to clearly list the types of events they look for and the data they expect in the log. You can then see for yourself what it takes to be able to use that tool and only log (or transform to qlog) that exact info. I hope this helps resolve some of the questions. The current proposal is the one I feel strikes the best balance between performance and usability, flexibility and pragmatism. Feel free to disagree with my points above and to go more in-depth on the github issues. With best regards, Robin On Thu, 18 Apr 2019 at 03:19, Christian Huitema wrote: > On 4/17/2019 5:55 PM, Kazuho Oku wrote: > > > Though, even if that is the case for HTTP-level logging, I'd still > > argue that it would be worthwhile to allow QUIC / H3 stacks to log the > > QUIC or the H3 frames using the wire-format. There's no reason to > > require each stack to implement the logging format. Allowing the > > stacks to log using the wire-format would lower the entry bar of the > > stacks supporting the analysis tools. > > I am a bit concerned that the proposed logging formats are rather > verbose, using text encodings and lots of detailed events. That useful > when debugging basic interop issues, but we are somewhat past that. As > QUIC is maturing, I expect to see a much greater emphasis on debugging > performance issues: software performance of course, but also performance > of recovery and congestion control. You need good traces to debug the > recovery and congestion issues, but you lose if turning on tracing slows > down the system so much that the behavior under traces does not reflect > normal behavior. And I am concerned that using verbose formats will do > just that. > > -- Christian Huitema > > > -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --0000000000004cd1760586cba0b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

Thank = you for the thoughtful comments.=C2=A0
I think I can answer most = of the remarks made with one statement: you can log whatever you want in wh= atever format, and then write a transformer into the qlog format.=C2=A0

A better way to describe qlog is probably "a = common input data format for tools" rather than a standard logg= ing format.
However, you can certainly use qlog as a basic lo= gging format as well, which is exactly what quicker and (partially) lsquic = are currently doing.=C2=A0
When you need higher performance or do= n't want to write two serializers in the implementation etc., you can l= og in other ways and then transform to qlog for ingestion in the tools.
This is usually relatively trivial and fast, e.g., see the quictrace= 2qlog and pcap2qlog converters we've already started (and what Jana is = also doing for quicly iiuc),=C2=A0
As you say, I don't think = it's realistic to get every implementation to agree on how exactly they= will log, whether it's a verbose .json or optimized flatbuffer setup.= =C2=A0

A few more in-depth comments:
1) I do not want tools to have to parse the binary wire image t= hemselves
=C2=A0 =C2=A0 - I envision many tool developers/maintai= ners will be students, interns or other non-QUIC experts. Having them write= /extend a parser is possibly not the best idea.=C2=A0
=C2=A0 =C2= =A0 - The binary formats are sometimes quite non-intuitive (e.g., ACK frame= ) which can lead to mistakes in interpretation.=C2=A0
=C2=A0 =C2= =A0 - Each tool platform/language (e.g., web, C++, python, ...) would need = its own frame parsing library (for JSON, that's usually readily availab= le)
=C2=A0 =C2=A0 - Parsing the binary in for example web-based t= ools (which I envision will be the largest group, as they allow ease of use= and sharing), will lead to performance problems there.
=C2=A0 = =C2=A0 - As Lucas said, ideally the logs would go much further than just th= e wire image. I'm more interested in when and how exactly an ACK is pro= cessed, rather than just what came in on the wire.=C2=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Taking that into consideration, the logs would = contain two formats, one for binary events, one for all the rest, again add= ing to complexity.

=C2=A0 =C2=A0 - That being said= , the original qlog proposal had the concept of also logging raw values, an= d it's certainly possible to re-incorporate that as an optional extra f= ield (see = issue 11).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e.g., you could just l= og the binary hex-string from the implementation, and then write a post-pro= cessing converter that parses the binary values and transforms them into th= e expected qlog fields.

2) The verbosity is indeed= a potential problem, but it's manageable
=C2=A0 =C2=A0- As s= tated at the beginning, for high-performance tracing, you could only log th= e select events you want or use a custom format and post-process it into ql= og for tooling
=C2=A0 =C2=A0- Even within the JSON setup, there a= re many ways to reduce the file-size and logging overhead (e.g., the techni= que used by the Netlog format, also discussable in issue 8)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Logging individual events should not take more overhead t= han normal textual logging that is now also done to stdout
=C2=A0= =C2=A0- I agree that current (v1) stacks are going beyond basic interop, b= ut this is meant to be more general purpose and long-term
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Think of teaching new people, implementing new = features (v2, other app-layer besides H3), major performance-related refact= oring, etc.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For those use case= s, a highly optimized format is in my opinion more of a hindrance than a mo= re verbose format is to congestion control / performance evaluation
=C2=A0 =C2=A0- Just like with normal logging, qlog has the concept of lo= g levels (e.g., Verbose vs Error-only), but then for categories. e.g., only= debugging HTTP/3 right now, not logging any of the QUIC stuff.=C2=A0
=


Smaller remarks:
- The "c= lass" fields are just because we are using TypeScript semantics (see issue 5)= . They do not mean that you cannot simply drop unknown frames.=C2=A0
<= div>=C2=A0 =C2=A0 =C2=A0In fact, one of the key tenets of qlog is that you = can add as many custom events as you want for easy extensibility.=C2=A0
- Tools would be required to clearly list the types of events they l= ook for and the data they expect in the log.=C2=A0
=C2=A0 =C2=A0 = =C2=A0You can then see for yourself what it takes to be able to use that to= ol and only log (or transform to qlog) that exact info.


I hope this helps resolve some of the questions.=C2=A0=
The current proposal is the one I feel strikes the best balance = between performance and usability, flexibility and pragmatism.=C2=A0
<= div>
Feel free to disagree with my points above and to go mor= e in-depth on the github issues.=C2=A0

With best r= egards,
Robin


On Thu, 18 Apr 2019 at 03:19, C= hristian Huitema <huitema@huitema= .net> wrote:
On 4/17/2019 5:55 PM, Kazuho Oku wrote:

> Though, even if that is the case for HTTP-level logging, I'd still=
> argue that it would be worthwhile to allow QUIC / H3 stacks to log the=
> QUIC or the H3 frames using the wire-format. There's no reason to<= br> > require each stack to implement the logging format. Allowing the
> stacks to log using the wire-format would lower the entry bar of the > stacks supporting the analysis tools.

I am a bit concerned that the proposed logging formats are rather
verbose, using text encodings and lots of detailed events. That useful
when debugging basic interop issues, but we are somewhat past that. As
QUIC is maturing, I expect to see a much greater emphasis on debugging
performance issues: software performance of course, but also performance of recovery and congestion control. You need good traces to debug the
recovery and congestion issues, but you lose if turning on tracing slows down the system so much that the behavior under traces does not reflect
normal behavior. And I am concerned that using verbose formats will do
just that.

-- Christian Huitema




--

<= td style=3D"font-family:Verdana,Geneva,sans-serif">Agoralaan Gebouw D - = B-3590 Diepenbeek --0000000000004cd1760586cba0b9-- From nobody Thu Apr 18 03:49:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE6C120092 for ; Thu, 18 Apr 2019 03:49:01 -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 vjOmuWHFNp37 for ; Thu, 18 Apr 2019 03:48:56 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2AE12002E for ; Thu, 18 Apr 2019 03:48:55 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id a190so2577718ite.4 for ; Thu, 18 Apr 2019 03:48: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=f+0lU/RTbbV48E/L1Ljr20elENnJAf9BMJ14rCp+l7w=; b=RQcRPTXW8ThGvERWYV+JJf3+l1/nnMuUlwqtTZKBg73zlnynmHyK5BgzhNV32L5+2C RWjTebBSDjSQ1R0sbZDhUDvqVMcowtAAEIVxRlFWCvWXThOj894SRORXzpLE8XZOsQI/ 6OKjQNSICLkZsj3nHlhgsE2r3G070dTyGnGCRvpT0U1VwuHlnlD7LP2ZRNzvKw3S4OBj iokDguaiwHsuLsUi+Yw83faBesgiOxXuCQifuu+MyRdPrtm3s3xyR6bJjmgYSEAoKZW4 jHFImdjpdC7tbE0mviF7NoLGztrnQVbI3ysdLJMD+F18+AAVHBLpMmqLWmTeM+nQl6K+ VV9A== 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=f+0lU/RTbbV48E/L1Ljr20elENnJAf9BMJ14rCp+l7w=; b=SBVxkeMLxLxs4GIIwP8z0IVV8BroEZVT13uUY0ISlKxpe487kIeJlZwE69f7JhKrcn Iaf8G1l/ADPYFjHEgZBvuPTQn6bp/TQvfEcxOJAdtjIB9zGoiImynjdX2FuHnhe5zUVV ZBUowVuUeVI9WsgC/O2R4chZri8Jr0xsuqowYclekpgq34IhuRKr9N86BOOPTJHOl1NK bh7iY2+3w7smvFbK13VRGRz4zVsU7fI3LtiAgKlPoD3BIWfNyVXoolk0B3ZYABesAGI5 y6LbJ6EHGjqAN8yAUlpsEgDrDOP5cQONPX66Ia58JGyXz2eQr5E4RxNUbhQXWwnm4Klk dfvA== X-Gm-Message-State: APjAAAXssJky7rRSiPd3FsR/EdiGldu7Kfg4uEnCDhGTULxh5pIYsP/N F5I3Dp5hPFkjuSmv801Favzj8nebhWUubxbCKSM= X-Google-Smtp-Source: APXvYqzcUOFtjUDuSnTdkso3Be4/wruMqfthhJnTIh7T0rjV+xsTNpO13ML0skovpHB9tQrl9KMSpY6zv0XG6yLneuc= X-Received: by 2002:a24:4d8a:: with SMTP id l132mr2740928itb.70.1555584535107; Thu, 18 Apr 2019 03:48:55 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 18 Apr 2019 03:48:53 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 18 Apr 2019 03:48:53 -0700 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: Robin MARX , Christian Huitema Cc: QUIC WG , Kazuho Oku , Lucas Pardue Content-Type: multipart/alternative; boundary="000000000000a21d320586cbbfed" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 10:49:01 -0000 --000000000000a21d320586cbbfed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It doesn=E2=80=99t really reflect on my earlier suggestion on making JSON flatbuffer compatible. The thing is that thare are parsers from JSON to protobuf and from JSON to flatbuffers where have you do not have to do anything other than writing some driver logic to get the conversion. A protobuf schema will often have a JSON format that is very similar to what is accepted by similar schema in FlatBuffers, so it suffice to define a protobuf schema and a FlatBufffers schema, and all conversion can happen automatically via JSON. However, if you rely on specific features such as Any or OneOf, it might not work, and if you use Base64 to encode strings instead of binary arrays, it will not work. But, it is generally not difficult to specify schema where this is not a problem. Googles Flatbuffer tool flatc convert json to binary given a schema. FlatBuffers for C (flatcc) generates JSON C parsers from a schema which can process JSON very fast into FlatBuffers (I=E2=80=99m the author). It is unlikely that you will see someone handcoding a JSON parser to convert it into FlatBuffers. Mikkel On 18 April 2019 at 12.40.34, Robin MARX (robin.marx@uhasselt.be) wrote: Hello everyone, Thank you for the thoughtful comments. I think I can answer most of the remarks made with one statement: you can log whatever you want in whatever format, and then write a transformer into the qlog format. A better way to describe qlog is probably "*a common input data format for tools*" rather than a standard *logging* format. However, you can certainly use qlog as a basic logging format as well, which is exactly what quicker and (partially) lsquic are currently doing. When you need higher performance or don't want to write two serializers in the implementation etc., you can log in other ways and then transform to qlog for ingestion in the tools. This is usually relatively trivial and fast, e.g., see the quictrace2qlog and pcap2qlog converters we've already started (and what Jana is also doing for quicly iiuc), As you say, I don't think it's realistic to get every implementation to agree on how exactly they will log, whether it's a verbose .json or optimized flatbuffer setup. A few more in-depth comments: 1) I do not want tools to have to parse the binary wire image themselves - I envision many tool developers/maintainers will be students, interns or other non-QUIC experts. Having them write/extend a parser is possibly not the best idea. - The binary formats are sometimes quite non-intuitive (e.g., ACK frame) which can lead to mistakes in interpretation. - Each tool platform/language (e.g., web, C++, python, ...) would need its own frame parsing library (for JSON, that's usually readily available) - Parsing the binary in for example web-based tools (which I envision will be the largest group, as they allow ease of use and sharing), will lead to performance problems there. - As Lucas said, ideally the logs would go much further than just the wire image. I'm more interested in when and how exactly an ACK is processed, rather than just what came in on the wire. Taking that into consideration, the logs would contain two formats, one for binary events, one for all the rest, again adding to complexity. - That being said, the original qlog proposal had the concept of also logging raw values, and it's certainly possible to re-incorporate that as an optional extra field (see issue 11 ). e.g., you could just log the binary hex-string from the implementation, and then write a post-processing converter that parses the binary values and transforms them into the expected qlog fields. 2) The verbosity is indeed a potential problem, but it's manageable - As stated at the beginning, for high-performance tracing, you could only log the select events you want or use a custom format and post-process it into qlog for tooling - Even within the JSON setup, there are many ways to reduce the file-size and logging overhead (e.g., the technique used by the Netlog format, also discussable in issue 8 ) Logging individual events should not take more overhead than normal textual logging that is now also done to stdout - I agree that current (v1) stacks are going beyond basic interop, but this is meant to be more general purpose and long-term Think of teaching new people, implementing new features (v2, other app-layer besides H3), major performance-related refactoring, etc. For those use cases, a highly optimized format is in my opinion more of a hindrance than a more verbose format is to congestion control / performance evaluation - Just like with normal logging, qlog has the concept of log levels (e.g., Verbose vs Error-only), but then for categories. e.g., only debugging HTTP/3 right now, not logging any of the QUIC stuff. Smaller remarks: - The "class" fields are just because we are using TypeScript semantics (se= e issue 5 ).. They do not mean that you cannot simply drop unknown frames. In fact, one of the key tenets of qlog is that you can add as many custom events as you want for easy extensibility. - Tools would be required to clearly list the types of events they look for and the data they expect in the log. You can then see for yourself what it takes to be able to use that tool and only log (or transform to qlog) that exact info. I hope this helps resolve some of the questions. The current proposal is the one I feel strikes the best balance between performance and usability, flexibility and pragmatism. Feel free to disagree with my points above and to go more in-depth on the github issues. With best regards, Robin On Thu, 18 Apr 2019 at 03:19, Christian Huitema > wrote: > On 4/17/2019 5:55 PM, Kazuho Oku wrote: > > > Though, even if that is the case for HTTP-level logging, I'd still > > argue that it would be worthwhile to allow QUIC / H3 stacks to log the > > QUIC or the H3 frames using the wire-format. There's no reason to > > require each stack to implement the logging format. Allowing the > > stacks to log using the wire-format would lower the entry bar of the > > stacks supporting the analysis tools. > > I am a bit concerned that the proposed logging formats are rather > verbose, using text encodings and lots of detailed events. That useful > when debugging basic interop issues, but we are somewhat past that. As > QUIC is maturing, I expect to see a much greater emphasis on debugging > performance issues: software performance of course, but also performance > of recovery and congestion control. You need good traces to debug the > recovery and congestion issues, but you lose if turning on tracing slows > down the system so much that the behavior under traces does not reflect > normal behavior. And I am concerned that using verbose formats will do > just that. > > -- Christian Huitema > > > -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --000000000000a21d320586cbbfed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = It doesn=E2=80=99t r= eally reflect on my earlier suggestion on making JSON flatbuffer compatible= .

<= 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">The thing is that t= hare are parsers from JSON to protobuf and from JSON to flatbuffers where h= ave you do not have to do anything other than writing some driver logic to = get the conversion.

A= protobuf schema will often have a JSON format that is very similar to what= is accepted by similar schema in FlatBuffers, so it suffice to define a pr= otobuf schema and a FlatBufffers schema, and all conversion can happen auto= matically via JSON.

H= owever, if you rely on specific features such as Any or OneOf, it might not= work, and if you use Base64 to encode strings instead of binary arrays, it= will not work. But, it is generally not difficult to specify schema where = this is not a problem.


It is unlikely that you will see = someone handcoding a JSON parser to convert it into FlatBuffers.

Mikkel



On 18 Apri= l 2019 at 12.40.34, Robin MARX (r= obin.marx@uhasselt.be) wrote:

Hello everyone,

Thank you for the thoughtful comments.=C2=A0
I think I can answer most of the remarks made with one statement: you can log whatever you want in whatever format, and then write a transformer into the qlog format.=C2=A0

A better way to describe qlog is probably "a common input data format for tools" rather than a standard logging format.
However, you can certainly use qlog as a basic logging format as well, which is exactly what quicker and (partially) lsquic are currently doing.=C2=A0
When you need higher performance or don't want to write two serializers in the implementation etc., you can log in other ways and then transform to qlog for ingestion in the tools.
This is usually relatively trivial and fast, e.g., see the quictrace2qlog and pcap2qlog converters we've already started (and what Jana is also doing for quicly iiuc),=C2=A0
As you say, I don't think it's realistic to get every implementation to agree on how exactly they will log, whether it's a verbose .json or optimized flatbuffer setup.=C2=A0

A few more in-depth comments:

1) I do not want tools to have to parse the binary wire image themselves
=C2=A0 =C2=A0 - I envision many tool developers/maintainers will be students, interns or other non-QUIC experts. Having them write/extend a parser is possibly not the best idea.=C2=A0
=C2=A0 =C2=A0 - The binary formats are sometimes quite non-intuitive (e.g., ACK frame) which can lead to mistakes in interpretation.=C2=A0
=C2=A0 =C2=A0 - Each tool platform/language (e.g., web, C++, python, ...) would need its own frame parsing library (for JSON, that's usually readily available)
=C2=A0 =C2=A0 - Parsing the binary in for example web-based tools (which I envision will be the largest group, as they allow ease of use and sharing), will lead to performance problems there.
=C2=A0 =C2=A0 - As Lucas said, ideally the logs would go much further than just the wire image. I'm more interested in when and how exactly an ACK is processed, rather than just what came in on the wire.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Taking that into consideration, the logs would contain two formats, one for binary events, one for all the rest, again adding to complexity.

=C2=A0 =C2=A0 - That being said, the original qlog proposal had the concept of also logging raw values, and it's certainly possible to re-incorporate that as an optional extra field (see issue 11).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e.g., you could just log the binary hex-string from the implementation, and then write a post-processing converter that parses the binary values and transforms them into the expected qlog fields.

2) The verbosity is indeed a potential problem, but it's manageable
=C2=A0 =C2=A0- As stated at the beginning, for high-performance tracing, you could only log the select events you want or use a custom format and post-process it into qlog for tooling
=C2=A0 =C2=A0- Even within the JSON setup, there are many ways to reduce the file-size and logging overhead (e.g., the technique used by the Netlog format, also discussable in issue 8)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Logging individual events should not take more overhead than normal textual logging that is now also done to stdout
=C2=A0 =C2=A0- I agree that current (v1) stacks are going beyond basic interop, but this is meant to be more general purpose and long-term
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Think of teaching new people, implementing new features (v2, other app-layer besides H3), major performance-related refactoring, etc.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For those use cases, a highly optimized format is in my opinion more of a hindrance than a more verbose format is to congestion control / performance evaluation
=C2=A0 =C2=A0- Just like with normal logging, qlog has the concept of log levels (e.g., Verbose vs Error-only), but then for categories. e.g., only debugging HTTP/3 right now, not logging any of the QUIC stuff.=C2=A0


Smaller remarks:
- The "class" fields are just because we are using TypeScrip= t semantics (= see issue 5).. They do not mean that you cannot simply drop unknown frames.=C2=A0
=C2=A0 =C2=A0 =C2=A0In fact, one of the key tenets of qlog is that you can add as many custom events as you want for easy extensibility.=C2=A0
- Tools would be required to clearly list the types of events they look for and the data they expect in the log.=C2=A0
=C2=A0 =C2=A0 =C2=A0You can then see for yourself what it takes to be able to use that tool and only log (or transform to qlog) that exact info.


I hope this helps resolve some of the questions.=C2=A0
The current proposal is the one I feel strikes the best balance between performance and usability, flexibility and pragmatism.=C2=A0

Feel free to disagree with my points above and to go more in-depth on the github issues.=C2=A0

With best regards,
Robin


On Thu, 18 Apr 2019 at 03:19, Christian Huitema <huitema@huitem= a..net> wrote:
On 4/17/2019 5:55 PM, Kazuho Oku wrote:

> Though, even if that is the case for HTTP-level logging, I'd still
> argue that it would be worthwhile to allow QUIC / H3 stacks to log the
> QUIC or the H3 frames using the wire-format. There's no reason to
> require each stack to implement the logging format. Allowing the
> stacks to log using the wire-format would lower the entry bar of the
> stacks supporting the analysis tools.

I am a bit concerned that the proposed logging formats are rather
verbose, using text encodings and lots of detailed events. That useful
when debugging basic interop issues, but we are somewhat past that. As
QUIC is maturing, I expect to see a much greater emphasis on debugging
performance issues: software performance of course, but also performance
of recovery and congestion control. You need good traces to debug the
recovery and congestion issues, but you lose if turning on tracing slows
down the system so much that the behavior under traces does not reflect
normal behavior. And I am concerned that using verbose formats will do
just that.

-- Christian Huitema




--

Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for Digita= l Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 9= 4
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
3D""
Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for Digital Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
=3D""
--000000000000a21d320586cbbfed-- From nobody Thu Apr 18 07:09:41 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D0A120345 for ; Thu, 18 Apr 2019 07:09: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=uhasselt.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSp34RscuXEA for ; Thu, 18 Apr 2019 07:09:35 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 DB67612014A for ; Thu, 18 Apr 2019 07:09:34 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id f18so2037806lja.10 for ; Thu, 18 Apr 2019 07:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7KxstqD+gNIxw76f0H8MRj5BmnGDnQxS2Lavdyzku00=; b=nV894RAUQUqM7Vl0yVjW8es81vnxMwKQQqK6BKHb1oXdEqg1abV2/mnRRUmq8hS2HZ 3QmLV+vW67LC3JVUQnaUjBAkjfnCWxegy1FjGOm4G/sBFtztwhSgxr3DcUklVF2jUz6f MKQP+hZ9bKEYP+YiXGlVVWvmbtq8q5S0x2UK8= 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=7KxstqD+gNIxw76f0H8MRj5BmnGDnQxS2Lavdyzku00=; b=kSCdTWt636L+v1vzeSrVJd7FB4ALcwQAHIhtnAwdVrwR5dmKv4bqApoMhHcr3XDmK/ jJIay//h2CTsfWB5RNoVNZLNzF/tShPlXZ8vJ21hU8vzBKZeaK7KC0lq8spBjWj46teM tXfYWi2RvkO4kS0YWdt79q+eyqnFDHpyo7OMMjwDyiOjVH823gLHz0X5Qg2lx0Je0Wx5 0OOQ+5IaCu4991WjFdSN3U4ZO+1RVcwmkxrntYIbLhU9a1hOuzIoTbXd4yTAtys+IpBw 4W+thcKSXep+4TyI/hHHKLH/KfYnv4NmoUIGW/PoC8z+qRd/YYcYGl5ScXBQgRGg+LM+ sZcA== X-Gm-Message-State: APjAAAU5dbp3Z8C3e2KkMVgS/64sM769AUr1iHzmdvoM+zjvTM2NXNqR qjjRL1tIkkyk2+jXDtz5XdwXTK7bKGZEV9rGWkrmFg== X-Google-Smtp-Source: APXvYqyi1FGLP/NHHhAw61k1O7cVzrWQIgQEMBvT0vZYa1uttdU/TqJE9gzTMmSpCkzSgMtLE5IDWqq0x/Yk7nxflYU= X-Received: by 2002:a2e:9645:: with SMTP id z5mr3591940ljh.187.1555596572572; Thu, 18 Apr 2019 07:09:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robin MARX Date: Thu, 18 Apr 2019 16:09:20 +0200 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Christian Huitema , QUIC WG , Kazuho Oku , Lucas Pardue Content-Type: multipart/alternative; boundary="0000000000001f60d50586ce8dee" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 14:09:40 -0000 --0000000000001f60d50586ce8dee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mikkel, Sorry for not addressing your first reply. At this point, I was not really considering making the format protobuf-compatible. I know that you can trivially transform from a binary to a json-based protobuf representation (that's what I'm doing in the quictrace2qlog tool ) I don't know all that much about protobuf, but from what I've learned from the quictrace format and its default json output, it seems like that would end up -a lot- more verbose than the current qlog proposal. E.g., quic-trace of 823KB to json clocks in at 14MB, due to a lot of repeated fields (see also issue 4 ). I'm not sure if protobuf supports the tricks we apply to bring down filesize (i.e., csv-alike having "column headers" that say what's in each column so not each entry needs those field names repeated). This approach is described in the current draft in section 3.3.4 . (see also the common_fields trick with group_ids and issue 8 ). If that type of approach is possible in protobuf/flatbuffer, it would certainly be interesting to consider it. If it's not, the (transformed) .json files would be much larger than what we have now, which would make it even more difficult to create scalable web-based tools. (Counterpoint: loading large json files is certainly possible in the browser, it's primarily rendering of many small elements that will be the bottleneck). An alternative argument you could make is that if you have the binary protobuf, you do not need to transform to json at all: just load the binary file using something like protobuf.js . However, this would make the logs unreadable to the human eye without using the tools, which makes it a little less applicable as a general logging format (e.g., to (partially) replace the textlogs that most implementation now output in an ad-hoc fashion). My personal feeling is that I would prefer a readable json file so I don't always need the tools, but possibly this is a trade-off that can be made (see .pcap). So some input would be welcome on: - Usefulness of human readability - Willingness to output protobuf/flatbuffer directly from implementations (if you have to transform from whatever your app is doing into protobuf as post-process anyway, you might as well transform to JSON imo) With best regards, Robin On Thu, 18 Apr 2019 at 12:48, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > It doesn=E2=80=99t really reflect on my earlier suggestion on making JSON > flatbuffer compatible. > > The thing is that thare are parsers from JSON to protobuf and from JSON t= o > flatbuffers where have you do not have to do anything other than writing > some driver logic to get the conversion. > > A protobuf schema will often have a JSON format that is very similar to > what is accepted by similar schema in FlatBuffers, so it suffice to defin= e > a protobuf schema and a FlatBufffers schema, and all conversion can happe= n > automatically via JSON. > > However, if you rely on specific features such as Any or OneOf, it might > not work, and if you use Base64 to encode strings instead of binary array= s, > it will not work. But, it is generally not difficult to specify schema > where this is not a problem. > > Googles Flatbuffer tool flatc convert json to binary given a schema. > FlatBuffers for C (flatcc) generates JSON C parsers from a schema which c= an > process JSON very fast into FlatBuffers (I=E2=80=99m the author). > > It is unlikely that you will see someone handcoding a JSON parser to > convert it into FlatBuffers. > > Mikkel > > > > On 18 April 2019 at 12.40.34, Robin MARX (robin.marx@uhasselt.be) wrote: > > Hello everyone, > > Thank you for the thoughtful comments. > I think I can answer most of the remarks made with one statement: you can > log whatever you want in whatever format, and then write a transformer in= to > the qlog format. > > A better way to describe qlog is probably "*a common input data format > for tools*" rather than a standard *logging* format. > However, you can certainly use qlog as a basic logging format as well, > which is exactly what quicker and (partially) lsquic are currently doing. > When you need higher performance or don't want to write two serializers i= n > the implementation etc., you can log in other ways and then transform to > qlog for ingestion in the tools. > This is usually relatively trivial and fast, e.g., see the quictrace2qlog > and pcap2qlog converters we've already started (and what Jana is also doi= ng > for quicly iiuc), > As you say, I don't think it's realistic to get every implementation to > agree on how exactly they will log, whether it's a verbose .json or > optimized flatbuffer setup. > > A few more in-depth comments: > > 1) I do not want tools to have to parse the binary wire image themselves > - I envision many tool developers/maintainers will be students, > interns or other non-QUIC experts. Having them write/extend a parser is > possibly not the best idea. > - The binary formats are sometimes quite non-intuitive (e.g., ACK > frame) which can lead to mistakes in interpretation. > - Each tool platform/language (e.g., web, C++, python, ...) would nee= d > its own frame parsing library (for JSON, that's usually readily available= ) > - Parsing the binary in for example web-based tools (which I envision > will be the largest group, as they allow ease of use and sharing), will > lead to performance problems there. > - As Lucas said, ideally the logs would go much further than just the > wire image. I'm more interested in when and how exactly an ACK is > processed, rather than just what came in on the wire. > Taking that into consideration, the logs would contain two > formats, one for binary events, one for all the rest, again adding to > complexity. > > - That being said, the original qlog proposal had the concept of also > logging raw values, and it's certainly possible to re-incorporate that as > an optional extra field (see issue 11 > ). > e.g., you could just log the binary hex-string from the > implementation, and then write a post-processing converter that parses th= e > binary values and transforms them into the expected qlog fields. > > 2) The verbosity is indeed a potential problem, but it's manageable > - As stated at the beginning, for high-performance tracing, you could > only log the select events you want or use a custom format and post-proce= ss > it into qlog for tooling > - Even within the JSON setup, there are many ways to reduce the > file-size and logging overhead (e.g., the technique used by the Netlog > format, also discussable in issue 8 > ) > Logging individual events should not take more overhead than > normal textual logging that is now also done to stdout > - I agree that current (v1) stacks are going beyond basic interop, but > this is meant to be more general purpose and long-term > Think of teaching new people, implementing new features (v2, > other app-layer besides H3), major performance-related refactoring, etc. > For those use cases, a highly optimized format is in my opinion > more of a hindrance than a more verbose format is to congestion control / > performance evaluation > - Just like with normal logging, qlog has the concept of log levels > (e.g., Verbose vs Error-only), but then for categories. e.g., only > debugging HTTP/3 right now, not logging any of the QUIC stuff. > > > Smaller remarks: > - The "class" fields are just because we are using TypeScript semantics (= see > issue 5 ).. They do > not mean that you cannot simply drop unknown frames. > In fact, one of the key tenets of qlog is that you can add as many > custom events as you want for easy extensibility. > - Tools would be required to clearly list the types of events they look > for and the data they expect in the log. > You can then see for yourself what it takes to be able to use that > tool and only log (or transform to qlog) that exact info. > > > I hope this helps resolve some of the questions. > The current proposal is the one I feel strikes the best balance between > performance and usability, flexibility and pragmatism. > > Feel free to disagree with my points above and to go more in-depth on the > github issues. > > With best regards, > Robin > > > On Thu, 18 Apr 2019 at 03:19, Christian Huitema > wrote: > >> On 4/17/2019 5:55 PM, Kazuho Oku wrote: >> >> > Though, even if that is the case for HTTP-level logging, I'd still >> > argue that it would be worthwhile to allow QUIC / H3 stacks to log the >> > QUIC or the H3 frames using the wire-format. There's no reason to >> > require each stack to implement the logging format. Allowing the >> > stacks to log using the wire-format would lower the entry bar of the >> > stacks supporting the analysis tools. >> >> I am a bit concerned that the proposed logging formats are rather >> verbose, using text encodings and lots of detailed events. That useful >> when debugging basic interop issues, but we are somewhat past that. As >> QUIC is maturing, I expect to see a much greater emphasis on debugging >> performance issues: software performance of course, but also performance >> of recovery and congestion control. You need good traces to debug the >> recovery and congestion issues, but you lose if turning on tracing slows >> down the system so much that the behavior under traces does not reflect >> normal behavior. And I am concerned that using verbose formats will do >> just that. >> >> -- Christian Huitema >> >> >> > > -- > > Robin Marx > PhD researcher - web performance > Expertise centre for Digital Media > > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > > > --=20 Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --0000000000001f60d50586ce8dee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mikkel,

Sorry for not addressing = your first reply.=C2=A0
At this point, I was not really consideri= ng making the format protobuf-compatible.=C2=A0
I know that you c= an trivially transform from a binary to a json-based protobuf representatio= n (that's what I'm doing in the quictrace2qlog tool)

I don&= #39;t know all that much about protobuf, but from what I've learned fro= m the quictrace format and its default json output, it seems like that woul= d end up -a lot- more verbose than the current qlog proposal.
E.g= ., quic-trace of 823KB to json clocks in at 14MB, due to a lot of repeated = fields (see= also issue 4).

I'm not sure if protobuf s= upports the tricks we apply to bring down filesize (i.e., csv-alike having = "column headers" that say what's in each column so not each e= ntry needs those field names repeated).
This approach is describe= d in the current draft in = section 3.3.4. (see also the common_fields trick with group_ids and issue 8).<= /div>

If that type of approach is possible in protobuf/f= latbuffer, it would certainly be interesting to consider it.=C2=A0
If it's not, the (transformed) .json files would be much larger than = what we have now, which would make it even more difficult to create scalabl= e web-based tools.=C2=A0
(Counterpoint: loading large json files = is certainly possible in the browser, it's primarily rendering of many = small elements that will be the bottleneck).=C2=A0

An alternative argument you could make is that if you have the binary prot= obuf, you do not need to transform to json at all: just load the binary fil= e using something like p= rotobuf.js.=C2=A0
However, this would make the logs unreadabl= e to the human eye without using the tools, which makes it a little less ap= plicable as a general logging format (e.g., to (partially) replace the text= logs that most implementation now output in an ad-hoc fashion).=C2=A0
=
My personal feeling is that I would prefer a readable json file so I d= on't always need the tools, but possibly this is a trade-off that can b= e made (see .pcap).=C2=A0

So some input would be w= elcome on:
- Usefulness of human readability
- Willingn= ess to output protobuf/flatbuffer directly from implementations (if you hav= e to transform from whatever your app is doing into protobuf as post-proces= s anyway, you might as well transform to JSON imo)

With best regards,
Robin


On Thu, 18 Apr 2019= at 12:48, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
It doesn=E2=80= =99t really reflect on my earlier suggestion on making JSON flatbuffer comp= atible.

The thing is that thare are parsers from JSON to protobuf and from JSON to= flatbuffers where have you do not have to do anything other than writing s= ome driver logic to get the conversion.

A protobuf schema will often have a JSON for= mat that is very similar to what is accepted by similar schema in FlatBuffe= rs, so it suffice to define a protobuf schema and a FlatBufffers schema, an= d all conversion can happen automatically via JSON.

However, if you rely on specific= features such as Any or OneOf, it might not work, and if you use Base64 to= encode strings instead of binary arrays, it will not work. But, it is gene= rally not difficult to specify schema where this is not a problem.

Googles Flatbuffe= r tool flatc convert json to binary given a schema. FlatBuffers for C (flat= cc) generates JSON C parsers from a schema which can process JSON very fast= into FlatBuffers (I=E2=80=99m the author).

It is unlikely that you will see someone= handcoding a JSON parser to convert it into FlatBuffers.

Mikkel



On 18 April 2019 at 12.40.34, Robin MARX (robin.marx@uhasselt.be) wrote:

=
<= span>
Hello everyone,

Thank you for the thoughtful comments.=C2=A0
I think I can answer most of the remarks made with one statement: you can log whatever you want in whatever format, and then write a transformer into the qlog format.=C2=A0

A better way to describe qlog is probably "a common input data format for tools" rather than a standard logging format.
However, you can certainly use qlog as a basic logging format as well, which is exactly what quicker and (partially) lsquic are currently doing.=C2=A0
When you need higher performance or don't want to write two serializers in the implementation etc., you can log in other ways and then transform to qlog for ingestion in the tools.
This is usually relatively trivial and fast, e.g., see the quictrace2qlog and pcap2qlog converters we've already started (and what Jana is also doing for quicly iiuc),=C2=A0
As you say, I don't think it's realistic to get every implementation to agree on how exactly they will log, whether it's a verbose .json or optimized flatbuffer setup.=C2=A0

A few more in-depth comments:

1) I do not want tools to have to parse the binary wire image themselves
=C2=A0 =C2=A0 - I envision many tool developers/maintainers will be students, interns or other non-QUIC experts. Having them write/extend a parser is possibly not the best idea.=C2=A0
=C2=A0 =C2=A0 - The binary formats are sometimes quite non-intuitive (e.g., ACK frame) which can lead to mistakes in interpretation.=C2=A0
=C2=A0 =C2=A0 - Each tool platform/language (e.g., web, C++, python, ...) would need its own frame parsing library (for JSON, that's usually readily available)
=C2=A0 =C2=A0 - Parsing the binary in for example web-based tools (which I envision will be the largest group, as they allow ease of use and sharing), will lead to performance problems there.
=C2=A0 =C2=A0 - As Lucas said, ideally the logs would go much further than just the wire image. I'm more interested in when and how exactly an ACK is processed, rather than just what came in on the wire.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Taking that into consideration, the logs would contain two formats, one for binary events, one for all the rest, again adding to complexity.

=C2=A0 =C2=A0 - That being said, the original qlog proposal had the concept of also logging raw values, and it's certainly possible to re-incorporate that as an optional extra field (see issue 11).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e.g., you could just log the binary hex-string from the implementation, and then write a post-processing converter that parses the binary values and transforms them into the expected qlog fields.

2) The verbosity is indeed a potential problem, but it's manageable
=C2=A0 =C2=A0- As stated at the beginning, for high-performance tracing, you could only log the select events you want or use a custom format and post-process it into qlog for tooling
=C2=A0 =C2=A0- Even within the JSON setup, there are many ways to reduce the file-size and logging overhead (e.g., the technique used by the Netlog format, also discussable in issue 8)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Logging individual events should not take more overhead than normal textual logging that is now also done to stdout
=C2=A0 =C2=A0- I agree that current (v1) stacks are going beyond basic interop, but this is meant to be more general purpose and long-term
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Think of teaching new people, implementing new features (v2, other app-layer besides H3), major performance-related refactoring, etc.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For those use cases, a highly optimized format is in my opinion more of a hindrance than a more verbose format is to congestion control / performance evaluation
=C2=A0 =C2=A0- Just like with normal logging, qlog has the concept of log levels (e.g., Verbose vs Error-only), but then for categories. e.g., only debugging HTTP/3 right now, not logging any of the QUIC stuff.=C2=A0


Smaller remarks:
- The "class" fields are just because we are using TypeScrip= t semantics (see issue 5).. They do not mean that you cannot simply drop unknown frames.=C2=A0
=C2=A0 =C2=A0 =C2=A0In fact, one of the key tenets of qlog is that you can add as many custom events as you want for easy extensibility.=C2=A0
- Tools would be required to clearly list the types of events they look for and the data they expect in the log.=C2=A0
=C2=A0 =C2=A0 =C2=A0You can then see for yourself what it takes to be able to use that tool and only log (or transform to qlog) that exact info.


I hope this helps resolve some of the questions.=C2=A0
The current proposal is the one I feel strikes the best balance between performance and usability, flexibility and pragmatism.=C2=A0

Feel free to disagree with my points above and to go more in-depth on the github issues.=C2=A0

With best regards,
Robin


On Thu, 18 Apr 2019 at 03:19, Christian Huitema <huitema@huitema..net> wrote:
On 4/17/2019 5:55 PM, Kazuho Oku wrote:

> Though, even if that is the case for HTTP-level logging, I'd still
> argue that it would be worthwhile to allow QUIC / H3 stacks to log the
> QUIC or the H3 frames using the wire-format. There's no reason to
> require each stack to implement the logging format. Allowing the
> stacks to log using the wire-format would lower the entry bar of the
> stacks supporting the analysis tools.

I am a bit concerned that the proposed logging formats are rather
verbose, using text encodings and lots of detailed events. That useful
when debugging basic interop issues, but we are somewhat past that. As
QUIC is maturing, I expect to see a much greater emphasis on debugging
performance issues: software performance of course, but also performance
of recovery and congestion control. You need good traces to debug the
recovery and congestion issues, but you lose if turning on tracing slows
down the system so much that the behavior under traces does not reflect
normal behavior. And I am concerned that using verbose formats will do
just that.

-- Christian Huitema




--

Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for Digital Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
=3D""


--

<= td style=3D"font-family:Verdana,Geneva,sans-serif">Agoralaan Gebouw D - = B-3590 Diepenbeek --0000000000001f60d50586ce8dee-- From nobody Thu Apr 18 07:38:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC0F12034B for ; Thu, 18 Apr 2019 07:38:56 -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 MimHw_CSTSAm for ; Thu, 18 Apr 2019 07:38:50 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03545120346 for ; Thu, 18 Apr 2019 07:38:50 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id s3so3655321itk.1 for ; Thu, 18 Apr 2019 07:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=MTkvEoGlLlzXgziDvU59y6oqgNKYjmaf3jD9nvFh83o=; b=OG85k8BY3yxyCWVhPPhtXO/YO7kj66nm4yQyZtwhgePzSF6qx84nJsKgG586BKdoeF x4J9U9VUlPgs0TclOG8JWJS/+Bm6wRLbkpFj+oANUratgmmJFW+VKTEpmLtOUJaRcPax xL/TBGkCi2VsuH77S5EIfUjvFH84yfuE7mupeM0QkpNZb/Lh07ItwmvI3S6/qKIJVRZO EW+5rkopSxNRDoPXiMJoZn0MwINxwHoqXkwPez567/hwLfkLY+AXzOc4skj5baf+VNlA /wbDStm6uoRj+e9ABI5gW2ciaI8ASouEKv4Emrm9MXG/CEdXmRyz68Qcnbx9rilFLjeE GM8g== 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=MTkvEoGlLlzXgziDvU59y6oqgNKYjmaf3jD9nvFh83o=; b=j19WDUnrwjSvIDlbKYkiWYuaRp8gq9qZfjfB90SBRYY1Dc90VKzCF2HSZX8L2AMK8p dh2W0QomnN26JkbU3DRJy/0v02o4nOnDzXVsGR/T9+ypjksNhlNh50rSzxEmz7dbgK7U 06Sa7213CtQdEe+0sgspvNWHkpyl1m/MV8K3dGLdV5r9kkHXwl5YtkLTOmJJ1+jgf6rX my40WI8VEHxAXfidectyfH3HPwjTo3ssDLVSXMqkZPvn0Mo/7P4zAgLXLuh0N8gRkWYW BivjRL2pn+PSRj4WRc36ZIW0uJ3KY84lGy7ORNLwYXG0iUXn0rFItCiPJWmiYyNQbbO/ cHcw== X-Gm-Message-State: APjAAAUsWZOpyyrJsp4kdtNdnKkYkMj8I+G0X+RI92ZwJGtcsGzU7sXr AVp3WVx9pTMPFasNwXMAYxKjoGW9hU4ZytwB9pg= X-Google-Smtp-Source: APXvYqwvdtcffM65BJDftwwJvFR9TzsmCUtSqYUMX23PB/bHeo+vkWkgLWM4bjn8YSZ27OFZSRq/+XSwXo50rHgJdR4= X-Received: by 2002:a24:9d96:: with SMTP id f144mr3345543itd.167.1555598329094; Thu, 18 Apr 2019 07:38:49 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 18 Apr 2019 07:38:47 -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: Thu, 18 Apr 2019 07:38:47 -0700 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: Robin MARX Cc: QUIC WG , Lucas Pardue , Christian Huitema , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000d1a7330586cef564" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 14:38:56 -0000 --000000000000d1a7330586cef564 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My impression was that you already used protobuf and it seems that you do, but perhaps not as prominent as I thought but for internal use. For humans, obviously JSON is the way to go. For machines it is less clear. I am not an expert on protobuf although I do know about the encoding format= . I do know a lot about FlatBuffers. Protobuf provides are rather compact binary format more than JSON and FlatBuffers, and possibly more compact than CSV. You do not have to store fields that have default values. Protobuf does not have implicit meaning like CSV fields. Each value is preceeded by a tag/type value, but that can is usually quite compact, and unused fields can be entirely omitted. However, protobuf is not directly accessible, it must be parsed into a host language structure. Depending on implementation this comes at a certain overhead. FlatBuffers is not nearly as compact - it can be both smaller and larger than JSON. All field names are implicit but there are pointers (offsets) that take up space. FlatBuffers does not store fields that have default values. FlatBuffers can be navigated directly without any allocation, for example from a memory mapped file. I do this on fairly large data sets with latency critical lookups, and it is very fast, although here, speed may not be a primary concern here. JSON is somewhat like protobuf in that it must be parsed and cannot be accessed directly. JSON parsers generally need to allocate a lot of memory, like between 3 and 10 times the file size, I would guess. Parsing JSON to FlatBuffers is interesting because JSON needs an in memory representation and this representation can be FlatBuffers. Thus, if the JSON format corresponds to a FlatBuffers schema, parsing can be extremely fast. Much faster than you can normally parse protobuf into a custom in-memory structure because you avoid a lot of allocations - if you used the code generated for C, and otherwise, it is likely still quite fast. With a bit of care, the JSON format can be designed to work with both protobuf and FlatBuffers. JSON fields that have default values are normally omitted in a FlatBuffers compatible configuration. This can save a lot of space, but for humans it might in some cases be confusing. You can force values to appear. FlatBuffers is not as widely supported as protobuf, but the list is growing with Javascript, Python, C/C++ Java as some of the most well known. If you find that another JSON format is much better and have good reasons for doing that, that is perfectly fine. What I am trying to argue is that if you have a format that is almost compatible with FlatBuffers and ProtoBuf, it would be sad not to go all the way and make it work. Both FlatBuffers, ProtoBuf and JSON are to an extend robust towards changes in the schema supporting backwards and forward schema evolution. However, a hand written JSON parser might not be equally robust towards changes. On 18 April 2019 at 16.09.33, Robin MARX (robin.marx@uhasselt.be) wrote: Hello Mikkel, Sorry for not addressing your first reply. At this point, I was not really considering making the format protobuf-compatible. I know that you can trivially transform from a binary to a json-based protobuf representation (that's what I'm doing in the quictrace2qlog tool ) I don't know all that much about protobuf, but from what I've learned from the quictrace format and its default json output, it seems like that would end up -a lot- more verbose than the current qlog proposal. E.g., quic-trace of 823KB to json clocks in at 14MB, due to a lot of repeated fields (see also issue 4 ). I'm not sure if protobuf supports the tricks we apply to bring down filesize (i.e., csv-alike having "column headers" that say what's in each column so not each entry needs those field names repeated). This approach is described in the current draft in section 3.3.4 . (see also the common_fields trick with group_ids and issue 8 ). If that type of approach is possible in protobuf/flatbuffer, it would certainly be interesting to consider it. If it's not, the (transformed) .json files would be much larger than what we have now, which would make it even more difficult to create scalable web-based tools. (Counterpoint: loading large json files is certainly possible in the browser, it's primarily rendering of many small elements that will be the bottleneck). An alternative argument you could make is that if you have the binary protobuf, you do not need to transform to json at all: just load the binary file using something like protobuf.js . However, this would make the logs unreadable to the human eye without using the tools, which makes it a little less applicable as a general logging format (e.g., to (partially) replace the textlogs that most implementation now output in an ad-hoc fashion). My personal feeling is that I would prefer a readable json file so I don't always need the tools, but possibly this is a trade-off that can be made (see .pcap). So some input would be welcome on: - Usefulness of human readability - Willingness to output protobuf/flatbuffer directly from implementations (if you have to transform from whatever your app is doing into protobuf as post-process anyway, you might as well transform to JSON imo) With best regards, Robin On Thu, 18 Apr 2019 at 12:48, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > It doesn=E2=80=99t really reflect on my earlier suggestion on making JSON > flatbuffer compatible. > > The thing is that thare are parsers from JSON to protobuf and from JSON t= o > flatbuffers where have you do not have to do anything other than writing > some driver logic to get the conversion. > > A protobuf schema will often have a JSON format that is very similar to > what is accepted by similar schema in FlatBuffers, so it suffice to defin= e > a protobuf schema and a FlatBufffers schema, and all conversion can happe= n > automatically via JSON. > > However, if you rely on specific features such as Any or OneOf, it might > not work, and if you use Base64 to encode strings instead of binary array= s, > it will not work. But, it is generally not difficult to specify schema > where this is not a problem. > > Googles Flatbuffer tool flatc convert json to binary given a schema. > FlatBuffers for C (flatcc) generates JSON C parsers from a schema which c= an > process JSON very fast into FlatBuffers (I=E2=80=99m the author). > > It is unlikely that you will see someone handcoding a JSON parser to > convert it into FlatBuffers. > > Mikkel > > > > On 18 April 2019 at 12.40.34, Robin MARX (robin.marx@uhasselt.be) wrote: > > Hello everyone, > > Thank you for the thoughtful comments. > I think I can answer most of the remarks made with one statement: you can > log whatever you want in whatever format, and then write a transformer in= to > the qlog format. > > A better way to describe qlog is probably "*a common input data format > for tools*" rather than a standard *logging* format. > However, you can certainly use qlog as a basic logging format as well, > which is exactly what quicker and (partially) lsquic are currently doing. > When you need higher performance or don't want to write two serializers i= n > the implementation etc., you can log in other ways and then transform to > qlog for ingestion in the tools. > This is usually relatively trivial and fast, e.g., see the quictrace2qlog > and pcap2qlog converters we've already started (and what Jana is also doi= ng > for quicly iiuc), > As you say, I don't think it's realistic to get every implementation to > agree on how exactly they will log, whether it's a verbose .json or > optimized flatbuffer setup. > > A few more in-depth comments: > > 1) I do not want tools to have to parse the binary wire image themselves > - I envision many tool developers/maintainers will be students, > interns or other non-QUIC experts. Having them write/extend a parser is > possibly not the best idea. > - The binary formats are sometimes quite non-intuitive (e.g., ACK > frame) which can lead to mistakes in interpretation. > - Each tool platform/language (e.g., web, C++, python, ...) would nee= d > its own frame parsing library (for JSON, that's usually readily available= ) > - Parsing the binary in for example web-based tools (which I envision > will be the largest group, as they allow ease of use and sharing), will > lead to performance problems there. > - As Lucas said, ideally the logs would go much further than just the > wire image. I'm more interested in when and how exactly an ACK is > processed, rather than just what came in on the wire. > Taking that into consideration, the logs would contain two > formats, one for binary events, one for all the rest, again adding to > complexity. > > - That being said, the original qlog proposal had the concept of also > logging raw values, and it's certainly possible to re-incorporate that as > an optional extra field (see issue 11 > ). > e.g., you could just log the binary hex-string from the > implementation, and then write a post-processing converter that parses th= e > binary values and transforms them into the expected qlog fields. > > 2) The verbosity is indeed a potential problem, but it's manageable > - As stated at the beginning, for high-performance tracing, you could > only log the select events you want or use a custom format and post-proce= ss > it into qlog for tooling > - Even within the JSON setup, there are many ways to reduce the > file-size and logging overhead (e.g., the technique used by the Netlog > format, also discussable in issue 8 > ) > Logging individual events should not take more overhead than > normal textual logging that is now also done to stdout > - I agree that current (v1) stacks are going beyond basic interop, but > this is meant to be more general purpose and long-term > Think of teaching new people, implementing new features (v2, > other app-layer besides H3), major performance-related refactoring, etc. > For those use cases, a highly optimized format is in my opinion > more of a hindrance than a more verbose format is to congestion control / > performance evaluation > - Just like with normal logging, qlog has the concept of log levels > (e.g., Verbose vs Error-only), but then for categories. e.g., only > debugging HTTP/3 right now, not logging any of the QUIC stuff. > > > Smaller remarks: > - The "class" fields are just because we are using TypeScript semantics (= see > issue 5 ).. They do > not mean that you cannot simply drop unknown frames. > In fact, one of the key tenets of qlog is that you can add as many > custom events as you want for easy extensibility. > - Tools would be required to clearly list the types of events they look > for and the data they expect in the log. > You can then see for yourself what it takes to be able to use that > tool and only log (or transform to qlog) that exact info. > > > I hope this helps resolve some of the questions. > The current proposal is the one I feel strikes the best balance between > performance and usability, flexibility and pragmatism. > > Feel free to disagree with my points above and to go more in-depth on the > github issues. > > With best regards, > Robin > > > On Thu, 18 Apr 2019 at 03:19, Christian Huitema > wrote: > >> On 4/17/2019 5:55 PM, Kazuho Oku wrote: >> >> > Though, even if that is the case for HTTP-level logging, I'd still >> > argue that it would be worthwhile to allow QUIC / H3 stacks to log the >> > QUIC or the H3 frames using the wire-format. There's no reason to >> > require each stack to implement the logging format. Allowing the >> > stacks to log using the wire-format would lower the entry bar of the >> > stacks supporting the analysis tools. >> >> I am a bit concerned that the proposed logging formats are rather >> verbose, using text encodings and lots of detailed events. That useful >> when debugging basic interop issues, but we are somewhat past that. As >> QUIC is maturing, I expect to see a much greater emphasis on debugging >> performance issues: software performance of course, but also performance >> of recovery and congestion control. You need good traces to debug the >> recovery and congestion issues, but you lose if turning on tracing slows >> down the system so much that the behavior under traces does not reflect >> normal behavior. And I am concerned that using verbose formats will do >> just that. >> >> -- Christian Huitema >> >> >> > > -- > > Robin Marx > PhD researcher - web performance > Expertise centre for Digital Media > > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > > > -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --000000000000d1a7330586cef564 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = My impression was th= at you already used protobuf and it seems that you do, but perhaps not as p= rominent as I thought but for internal use.


For humans= , obviously JSON is the way to go. For machines it is less clear.

I= am not an expert on protobuf although I do know about the encoding format.=
I do know a = lot about FlatBuffers.

You do not have to store fields that have = default values. Protobuf does not have implicit meaning like CSV fields. Ea= ch value is preceeded by a tag/type value, but that can is usually quite co= mpact, and unused fields can be entirely omitted.

However, protobuf is not directly accessible, = it must be parsed into a host language structure. Depending on implementati= on this comes at a certain=C2=A0
overhead.

FlatBuffers is not nearly as compact - it can be both smaller and = larger than JSON. All field names are implicit but there are pointers (offs= ets) that take up space.

FlatBuffers does not store fields that have default values. FlatBuffers= can be navigated directly without any allocation, for example from a memor= y mapped file. I do this on fairly large data sets with latency critical lo= okups, and it is very fast, although here, speed may not be a primary conce= rn here.

=
JSON is some= what like protobuf in that it must be parsed and cannot be accessed directl= y. JSON parsers generally need to allocate a lot of memory, like between 3 = and 10 times the file size, I would guess.

Parsing JSON to FlatBuffers is interesting because J= SON needs an in memory representation and this representation can be FlatBu= ffers. Thus, if the JSON format corresponds to a FlatBuffers schema, parsin= g can be extremely fast. Much faster than you can normally parse protobuf i= nto a custom in-memory structure because you avoid a lot of allocations - i= f you used the code generated for C, and otherwise, it is likely still quit= e fast.

<= /div>
With a bit of= care, the JSON format can be designed to work with both protobuf and FlatB= uffers.

<= /div>
JSON fields t= hat have default values are normally omitted in a FlatBuffers compatible co= nfiguration. This can save a lot of space, but for humans it might in some = cases be confusing. You can force values to appear.

FlatBuffers is not as widely supported as pr= otobuf, but the list is growing with Javascript, Python, C/C++ Java as some= of the most well known.

If you find that another JSON format is much better and have good reaso= ns for doing that, that is perfectly fine. What I am trying to argue is tha= t if you have a format that is almost compatible with FlatBuffers and Proto= Buf, it would be sad not to go all the way and make it work.

Both FlatBuffers, ProtoBuf and JSON are to= an extend robust towards changes in the schema supporting backwards and fo= rward schema evolution. However, a hand written JSON parser might not be eq= ually robust towards changes.

On 18= April 2019 at 16.09.33, Robin MARX (robin.marx@uhasselt.be) wrote:

Hello Mikkel,

Sorry for not addressing your first reply.=C2=A0
At this point, I was not really considering making the format protobuf-compatible.=C2=A0
I know that you can trivially transform from a binary to a json-based protobuf representation (that's what I'm doing in the quictrace2qlog tool)

I don't know all that much about protobuf, but from what I've learned from the quictrace format and its default json output, it seems like that would end up -a lot- more verbose than the current qlog proposal.
E.g., quic-trace of 823KB to json clocks in at 14MB, due to a lot of repeated fields (see also issue 4).

I'm not sure if protobuf supports the tricks we apply to bring down filesize (i.e., csv-alike having "column headers" that say what's in each column so not each entry needs those field names repeated).
This approach is described in the current draft in section 3.3.4. (see also the common_fields trick with group_ids and issue 8).

If that type of approach is possible in protobuf/flatbuffer, it would certainly be interesting to consider it.=C2=A0
If it's not, the (transformed) .json files would be much larger than what we have now, which would make it even more difficult to create scalable web-based tools.=C2=A0
(Counterpoint: loading large json files is certainly possible in the browser, it's primarily rendering of many small elements that will be the bottleneck).=C2=A0

An alternative argument you could make is that if you have the binary protobuf, you do not need to transform to json at all: just load the binary file using something like protobuf.js.=C2=A0
However, this would make the logs unreadable to the human eye without using the tools, which makes it a little less applicable as a general logging format (e.g., to (partially) replace the textlogs that most implementation now output in an ad-hoc fashion).=C2=A0
My personal feeling is that I would prefer a readable json file so I don't always need the tools, but possibly this is a trade-off that can be made (see .pcap).=C2=A0

So some input would be welcome on:
- Usefulness of human readability
- Willingness to output protobuf/flatbuffer directly from implementations (if you have to transform from whatever your app is doing into protobuf as post-process anyway, you might as well transform to JSON imo)

With best regards,
Robin


On Thu, 18 Apr 2019 at 12:48, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
It doesn=E2=80=99t really reflect on my earlier suggestion on making JSON flatbuffer compatible.

The thing is that thare are parsers from JSON to protobuf and from JSON to flatbuffers where have you do not have to do anything other than writing some driver logic to get the conversion.

A protobuf schema will often have a JSON format that is very similar to what is accepted by similar schema in FlatBuffers, so it suffice to define a protobuf schema and a FlatBufffers schema, and all conversion can happen automatically via JSON.

However, if you rely on specific features such as Any or OneOf, it might not work, and if you use Base64 to encode strings instead of binary arrays, it will not work. But, it is generally not difficult to specify schema where this is not a problem.

Googles Flatbuffer tool flatc convert json to binary given a schema. FlatBuffers for C (flatcc) generates JSON C parsers from a schema which can process JSON very fast into FlatBuffers (I=E2=80=99m the author).

It is unlikely that you will see someone handcoding a JSON parser to convert it into FlatBuffers.

Mikkel



On 18 April 2019 at 12.40.34, Robin MARX (robin.marx@uhasselt.be) wrote:

Hello everyone,

Thank you for the thoughtful comments.=C2=A0
I think I can answer most of the remarks made with one statement: you can log whatever you want in whatever format, and then write a transformer into the qlog format.=C2=A0

A better way to describe qlog is probably "a common input data format for tools" rather than a standard logging format.
However, you can certainly use qlog as a basic logging format as well, which is exactly what quicker and (partially) lsquic are currently doing.=C2=A0
When you need higher performance or don't want to write two serializers in the implementation etc., you can log in other ways and then transform to qlog for ingestion in the tools.
This is usually relatively trivial and fast, e.g., see the quictrace2qlog and pcap2qlog converters we've already started (and what Jana is also doing for quicly iiuc),=C2=A0
As you say, I don't think it's realistic to get every implementation to agree on how exactly they will log, whether it's a verbose .json or optimized flatbuffer setup.=C2=A0

A few more in-depth comments:

1) I do not want tools to have to parse the binary wire image themselves
=C2=A0 =C2=A0 - I envision many tool developers/maintainers will be students, interns or other non-QUIC experts. Having them write/extend a parser is possibly not the best idea.=C2=A0
=C2=A0 =C2=A0 - The binary formats are sometimes quite non-intuitive (e.g., ACK frame) which can lead to mistakes in interpretation.=C2=A0
=C2=A0 =C2=A0 - Each tool platform/language (e.g., web, C++, python, ...) would need its own frame parsing library (for JSON, that's usually readily available)
=C2=A0 =C2=A0 - Parsing the binary in for example web-based tools (which I envision will be the largest group, as they allow ease of use and sharing), will lead to performance problems there.
=C2=A0 =C2=A0 - As Lucas said, ideally the logs would go much further than just the wire image. I'm more interested in when and how exactly an ACK is processed, rather than just what came in on the wire.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Taking that into consideration, the logs would contain two formats, one for binary events, one for all the rest, again adding to complexity.

=C2=A0 =C2=A0 - That being said, the original qlog proposal had the concept of also logging raw values, and it's certainly possible to re-incorporate that as an optional extra field (see issue 11).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e.g., you could just log the binary hex-string from the implementation, and then write a post-processing converter that parses the binary values and transforms them into the expected qlog fields.

2) The verbosity is indeed a potential problem, but it's manageable
=C2=A0 =C2=A0- As stated at the beginning, for high-performance tracing, you could only log the select events you want or use a custom format and post-process it into qlog for tooling
=C2=A0 =C2=A0- Even within the JSON setup, there are many ways to reduce the file-size and logging overhead (e.g., the technique used by the Netlog format, also discussable in issue 8= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Logging individual events should not take more overhead than normal textual logging that is now also done to stdout
=C2=A0 =C2=A0- I agree that current (v1) stacks are going beyond basic interop, but this is meant to be more general purpose and long-term
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Think of teaching new people, implementing new features (v2, other app-layer besides H3), major performance-related refactoring, etc.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For those use cases, a highly optimized format is in my opinion more of a hindrance than a more verbose format is to congestion control / performance evaluation
=C2=A0 =C2=A0- Just like with normal logging, qlog has the concept of log levels (e.g., Verbose vs Error-only), but then for categories. e.g., only debugging HTTP/3 right now, not logging any of the QUIC stuff.=C2=A0


Smaller remarks:
- The "class" fields are just because we are using TypeScript semantics (see issue 5).. They do not mean that you c= annot simply drop unknown frames.=C2=A0
=C2=A0 =C2=A0 =C2=A0In fact, one of the key tenets of qlog is that you can add as many custom events as you want for easy extensibility.=C2=A0
- Tools would be required to clearly list the types of events they look for and the data they expect in the log.=C2=A0
=C2=A0 =C2=A0 =C2=A0You can then see for yourself what it takes to be able to use that tool and only log (or transform to qlog) that exact info.


I hope this helps resolve some of the questions.=C2=A0
The current proposal is the one I feel strikes the best balance between performance and usability, flexibility and pragmatism.=C2=A0

Feel free to disagree with my points above and to go more in-depth on the github issues.=C2=A0

With best regards,
Robin
On Thu, 18 Apr 2019 at 03:19, Christian Huitema <huitema@huitema..net> wrote:
On 4/17/2019 5:55 PM, Kazuho Oku wrote:

> Though, even if that is the case for HTTP-level logging, I'd still
> argue that it would be worthwhile to allow QUIC / H3 stacks to log the
> QUIC or the H3 frames using the wire-format. There's no reason to
> require each stack to implement the logging format. Allowing the
> stacks to log using the wire-format would lower the entry bar of the
> stacks supporting the analysis tools.

I am a bit concerned that the proposed logging formats are rather
verbose, using text encodings and lots of detailed events. That useful
when debugging basic interop issues, but we are somewhat past that. As
QUIC is maturing, I expect to see a much greater emphasis on debugging
performance issues: software performance of course, but also performance
of recovery and congestion control. You need good traces to debug the
recovery and congestion issues, but you lose if turning on tracing slows
down the system so much that the behavior under traces does not reflect
normal behavior. And I am concerned that using verbose formats will do
just that.

-- Christian Huitema

--

Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for Digita= l Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 9= 4
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
3D""
Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for Digital Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
=3D""


--

Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for Digital Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
=3D""
--000000000000d1a7330586cef564-- From nobody Thu Apr 18 08:04:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF75120172 for ; Thu, 18 Apr 2019 08:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 HtOqnioT0w4L for ; Thu, 18 Apr 2019 08:04:03 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FC1120170 for ; Thu, 18 Apr 2019 08:04:03 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id p20so2479545qtc.9 for ; Thu, 18 Apr 2019 08:04:03 -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=+P+cCNChRZYSUexxwbTtnPoPx3LwxC7081qW+LgAtaY=; b=Z65AGjolzVcdHFiBD0Mro20ILCor1ch3Scf23P108Dzz7jQSIoYpPEL0wIYUjQRiRj HxHig/OP7hoDDLXtvChwMfIz8DhGNw20ABi1493hCOkUWay60FcgsT5+zHfP2mV8hKSI jBXk75nkC2VXrYcrmyGdGDU51zm4fVbzKzKs9vi1akFG7ESiCRUbkiF3cm1DorYdyVwU iOYv4z0pokyn62/TcX7Tb0Y8kksxasETHVaSy80d0GYCK3ZjG/s76onSjLyKo+WRgzTT LfTNRXaDLqDlo14qHvgaQvAuGiTJsKgVXMIzsJaURlo9BwWJayhjFq8Ian8c4ZxITGM6 hwzw== 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=+P+cCNChRZYSUexxwbTtnPoPx3LwxC7081qW+LgAtaY=; b=bE8E+ugo7KYBVWf49Z6myFhf3duPakeLK2Vs2bLonHc1DKhgO7VG7A+tSjDU7moSl6 r8EyfeDe+k95V2tdoVjyko+nBKC/Oo3u9girBY07xJ2NWC5LZmuQ2U0WpYZDtdnQrFqL jAQcB+i12NNbkRlI6MCWHLr5yxk1gOh/xijUuYoJRLGQuxy1RBc8auj4AYGIGc242SS5 rVTrL98HBEDWnQ/abZTkcBlJAvQ5uVaFu0Dm4DFFM8b+3vJ8rjgjLUU9I1ktr2crdpkU 2tYYyWPmbM6QgNziOoL9/59zFXHdFju6ACJsZW+tk9yY88H7tnxfRrBj6d77cAtaBhql uGJw== X-Gm-Message-State: APjAAAVCqnRhMbOEqKRjMMdeB6HC5omk33kn4VgipU6POjAsP441gC5+ On9LFe7JAJyBUhV9e+Oq0dLAHA== X-Google-Smtp-Source: APXvYqylHOjBIXoQ36C41V6GqlCf75oqXxkp8CJyA0eVA06lT2Srbkv7F5R5cz7pLgjhg5XwNOxdYw== X-Received: by 2002:ac8:3821:: with SMTP id q30mr72872394qtb.73.1555599842129; Thu, 18 Apr 2019 08:04:02 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id r15sm1423548qtb.22.2019.04.18.08.04.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 08:04:01 -0700 (PDT) Date: Thu, 18 Apr 2019 11:03:55 -0400 From: Dmitri Tikhonov To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= Cc: Robin MARX , QUIC WG , Christian Huitema , Kazuho Oku , Lucas Pardue Subject: Re: QUIC logging and tooling : moving towards qlog Message-ID: <20190418150354.GA4403@ubuntu-dmitri> Mail-Followup-To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Robin MARX , QUIC WG , Christian Huitema , Kazuho Oku , Lucas Pardue References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 15:04:06 -0000 On Thu, Apr 18, 2019 at 07:38:47AM -0700, Mikkel Fahne Jrgensen wrote: > FlatBuffers is not as widely supported as protobuf, but the list is growing > with Javascript, Python, C/C++ Java as some of the most well known. > > If you find that another JSON format is much better and have good reasons > for doing that, that is perfectly fine. What I am trying to argue is that > if you have a format that is almost compatible with FlatBuffers and > ProtoBuf, it would be sad not to go all the way and make it work. > > Both FlatBuffers, ProtoBuf and JSON are to an extend robust towards changes > in the schema supporting backwards and forward schema evolution. However, a > hand written JSON parser might not be equally robust towards changes. There are several reasons for sticking with JSON: - Robin and his crew have written much code that uses JSON. - There are probably a couple of orders of magnitude more JSON implementations than proto bufs and flatbuffers implementations combined. - JSON is human readable. - JSON is greppable. It can be processed by command-line tools without having to spend half an hour reading docs and installing special software. (This is actually a pretty high barrier to entry: most people won't go that far unless they _really_ have to.) - JSON has a standard MIME type. For example, Firefox makes responses of type application/json look pretty [1]. I propose we stop arguing about this and agree that JSON, while not perfect, is a pretty good choice with which we should stick. - Dmitri. 1. https://www.http3check.net/?host=www.http3check.net&format=qlog From nobody Thu Apr 18 08:11:52 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00041120356 for ; Thu, 18 Apr 2019 08:11:49 -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 E0_93mwqJRwv for ; Thu, 18 Apr 2019 08:11:47 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D6E12034C for ; Thu, 18 Apr 2019 08:11:47 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id y134so3803594itc.5 for ; Thu, 18 Apr 2019 08:11:47 -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=JyD/bslvdRKZsT8EG1fu+lcYFbDr6Hl+hp2tDrwiGek=; b=VZlOSFfRz99/pfvouj2VpEEqB+jzONC2VME/K9cSbuMKXh3b76gS5/T8LTOTQ6U11e SUN5S0PStAX20lGei8k+kVmm9KhDuyeX5mRerpiFIqS7c1FX+UqSe4gViQwZz/FkRHMn YXazYEHIbchJhtljEZ8kfRuwf66QGMpCAcC6sSaWAaXhBVyLDhO7AkN0HOJfbnpFLk7C iwxhTSegE4pIjv0HN0quTDkUwto8QMDMqwA5PWc1CH+krScij0Iwxr6vaytm2ll98NVc Y0ayNQUv0g64F/T/IXgVNhW71hWqPr6sEvWu4R4aTotNb5Aly1Yq+GsKmmCa2NMW47Mt YX8Q== 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=JyD/bslvdRKZsT8EG1fu+lcYFbDr6Hl+hp2tDrwiGek=; b=UUMAakYL6AKmE9U/lqjpXU+lmncCT6QRvwNRQoeRMURu4n3KoAMpiglnNyVAb1WXL5 DPIhspDYL/hIuL0FFZmZgYLabWJLAdWhg91h9uJgXWV2pKK8+R58ZjHHNixbO/0ytt5H FAfdvwuozZTZrCQp6kl/6+8S94jTYLAxJORYHqoxtw8nt6XzzhUflmkVY+WJqYxVHO6g fL/hluW31ZKzNcRiZ3HgYZnbohlm561/ZN9Id3oUEnG2U3otvsTTFjqZYl6YJLypGXXR WytKQqCS40HbGsBDduTAavQCtgb6NIYakB1KnlSOgATthZZH8DDbz0j8H971tFg0M6BU 750A== X-Gm-Message-State: APjAAAXBKMYOQ/zGLzCV/EFOaOJb0mlHQOtp6e4FaMv0CpVToRgj5B8l Z2Hfx0DG5ewIEe6MX/dFlo44gX2XfpL/OJxzuQw= X-Google-Smtp-Source: APXvYqzF7LjbgKR99BSeka+AseD98jVV6AqUkUqWB1Jp3aX9j4gbtmvvEQXtb/1MF3AbFtQxxYtyW3BWpIUpdcsEg6I= X-Received: by 2002:a24:9d96:: with SMTP id f144mr3478726itd.167.1555600306524; Thu, 18 Apr 2019 08:11:46 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 18 Apr 2019 08:11:45 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <20190418150354.GA4403@ubuntu-dmitri> References: <20190418150354.GA4403@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 18 Apr 2019 08:11:45 -0700 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: Dmitri Tikhonov Cc: Kazuho Oku , QUIC WG , Lucas Pardue , Christian Huitema , Robin MARX Content-Type: multipart/alternative; boundary="000000000000aed6d00586cf6b80" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 15:11:50 -0000 --000000000000aed6d00586cf6b80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You are missing the point. JSON can be the format of choice. The point is if the JSON format should be compatible with binary protocol parsers. On 18 April 2019 at 17.04.03, Dmitri Tikhonov (dtikhonov@litespeedtech.com) wrote: On Thu, Apr 18, 2019 at 07:38:47AM -0700, Mikkel Fahn=C3=B8e J=C3=B8rgensen= wrote: > FlatBuffers is not as widely supported as protobuf, but the list is growing > with Javascript, Python, C/C++ Java as some of the most well known. > > If you find that another JSON format is much better and have good reasons > for doing that, that is perfectly fine. What I am trying to argue is that > if you have a format that is almost compatible with FlatBuffers and > ProtoBuf, it would be sad not to go all the way and make it work. > > Both FlatBuffers, ProtoBuf and JSON are to an extend robust towards changes > in the schema supporting backwards and forward schema evolution. However, a > hand written JSON parser might not be equally robust towards changes. There are several reasons for sticking with JSON: - Robin and his crew have written much code that uses JSON. - There are probably a couple of orders of magnitude more JSON implementations than proto bufs and flatbuffers implementations combined. - JSON is human readable. - JSON is greppable. It can be processed by command-line tools without having to spend half an hour reading docs and installing special software. (This is actually a pretty high barrier to entry: most people won't go that far unless they _really_ have to.) - JSON has a standard MIME type. For example, Firefox makes responses of type application/json look pretty [1]. I propose we stop arguing about this and agree that JSON, while not perfect, is a pretty good choice with which we should stick. - Dmitri. 1. https://www.http3check.net/?host=3Dwww.http3check.net&format=3Dqlog --000000000000aed6d00586cf6b80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = You are missing the = point.

JSON can be th= e format of choice. The point is if the JSON format should be compatible wi= th binary protocol parsers.


On 18 April 2019 at 1= 7.04.03, Dmitri Tikhonov (dt= ikhonov@litespeedtech.com) wrote:

On Thu, Apr 18, 2019 at 07:38:47AM= -0700, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> FlatBuffers is not as widely supported as protobuf, but the list i= s growing
> with Javascript, Python, C/C++ Java as some of the most well known= .
> =20
> If you find that another JSON format is much better and have good = reasons
> for doing that, that is perfectly fine. What I am trying to argue = is that
> if you have a format that is almost compatible with FlatBuffers an= d
> ProtoBuf, it would be sad not to go all the way and make it work.
> =20
> Both FlatBuffers, ProtoBuf and JSON are to an extend robust toward= s changes
> in the schema supporting backwards and forward schema evolution. H= owever, a
> hand written JSON parser might not be equally robust towards chang= es.

There are several reasons for sticking with JSON:

- Robin and his crew have written much code that uses JSON.

- There are probably a couple of orders of magnitude more
JSON implementations than proto bufs and flatbuffers
implementations combined.

- JSON is human readable.

- JSON is greppable. It can be processed by command-line
tools without having to spend half an hour reading docs
and installing special software. (This is actually a pretty
high barrier to entry: most people won't go that far unless
they _really_ have to.)

- JSON has a standard MIME type. For example, Firefox makes
responses of type application/json look pretty [1].

I propose we stop arguing about this and agree that JSON, while not
perfect, is a pretty good choice with which we should stick.

- Dmitri.

1. https://www.http3check.net/?host=3Dwww.http3check.net&f= ormat=3Dqlog
--000000000000aed6d00586cf6b80-- From nobody Thu Apr 18 08:27:48 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF4B120439 for ; Thu, 18 Apr 2019 08:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 G-FJz2r8XPk4 for ; Thu, 18 Apr 2019 08:27:40 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F22D12043C for ; Thu, 18 Apr 2019 08:27:40 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id p20so2572641qtc.9 for ; Thu, 18 Apr 2019 08:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=+yz4yY1sZDl2MAxYP7KZ2xyubdt6wwQo0XNBbGdaX/w=; b=0n3CO6VK7tJZPR/t6+/1FlFgk/zJ6T5QLaatISt+OxnKiSQVswbIkBpzrk9TxmUErY NG68lA8VZeK24XmkLnh59bod8fcqDsTfRZei1NQKECEM5giiHBobLtD1/kHFl37hOKmH 8S5dsu5OBfxKGv3elA6K5xxRcrfH4ECSqUG3Lt51EyR6QtxagkNK7l/VsykjMbrhN8tF JP50fINWY7RA/3V0zny0P0XmzIUsNPbwZ3+sutabWX95i/bqyCyyKf7KX0hwzmFqpi0R LbH9Lj5D2H77T4equL0gDLMCaJBwOd7FECtXz7zSxKdeA0YfMuAKDw3c3TYCg0p0pPjJ Rg2g== 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=+yz4yY1sZDl2MAxYP7KZ2xyubdt6wwQo0XNBbGdaX/w=; b=XFXb1ySehXWvKrm+YOeD6n8Oq+UZkvU63pNrGgQabPUYYmKCNd2mnxKib7r5rEkbs2 eho/pQx/rdbPizu/Iqqs168rBnylEq/B1lS0nL5GI1e+LxNnNsOv6UniyIocrHJuD/ue rLlss35MmfC9/8L4+Y6yebKi1hyVXK1Pe3RAMHEk6lT+Bh0NBLBkQdrSm/CQpPvYyJmc gWNzKCvV4N5aOVO5ijAsKB6ZSK3rB0MWXQMn5DE2tvQiwnApVQ2li8xgLWZT6Ta3MY+V Z8y8Bvs8wgVaE0Y2UIjXJXVRMlR3/KJTNb9CSvJx4pqh7vF3KMislO/mnTvJQp8IY5Fw FHtw== X-Gm-Message-State: APjAAAXLYgCNKARtTB2WbWdV0ht91Ro/kK3IkKpI/VLO4EpNK3Fo59nV 9BO6JTk4Rv/1pQ2uPwm/SvhTZA== X-Google-Smtp-Source: APXvYqznKuBbIZUNcuahmfOzMKYA8ETwhkA22zfiAOC5jie/6ZaS900MDVSX847K5N/SkXUmVHWsHQ== X-Received: by 2002:aed:3c5b:: with SMTP id u27mr77964101qte.6.1555601259453; Thu, 18 Apr 2019 08:27:39 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id a47sm1644362qtb.79.2019.04.18.08.27.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 08:27:38 -0700 (PDT) Date: Thu, 18 Apr 2019 11:27:36 -0400 From: Dmitri Tikhonov To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= Cc: Kazuho Oku , QUIC WG , Lucas Pardue , Christian Huitema , Robin MARX Subject: Re: QUIC logging and tooling : moving towards qlog Message-ID: <20190418152735.GB4403@ubuntu-dmitri> Mail-Followup-To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Kazuho Oku , QUIC WG , Lucas Pardue , Christian Huitema , Robin MARX References: <20190418150354.GA4403@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 15:27:47 -0000 On Thu, Apr 18, 2019 at 08:11:45AM -0700, Mikkel Fahne Jrgensen wrote: > You are missing the point. > > JSON can be the format of choice. The point is if the JSON format should be > compatible with binary protocol parsers. Hmm. I suppose this was your point, then: " With a bit of care, the JSON format can be designed to work " with both protobuf and FlatBuffers. A "free" performance boost is good. On the other hand, those who want to consume qlog information as a protobuf can just write a converter, no? I am not familiar with protobuf or flat buffers and so I cannot judge the magnitude of "bit" in the "bit of care." Still, at this stage, optimizing seems premature. - Dmitri. From nobody Thu Apr 18 09:04:58 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1175B12032B for ; Thu, 18 Apr 2019 09:04:57 -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 16J6w9PYkass for ; Thu, 18 Apr 2019 09:04:54 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B1C12014E for ; Thu, 18 Apr 2019 09:04:54 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id y10so4136664itc.1 for ; Thu, 18 Apr 2019 09:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=uPLRW2FsBHRxi+B4yRm9xSpV2CdR/ps/XQu82BjhfjU=; b=guJ6U2+XsFbvDllMzJkmDXeAcu4jRXrh4recwYExha0eBaOarN2s+tDmyMFI7R9kZt LKq0M3APOboQSenjk67rBws6CITSA/NZqnGldnpFYrmGpTDUQeMmP6e1hnPccRTXHPzV 5BYDUa7EqQfihr5QltQnCebGc20kggn1TcTLanIdc2itBmVZ+X4Pwg97aV+tSKO6cuxK cZNsh1HC4iBPhPXB1CU0CbwvkS+P7bHxRuRn3dBqaNtGrRfiAnNdoGugtQlpRmmThPBQ MCQA/gad2vXicUjlC/tWkUYEqpTG0iOZE0UL0uZGnqJLegjN0KFtLZxFbxMia4EZuDY5 iLGg== 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=uPLRW2FsBHRxi+B4yRm9xSpV2CdR/ps/XQu82BjhfjU=; b=PG03XM9VfxyS46Yf2jevnMkjOd2OU5FMKtmpkR9JcnnWzDrn24t9+QTg50qyAF2tvu f62q2F7/KxVwNyGyszLp6E2a9LbpZac96coxA1UhuG9gQY6aP5MuCyiLIPXBzT7aRrXC MWGN1w+kxveicgvlBwOLArEatp5doWUDKaC7zNSyXLG/t9OUBfrDv2ydKUtQQmuZddr5 potHwxDHYCb0dvA1Qmc5hEORxD0GvUS/9UHH+LGEA7OzRj2c4fJR5nDvfiCFO5foNRSN AF24vlaQte95el5HJgQS8WNgHCdjVIuYHm4GLafiJR6No3G/FipVIPV0F7Uvb+7DGwi8 sMQA== X-Gm-Message-State: APjAAAXFZMiZarUv7jVG7CeucLH+HwJe6PJOT2HXfDoFAU2f0tMjdARW 2kTzWzUw8ToYBTaCmdoAKy1z0ZoCk3710GCzV/s= X-Google-Smtp-Source: APXvYqz8K7ApiOGHp0hp2LDxzWEEqeWKvk+PVRNZC6YQjqI0WEYMQ3VAjTYumlgbxSWTXFkbM66OH5S6JcadNsCqbrM= X-Received: by 2002:a24:7cf:: with SMTP id f198mr3905328itf.148.1555603494012; Thu, 18 Apr 2019 09:04:54 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 18 Apr 2019 09:04:53 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <20190418152735.GB4403@ubuntu-dmitri> References: <20190418150354.GA4403@ubuntu-dmitri> <20190418152735.GB4403@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 18 Apr 2019 09:04:52 -0700 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: Dmitri Tikhonov Cc: Robin MARX , QUIC WG , Lucas Pardue , Christian Huitema , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000ac09760586d0291b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 16:04:57 -0000 --000000000000ac09760586d0291b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ideally the JSON format is designed such that there exists a compatible protobuf schema and a compatible FlatBuffers schema. If this is the case, there ought to be tooling to convert JSON to protobuf or to FlatBuffers with very little effort. If the JSON format is not designed with this in mind, it will be a lot more work to design a converter and you might not be able to get an exact representation and each language might end up with its own parser and own interpretation. On 18 April 2019 at 17.27.40, Dmitri Tikhonov (dtikhonov@litespeedtech.com) wrote: On Thu, Apr 18, 2019 at 08:11:45AM -0700, Mikkel Fahn=C3=B8e J=C3=B8rgensen= wrote: > You are missing the point. > > JSON can be the format of choice. The point is if the JSON format should be > compatible with binary protocol parsers. Hmm. I suppose this was your point, then: " With a bit of care, the JSON format can be designed to work " with both protobuf and FlatBuffers. A "free" performance boost is good. On the other hand, those who want to consume qlog information as a protobuf can just write a converter, no? I am not familiar with protobuf or flat buffers and so I cannot judge the magnitude of "bit" in the "bit of care." Still, at this stage, optimizing seems premature. - Dmitri. --000000000000ac09760586d0291b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Ideally the JSON for= mat is designed such that there exists a compatible protobuf schema and a c= ompatible FlatBuffers schema.
If this is the case, there ought to be tooling to convert = JSON to protobuf or to FlatBuffers with very little effort.

If the JSON format is not designed w= ith this in mind, it will be a lot more work to design a converter and you = might not be able to get an exact representation and each language might en= d up with its own parser and own interpretation.

On 18= April 2019 at 17.27.40, Dmitri Tikhonov (dtikhonov@litespeedtech.com) wrote:

On Thu, Apr 18, 201= 9 at 08:11:45AM -0700, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> You are missing the point.
> =20
> JSON can be the format of choice. The point is if the JSON format = should be
> compatible with binary protocol parsers.

Hmm. I suppose this was your point, then:

" With a bit of care, the JSON format can be designed to work
" with both protobuf and FlatBuffers.

A "free" performance boost is good. On the other hand, those= who
want to consume qlog information as a protobuf can just write a
converter, no?

I am not familiar with protobuf or flat buffers and so I cannot
judge the magnitude of "bit" in the "bit of care." = Still, at this
stage, optimizing seems premature.

- Dmitri.
--000000000000ac09760586d0291b-- From nobody Thu Apr 18 17:17:25 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5320B120058 for ; Thu, 18 Apr 2019 17:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 d3UFJ4NofxZB for ; Thu, 18 Apr 2019 17:17:20 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 2187012004C for ; Thu, 18 Apr 2019 17:17:19 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id k8so3344691lja.8 for ; Thu, 18 Apr 2019 17:17:19 -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=xUc6n8nBPIg1c6GDl22kU8jMAC2P7JdhgqjpR4pQIh4=; b=WvyYFcgZk9MBTJZddk7GSf83gVzR/QcmvGEkfKCQBYe/yydFQcbqi2meA+dO9gKhJU nnvkoxm1uxcjHWpvJdqAglntMK4Oy2XN417vNRxYqzQJ9Rq27uIBlkGWdPktPYNWANxt EzkK0fOt6jvs63pBkoyKo2gA9KYpF6LWhEsrNEcsQp/I1THPz4hweqnbYb1A9Hdzt/ej XiCjGpEyxmYU7u6zvVYl+gnK7t9pI4i3YWNY5bpZIQFH0f8Zr8UgQIFZNBAUU0v0c3rk 8XZYepJ2WJhy6wMEIjzIy3Ca/QqXI2K+Fq8Z5pv2exn7efCh69i4/L/1r7E9HcHdrOSf bKNQ== 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=xUc6n8nBPIg1c6GDl22kU8jMAC2P7JdhgqjpR4pQIh4=; b=Fct7WhCmvtRJ6/9CyQDn9nFLDUwFDnCNC2XlEnMxpqdrF0dB/m01Q3ppsyByETgmIa nfNqtj3FJfv7TB17zXCUO6I1E5bQSdVoPe1RYzcf7xVABEESVhQ2GVwOkI4y27qG7WG8 XGFABmBtma57RUe5zOpgXRYSFHr4mcSlSNW2YeDbyTeuk9Eby0J/Ba3ehhsupgdW2J/l RdYcguI5WNQKFn6EsRciY5UYKZgOXrelk+tAy3SbXgDF6x+f2tgFD3W/CGt2u3fF5vI0 80iCv5LDssDViBrmP7xGOOhCDYCUgR7bkQsl6UFSu/F1zrrRhzZu1pyA7NJ0cTKS06t0 Zv+g== X-Gm-Message-State: APjAAAWAz51VAPsA87FEn15GPJnePdKDSZ+GdhF1IS/jqbRVCssCDPl1 4QwytCJQj4ntIBN8CN7YNeqRyS1hbHEohMd0Oaw= X-Google-Smtp-Source: APXvYqzOxo9792xYhnRYY6ncJHbGCYDKZrV4zbXQWcuf7Baa4sXvICM7Yg8g7d4cxfxPU8wJC5Tj8oOEGrSs3ZPBh4c= X-Received: by 2002:a2e:8616:: with SMTP id a22mr516066lji.173.1555633038115; Thu, 18 Apr 2019 17:17:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Fri, 19 Apr 2019 09:17:04 +0900 Message-ID: Subject: Re: QUIC logging and tooling : moving towards qlog To: Robin MARX Cc: Christian Huitema , Lucas Pardue , QUIC WG Content-Type: multipart/alternative; boundary="000000000000a3486e0586d70a50" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 00:17:24 -0000 --000000000000a3486e0586d70a50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Robin, Thank you for your responses. I can see that requiring every analysis tool to implement their own frame decoder is counterproductive. It's mirror image of my comment stating that requiring every QUIC stack to implement their own qlog encoders is counterproductive. And as a solution, I think I agree that defining both is a good idea. Thank you for opening issue #11. It would be a win-win situation if all the QUIC / H3 stacks and analysis tools could rely on a common converter that translates the binary frame format to a JSON-based one. 2019=E5=B9=B44=E6=9C=8818=E6=97=A5(=E6=9C=A8) 19:40 Robin MARX : > Hello everyone, > > Thank you for the thoughtful comments. > I think I can answer most of the remarks made with one statement: you can > log whatever you want in whatever format, and then write a transformer in= to > the qlog format. > > A better way to describe qlog is probably "*a common input data format > for tools*" rather than a standard *logging* format. > However, you can certainly use qlog as a basic logging format as well, > which is exactly what quicker and (partially) lsquic are currently doing. > When you need higher performance or don't want to write two serializers i= n > the implementation etc., you can log in other ways and then transform to > qlog for ingestion in the tools. > This is usually relatively trivial and fast, e.g., see the quictrace2qlog > and pcap2qlog converters we've already started (and what Jana is also doi= ng > for quicly iiuc), > As you say, I don't think it's realistic to get every implementation to > agree on how exactly they will log, whether it's a verbose .json or > optimized flatbuffer setup. > > A few more in-depth comments: > > 1) I do not want tools to have to parse the binary wire image themselves > - I envision many tool developers/maintainers will be students, > interns or other non-QUIC experts. Having them write/extend a parser is > possibly not the best idea. > - The binary formats are sometimes quite non-intuitive (e.g., ACK > frame) which can lead to mistakes in interpretation. > - Each tool platform/language (e.g., web, C++, python, ...) would nee= d > its own frame parsing library (for JSON, that's usually readily available= ) > - Parsing the binary in for example web-based tools (which I envision > will be the largest group, as they allow ease of use and sharing), will > lead to performance problems there. > - As Lucas said, ideally the logs would go much further than just the > wire image. I'm more interested in when and how exactly an ACK is > processed, rather than just what came in on the wire. > Taking that into consideration, the logs would contain two > formats, one for binary events, one for all the rest, again adding to > complexity. > > - That being said, the original qlog proposal had the concept of also > logging raw values, and it's certainly possible to re-incorporate that as > an optional extra field (see issue 11 > ). > e.g., you could just log the binary hex-string from the > implementation, and then write a post-processing converter that parses th= e > binary values and transforms them into the expected qlog fields. > > 2) The verbosity is indeed a potential problem, but it's manageable > - As stated at the beginning, for high-performance tracing, you could > only log the select events you want or use a custom format and post-proce= ss > it into qlog for tooling > - Even within the JSON setup, there are many ways to reduce the > file-size and logging overhead (e.g., the technique used by the Netlog > format, also discussable in issue 8 > ) > Logging individual events should not take more overhead than > normal textual logging that is now also done to stdout > - I agree that current (v1) stacks are going beyond basic interop, but > this is meant to be more general purpose and long-term > Think of teaching new people, implementing new features (v2, > other app-layer besides H3), major performance-related refactoring, etc. > For those use cases, a highly optimized format is in my opinion > more of a hindrance than a more verbose format is to congestion control / > performance evaluation > - Just like with normal logging, qlog has the concept of log levels > (e.g., Verbose vs Error-only), but then for categories. e.g., only > debugging HTTP/3 right now, not logging any of the QUIC stuff. > > > Smaller remarks: > - The "class" fields are just because we are using TypeScript semantics (= see > issue 5 ). They do > not mean that you cannot simply drop unknown frames. > In fact, one of the key tenets of qlog is that you can add as many > custom events as you want for easy extensibility. > - Tools would be required to clearly list the types of events they look > for and the data they expect in the log. > You can then see for yourself what it takes to be able to use that > tool and only log (or transform to qlog) that exact info. > > > I hope this helps resolve some of the questions. > The current proposal is the one I feel strikes the best balance between > performance and usability, flexibility and pragmatism. > > Feel free to disagree with my points above and to go more in-depth on the > github issues. > > With best regards, > Robin > > > On Thu, 18 Apr 2019 at 03:19, Christian Huitema > wrote: > >> On 4/17/2019 5:55 PM, Kazuho Oku wrote: >> >> > Though, even if that is the case for HTTP-level logging, I'd still >> > argue that it would be worthwhile to allow QUIC / H3 stacks to log the >> > QUIC or the H3 frames using the wire-format. There's no reason to >> > require each stack to implement the logging format. Allowing the >> > stacks to log using the wire-format would lower the entry bar of the >> > stacks supporting the analysis tools. >> >> I am a bit concerned that the proposed logging formats are rather >> verbose, using text encodings and lots of detailed events. That useful >> when debugging basic interop issues, but we are somewhat past that. As >> QUIC is maturing, I expect to see a much greater emphasis on debugging >> performance issues: software performance of course, but also performance >> of recovery and congestion control. You need good traces to debug the >> recovery and congestion issues, but you lose if turning on tracing slows >> down the system so much that the behavior under traces does not reflect >> normal behavior. And I am concerned that using verbose formats will do >> just that. >> >> -- Christian Huitema >> >> >> > > -- > > Robin Marx > PhD researcher - web performance > Expertise centre for Digital Media > > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > > > --=20 Kazuho Oku --000000000000a3486e0586d70a50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robin,

Thank you for your responses.

<= /div>
I can see that requiring every analysis tool to imple= ment their own frame decoder is counterproductive. It's mirror image of= my comment stating that requiring every QUIC stack to implement their own = qlog encoders is counterproductive.

And as a solution, I think I agree that defining both is a good i= dea. Thank you for opening issue #11.

It would be a win-win situation if all the QUIC / H3 stacks and= analysis tools could rely on a common converter that translates the binary= frame format to a JSON-based one.

2019=E5=B9=B44=E6=9C=8818=E6=97=A5(=E6=9C= =A8) 19:40 Robin MARX <robin.m= arx@uhasselt.be>:
Hello everyone,

Thank you for the thoughtful= comments.=C2=A0
I think I can answer most of the remarks made wi= th one statement: you can log whatever you want in whatever format, and the= n write a transformer into the qlog format.=C2=A0

= A better way to describe qlog is probably "a common input data form= at for tools" rather than a standard logging format.
<= div>However, you can certainly use qlog as a basic logging format as well, = which is exactly what quicker and (partially) lsquic are currently doing.= =C2=A0
When you need higher performance or don't want to writ= e two serializers in the implementation etc., you can log in other ways and= then transform to qlog for ingestion in the tools.
This is usual= ly relatively trivial and fast, e.g., see the quictrace2qlog and pcap2qlog = converters we've already started (and what Jana is also doing for quicl= y iiuc),=C2=A0
As you say, I don't think it's realistic t= o get every implementation to agree on how exactly they will log, whether i= t's a verbose .json or optimized flatbuffer setup.=C2=A0

=
A few more in-depth comments:

1) I do n= ot want tools to have to parse the binary wire image themselves
= =C2=A0 =C2=A0 - I envision many tool developers/maintainers will be student= s, interns or other non-QUIC experts. Having them write/extend a parser is = possibly not the best idea.=C2=A0
=C2=A0 =C2=A0 - The binary form= ats are sometimes quite non-intuitive (e.g., ACK frame) which can lead to m= istakes in interpretation.=C2=A0
=C2=A0 =C2=A0 - Each tool platfo= rm/language (e.g., web, C++, python, ...) would need its own frame parsing = library (for JSON, that's usually readily available)
=C2=A0 = =C2=A0 - Parsing the binary in for example web-based tools (which I envisio= n will be the largest group, as they allow ease of use and sharing), will l= ead to performance problems there.
=C2=A0 =C2=A0 - As Lucas said,= ideally the logs would go much further than just the wire image. I'm m= ore interested in when and how exactly an ACK is processed, rather than jus= t what came in on the wire.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Taking that into consideration, the logs would contain two formats, one= for binary events, one for all the rest, again adding to complexity.
=

=C2=A0 =C2=A0 - That being said, the original qlog prop= osal had the concept of also logging raw values, and it's certainly pos= sible to re-incorporate that as an optional extra field (see issue = 11).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e.g., you could just log the= binary hex-string from the implementation, and then write a post-processin= g converter that parses the binary values and transforms them into the expe= cted qlog fields.

2) The verbosity is indeed a pot= ential problem, but it's manageable
=C2=A0 =C2=A0- As stated = at the beginning, for high-performance tracing, you could only log the sele= ct events you want or use a custom format and post-process it into qlog for= tooling
=C2=A0 =C2=A0- Even within the JSON setup, there are man= y ways to reduce the file-size and logging overhead (e.g., the technique us= ed by the Netlog format, also discussable in issue 8)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Logging individual events should not take more = overhead than normal textual logging that is now also done to stdout
<= div>=C2=A0 =C2=A0- I agree that current (v1) stacks are going beyond basic = interop, but this is meant to be more general purpose and long-term
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Think of teaching new people, impleme= nting new features (v2, other app-layer besides H3), major performance-rela= ted refactoring, etc.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For thos= e use cases, a highly optimized format is in my opinion more of a hindrance= than a more verbose format is to congestion control / performance evaluati= on
=C2=A0 =C2=A0- Just like with normal logging, qlog has the con= cept of log levels (e.g., Verbose vs Error-only), but then for categories. = e.g., only debugging HTTP/3 right now, not logging any of the QUIC stuff.= =C2=A0


Smaller remarks:
-= The "class" fields are just because we are using TypeScript sema= ntics (see issue 5). They do not mean that you cannot simply dro= p unknown frames.=C2=A0
=C2=A0 =C2=A0 =C2=A0In fact, one of the k= ey tenets of qlog is that you can add as many custom events as you want for= easy extensibility.=C2=A0
- Tools would be required to clearly l= ist the types of events they look for and the data they expect in the log.= =C2=A0
=C2=A0 =C2=A0 =C2=A0You can then see for yourself what it = takes to be able to use that tool and only log (or transform to qlog) that = exact info.


I hope this helps resol= ve some of the questions.=C2=A0
The current proposal is the one I= feel strikes the best balance between performance and usability, flexibili= ty and pragmatism.=C2=A0

Feel free to disagree wit= h my points above and to go more in-depth on the github issues.=C2=A0
=

With best regards,
Robin

=

= On Thu, 18 Apr 2019 at 03:19, Christian Huitema <huitema@huitema.net> wrote:
On 4/17/2019 5:55 PM, Kazuho Oku wrote:

> Though, even if that is the case for HTTP-level logging, I'd still=
> argue that it would be worthwhile to allow QUIC / H3 stacks to log the=
> QUIC or the H3 frames using the wire-format. There's no reason to<= br> > require each stack to implement the logging format. Allowing the
> stacks to log using the wire-format would lower the entry bar of the > stacks supporting the analysis tools.

I am a bit concerned that the proposed logging formats are rather
verbose, using text encodings and lots of detailed events. That useful
when debugging basic interop issues, but we are somewhat past that. As
QUIC is maturing, I expect to see a much greater emphasis on debugging
performance issues: software performance of course, but also performance of recovery and congestion control. You need good traces to debug the
recovery and congestion issues, but you lose if turning on tracing slows down the system so much that the behavior under traces does not reflect
normal behavior. And I am concerned that using verbose formats will do
just that.

-- Christian Huitema




--

= T = +32(0)11 26 84 79 - G= SM +32(0)497 72 86 94
Robin=C2=A0Marx
PhD researcher - web pe= rformance
= Expertise centre for Digital Media
=C2=A0
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campu= s Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0EDM-2.05
= =C2=A0
3D"=


--
Kazuho Oku
--000000000000a3486e0586d70a50-- From nobody Fri Apr 19 00:05:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8571202B9 for ; Fri, 19 Apr 2019 00:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[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 x850dBWPwL8F for ; Fri, 19 Apr 2019 00:05:47 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08B11202B7 for ; Fri, 19 Apr 2019 00:05:46 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id q14so7129630itk.0 for ; Fri, 19 Apr 2019 00:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=y/s79NpTWxyPE+o+XqzH1lpu2G9fdHY+NeBfc5hfuTI=; b=AxfZXe6dLW7z78OJeIR522CrrDQKXmzcb2pnpYCWCc96kymJkr0ZfdwPAuSmWFtOLH JaFIrPRrLio0i/2sMTHAHP0v21kLWPq30hX6VNujKCXNoKtq8WcXDO6mc7xTzHot62sB ZtjQbQQAhlMT2MwjUsKfGOBT2J5v2jCjwL2HkjBnSBnqC76nG+oCmZAu1gAYxSLqOn8B C6YQMljFvGSnAMutozox/apm+inBNc6pQ+NK46M2dodqDPak/5+fRimPbIcFSbNDUdNz /rOu+jGi9LjyClk4e00t786QfL4O9QIGu1D/8qzOipXeg0p5iXJlyXsziUObKq9BwM86 +0Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=y/s79NpTWxyPE+o+XqzH1lpu2G9fdHY+NeBfc5hfuTI=; b=rpboL/h+F9t1MICgxzJIjIZRMf6/rSuQLbzLNFlGLKrikSboFi13Tu4S8SVK4uC9+u ra5SyJfkCJS+pL8nOYaoGIjpWlyaviGdxgXvwfbTh10+6Z/X5F1FpYLwgfZzZ8oUuDPc FgtTM8zFAgMBtfGqR/k1q4P/iyfZeOjqk1SVPmCJEjws6nGxsxKk+3E+WSOeW4gsGsXX Vy5vQ7829UZzF2Aryg7jnoZa78D42Ny2p8tf+v/Y5gIeVUjBIBSP8xnrwBHXdZXEcyUt bi4piYAkThdWVKvrmgNWr/wzRXjLn3Zv/baL8GTpSER7LoRJeIlZcN1VOtmtrRARkC2u k6cw== X-Gm-Message-State: APjAAAVdQUGB4vkyXEJ+FP+sKxjlpte3eOWftaHiNmUSkpW0BczUWIoT doBmC+5v8RaqThUC+K99RJs454/ldOzyR4eYlUIqUg== X-Google-Smtp-Source: APXvYqzzjUhzQxOA1x3Uxp+EPLwvYJPu+DamAKLJMlGz9b+32K1QalnbcUEgAxPTILN3ei8QCUlnN5JbPUFT4J/48cY= X-Received: by 2002:a24:7cf:: with SMTP id f198mr1724707itf.148.1555657546000; Fri, 19 Apr 2019 00:05:46 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 19 Apr 2019 00:05:44 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 19 Apr 2019 00:05:44 -0700 Message-ID: Subject: Retry across versions To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000006beceb0586dcbf9a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 07:05:48 -0000 --0000000000006beceb0586dcbf9a Content-Type: text/plain; charset="UTF-8" Do we have anything the relates Retry packets across versions? A Retry can be used to verify a client address, but it can also be used to route traffic to a new server via a change in DCID in the initial packet. Since version aliasing makes it hard for load balancers to direct traffic to a server handling a specific version, Retry might be a solution. However, this only works to the extend that Retry works across versions. Mikkel --0000000000006beceb0586dcbf9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Do we have anything = the relates Retry packets across versions?

A Retry can be used to verify a client address, but = it can also be used to route traffic to a new server via a change in DCID i= n the initial packet.

Since version aliasing makes it hard for load balancers to direct traffic = to a server handling a specific version, Retry might be a solution. However= , this only works to the extend that Retry works across versions.

Mikkel

--0000000000006beceb0586dcbf9a-- From nobody Fri Apr 19 03:29:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A71120130 for ; Fri, 19 Apr 2019 03:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRABdvdItdBT for ; Fri, 19 Apr 2019 03:29:06 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D24A120123 for ; Fri, 19 Apr 2019 03:29:06 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id AFD931B0012D for ; Fri, 19 Apr 2019 11:29:03 +0100 (BST) Message-ID: <5CB9A2EF.5030501@erg.abdn.ac.uk> Date: Fri, 19 Apr 2019 11:29:03 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: quic@ietf.org Subject: Re: Retry across versions References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 10:29:09 -0000 On 19/04/2019, 08:05, Mikkel Fahnøe Jørgensen wrote: > Do we have anything the relates Retry packets across versions? > A Retry can be used to verify a client address, but it can also be > used to route traffic to a new server via a change in DCID in the > initial packet. > > Since version aliasing makes it hard for load balancers to direct > traffic to a server handling a specific version, Retry might be a > solution. However, this only works to the extend that Retry works > across versions. > > Mikkel > Previoulsy, I think we made the reset design specific to QUIC version 1. The more I think about alias of the version number, the more concerned I am. I'm think adds extra semantics to tray and "fix" a potential issue. Gorry From nobody Fri Apr 19 05:23:49 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E4912021B for ; Fri, 19 Apr 2019 05:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5a_K73yTj_T for ; Fri, 19 Apr 2019 05:23:47 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5E812009C for ; Fri, 19 Apr 2019 05:23:47 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id u65so8019431itc.2 for ; Fri, 19 Apr 2019 05:23:47 -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=QrVRca3rH+JBc949ILUSUyk5RLxzwn7QjuAW1R0tq1M=; b=pk7/S8zqzUkv216lTqYLgJcRMlRUWSDSKbHMfdxbyYZLXBqSbhSLQtuNThSJ3WApqr EG1zceaM+HVd8fn2vQWW8P3fbQvRSQJCpEYcMDzv05kOF577wtgA6cbMypIW4moQh03h 5+VQMz2Ibnyw7g0Q6iXqZfuPCR8zy1UuYWAGUw/wGGdDOHyJYladEnOEwgBWUulM8BOV wf9KceNP05LjwLNvjsYSLEHNxPiFPix1Wo/rerCzlkSUz6wRUqmc/ccBqcfNYCvKa7JJ aSEZdRbdAUIEn5tHZZZzosfK77JdNbzT+AfrmEbhjA59j+T4py+dwQ5Jzbwrh3iyOQk/ v70g== 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=QrVRca3rH+JBc949ILUSUyk5RLxzwn7QjuAW1R0tq1M=; b=GbC8qLnC7e6p8fljjFoYQsfjOwl8OTdMbqkuoTbhWNdOWiJDqpS5uKtUQ4A9CjVvYn pPipLXH8nCgWTwANORvUWiUKelW4fC1VhfC3o0mpJG2i8+5UKgRLyFweI5pnZxBUT0KQ cX5Pkld2HfU++oJQfYh4ziY86Hke6NFOELK6ILzC9S4HcXf+YIQWB8tGG3efo7zkbzI/ SRKHZ6TBN1rFI5BM68KxQKhJfhVhtvnE97rhv4CENgYWcX+YLALMRY5DYjMXJnVUx+WH 5b6LaLoLBWDYVb+nW9wAeG9zmo5OLspiDT4Mmy09DBTrf0Qy/n1LPI9ZsLBFE+rnOzwA IOGg== X-Gm-Message-State: APjAAAUGOSKls3uR5myqbiApOMkJ+Tloxy7mqJN0ohv4FTB+PMKzePF3 b/4B9IpQWdutDze5Wsdvk0AJWwalr4NEz+9ifILCSETY X-Google-Smtp-Source: APXvYqynCEpGpPPhRbXIr6On+RzGJrWR0M44RvnaBSHDZHYh370vnopE7Itltbi60MvBNDXK3VabQcHM6ONER3qm/qo= X-Received: by 2002:a02:7829:: with SMTP id p41mr631741jac.120.1555676626447; Fri, 19 Apr 2019 05:23:46 -0700 (PDT) MIME-Version: 1.0 From: May Liu Date: Fri, 19 Apr 2019 20:23:35 +0800 Message-ID: Subject: Discovering an HTTP/3 Endpoint in 302 Redirect To: quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000b473ba0586e1301b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 12:23:49 -0000 --000000000000b473ba0586e1301b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In draft-ietf-quic-http-19, we use response header "Alt-Svc" to discover an HTTP/3 endpoint. In 302 redirect case=EF=BC=8Cwhich header should we use to recognize the ta= rget endpoint support HTTP/3 ? Thanks, May --000000000000b473ba0586e1301b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In=C2=A0draft-ietf-quic-http-19, we use r= esponse header "Alt-Svc" to discover an HTTP/3 endpoint.
In 302 redirect case=EF=BC=8Cwhich header should we use to re= cognize the target endpoint support HTTP/3 ?

Thanks, May
--000000000000b473ba0586e1301b-- From nobody Fri Apr 19 08:10:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDD71202FD for ; Fri, 19 Apr 2019 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 J0PYGAaVdY3X for ; Fri, 19 Apr 2019 08:10:32 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6502C120159 for ; Fri, 19 Apr 2019 08:10:32 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id a15so2804030wrw.3 for ; Fri, 19 Apr 2019 08:10:32 -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=gzTm+LS7KC+YfcYnXIe/BK67QDTUnICc4UXp4htBIUQ=; b=oUe+7LhhpKyTgHFeH4L2FY/YYhwz+DLsvcoMBxhzMlyw+dgptmypFvo+D7McsM4wp6 6XsUHl+UMboktm61vrexjOd4XzSZtliL+SF4JF0AEFgpdq/En5Rtn8mjov2UF7ESHnCY iCTuJSrSBtLDw/x23UMkSh3ov9HaORcHYC0jleDgAmVLqut75nO21011M1b5wbZGAoLx IokzEcGT62Rf03qYH1KLqJrj2zy9CirB7miq26ydgmOi1/25YMS2FOCCYmGzuGnfIt3s kPFgfrYDcuiKdgmz1BfJ+mVKDJEgJPnwlvhsiAe0rTdOE4hIRvTOEzwHUnLTQqy6qCiN o5Qw== 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=gzTm+LS7KC+YfcYnXIe/BK67QDTUnICc4UXp4htBIUQ=; b=ZjHx/Mb7QG94nS6QBLYnPfLzohF+LaG1hBptQIup2rHQxa2mVKRcLepUUQneFQGKCb 6vneQbTRjEsDqqKS23Z4oApdb+G21EgaK0HHx1HAZiHURna8j3ouTYPTyqKWj/OdRu3p uGjAg5uxNfmfWcpNneM88MDrD+vg58eCjFIY06dKA3acMKJRJ6XLe1cfOFiNsJ7n8Dvo 08qSCw+cJmB8qtvPVxhsRP0o4cCDY4kGqeeRf6qlX5qCZHtTEOGu2FaPxQh0aaxZlN6C fZs9I7Vppf/0JB0M81EctKYJe3+nPugO6yfioSiDXFvXBDUJumz0Au1k8GJLRFM2Lr1i Lx8A== X-Gm-Message-State: APjAAAVOPXm1TlfC4QHvT1b/0W1WB0m/ds8hJ4GVbKtKQVaM9fGUkZIy Zy5ELx1Fnh3y2vZWn8McyD4Qlir+BaNqK/19BG3KoA== X-Google-Smtp-Source: APXvYqzVUX9sCwGZsNJd7M9rLvocyd9GZMBthZ0aRzufzb74dKqqE2fAZB84IUTR1z4hWxYUzN9UTzK2BjBZrfjcmpk= X-Received: by 2002:adf:f5c7:: with SMTP id k7mr3215162wrp.197.1555686630571; Fri, 19 Apr 2019 08:10:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Fri, 19 Apr 2019 11:10:18 -0400 Message-ID: Subject: Re: Some notes about WebRTC and QUIC To: Ingemar Johansson S Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000ffbf040586e384ed" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 15:10:35 -0000 --000000000000ffbf040586e384ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Roberto, I was thinking per-connection ACK policies. Thanks Ingemar, that's great information. On Thu, Apr 18, 2019 at 3:18 AM Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > > > And thanks for sharing the meeting notes. I believe that there are > benefits with WebRTC over QUIC, especially the possibility to run a unifi= ed > congestion control has some merit given simulation studies that I have ru= n. > > > > For what it=E2=80=99s worth.. During the development of SCReAM ( > https://tools.ietf.org/html/rfc8298 ) I have collected some experience in > how SCReAM works and what it requires in terms of feedback for optimal > function. SCReAM is congestion control for RTP media, SCReAM has built in > support for prioritization between media streams. The observant reader ma= y > make the observation that SCReAM resembles LEDBAT quite a lot and that is > quite true, SCReAM however also adds the interaction with the media coder= s, > stream queues and ECN/L4S support. Mixing small and large packets (voice, > video) does not seem to be a problem in simulations, but sofar SCReAM has > only been used for the transmission of video at bitrates ranging from > ~200kbps to 50+Mbps. > > I don=E2=80=99t believe that it is possible to take SCReAM and put it as = is into a > WebRTC over QUIC solution but perhaps some ideas can be stolen. > > > > > > A few observations: > > > > Timestamps : A receive timestamp for each packet is not needed for the > function of SCReAM. It is sufficient with a receive timestamp of the last > received RTP packet. The current implementation ( > https://github.com/EricssonResearch/scream) implements > https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-02 whi= ch > reports timestamps per packet, the issue is that it increases the feedbac= k > size quite a lot. An earlier version of the SCReAM code generated feedbac= k > packets that were just 48bytes, the size with the new format is 128 bytes > or even more. > It's very nice to only need a receive timestamp from the last received RTP pacekt. Currently, GoogCC is designed to require one timestamp for every RTP packet, which as you said greatly increases the size. > > > ACK rates: A low bitrates it is possible with feedback as seldom as every > 50-100ms, at higher bitrate more frequent feedback is required. For > instance, at 50Mbps or beyond, feedback is transmitted roughly every 2ms. > > > > Stream scheduling and prioritization: SCReAM implements an RTP queue per > media stream, something that is best referred to as a credit based > scheduler picks RTP packets from the queues in a priority fashion ( > https://tools.ietf.org/html/rfc8298#page-24). This approach seems to work > well according to tests we have done. The RTP queues are mostly empty but > serves as shock absorbers for instance when link throughput drops quickly= . > > > > Regards > > Ingemar > > > > > > > > > > > > *From:* Ian Swett > *Sent:* den 17 april 2019 17:42 > *To:* IETF QUIC WG > *Subject:* Some notes about WebRTC and QUIC > > > > When in Prague, I organized a small WebRTC over QUIC lunch to discuss wha= t > it might look like and what the goals are. > > > > Attached are some notes from the conversation. > > > > Thanks, Ian > > > --000000000000ffbf040586e384ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roberto, I was thinking per-connection ACK policies.<= /div>


Thanks Inge= mar, that's great information.

On Thu, Apr 18, 2019 at 3:18 AM Ingemar J= ohansson S <ingemar.= s.johansson@ericsson.com> wrote:

Hi<= /p>

=C2=A0

And thanks for sharing the meeting notes. I= believe that there are benefits with WebRTC over QUIC, especially the poss= ibility to run a unified congestion control has some merit given simulation= studies that I have run.

<= span lang=3D"EN-US">=C2=A0

<= span lang=3D"EN-US">For what it=E2=80=99s worth.. During the development of= SCReAM (= https://tools.ietf.org/html/rfc8298 ) I have collected some experience = in how SCReAM works and what it requires in terms of feedback for optimal f= unction. SCReAM is congestion control for RTP media, SCReAM has built in su= pport for prioritization between media streams. The observant reader may ma= ke the observation that SCReAM resembles LEDBAT quite a lot and that is qui= te true, SCReAM however also adds the interaction with the media coders, st= ream queues and ECN/L4S support. Mixing small and large packets (voice, vid= eo) does not seem to be a problem in simulations, but sofar SCReAM has only= been used for the transmission of video at bitrates ranging from ~200kbps = to 50+Mbps.

I don=E2=80=99t believe that it is possible to take SCReAM and put it = as is into a WebRTC over QUIC solution but perhaps some ideas can be stolen= .

=C2=A0

=C2=A0

A few= observations:

=C2=A0

Timestamps : A receive timestamp for each packet is not needed for = the function of SCReAM. It is sufficient with a receive timestamp of the la= st received RTP packet.=C2=A0 The current implementation (https://github.com/EricssonResearch/scream) implements https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-02 which reports timestamps per packet, the issue= is that it increases the feedback size quite a lot. An earlier version of = the SCReAM code generated feedback packets that were just 48bytes, the size= with the new format is 128 bytes or even more.


It's very nice to only need a receive times= tamp from the last received RTP pacekt.=C2=A0 Currently, GoogCC is designed= to require one timestamp for every RTP packet, which as you said greatly i= ncreases the size.
=C2=A0

=C2=A0

ACK rates: A low bitrat= es it is possible with feedback as seldom as every 50-100ms, at higher bitr= ate more frequent feedback is required. For instance, at 50Mbps or beyond, = feedback is transmitted roughly every 2ms.

=C2=A0

Stream scheduling and prioritization: S= CReAM implements an RTP queue per media stream, something that is best refe= rred to as a credit based scheduler picks RTP packets from the queues in a = priority fashion (https://tools.ietf.org/html/rf= c8298#page-24). This approach seems to work= well according to tests we have done. The RTP queues are mostly empty but = serves as shock absorbers for instance when link throughput drops quickly.<= u>

= =C2=A0

Regards=

Ingema= r

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Ian Swett &= lt;ianswett@google= .com>
Sent: den 17 april 2019 17:42
To: IETF QU= IC WG <quic@ietf.org<= /a>>
Subject: Some notes about WebRTC and QUIC

=C2=A0

--000000000000ffbf040586e384ed-- From nobody Fri Apr 19 11:33:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B44120320 for ; Fri, 19 Apr 2019 11:33:05 -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 haVCysN4t8zH for ; Fri, 19 Apr 2019 11:33:02 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4AF120110 for ; Fri, 19 Apr 2019 11:33:02 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id c1so7031209wml.4 for ; Fri, 19 Apr 2019 11:33:02 -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=74eOXip1SCuM8avfSpipWpmmISUoEUadBs1OR0ABdMI=; b=hgfjjaSCRCLYFUQxFAaNDTqWa5Fin4v0yDI8cxV5S2vK1mrToBZCPQ+tw4eQFa2hDc YFzifZmNFztmJj1DDcqUoS3vfasKC75Ov0dwIgcb4tmepKv8fFd5VS38MQvCwBLD3wgl kZSbeoTaAPJ2kwMZhKJAUwRQgn8qvhzE0YKbbuPnL7VvrewyUlpqVZDNJo/Vm0Jjnvpt K4XAuZ6ZbbACL2ovtahAj+Mlg/0VIuGjLzwe5fJExXETENxsbKCMgj7PmD+IPRHFs6ES UzyVwjqoU681NsAuUpM23ohN0PUVF6hHqHp+ZBUx/JoGfpzG2GZyRCAuuxDuQgbtaqLa 2eWA== 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=74eOXip1SCuM8avfSpipWpmmISUoEUadBs1OR0ABdMI=; b=d+2cC/E3KWlB3ZAlwN+dkYQikLV5zKjxmEiQn1rnYYpfJHFVzlbRg030ij9STrcqQF FLw8j6EzR8VvTv/eMUNL02EX1aa38uFpgGsG8Ha63LMm32XDbtH0mrnh8QQm/eLz8o/Z Dwdz8zpSd6Uz3L9V9mlY0v7EHED+ubaCpAsHGhLoUfvCu8XQ2mybj7uyJzDGAgNw/Oma TTAlun+vHwh1ZEIl3zlhebNUw8P4ccxRKmKYIGr/1q13Cgbhxqcmgmq6S/4jlEgJNPXx p6hYRfBmjcupTsYs6Boe6zotLLgEELIQ+F7shZ6TomzgEVBDhcP+8756pyOpBkEbmJe0 Mtag== X-Gm-Message-State: APjAAAU1IDTuywKLsiVrkEGak3FGIkVD8BypAhUraHaNDTZAKCJ+B+xi VJZTJn6/zhWo8H+xfUD5ncrpzcR88hbQoJFTmi0= X-Google-Smtp-Source: APXvYqycC2quFZpG/WoyVgjr1bf7ihaiFlZEjbnK+yHfa4DUsIL1h84uP2KBbM/69xcpQSSPFTxxIPh89VydbBxfVnA= X-Received: by 2002:a1c:ac07:: with SMTP id v7mr3355230wme.49.1555698781033; Fri, 19 Apr 2019 11:33:01 -0700 (PDT) MIME-Version: 1.0 References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> In-Reply-To: From: Martin Duke Date: Fri, 19 Apr 2019 11:32:48 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: "Brian Trammell (IETF)" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Gorry Fairhurst , "quic@ietf.org" , "Border, John" , Roberto Peon , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="000000000000389b3e0586e65978" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 18:33:05 -0000 --000000000000389b3e0586e65978 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2019 at 4:15 AM Brian Trammell (IETF) wrote: > > > > On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > > > > Will it help to be is opaque as possible, or not? Some of the scenarios > I posted earlier show that no matter what you do, something will get in t= he > way. > > This all comes down to the threat model, and the model of incentives for > on-path devices. > > I personally think the correct design target is to put trivial > QUIC-discriminability into the wire image, since there will be a lot of > pressure to distinguish QUIC from not-QUIC traffic regardless of what we > do, and if we don't put grippy bits in the wire image, the distinguishing > functions will grip on to the slippy bits, with difficult to predict > outcomes. I recognize I am in the minority (of people who speak up) on th= is > issue, though. > > Cheers, > > Brian > > Can Brian (or anyone else) comment on what the threat model was that caused middleboxes to drop TLS 1.3 when it used the actual version field? It seems especially perverse for non-surveillance devices to drop future versions that are, almost by definition, more secure. At this moment, my strong support for greasing is driven my fear of this behavior that seems nonsensical to me. --000000000000389b3e0586e65978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000002278c9058720c152-- From nobody Tue Apr 23 00:09:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C830B120091 for ; Tue, 23 Apr 2019 00:09: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, 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=TkrbDxLI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uSuUTg+F Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIJOrbLLymf1 for ; Tue, 23 Apr 2019 00:09:19 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C9412006D for ; Tue, 23 Apr 2019 00:09:19 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C23292440A; Tue, 23 Apr 2019 03:09:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:09:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=u WorLSc4NqPv3C12Uy/eaK6k38MiSd9ZGFrsQT00SM4=; b=TkrbDxLIE55xBgqkH nXSlNrufueL6xjEnl4cab27a8OkhMyFL4Vbk+YuRmHRgX6pqjZDiXeSl2/9kXo/e m2j1p4Hha9bCMObZpyxYlnCF4dkWl6uQaotZgQ4cwZhWQXiCOfPAXeG6IQtlOWh/ CTKWkORjqajCzhHs9/kF/tMzNFc45EtONhfsVZpMPMWkmNwUjHzJyb9aqJwuAOf5 6y0OZxZ6F/jx5hicUIjnYNZv4yrcUHFXPbfdKcMhlcskr6pd9cp/pbXYSQZGt4NL +nVmMzJSkwMj0+fKpMXn1mcGmWXu3shIAYG3S1keFfQ8w+pomxS7LuD7cAY9d3Gs 40Q6A== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=uWorLSc4NqPv3C12Uy/eaK6k38MiSd9ZGFrsQT00S M4=; b=uSuUTg+F59Ki9ga7TM/EmX7KQRa5toBAfUOkqvc0C9avipzcSajUWhpCW R4bxTuTNGzrV+HzLq9i+qBlv4oripjIE7uadNmjzDCKu4dAf5F98SLt/kkqhvHYD iF6EmmZ+/Uw0J7xAAktwSgO9KpcxWuF7NsdNtcnuhhkcsWLnwLU8qWuP88YutxH/ 6JvR/5k9ame3t4/So/H/ijOutjiQmkd7jE5SIFQdDrPkMil0jGFEbevW+acYMjkY BrDwTigqfuprh5MZRayudBr8YPMdPIqMFSatW0T4JlucxpsDkqwkk28stevtuY9l ioD/hvDpeaPxQiW0zc8+JrGcir+kQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 5F207103CB; Tue, 23 Apr 2019 03:09:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Consensus Call: Remember Fewer Transport Parameters for 0-RTT #2464 From: Mark Nottingham In-Reply-To: Date: Tue, 23 Apr 2019 17:09:12 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: <62ACEC8C-B8C9-494F-B4A4-B0CE22F1D026@mnot.net> To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:09:22 -0000 Hearing no pushback, consensus is declared. > On 16 Apr 2019, at 5:58 pm, Dirkjan Ochtman = wrote: >=20 > The issue link is wrong here, should be: >=20 > https://github.com/quicwg/base-drafts/issues/2464 >=20 >=20 > On Tue, Apr 16, 2019, 09:47 Mark Nottingham wrote: > Regarding: > >=20 > The editors believe that this PR resolved the issue: > >=20 > ....... and discussion so far seems to support consensus to do so. If = you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:10:13 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0FF120227 for ; Tue, 23 Apr 2019 00:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=dSHxZ0lA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gCAycBdm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyfeZ8tLX371 for ; Tue, 23 Apr 2019 00:10:10 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1500120091 for ; Tue, 23 Apr 2019 00:10:09 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C87FA28596; Tue, 23 Apr 2019 03:10:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:10:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=U a1ngD/UzFVPFCByaaHLsDK4KhiPkN5RvxhWpZxA/Dk=; b=dSHxZ0lAsopZBH2+M QgAvUQpkDIy2KwexxvYfOf+8KAREGiUt2NSuun+bEDWiXoSXLhMYgkAx91vbrSgy dAvIi8lvkZ1D5qRh22hgoFEA8/QtLuFxB0D4ASWKPqJAj1MqxTXSNeUXD9/BNwR7 Uzd6esKHNX1E0fDIvMwHjnBq3K4nQgWsIP5EvB1H4JZ2SddVWx/tYVEuizdO7E2b C570hZfRqzQJYM9zICNP3hAXG6SAY1SwmFxMWd3sYwvnWFZv3kfURLzv7xPAZvb1 /rsuONJGu+zQTACm3sgP7fIN7oWCr9HkkXI8LTG7J+3pILEFHFdJypSMSO8z+afN BZsiw== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Ua1ngD/UzFVPFCByaaHLsDK4KhiPkN5RvxhWpZxA/ Dk=; b=gCAycBdmsPofq/DCmevBNH0pBvAL1TaJCC+aOenVT5/IgSLmFRwXo1xn5 /qsBBAGOm0va9sFgkdOh8NwEmtKolMhi8Grt4RJ9EV2nA/jnkfUCqDFdOFDM0TDV fkoPrHS+uuf44LxSSSxdvtBCpCgLlEVewYoDsO5RviP/YiDp8gXL9BCW7911/WB2 sOqTgqLvbiD+pvhqqJhi7nh38SVvLH7EU7M0UqVvhy05VpzCTDR00219UHAgAjwb NtvOiEGK9XIOF4sSp4VcoxVhEMR9Cp/vSCqiXQqYwWAt/8KVFSs5BU7yZGy4XH/X 9uwsVKv/Ewc3Ertiu1iYRRziREm7w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 71DDA103CB; Tue, 23 Apr 2019 03:10:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Consensus Call: rate-limiting of CID issuance needs to be allowed #2436 From: Mark Nottingham In-Reply-To: <1F1C9731-8860-4ADF-8258-C0F65A973D0D@mnot.net> Date: Tue, 23 Apr 2019 17:10:06 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <8D8D327E-4290-48B5-B5BF-11811DC9BCB8@mnot.net> References: <1F1C9731-8860-4ADF-8258-C0F65A973D0D@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:10:12 -0000 Hearing no pushback, consensus is declared. > On 16 Apr 2019, at 5:47 pm, Mark Nottingham wrote: >=20 > Regarding: > >=20 > The editors believe that this PR resolved the issue: > >=20 > ...... and discussion so far seems to support consensus to do so. If = you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:10:45 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F34120091 for ; Tue, 23 Apr 2019 00:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=hnUtmH3/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h/DKW8eC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_BngtfAVwq0 for ; Tue, 23 Apr 2019 00:10:42 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B51512023C for ; Tue, 23 Apr 2019 00:10:38 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3D16525D24; Tue, 23 Apr 2019 03:10:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:10:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=T gK32nXQG6UIfwsCCHG9NPWyjdFprelyYKPg8X3pQZ8=; b=hnUtmH3/9QQIW+e4a twaTx8hh+5kBDs0M46pkMy7OGKuQzNa+XOVvMwZxBE12b8UE4G2p9xzGc1uaFj/w cQUo8dRSmtJf9H2nuN2to9ihk1myuoly6K/9c3SmRPH0kjiMoqLGXLMZaFIOthsz /MLM2auCQZ3fcKd1+4Bginy/pC/cGCbQRVTe20mgAmBKLJPetqrOfs4wgorz8RGL iZRpl7/N1btwEkqWb2p0qAyFOKLpKGDDYSjd5WR31ssJQFfzoJwfRBexhC+bgKLE Tx4wirboOMn3A0eyGAMLwrqrzZnzizhrATO1Xt9d7p/dUE569EYVGPpWEYOv575s Dkj7Q== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=TgK32nXQG6UIfwsCCHG9NPWyjdFprelyYKPg8X3pQ Z8=; b=h/DKW8eCLp66Bb4i3xdErg4fihumsADfLonJ0RODPF72Wwf2mny050Zet p/67BACxFhdvmwqIPH+1Ov/Tt6W+eLiHXeYZe0uSRCqJ67BRizVqDQudF5IfcBEa nZrPZmOeOgeS0ZvA+65yER78s6CgO9pJNkC1eNO+bzVJVKZfklt4GkF3kOWwXI/j gibilIxTVCfyHyVH6j6QzgCZyzjwb1QGuktbEOgXWx0UBMEpgGIF6tAaPa6kj0FK ZSKaNSie5edVz1WTSZeZWynIeuCzzJIJNHMui4f46GKOY8ISsvD9GAUHr+CrTQYg qK8Wikp0vVcgkkksPnxAyLcG6ujGw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id D689F103CF; Tue, 23 Apr 2019 03:10:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Consensus Call: Are transport parameters mandatory? #2528 From: Mark Nottingham In-Reply-To: Date: Tue, 23 Apr 2019 17:10:35 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:10:45 -0000 Hearing no pushback, consensus is declared. > On 16 Apr 2019, at 5:47 pm, Mark Nottingham wrote: >=20 > Regarding: > >=20 > The editors believe that this PR resolved the issue: > >=20 > ...... and discussion so far seems to support consensus to do so. If = you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:11:11 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CC112023E for ; Tue, 23 Apr 2019 00:11: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, 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=VHm14sq1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tpiqv0Pj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POd4XuR9AWn4 for ; Tue, 23 Apr 2019 00:11:08 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501B1120241 for ; Tue, 23 Apr 2019 00:11:05 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 377C325E5B; Tue, 23 Apr 2019 03:11:04 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:11:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=G 5p4i+BH58zFAIcA9u+SMY3KJ6VfI1Y5y8ErKEl3uLU=; b=VHm14sq1KqgkOunma vo1Amv6ilbrdp6aHyiEsg3y+l/1MD2SRvR6Vsc8tPB9DCgAzc1Hz3Ij/fdF0YQh8 DapkwPDO3ABKKvOoD9r6Lt+VI9Ta7hcYgegPPE1bFhWC7m5LQPkbcrFVan9w467v 4H5mvr2FTI+32kf1vT058V7Cm14vtPBZY5kdZE9y91Ujmis7BlwiCsKJ22TqiCLA mC3CYJENGw0kyZixTYR0Bri1Ve2z9/o/vDhQiD+4BsjQP42WRdisJ7aNabl8F5ug /wsFnAqh1b6rCqccEbnYu57iJUTVcOGfs+nEJL7fuKL1qeVq+AvfyeDW9ZwCuy2u 3yPRQ== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=G5p4i+BH58zFAIcA9u+SMY3KJ6VfI1Y5y8ErKEl3u LU=; b=tpiqv0Pjd6+DKTGvKmnbKATILOecu7CUAAOBf6Jm2hSyj0zOci+tTPTSl dXuMVABmW49gaDNppIk+8ioMkGDsRzFpIgPMl4qJnym09SbjvIkUjVVh4g6ssdW/ Jm80NGLhUI+/JSOxg5A9fSLQSL7QHBc77+w+teD84vX1ztuR+lvksNk6sQlJouBj 5aappAgvrjo+dbIXhN91RCRVpVMClUaPIDZgkgecINthq3QqGvSGT5dDZHoRY8mw 1q0oRFepLsGzXSB0JTYYlP31igfXZBduOjmNFEd0X0xV+vRKc2tHTOm10NPu1LpJ iBMHtppp2kFuuEMjAXMqBexihNDpg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgepud X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id D978E10319; Tue, 23 Apr 2019 03:11:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Consensus Call: VN packets may be dropped more often when the QUIC bit is 0 #2400 From: Mark Nottingham In-Reply-To: <96D1B775-F34B-442A-BE49-C8F811891641@mnot.net> Date: Tue, 23 Apr 2019 17:11:02 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <64C69A8B-CEF7-40C5-A382-EA7D697584B5@mnot.net> References: <96D1B775-F34B-442A-BE49-C8F811891641@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:11:10 -0000 Hearing no pushback, consensus is declared. > On 16 Apr 2019, at 5:47 pm, Mark Nottingham wrote: >=20 > Regarding: > >=20 > The editors believe that this PR resolved the issue: > >=20 > ...... and discussion so far seems to support consensus to do so. If = you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:11:42 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7712712023E for ; Tue, 23 Apr 2019 00:11:40 -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=cDPMpFq6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=znaalyOa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdQqh0vT_9sc for ; Tue, 23 Apr 2019 00:11:38 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1777120091 for ; Tue, 23 Apr 2019 00:11:38 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7D0BD20D12; Tue, 23 Apr 2019 03:11:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:11:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=n oC/yvVCqKeILozsmKORkkchuY1X948J7m0lO5YLrfE=; b=cDPMpFq6RCGCshA0x nZ6990EWRhUxmbUXQ8lYFEbwXCvO5Eqcgx5zkhv2QILUz7qBUkAQAHAwLlY1sJlx cWRVHsoNE5TL1TCqAQeXSr6nY1D0fiSpTQbxGIt7Y2DwfKWqxZN0ZMvt6mukW73e eeB1/1wKPsktQKvO/91orxMu7G4F6CGgRS/p6RymL2TQw11yckwc8krv7Q+BFqGb 4HcFJshzR0VgCvRvy9kzpgY4j14cD0AHYRf3lrRUY7ozXDAwObkS/L+yp1U5rZi4 Rgs70ML4W43CAGeH2bPG8upu5VF9X2Mznlywm9cm3dVaL9s7we5AK9iih1WIhaWo 8nqYg== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=noC/yvVCqKeILozsmKORkkchuY1X948J7m0lO5YLr fE=; b=znaalyOaWSTzG87fTmea01SdtGdldZkHKkOE5AiJhEjbPdwGaQnoQ+epH WXd7OZcIOno/JrIHWzw7JNddl5YHwdcZdXM6B4IO1IRqXwcw90REbk/5R1MBLhT9 uEN+jAzwUZ2sKmBZFqPOhoOrh9HG7aTJNB/FzdM/ZRwwLhX4xfMkj1bnxyGf6x9m rkjmVqIrTkhSEDSxDB796bmWGKONDKGvFSURnMyzNDhv/sYJqYFDLX+V7KXozHUE nfhc+lJOmJgB4Dlp/fxOUFIO2UwgkNuRkBQaSREw7xFCuLrPfOiP97K1odh0Ut+k DePPfzLY6zbc3gOZXYRrDyEsmdNPw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgepvd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 01583103CC; Tue, 23 Apr 2019 03:11:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Consensus Call: Remove size optimization for Initial packets #2522 From: Mark Nottingham In-Reply-To: <5DC2E80E-0E67-47B3-9C71-3A8CF8DD46FB@mnot.net> Date: Tue, 23 Apr 2019 17:11:35 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <9CFC6CCF-1122-4A1A-BC87-66D5AFA90685@mnot.net> References: <5DC2E80E-0E67-47B3-9C71-3A8CF8DD46FB@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:11:41 -0000 Hearing no pushback, consensus is declared. > On 16 Apr 2019, at 5:47 pm, Mark Nottingham wrote: >=20 > Regarding: > >=20 > The editors believe that this PR resolved the issue: > >=20 > ...... and discussion so far seems to support consensus to do so. If = you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:28:53 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BC012023C for ; Tue, 23 Apr 2019 00:28: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=Opy4R4EJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NWNBFT98 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHbDq2smtpyo for ; Tue, 23 Apr 2019 00:28:50 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EEA812008C for ; Tue, 23 Apr 2019 00:28:50 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7840222F10; Tue, 23 Apr 2019 03:28:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:28:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=q1GjTKZC5wtOsUSQqxN1iTdxu+jS8Z tsdjtt/26qLt8=; b=Opy4R4EJ1Gs80XHapz8pd1+RHDx/Qycx9Q4sbK+8ianYy1 WwmhermsOlW0lnStLNI0Q5GbOs6lidmuEmipV6DBuJuhaR3Ef77SAZBAT2L6FVj9 zclEp25flMqF7wQgHzoNJ20/OtQ1wMhg1Ko5Mqhi32B9brUFE0tdpC4EvRE+Hu54 qJniMLS43Ymv1WMiQ6cEeoj5chirJkvMK2qu/QxYZLGAuJADC1XfGZ6h7A3Oe25c muyR8pkU2CFnOWVgjhKnwaGx2o7oK1eKzCrIiiF/Frb5UVCLwWXrbDQ/QM7Y3OrI CmOipBNLkzEonC1xnqtdJ7xc6xXu12F7rgd3gEGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=q1GjTK ZC5wtOsUSQqxN1iTdxu+jS8Ztsdjtt/26qLt8=; b=NWNBFT98dSk1OMht7uaAWt /Y2Dkl5i0RyUgnm2LtifNxWuptBVm+Q43JYtzeP7gQzI0WaZasdXoDRDL2nsYNmU ddGpfTm+D5wl7HjS18XwQDgoCSKsjQzfhKHx9dSihHRUDzcXs/eaVOQYAYUkztdw KsH40M7gl201CeyMOtIdxkJXv2g0Nj/qujhcLMNMZFd2ITf0eRE5tDuaw45aDMqv 9nIXZZywqAIYaTrDvBgEfrnbxUYX4VJslwNfq5TtmiB6jIM2Jc4bhkJLO2tGh98i U7lFg8MpflIGvxFy4g/YfVrzChN0XBsHBnw5urLYN7U93TFryG6oIL29KBdpmimA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 57E96103CA; Tue, 23 Apr 2019 03:28:47 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Consensus Call: Message-Id: Date: Tue, 23 Apr 2019 17:28:45 +1000 Cc: Lars Eggert To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:28:52 -0000 Regarding: The editors believe that this PR resolved the issue: ...... and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:29:03 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAB112008C for ; Tue, 23 Apr 2019 00:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=td0BnbSM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FuADJJuO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJNYzQhC-nnM for ; Tue, 23 Apr 2019 00:28:51 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB89120091 for ; Tue, 23 Apr 2019 00:28:51 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3D2A422245; Tue, 23 Apr 2019 03:28:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:28:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=vtybRtJ866Gh+OVs5QsFf/rZLkQmeL hCqF9B76tB2H4=; b=td0BnbSMHt6tvKhDD37mIvH1V++add8gRNYN+hRHKjfHiq tAJKB+ixU8uiWP+w8pOexOuCSwvDxSKT3iB6lViWkMvwtEqWIH5KjXflG4Xv5YaQ KlIEGrO9bbVAk6yLwwQ0UOIfs0i4J5g+xPVL2YX8r370G/SRIFGtrlRC5RSWlxR7 JD6rakWVen8LgJn5yebZapmtScaklqfz3PNE3ECgPyEuV73WHcUBrA7iKYLRD1nY Mb7LKwITLPOtC5I01YubyRk6zWAg7zm1cknv5X88rld0dLu2bP0eUnQaYfuznJkG PHuvJpvjv0OsUUGvdlcrUQso1pP5C3kAoUM5QP8g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=vtybRt J866Gh+OVs5QsFf/rZLkQmeLhCqF9B76tB2H4=; b=FuADJJuOD26mim6N7eNu+8 Wwgm1r0dajjIdtK+dIqk/BHtP1ISMKwLiHdowmmMMtwnk1akfnJC6KQl/tZBRKGk 95jBr8MVEUV8/QDFPrMRf5GfhEn85o+curC36LFxdM+NEmddDnHZaF7FvT0B1doW 0KZoSykYTkXAJ9Zk+UCsaWDjwVuFKiTc1oZCI3fp4nHF0cFkBolnn7hVg9bVoAEQ NmPi5CbztKjnod+26PX3LSWGc8ed2vVNnH28cKws/mrUkBdHhz3l363g7l50yCo0 JbYR5O3ZgJSFv3ch/DdqoXq67pH6LURWPJzLDj1m7pqtJuEay+9S2cgP3wEChKKw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id DACDC103CF; Tue, 23 Apr 2019 03:28:48 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Consensus Call: Message-Id: <432F5703-9C52-4153-ACED-11578D503F5E@mnot.net> Date: Tue, 23 Apr 2019 17:28:47 +1000 Cc: Lars Eggert To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:28:53 -0000 Regarding: The editors believe that this PR resolved the issue: ...... and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:30:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4585C12023C for ; Tue, 23 Apr 2019 00:30:17 -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=hWqTPSFD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HUC7VdKk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrCGpzmrhWtN for ; Tue, 23 Apr 2019 00:30:15 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F5C120091 for ; Tue, 23 Apr 2019 00:30:15 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CE095248C1; Tue, 23 Apr 2019 03:30:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:30:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=T OOzSHUlXM5YRhV9VC7BnXDu2a/ssbj0U9YLW6n//qQ=; b=hWqTPSFDpW5lh5W45 QT45tP57CcaSzBYf08kQOlZPoeqsbIBizY0mNlR05oYHI8KocqWOereuAaRFiS0V ebJX5gIEySAHkueKfMOYallJmVWNtBVwCHnYZeaG8oT7P8zB7XuiqYrxpi2ccSFX 9zgEouXH/fzrsgxyg8WilzKj94FCfdzZJ1IJ9Ge3O2QPTUX4ZZR+AvnOYMzR12ck jEjqM9BQENfFfv5ijHAmZkXWysPG8JGvuw48wIlZZ/q2vfjrslnLNtg4WRzRs42h tU5F+Cx+Q9+rWBdPvwKXABEDrlT9qJaxbi500g5GEG0JiuLDg6GrR+nXjAp9uEoT XL4+A== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=TOOzSHUlXM5YRhV9VC7BnXDu2a/ssbj0U9YLW6n// qQ=; b=HUC7VdKkciifw1beF1uznGL86wDtvP6lrO1rlmrao+52trvTMjFIxe1+P sUWquhpaDZj00MD1uHhWkHNhBjtcUF/YerlPQR/lqSwnQR86ZKTWXqBXPL5TD7SE igevZBb96ZV6a+uF7DLtUD75cX3XWJU1phTJenBtl4VRThdMR9WE2NmKbpLiEzTi 3IWK2v71070jhcCq8MrBxOKVWuQJMRjHte7RqgxBVPj5DIcWFvgHR6WwywXRYfmY BRu++Wo/1MJnn8fvrClM0/qqHwxELHiYO6XGbtieICRscYlGjpXukSC1d8nIktkJ MjCd9rX1gdQasqqr0r+s7y8n9D/Mw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 53ADD103CC; Tue, 23 Apr 2019 03:30:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Consensus Call: Use short headers for stateless reset #2599 From: Mark Nottingham In-Reply-To: <432F5703-9C52-4153-ACED-11578D503F5E@mnot.net> Date: Tue, 23 Apr 2019 17:30:12 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <876F0C09-4A34-4489-B1DB-5FF365E4B6C3@mnot.net> References: <432F5703-9C52-4153-ACED-11578D503F5E@mnot.net> To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:30:18 -0000 ... and now with a title. > On 23 Apr 2019, at 5:28 pm, Mark Nottingham wrote: >=20 > Regarding: > >=20 > The editors believe that this PR resolved the issue: > >=20 > ....... and discussion so far seems to support consensus to do so. If = you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:38:35 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5B112020A for ; Tue, 23 Apr 2019 00:38:33 -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=kYMEZ2XQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dBhsD8gA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwvph7kORN1I for ; Tue, 23 Apr 2019 00:38:32 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CEB8120091 for ; Tue, 23 Apr 2019 00:38:32 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AB7672654B; Tue, 23 Apr 2019 03:29:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:29:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=x mI+YJyfDOI3dJOIRzDVaeGYiv/MgMdhCuXd6IDWnNs=; b=kYMEZ2XQ87uQGMdnL +2m85a7OovS6+/81Qa8H//fpjTVwz+0Bja51hUciMB2/dYruIJ6pAajSOQsu2VpG 7VffPBMvnq0UN3QD0OgIn8/7IMrjZwHOI76isUhXdI6mLxOSGhAWxRkVR9/1jF1O KeEjVHtMM2mbNTXUzuBdXaGjFdZ6CLbqAQSgPh21lQpSAxPTXg7Z5YDjxLjJDXkA ANEtMYFvfsuPDDk4xv7kdk/CTrW43arc0GydZ1/aJIqncOweXDO83n1Z7CLf1nET g6Du3qFKRUIZpT0BtiqERj1k1GA/Tq97K+roNCH9+TJHCa2ZHjr+IEM3BJciq1EU q21Pw== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=xmI+YJyfDOI3dJOIRzDVaeGYiv/MgMdhCuXd6IDWn Ns=; b=dBhsD8gAcHTTCsZUh6bUdRZqnHcjt9iapREqka4R29bcD2GGITixPcB9G pxEhpFSDd8ue0/SH5jwfk2p3GNr+L6h9RDEmHIBHPXzhEfcss5wdAMca8BvHP1fb fEJU+GoCXMWz39Burxd17bo2u27b9N61Hn3+rqVbBUUzK2dQv7EA+7uvhOg+RpxS JX8LPnszciT57DoAsmcbRmM8ysZBV5IbjMvN/jRsIumV6CNyphBkVtjdSrFDMdfw T44pJdCiUqbbz7wN7i8hkXChobUBKD9iAuLcNBWGOpm0Yd6KJDfJNRsd4eWCQ1Q6 GNTo2EizCTcc3iB54OFbchRCy8lqg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 2ED8F10319; Tue, 23 Apr 2019 03:29:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Consensus Call: Flow control for post-handshake CRYPTO messages #1834 From: Mark Nottingham In-Reply-To: Date: Tue, 23 Apr 2019 17:29:40 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <71AC126A-FA71-4356-9B11-C0963AC5437A@mnot.net> References: To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:38:33 -0000 Bah, sorry; forgot the title. > On 23 Apr 2019, at 5:28 pm, Mark Nottingham wrote: >=20 > Regarding: > >=20 > The editors believe that this PR resolved the issue: > >=20 > ....... and discussion so far seems to support consensus to do so. If = you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:38:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C466512020A for ; Tue, 23 Apr 2019 00:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=JXPnBIqI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E4hH8e3W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOxZfqlsoJjD for ; Tue, 23 Apr 2019 00:38:32 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256D41200B3 for ; Tue, 23 Apr 2019 00:38:32 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 46913201E3; Tue, 23 Apr 2019 03:28:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:28:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=poU64dF7Uvti2nEZIUws0QV6QDHUum DRasfOkjt7Ecc=; b=JXPnBIqIpIZVg65yq86mKblXmC3f993LmH8GgGj6eTMQdN aBRBK0bHY1/JG5A2uD88NGMD084SbQPZSHgmmIvI/iJixwNZyeYZdi1BmCebWb7s hfEtMrEz8mIT1FdMLOOYLjrMZ68s+yznUR7hETXlfWNOiDHppRM/7TBToSMGroQK BPUZ4qlVTDiHH3QJgzfQg3Otv736GEs8Sj1FJP01LCS9/q3fFVdbWl80YImN/M5C d+kVQ9VgGpQtYgICrxb0uSIT3AfPMWxwa09tGPht6qe1Ih3zKd5pVIFy/VDxE37x /3ngbd6bTTgPtgHH0a2dL6RkWse+A2llDvmjdMTA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=poU64d F7Uvti2nEZIUws0QV6QDHUumDRasfOkjt7Ecc=; b=E4hH8e3WmwIYSbEpbBSuDv 6r5CkIntigylP661cfmB0U1e8iR8mini7YHRvVjXsM+FuJR8grWtuwNrv+iHpLN0 pCEOsA3PI0oG+N60Wv5aZytJRbqL2cI/n8zzNAWklLog93gP/PB+Td9SdGyy5qCY 6tQcKaCY0vtPiEJAj9VsB88f3TPXdw/yFUrRTkSVkYdLqbOFny1QjOWJ3J/jnoQZ MK54YQnWcwlAumt+BvB6MN+uI7+V0cchEDr7OBbt4TLx+/SKUEO7xNVxbfYYvvTe PVIQm2Wa1GAkfWBkM9HigSo1MBdN48mGfu4TSxCwNnmlIoL8X3yiC3cscB7F2Zaw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id E6B5E10316; Tue, 23 Apr 2019 03:28:50 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Consensus Call: Message-Id: Date: Tue, 23 Apr 2019 17:28:51 +1000 Cc: Lars Eggert To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:38:35 -0000 Regarding: There seems to be consensus on the issue to close it as out-of-scope for = QUICv1; while it's labeled QUICv2, that is not a commitment to work on = it in the future, just an indication of interest. If you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 00:44:41 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615DE1200B3 for ; Tue, 23 Apr 2019 00:44:40 -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=bZF1Fw+1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pZMT0drf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLSJPIldS-Cn for ; Tue, 23 Apr 2019 00:44:38 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9EF120091 for ; Tue, 23 Apr 2019 00:44:38 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EFB9B220CB; Tue, 23 Apr 2019 03:44:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Apr 2019 03:44:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=m SkmfAxKEy9VtGFnIJGFA8qMfk47M82Z4CJh6/1qzPM=; b=bZF1Fw+1KtxJ6ewao jXIxIqrlpmEsJzYOqThooK9jS9bKm/ZaB+QlksfS1LhsK2wgJdIce+V9/JG8aRuL zewppjBPw8zt4Yg9B77xjwLQZDVwHIijg71Q8MTv9VDUVIsgj/TIxrUW4w4DkAVr xbvRc4oPfgF/lJerWvZxx0oimCmBTaJzYrDL6Tt73Yr/tH7OmtMOrxDzgZK3GVHe I3+Ncy5Gq51ZQw9k0jYxgE84CF8L/P0O+5gY0UtW667yQUeDEY9cKul0B8Ygh7CK JiHXog7gO981TPEtMrYYTeLZ6fBn78VgF8pyrgx0s4EbYnCz1T/CEZYAj5ArmMkk gD7Ww== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=mSkmfAxKEy9VtGFnIJGFA8qMfk47M82Z4CJh6/1qz PM=; b=pZMT0drfsmd5RDUSmx/EXgmoHL5gngQSN4npVhgqFC5aPOI2lloR9Ovt8 cBaPA99f45fjMC3c1+bFaDrPifxnvjooT2sQAVhB7t79P0Ef0r/J+LwmHF8g5pIl jKcvdrMBSpwPNTGKBFZNnRQ/cfpVNiax6s2mmIi3VhZCa97BE1neoX0sSdzWBeY9 S8TXfvk9A7Dq/NcRSyO1EIkdQVRS2g7ATz2l1T/st7d2z+oTA9Ou/ImpORwi7XgT eJmBMdWGZzN0uK3mAWcxUsHQUl6EZz0DM7tCVI3TZywpFo5v+18/s+B1QJr2y2Q4 q/psI/Ta9Mu/kD/EEBsitQUd6Q5qg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F19B10316; Tue, 23 Apr 2019 03:44:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Consensus Call: MAX_PACKET_SIZE frame #2545 From: Mark Nottingham In-Reply-To: Date: Tue, 23 Apr 2019 17:44:31 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <5C3EEB14-9461-4CBB-967B-6EBC7D3F3E07@mnot.net> References: To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 07:44:40 -0000 And again, now with Title. > On 23 Apr 2019, at 5:28 pm, Mark Nottingham wrote: >=20 > Regarding: > >=20 > There seems to be consensus on the issue to close it as out-of-scope = for QUICv1; while it's labeled QUICv2, that is not a commitment to work = on it in the future, just an indication of interest. >=20 > If you object, please do so on the issue or in response to this = message; absent any pushback, we'll declare consensus at the end of the = week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Apr 23 01:45:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72ADF120227 for ; Tue, 23 Apr 2019 01:45: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, DKIMWL_WL_HIGH=-0.001, 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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cWhlSWVTObP for ; Tue, 23 Apr 2019 01:45:10 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EAF41200FA for ; Tue, 23 Apr 2019 01:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ApQifQmp+me+nYruYo+FCya4ZKnPZjSw3Cxa3NR7hR4=; b=G0CEHLfikhphJGNHcHykGVXdqUn3FxpL3kSASC+nP9PD/dW+tckbytzSOjTFK0M2M1CfFw0nKLvyEbJVaMIXtDjkLOZK4+jJ5g6gnkapOuxcD02Mpj8dqiOrNCWac3HQfK+oV9Iei8/Bs2Cx/yDU6oN8nOENJWwUuXFWBReIrYo= Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB3402.eurprd07.prod.outlook.com (10.170.247.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.7; Tue, 23 Apr 2019 08:45:05 +0000 Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::8085:df69:92b4:8bbb]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::8085:df69:92b4:8bbb%4]) with mapi id 15.20.1835.007; Tue, 23 Apr 2019 08:45:05 +0000 From: Ingemar Johansson S To: Ian Swett CC: IETF QUIC WG , Neal Cardwell , Yuchung Cheng , "Bob Briscoe (ietf@bobbriscoe.net)" , Ingemar Johansson S Subject: RE: Some notes about WebRTC and QUIC Thread-Topic: Some notes about WebRTC and QUIC Thread-Index: AQHU9U/7HIw+32S3fkeM+SnZYZfyQKZBeYfAgAIf2ACABdpAEA== Date: Tue, 23 Apr 2019 08:45:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4875cf02-0c87-423b-f293-08d6c7c7fbee x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB3402; x-ms-traffictypediagnostic: HE1PR07MB3402: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3513; x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(136003)(39860400002)(366004)(346002)(189003)(199004)(7696005)(76116006)(73956011)(2906002)(26005)(4326008)(33656002)(66066001)(7736002)(8936002)(5660300002)(66946007)(66616009)(606006)(6506007)(66446008)(64756008)(66556008)(53546011)(186003)(99286004)(66476007)(71200400001)(68736007)(86362001)(71190400001)(102836004)(3846002)(790700001)(6116002)(54906003)(316002)(8676002)(478600001)(486006)(256004)(5024004)(476003)(76176011)(55016002)(14444005)(99936001)(74316002)(25786009)(446003)(11346002)(54896002)(53936002)(236005)(9686003)(6306002)(229853002)(81166006)(81156014)(14454004)(52536014)(966005)(6246003)(97736004)(6916009)(107886003)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3402; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tYScviR4bhei33y/8GkADV1T/60y+RbQdVBhiiuDtupAxDTJ9bBNo8CgzoF8yVYAbEnQ/iE90hwvyVBjQdTVq0L+23TG43g4NF3cfTbMs24kH9K25XQkf4v7kycDMGBgHEKhn3TQCOFWYrJfq+SPW5z2dE971zYu89Hc01pjFKXHjIpDUIKVEdy/0EK4iOYagSa9ZOBfX8oKYc4ZxRtM8q6s+vob4EJQfnSy7hyqpLVPBepvUgJ5/et9krrGjGvbQ8dfqUF2fPKZhjHCi+ApZGoucYdZdCuWU9ZEY+RHIa+W1iIBQL+VPEoOQLRsLxHhw3feOaYKVp1L3SAcFQsk45gzHj4DK/Hath/c+7L6OESL5Hjm8VjRZIW3Oul61VXwHG1Lbsd/KjGRwCbXCNtJ62Ghcv0VFGfXoAD29EoQX8Y= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01D4_01D4F9C1.9BE1AE10" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4875cf02-0c87-423b-f293-08d6c7c7fbee X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 08:45:05.6822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3402 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 08:45:15 -0000 ------=_NextPart_000_01D4_01D4F9C1.9BE1AE10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01D5_01D4F9C1.9BE1AE10" ------=_NextPart_001_01D5_01D4F9C1.9BE1AE10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi =20 As additional input.=20 =20 I understand that GoogCC need these per packet timestamps as it = estimates the link bandwidth based in interpacket arrival. SCReAM does however not benefit from this information as it is more = =E2=80=9Ctraditional=E2=80=9D ACK-clocked in its design. However, being = ACK-clocked it requires at least an ACK every RTT to keep a healthy = self-clocking loop at high bitrates and that at-least-one-ACK-per-RTT = is actually to be seen as the absolute pain limit. =20 As far as I can see there could be congestion control work that benefits = from a more dense time stamp. BBR(v2) : I guess it is best if Neil or Yuchung outline what is needed = in terms of timestamp for good BBR performance TCP Prague (paced chirp) : The paced chirp method can benefit from more = dense timestamps. I guess Bob is the best to provide with input on this = and how much time stamp information that is needed for good performance. Other work on congestion control ? =20 /Ingemar =20 From: Ian Swett =20 Sent: den 19 april 2019 17:10 To: Ingemar Johansson S Cc: IETF QUIC WG Subject: Re: Some notes about WebRTC and QUIC =20 Roberto, I was thinking per-connection ACK policies. =20 =20 Thanks Ingemar, that's great information. =20 On Thu, Apr 18, 2019 at 3:18 AM Ingemar Johansson S = > wrote: Hi =20 And thanks for sharing the meeting notes. I believe that there are = benefits with WebRTC over QUIC, especially the possibility to run a = unified congestion control has some merit given simulation studies that = I have run.=20 =20 For what it=E2=80=99s worth.. During the development of SCReAM = (https://tools.ietf.org/html/rfc8298 ) I have collected some experience = in how SCReAM works and what it requires in terms of feedback for = optimal function. SCReAM is congestion control for RTP media, SCReAM has = built in support for prioritization between media streams. The observant = reader may make the observation that SCReAM resembles LEDBAT quite a lot = and that is quite true, SCReAM however also adds the interaction with = the media coders, stream queues and ECN/L4S support. Mixing small and = large packets (voice, video) does not seem to be a problem in = simulations, but sofar SCReAM has only been used for the transmission of = video at bitrates ranging from ~200kbps to 50+Mbps. I don=E2=80=99t believe that it is possible to take SCReAM and put it as = is into a WebRTC over QUIC solution but perhaps some ideas can be = stolen. =20 =20 A few observations: =20 Timestamps : A receive timestamp for each packet is not needed for the = function of SCReAM. It is sufficient with a receive timestamp of the = last received RTP packet. The current implementation ( = = https://github.com/EricssonResearch/scream) implements = = https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-02 = which reports timestamps per packet, the issue is that it increases the = feedback size quite a lot. An earlier version of the SCReAM code = generated feedback packets that were just 48bytes, the size with the new = format is 128 bytes or even more. =20 It's very nice to only need a receive timestamp from the last received = RTP pacekt. Currently, GoogCC is designed to require one timestamp for = every RTP packet, which as you said greatly increases the size. =20 =20 ACK rates: A low bitrates it is possible with feedback as seldom as = every 50-100ms, at higher bitrate more frequent feedback is required. = For instance, at 50Mbps or beyond, feedback is transmitted roughly every = 2ms. =20 Stream scheduling and prioritization: SCReAM implements an RTP queue per = media stream, something that is best referred to as a credit based = scheduler picks RTP packets from the queues in a priority fashion ( = = https://tools.ietf.org/html/rfc8298#page-24). This approach seems to = work well according to tests we have done. The RTP queues are mostly = empty but serves as shock absorbers for instance when link throughput = drops quickly. =20 Regards Ingemar =20 =20 =20 =20 =20 From: Ian Swett >=20 Sent: den 17 april 2019 17:42 To: IETF QUIC WG > Subject: Some notes about WebRTC and QUIC =20 When in Prague, I organized a small WebRTC over QUIC lunch to discuss = what it might look like and what the goals are. =20 Attached are some notes from the conversation. =20 Thanks, Ian =20 ------=_NextPart_001_01D5_01D4F9C1.9BE1AE10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi

 

As additional input. =

 

I understand that GoogCC need these = per packet timestamps as it estimates the link bandwidth based in = interpacket arrival.

SCReAM does however = not benefit from this information as it is more = =E2=80=9Ctraditional=E2=80=9D ACK-clocked in its design. However, being = ACK-clocked it requires at least an ACK every RTT to keep a healthy = self-clocking loop at high bitrates and that at-least-one-ACK-per-RTT = =C2=A0is actually to be seen as the absolute pain = limit.

 

As far as I can see there could be = congestion control work that benefits from a more dense time = stamp.

BBR(v2) : I guess it is best if = Neil or Yuchung outline what is needed in terms of timestamp for good = BBR performance

TCP Prague (paced = chirp) : The paced chirp method can benefit from more dense timestamps. = I guess Bob is the best to provide with input on this and how much time = stamp information that is needed for good = performance.

Other work on = congestion control ?

 

/Ingemar

 

From: Ian Swett = <ianswett@google.com>
Sent: den 19 april 2019 = 17:10
To: Ingemar Johansson S = <ingemar.s.johansson@ericsson.com>
Cc: IETF QUIC WG = <quic@ietf.org>
Subject: Re: Some notes about WebRTC and = QUIC

 

Roberto, I was thinking per-connection ACK = policies.

 

 

Thanks Ingemar, that's great = information.

 

On = Thu, Apr 18, 2019 at 3:18 AM Ingemar Johansson S <ingemar.s.johansson@eric= sson.com> wrote:

Hi

 <= /o:p>

And thanks for sharing the meeting notes. I believe that = there are benefits with WebRTC over QUIC, especially the possibility to = run a unified congestion control has some merit given simulation studies = that I have run.

 

For what it=E2=80=99s worth.. During the development of = SCReAM (https://tools.ietf.org/html/rfc8298 ) I have = collected some experience in how SCReAM works and what it requires in = terms of feedback for optimal function. SCReAM is congestion control for = RTP media, SCReAM has built in support for prioritization between media = streams. The observant reader may make the observation that SCReAM = resembles LEDBAT quite a lot and that is quite true, SCReAM however also = adds the interaction with the media coders, stream queues and ECN/L4S = support. Mixing small and large packets (voice, video) does not seem to = be a problem in simulations, but sofar SCReAM has only been used for the = transmission of video at bitrates ranging from ~200kbps to = 50+Mbps.

I don=E2=80=99t believe that it is possible to take SCReAM = and put it as is into a WebRTC over QUIC solution but perhaps some ideas = can be stolen.

 

 

A few observations:

 

Timestamps : A receive timestamp for each packet is not = needed for the function of SCReAM. It is sufficient with a receive = timestamp of the last received RTP packet.  The current = implementation (https://github.com/EricssonResearch/scream) implements https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-m= essage-02 which reports timestamps per = packet, the issue is that it increases the feedback size quite a lot. An = earlier version of the SCReAM code generated feedback packets that were = just 48bytes, the size with the new format is 128 bytes or even = more.

 

It's very nice to only need a receive timestamp from = the last received RTP pacekt.  Currently, GoogCC is designed to = require one timestamp for every RTP packet, which as you said greatly = increases the size.

 

 

ACK rates: A low bitrates it is possible with feedback as = seldom as every 50-100ms, at higher bitrate more frequent feedback is = required. For instance, at 50Mbps or beyond, feedback is transmitted = roughly every 2ms.

 

Stream scheduling and prioritization: SCReAM implements an = RTP queue per media stream, something that is best referred to as a = credit based scheduler picks RTP packets from the queues in a priority = fashion (https://tools.ietf.org/html/rfc8298#page-24). This approach seems to work well according to tests we = have done. The RTP queues are mostly empty but serves as shock absorbers = for instance when link throughput drops quickly.

 

Regards

Ingemar

 

 

 

 

 

From: Ian Swett <ianswett@google.com>
Sent: den 17 = april 2019 17:42
To: IETF QUIC WG <quic@ietf.org>
Subject: Some notes = about WebRTC and QUIC

 <= /o:p>

When in = Prague, I organized a small WebRTC over QUIC lunch to discuss what it = might look like and what the goals are.

 <= /o:p>

Attached = are some notes from the conversation.

 <= /o:p>

Thanks, = Ian

 <= /o:p>

------=_NextPart_001_01D5_01D4F9C1.9BE1AE10-- ------=_NextPart_000_01D4_01D4F9C1.9BE1AE10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3 MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J 0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9 7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP 9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6 Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8 TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3 OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO 30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3 0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5 S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT 05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT 9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx 5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+ i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xOTA0MjMwODQ1MDNaMCMGCSqGSIb3DQEJBDEWBBQm32Dge5iz5/uZ6ncB K74XySEIRTBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBACgyNbvUTcOkzzdvyVwp/vpVD8fAv71MjmYeeJlA dPlO86ofZrTYL8sO4Im1hWhao555prUO2JNL9HaWUSVhJ0fIRjlmp1FBjW25QIyav0vm7Hp0a2v1 RrAlXHe2CbhcgTwt4chVwHnrLd10XZFXBZmPFuHkNrPH7j78bchurF+uiEUecXTtvR+ENJgNSO5S uuUu4EA5egqKF8x+N49hiJXeJRozr3epvAINQk3kV8jrHTnaTjV6AhvqUUa9S0T3g6yDzhutKC5y a371OfFt0UVGJXSIxGba+8kLAaIa0p5n0qa7XNJaYL3KPWCXpAqQHyYYyb3OaqqfpvkMswncUXoA AAAAAAA= ------=_NextPart_000_01D4_01D4F9C1.9BE1AE10-- From nobody Tue Apr 23 13:12:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5BC12035B for ; Tue, 23 Apr 2019 13:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.511 X-Spam-Level: X-Spam-Status: No, score=-15.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 m6awTjeUV0sF for ; Tue, 23 Apr 2019 13:12:33 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73A6120357 for ; Tue, 23 Apr 2019 13:12:32 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id u15so14007172otq.10 for ; Tue, 23 Apr 2019 13:12:32 -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=CWKq4kS66dwm9tGbNBYoQI3bExz4bFY87yrkl5NBCdM=; b=vBwKGrEMnKf3cZfmq60PGEVeV6agUJL11gF9ltrLrMNRgNHmEGs0azbGgeYevTMTJP CZdXykyi56mjFxsAA7Vw7RQC6O4fOarTaFsfNXqrGBWi7b+GvHtCAkweKG+WA7S1cYrm tfC8VW0OP7spHIL5qUd9dRoC2c4PiManmAiZFESpIGwouA3i60ETN1KisIBZki5lVnj3 9YBezBr3V0aq3b7IHWsvAPBgGhF03ebt7XZJRkMiJLFD/oHGTF+LCXHTySmbvYIbrlHH 8FqQSX92VnJY4YhAnlaa8uMchIJxpN+ZDXYN6stzH+pHuSUIHPyZYTNq68kLZlPluFCh v5fw== 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=CWKq4kS66dwm9tGbNBYoQI3bExz4bFY87yrkl5NBCdM=; b=CB+3Ax84xCTNSL+ugQkhaaQaizzaVDLc7yd9Oe48QPEM3SGwzvBYilXtIh9itpVHzM aD6IGhJWQaXDQUnUG5TXI6NeGTDq+FCDCOfkeV/O2lNoE44+NsOnHSbWXEqn8Pn1EXIs bfBNbf76tnd+Um+BgUCW+Zg6zB6gm1sSiA6bdAP8MVvGOZU+eOaSOqxWGfvwsXvWR6B7 qwZIcwUlyoC9NiYRIRAiN6R+/aaqYuqiHK7pOjlHsx5l2Acl+FiMB0GxW9aGQpjTgGo3 uCVRyd8jhHTOOSGYJh3WKg6zIepN7HwBX3M1UUMIuGwo/2d0IVhZbnMRQjxLJyQLJiyy DfFA== X-Gm-Message-State: APjAAAUgwgCQaMGuQxjjBGipgQ6rYFkcKCChdSXqPv40+Uq6sMi2QsTT WoZ1Hohgsf1Vvv5OmvTho7HoVYyJoQAnfko0gUNRxg== X-Google-Smtp-Source: APXvYqx2+yOnRq21726u+2BQveh6FwWBpi78Iq4jm4ZuswNwckozEUA/Z/EbpRS0V4HeakKBMJOL3OVT8Bc3TPHij+8= X-Received: by 2002:a05:6830:1192:: with SMTP id u18mr15992217otq.295.1556050351601; Tue, 23 Apr 2019 13:12:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bjorn Mellem Date: Tue, 23 Apr 2019 13:12:20 -0700 Message-ID: Subject: Re: Some notes about WebRTC and QUIC To: Ingemar Johansson S Cc: Ian Swett , "Bob Briscoe (ietf@bobbriscoe.net)" , IETF QUIC WG , Neal Cardwell , Yuchung Cheng Content-Type: multipart/alternative; boundary="00000000000076144005873834f2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 20:12:35 -0000 --00000000000076144005873834f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable SCReAM could be interesting to experiment with in WebRTC-over-QUIC. The aspect of managing RTP queues and prioritizing through weighted credit scheduling could be helpful. Thanks for raising this! We had some problems with the ACK-clocked part of BBR in early experiments: bumping up against the CWND caused sending freezes and delay spikes. However, it might be solvable by keeping changes to media rate control in sync with changes to the CWND and applying back-pressure based on local queues (as SCReAM does). More inline. Bjorn On Tue, Apr 23, 2019 at 1:45 AM Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > > > As additional input. > > > > I understand that GoogCC need these per packet timestamps as it estimates > the link bandwidth based in interpacket arrival. > > SCReAM does however not benefit from this information as it is more > =E2=80=9Ctraditional=E2=80=9D ACK-clocked in its design. However, being A= CK-clocked it > requires at least an ACK every RTT to keep a healthy self-clocking loop a= t > high bitrates and that at-least-one-ACK-per-RTT is actually to be seen a= s > the absolute pain limit. > Interesting--so it needs more frequent ACKs but less data per ACK. As Ian's notes mentioned, one of the challenges we've had in WebRTC-over-QUIC is tuning the ACK policy to control overhead (especially at low bandwidth). Since we're using GoogCC, we've mostly tuned it for less frequent ACKs. The real killer has been small ACK frames that aren't bundled with other frames, as they contribute especially high UDP/IP overhead. Scaling the frequency with bandwidth should help. This is something that WebRTC does with GoogCC as well. We don't currently have that capability in gQUIC, but it's the kind of ACK policy we're likely to end up wanting from QUIC. > > > As far as I can see there could be congestion control work that benefits > from a more dense time stamp. > > BBR(v2) : I guess it is best if Neil or Yuchung outline what is needed in > terms of timestamp for good BBR performance > > TCP Prague (paced chirp) : The paced chirp method can benefit from more > dense timestamps. I guess Bob is the best to provide with input on this a= nd > how much time stamp information that is needed for good performance. > > Other work on congestion control ? > > > /Ingemar > > > > *From:* Ian Swett > *Sent:* den 19 april 2019 17:10 > *To:* Ingemar Johansson S > *Cc:* IETF QUIC WG > *Subject:* Re: Some notes about WebRTC and QUIC > > > > Roberto, I was thinking per-connection ACK policies. > > > > > > Thanks Ingemar, that's great information. > > > > On Thu, Apr 18, 2019 at 3:18 AM Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > Hi > > > > And thanks for sharing the meeting notes. I believe that there are > benefits with WebRTC over QUIC, especially the possibility to run a unifi= ed > congestion control has some merit given simulation studies that I have ru= n. > > > > For what it=E2=80=99s worth.. During the development of SCReAM ( > https://tools.ietf.org/html/rfc8298 ) I have collected some experience in > how SCReAM works and what it requires in terms of feedback for optimal > function. SCReAM is congestion control for RTP media, SCReAM has built in > support for prioritization between media streams. The observant reader ma= y > make the observation that SCReAM resembles LEDBAT quite a lot and that is > quite true, SCReAM however also adds the interaction with the media coder= s, > stream queues and ECN/L4S support. Mixing small and large packets (voice, > video) does not seem to be a problem in simulations, but sofar SCReAM has > only been used for the transmission of video at bitrates ranging from > ~200kbps to 50+Mbps. > > I don=E2=80=99t believe that it is possible to take SCReAM and put it as = is into a > WebRTC over QUIC solution but perhaps some ideas can be stolen. > > > > > > A few observations: > > > > Timestamps : A receive timestamp for each packet is not needed for the > function of SCReAM. It is sufficient with a receive timestamp of the last > received RTP packet. The current implementation ( > https://github.com/EricssonResearch/scream > ) > implements > https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-02 whi= ch > reports timestamps per packet, the issue is that it increases the feedbac= k > size quite a lot. An earlier version of the SCReAM code generated feedbac= k > packets that were just 48bytes, the size with the new format is 128 bytes > or even more. > > > > It's very nice to only need a receive timestamp from the last received RT= P > pacekt. Currently, GoogCC is designed to require one timestamp for every > RTP packet, which as you said greatly increases the size. > > > > > > ACK rates: A low bitrates it is possible with feedback as seldom as every > 50-100ms, at higher bitrate more frequent feedback is required. For > instance, at 50Mbps or beyond, feedback is transmitted roughly every 2ms. > > > > Stream scheduling and prioritization: SCReAM implements an RTP queue per > media stream, something that is best referred to as a credit based > scheduler picks RTP packets from the queues in a priority fashion ( > https://tools.ietf.org/html/rfc8298#page-24). This approach seems to work > well according to tests we have done. The RTP queues are mostly empty but > serves as shock absorbers for instance when link throughput drops quickly= . > > > > Regards > > Ingemar > > > > > > > > > > > > *From:* Ian Swett > *Sent:* den 17 april 2019 17:42 > *To:* IETF QUIC WG > *Subject:* Some notes about WebRTC and QUIC > > > > When in Prague, I organized a small WebRTC over QUIC lunch to discuss wha= t > it might look like and what the goals are. > > > > Attached are some notes from the conversation. > > > > Thanks, Ian > > > > --00000000000076144005873834f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SCReAM could be interesting to experim= ent with in WebRTC-over-QUIC.=C2=A0 The aspect of managing RTP queues and p= rioritizing through weighted credit scheduling could be helpful.=C2=A0 Than= ks for raising this!

We had some problems with the A= CK-clocked part of BBR in early experiments: bumping up against the CWND ca= used sending freezes and delay spikes.=C2=A0 However, it might be solvable = by keeping changes to media rate control in sync with changes to the CWND a= nd applying back-pressure based on local queues (as SCReAM does).
<= br>
More inline.

Bjorn

On Tue, Apr 23, 20= 19 at 1:45 AM Ingemar Johansson S <ingemar.s.johansson@ericsson.com> w= rote:

H= i

=C2=A0

As ad= ditional input.

=C2=A0

I understand that GoogCC need these per packet timestamps as it = estimates the link bandwidth based in interpacket arrival.

SCReAM does however not= benefit from this information as it is more =E2=80=9Ctraditional=E2=80=9D = ACK-clocked in its design. However, being ACK-clocked it requires at least = an ACK every RTT to keep a healthy self-clocking loop at high bitrates and = that at-least-one-ACK-per-RTT =C2=A0is actually to be seen as the absolute = pain limit.


Interestin= g--so it needs more frequent ACKs but less data per ACK.=C2=A0 As Ian's= notes mentioned, one of the challenges we've had in WebRTC-over-QUIC i= s tuning the ACK policy to control overhead (especially at low bandwidth).= =C2=A0 Since we're using GoogCC, we've mostly tuned it for less fre= quent ACKs.

The real killer has been small ACK frames = that aren't bundled with other frames, as they contribute especially hi= gh UDP/IP overhead.

Scaling the frequency with bandwid= th should help.=C2=A0 This is something that WebRTC does with GoogCC as wel= l.=C2=A0 We don't currently have that capability in gQUIC, but it's= the kind of ACK policy we're likely to end up wanting from QUIC.
=

=C2=A0

As far as I can see the= re could be congestion control work that benefits from a more dense time st= amp.

BB= R(v2) : I guess it is best if Neil or Yuchung outline what is needed in ter= ms of timestamp for good BBR performance

TCP Prague (paced chirp) : The paced ch= irp method can benefit from more dense timestamps. I guess Bob is the best = to provide with input on this and how much time stamp information that is n= eeded for good performance.

= Other work on congestion control ?=C2=A0

<= u>=C2=A0

/= Ingemar

=C2=A0

From: Ian S= wett <ianswett@= google.com>
Sent: den 19 april 2019 17:10
To: I= ngemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: IE= TF QUIC WG <quic@ietf= .org>
Subject: Re: Some notes about WebRTC and QUIC=

=C2=A0

Roberto, I was thinking per-connection A= CK policies.

=C2= =A0

=C2=A0

Thanks Ingemar, that's great information= .

=C2=A0

On Thu, Apr 18, 2019 at 3:18 AM Ingemar Johan= sson S <ingemar.s.johansson@ericsson.com> wrote:

Hi<= /p>

=C2=A0

And thanks for sharing the meeting notes. I believe that= there are benefits with WebRTC over QUIC, especially the possibility to ru= n a unified congestion control has some merit given simulation studies that= I have run.

=C2=A0

For what it=E2=80=99s worth.. During the development of SCReAM (https://tools= .ietf.org/html/rfc8298 ) I have collected some experience in how SCReAM= works and what it requires in terms of feedback for optimal function. SCRe= AM is congestion control for RTP media, SCReAM has built in support for pri= oritization between media streams. The observant reader may make the observ= ation that SCReAM resembles LEDBAT quite a lot and that is quite true, SCRe= AM however also adds the interaction with the media coders, stream queues a= nd ECN/L4S support. Mixing small and large packets (voice, video) does not = seem to be a problem in simulations, but sofar SCReAM has only been used fo= r the transmission of video at bitrates ranging from ~200kbps to 50+Mbps.

I don=E2= =80=99t believe that it is possible to take SCReAM and put it as is into a = WebRTC over QUIC solution but perhaps some ideas can be stolen.

=C2=A0

=C2=A0

A few observations= :

=C2= =A0

Tim= estamps : A receive timestamp for each packet is not needed for the functio= n of SCReAM. It is sufficient with a receive timestamp of the last received= RTP packet.=C2=A0 The current implementation (https://github.com/EricssonResearch/scream<= /a>) implements https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-m= essage-02 which reports timestamps per pack= et, the issue is that it increases the feedback size quite a lot. An earlie= r version of the SCReAM code generated feedback packets that were just 48by= tes, the size with the new format is 128 bytes or even more.<= u>

=C2= =A0

It's very nice to only = need a receive timestamp from the last received RTP pacekt.=C2=A0 Currently= , GoogCC is designed to require one timestamp for every RTP packet, which a= s you said greatly increases the size.

=C2=A0

=C2=A0<= /p>

ACK rates: A low bitrates it= is possible with feedback as seldom as every 50-100ms, at higher bitrate m= ore frequent feedback is required. For instance, at 50Mbps or beyond, feedb= ack is transmitted roughly every 2ms.

=C2=A0

Stream scheduling and prioritization: SCReAM= implements an RTP queue per media stream, something that is best referred = to as a credit based scheduler picks RTP packets from the queues in a prior= ity fashion (https://tools.ietf.org/html/rfc8298= #page-24). This approach seems to work well= according to tests we have done. The RTP queues are mostly empty but serve= s as shock absorbers for instance when link throughput drops quickly.

=C2=A0

Regards

Ingemar

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

= From: Ian Swett <ianswett@google.com<= /a>>
Sent: den 17 april 2019 17:42
To: IETF QUIC WG= <quic@ietf.org&g= t;
Subject: Some notes about WebRTC and QUIC=

=C2=A0

When in Prague, I organized a small WebRTC over QUIC lunch = to discuss what it might look like and what the goals are.

=C2=A0

Attached are some notes from the conversation.

=C2=A0

Thanks, Ian

=C2=A0

--00000000000076144005873834f2-- From nobody Tue Apr 23 16:21:09 2019 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 0E21B120006; Tue, 23 Apr 2019 16:21:00 -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-20.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <155606166000.32497.14222140370535177632@ietfa.amsl.com> Date: Tue, 23 Apr 2019 16:21:00 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 23:21:00 -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-20.txt Pages : 143 Date : 2019-04-23 Abstract: This document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at . Working Group information can be found at ; source code and issues list for this draft can be found at . 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 23 16:21:20 2019 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 552E4120119; Tue, 23 Apr 2019 16:21:00 -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-20.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <155606166029.32485.7962975802846988711@ietfa.amsl.com> Date: Tue, 23 Apr 2019 16:21:00 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 23:21:00 -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 TLS to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-20.txt Pages : 43 Date : 2019-04-23 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 23 16:48:11 2019 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 D99CB1200E6; Tue, 23 Apr 2019 16:48:01 -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-20.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <155606328182.32541.9072527323252261879@ietfa.amsl.com> Date: Tue, 23 Apr 2019 16:48:01 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 23:48:02 -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 Version 3 (HTTP/3) Author : Mike Bishop Filename : draft-ietf-quic-http-20.txt Pages : 55 Date : 2019-04-23 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 HTTP/3. 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 23 16:48:21 2019 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 4E2E912066F; Tue, 23 Apr 2019 16:48:08 -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-qpack-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <155606328826.32497.8941190890489700916@ietfa.amsl.com> Date: Tue, 23 Apr 2019 16:48:08 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 23:48: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 : QPACK: Header Compression for HTTP/3 Authors : Charles 'Buck' Krasic Mike Bishop Alan Frindell Filename : draft-ietf-quic-qpack-08.txt Pages : 37 Date : 2019-04-23 Abstract: This specification defines QPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/3. This is a variation of HPACK header compression that seeks to reduce head-of-line blocking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-qpack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-qpack-08 https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-qpack-08 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 23 16:57:00 2019 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 5F0701201B6; Tue, 23 Apr 2019 16:56:59 -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-20.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <155606381931.32445.14925754384343511313@ietfa.amsl.com> Date: Tue, 23 Apr 2019 16:56:59 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 23:56:59 -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-20.txt Pages : 41 Date : 2019-04-23 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 23 23:09:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15F112004C for ; Tue, 23 Apr 2019 23:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cuf0RIX9Brdi for ; Tue, 23 Apr 2019 23:06:33 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAB612002E for ; Tue, 23 Apr 2019 23:06:33 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id c3so7288855iok.6 for ; Tue, 23 Apr 2019 23:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=OIkB20kHhRUMZKRjQMBCBUf0/0zremu2Mnj5ESIHxIQ=; b=tnPj4qaixnmrkawIOitYSU7Lhe4Y94q4mwCFwWJf2dbetIJaxcMIAXaQYWVgCiDKHS y0hvvrb2dc1n2Y+sjDK6JjEf2J/ADAK10ouqzemueb4oTn7hSrwU5C7JKDS3v4iXzM3n 9UmvDhGr34DD+ybe14h1VDgGqSpaHHpnxKye1G9b0fBlar8Ta1tlZkD3jM+IPdI1Meon 8JKAmRquTH8QPVbm+Fkanw57KWb+ThDR4niAeqgoDnMeBclnOHooxxym4BtHzqPHoU/b ixNDAF7UQgC6amONz1O4lTrRiDB3MzCX/jwYTV31PqwrpH/iUQrrUYp9SJ2Kz1jdF6vD bz3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=OIkB20kHhRUMZKRjQMBCBUf0/0zremu2Mnj5ESIHxIQ=; b=f5JuBW192U3bUS1mAmsrIhWtq2BMDONrYSA8gxsLJ3aRaNHlF9yfJWSAsaeCY1fSzF QufYMNdbKryiKfG0RkGvwVvDTqjnKFh9ylF9LlKcWNO+vXB1gA0u/AeCWTTr377rG8qH hh0Z0vfnr8r/wJp1n3jx6OtE1aCm0mWKj7x8NEvu4ujrDwtcBdptDZFYdZItxjVit1MK MGYlg12eJz/5+EYSp1NTDkRkaEZzKQQfWzAraRFna0VLHVyTNM5nMbyRvND/A41ulG5S x96NNCTyl5s1XTjA2+4IhKYBVetb2SXR+8UsLJeVlIXs1vGDajhZp23yQ2d0q99eWnul K+FQ== X-Gm-Message-State: APjAAAUw6ZDUANW0yqupRdrc1eHOK+TwNd8HurOGMmG6QfAiuthqhnLR 9Wh/j6I3KPKQPl/0YcegpWQjEh0fCEL3NqwHBYyBNA== X-Google-Smtp-Source: APXvYqwwFtSIIjWvadPS9M1YP5+3sBvvVt16wSACUU3PBEuHHfX8yufpc35vXKUwUSfiglhKLymoEEGPk5nOFGPBlI0= X-Received: by 2002:a5e:df07:: with SMTP id f7mr20629182ioq.166.1556085992856; Tue, 23 Apr 2019 23:06:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 23 Apr 2019 23:06:31 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 23 Apr 2019 23:06:31 -0700 Message-ID: Subject: PROXY protocol To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000d8227f0587408021" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 06:06:36 -0000 --000000000000d8227f0587408021 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Various cloud load balancers appear to be adding the PROXY protocol which is a single line of text inserted in front of routed packets. https://blog.digitalocean.com/load-balancers-now-support-proxy-protocol/ I=E2=80=99m not deep into this issue, but it appears to also apply to binar= y protocols. I wonder if there is something QUIC should address here in order to avoid having to parse text headers routed packets. For reverse proxy HTTP there is the X-Forwarded family of headers but the PROXY protocol is for cases where this does not apply. In particular, an application might want to know the original IP and port of a QUIC connection before it passed through a load balancer, for example for IP whitelisting. Mikkel --000000000000d8227f0587408021 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Various cloud load b= alancers appear to be adding the PROXY protocol which is a single line of t= ext inserted in front of routed packets.


I=E2=80=99m not deep into this issue, but it appears to also app= ly to binary protocols.

I wonder if there is something QUIC should address here in order to avoi= d having to parse text headers routed packets.

For reverse proxy HTTP there is the X-Forwarded f= amily of headers but the PROXY protocol is for cases where this does not ap= ply.

In particular, an application might want to k= now the original IP and port of a QUIC connection before it passed through = a load balancer, for example for IP whitelisting.

=
<= div style=3D"font-size:13px">Mikkel

=
--000000000000d8227f0587408021-- From nobody Tue Apr 23 23:10:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BAA120154 for ; Tue, 23 Apr 2019 23:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5X8SSuEP3tg for ; Tue, 23 Apr 2019 23:07:07 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B85512002E for ; Tue, 23 Apr 2019 23:07:07 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id e13so4289825itk.4 for ; Tue, 23 Apr 2019 23:07:07 -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=MDGYYtFfqsOuptfY+kkSev95GkNsbiF2S6TT+GhmccE=; b=Hmg0UTffYMgTZvyxd0pNPoCGx/Psvya7b25qSON+DevN1HajxGycMnfoxtv8X+7af7 4Telvdu19i0nMiHajQBNcu8r8gHXIPR1eTwm0g904T1ZpcDARRDoUCJKnJ+zAzo+iDJO TIzue7eQyedlgwoh/LPnf8z/POdGNLh72imyiMTHcWDWqdnm3vBPA5wFBGWvrs/ipYh8 OdBOn7HJwUYmCsPU4yhd4YWADd25gPh81rYZgtPab8Uy0sd453lKl/nijSbzOf7L0Pfy ZCFs86uOAcXf90fEaqan+CifqZAjyBYXOkxtNOahObAcTWKwsYrahH5hGNNiVSWSOj61 VMWg== 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=MDGYYtFfqsOuptfY+kkSev95GkNsbiF2S6TT+GhmccE=; b=DlF+K3vfkQ8KM6rNf9k3x0oqKVTJGA5sa7yPkYWU6bgKfaRipTj0H2waYrQVZKhltG CMQ74RiWf8d3IJ7FvvALL0h3gxgLApbZF/DEuS8X4zG3SLyxy0YYdkZpALBHxWoYo5aN YtwZ3OqkC+sH3USTm1c6hjq3O4M7VMlmIN2XPUG96fIkPNWkG327NKSNF9iSEVaqk2V3 Fc3HECw3jL1lGt7LLzpaFpgRIOjEZyWt4CFrk7lrGCKIOm62D8ZdxnAz6MFhQwm2HELk VDiomZ6W8VwwYFCRMsWQKQPEMM9v5Mc6OZRhBZit5rMFucLfoJpGq2QNfeFSz2wwffmF 7Mdg== X-Gm-Message-State: APjAAAUtwx3cMscd3+xgX8fakS5Kb7ut1DieXSHxGQF1bebBZodvNw0k Qnd3o+i7fYy1/foePNhz6+KJdrGo6q1ryXeANYWXgg== X-Google-Smtp-Source: APXvYqxh7JVp1/lNMAKZwR/wru3bh309Z/sjGPlrN7/7Xb2Qg1rfD2dllyUTgsGeOsYapAOmcr8I7zCvKDGpfdJFcW4= X-Received: by 2002:a24:4d8a:: with SMTP id l132mr5342898itb.70.1556086026248; Tue, 23 Apr 2019 23:07:06 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 23 Apr 2019 23:07:05 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 23 Apr 2019 23:07:05 -0700 Message-ID: Subject: Re: PROXY protocol To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000d5a6540587408254" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 06:07:09 -0000 --000000000000d5a6540587408254 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable some background https://blog.digitalocean.com/load-balancers-now-support-proxy-protocol/ On 24 April 2019 at 08.06.31, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@g= mail.com) wrote: Various cloud load balancers appear to be adding the PROXY protocol which is a single line of text inserted in front of routed packets. https://blog.digitalocean.com/load-balancers-now-support-proxy-protocol/ I=E2=80=99m not deep into this issue, but it appears to also apply to binar= y protocols. I wonder if there is something QUIC should address here in order to avoid having to parse text headers routed packets. For reverse proxy HTTP there is the X-Forwarded family of headers but the PROXY protocol is for cases where this does not apply. In particular, an application might want to know the original IP and port of a QUIC connection before it passed through a load balancer, for example for IP whitelisting. Mikkel --000000000000d5a6540587408254 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = some background


=
On Mon, Apr 15, 2019 at 4:15 AM Brian= Trammell (IETF) <ietf@trammell.ch> wrote:

> On 15 Apr 2019, at 11:28, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= ; wrote:


> Will it help to be is opaque as possible, or not? Some of the scenario= s I posted earlier show that no matter what you do, something will get in t= he way.

This all comes down to the threat model, and the model of incentives for on= -path devices.

I personally think the correct design target is to put trivial QUIC-discrim= inability into the wire image, since there will be a lot of pressure to dis= tinguish QUIC from not-QUIC traffic regardless of what we do, and if we don= 't put grippy bits in the wire image, the distinguishing functions will= grip on to the slippy bits, with difficult to predict outcomes. I recogniz= e I am in the minority (of people who speak up) on this issue, though.

Cheers,

Brian


Can Brian (or anyone else) comment on = what the threat model was that caused middleboxes to drop TLS 1.3 when it u= sed the actual version field? It seems especially perverse for non-surveill= ance devices to drop future versions that are, almost by definition, more s= ecure. At this moment, my strong support for greasing is driven my fear of = this behavior that seems nonsensical to me.

--000000000000389b3e0586e65978-- From nobody Fri Apr 19 12:40:51 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628B812036F for ; Fri, 19 Apr 2019 12:40:49 -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 C3UAJSLbu5Dk for ; Fri, 19 Apr 2019 12:40:47 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820104.outbound.protection.outlook.com [40.107.82.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 2ADC2120368 for ; Fri, 19 Apr 2019 12:40:46 -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:X-MS-Exchange-SenderADCheck; bh=ripbgPzTpz9WGX0ZCKXJuuFWPO/trwKVPHfZ80QVLyI=; b=TCg2nmxbEKrbWCl0cQGH09AvMI9GVpiW5lf03WAzMcvE+Vuk3NSssphTOtPvMynp7XkJNI+LwfYGvNxDYAsh7R6A8F3GN/xCtxKD+v0YQ86JrlmUKhGYZvVKtj8z3gLVMexXw3Q7uWkiN1UzM7OmcD0S7Ft6nNf1vvSFxOrTikI= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0152.namprd22.prod.outlook.com (10.169.183.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.14; Fri, 19 Apr 2019 19:40:44 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::bc8f:9757:f4f4:7b86]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::bc8f:9757:f4f4:7b86%9]) with mapi id 15.20.1813.011; Fri, 19 Apr 2019 19:40:44 +0000 From: Mike Bishop To: May Liu , "quic@ietf.org" Subject: RE: Discovering an HTTP/3 Endpoint in 302 Redirect Thread-Topic: Discovering an HTTP/3 Endpoint in 302 Redirect Thread-Index: AQHU9qrIhpnHyz2z5U+zfzRNiq7xLqZD4cHw Date: Fri, 19 Apr 2019 19:40:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:81d1:439e:6387:e9f0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa240afb-3bc2-43eb-8de4-08d6c4fee9c0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:CY4PR22MB0152; x-ms-traffictypediagnostic: CY4PR22MB0152: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0012E6D357 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(376002)(366004)(396003)(39830400003)(199004)(189003)(66946007)(110136005)(54896002)(6306002)(5660300002)(9686003)(55016002)(99286004)(476003)(52536014)(53936002)(46003)(446003)(486006)(11346002)(14454004)(2501003)(102836004)(6116002)(790700001)(66476007)(66556008)(508600001)(53546011)(316002)(68736007)(7696005)(74482002)(71200400001)(6506007)(4744005)(186003)(2906002)(256004)(81166006)(33656002)(76176011)(81156014)(8676002)(8936002)(76116006)(229853002)(6246003)(86362001)(71190400001)(7736002)(74316002)(97736004)(6436002)(73956011)(25786009)(64756008)(66446008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0152; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: y0e71xBK55fyp7InSIXAcdWFqmyJSBfKxzV2eVoapDGdRd/38tlQ51QZZZaOAdeIkuGpWaHLxdol/Ub/P2pPj8sXNLBfY4ezkPxyFV2S+CrsIHLdlNBlOqj1D0HZFqHP3/TC3WcukCNXMzbRI1wJR824tXbyxV+kmzZM5uBViJS33vl8E4yImfT2DIY4c3tuEjuTF4S+gZ/sg2TQRoXyO/rHtg4FA01AVJ3+D3ahNY+tv7ttG4Blx5LV7TY/yaFIRvnfEFtSVCcNkgCHNOuhc+Xn1lPEQ7lgqfTn4dDHVufYg3ru+NHW2RW6JhKsRAJqJIIhjvSx3cd2OmKlsmW4vKKM82O76wNc/p3LprEftkDWkQ8i6nhLMUVDnocNRDFD6bBvZXPrwLeXYLaU4V+qILZADqf0KvdAjk+p51iefDg= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB098333C09C57CE58D37AE0C1DA270CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: fa240afb-3bc2-43eb-8de4-08d6c4fee9c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2019 19:40:43.8809 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0152 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 19:40:50 -0000 --_000_CY4PR22MB098333C09C57CE58D37AE0C1DA270CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXNpbmcgdGhlIEhUVFAvMiBBTFRTVkMgZnJhbWUsIGFuIG9yaWdpbiB0aGF0IHdhcyBhdXRob3Jp dGF0aXZlIGZvciBib3RoIHRoZSBvbGQgYW5kIG5ldyBvcmlnaW5zIGNvdWxkIGFkdmVydGlzZSBh biBBbHQtU3ZjIHJlY29yZCBmb3IgdGhlIHRhcmdldCBvcmlnaW4gcHJpb3IgdG8gc2VuZGluZyB0 aGUgMzAyLiAgSG93ZXZlciwgaWYgdGhlIG9yaWdpbiBpc27igJl0IGF1dGhvcml0YXRpdmUgZm9y IHRoZSB0YXJnZXQgb2YgdGhlIHJlZGlyZWN0LCB0aGVyZeKAmXMgY3VycmVudGx5IG5vIGRlZmlu ZWQgd2F5IHRvIGRvIHRoYXQg4oCTIHlvdeKAmWQgY29ubmVjdCB0byB0aGUgdGFyZ2V0IG9mIHRo ZSByZWRpcmVjdCBhbmQgZGlzY292ZXIgSFRUUC8zIHN1cHBvcnQgZnJvbSB5b3VyIGV4Y2hhbmdl IHdpdGggaXQuDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIE1heSBMaXUNClNlbnQ6IEZyaWRheSwgQXByaWwgMTksIDIwMTkgNToyNCBBTQ0KVG86IHF1 aWNAaWV0Zi5vcmcNClN1YmplY3Q6IERpc2NvdmVyaW5nIGFuIEhUVFAvMyBFbmRwb2ludCBpbiAz MDIgUmVkaXJlY3QNCg0KSW4gZHJhZnQtaWV0Zi1xdWljLWh0dHAtMTksIHdlIHVzZSByZXNwb25z ZSBoZWFkZXIgIkFsdC1TdmMiIHRvIGRpc2NvdmVyIGFuIEhUVFAvMyBlbmRwb2ludC4NCkluIDMw MiByZWRpcmVjdCBjYXNl77yMd2hpY2ggaGVhZGVyIHNob3VsZCB3ZSB1c2UgdG8gcmVjb2duaXpl IHRoZSB0YXJnZXQgZW5kcG9pbnQgc3VwcG9ydCBIVFRQLzMgPw0KDQpUaGFua3MsIE1heQ0K --_000_CY4PR22MB098333C09C57CE58D37AE0C1DA270CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVzaW5nIHRoZSBIVFRQ LzIgQUxUU1ZDIGZyYW1lLCBhbiBvcmlnaW4gdGhhdCB3YXMgYXV0aG9yaXRhdGl2ZSBmb3IgYm90 aCB0aGUgb2xkIGFuZCBuZXcgb3JpZ2lucyBjb3VsZCBhZHZlcnRpc2UgYW4gQWx0LVN2YyByZWNv cmQgZm9yIHRoZSB0YXJnZXQgb3JpZ2luIHByaW9yIHRvIHNlbmRpbmcgdGhlIDMwMi4mbmJzcDsg SG93ZXZlciwgaWYgdGhlIG9yaWdpbiBpc27igJl0IGF1dGhvcml0YXRpdmUgZm9yIHRoZSB0YXJn ZXQNCiBvZiB0aGUgcmVkaXJlY3QsIHRoZXJl4oCZcyBjdXJyZW50bHkgbm8gZGVmaW5lZCB3YXkg dG8gZG8gdGhhdCDigJMgeW914oCZZCBjb25uZWN0IHRvIHRoZSB0YXJnZXQgb2YgdGhlIHJlZGly ZWN0IGFuZCBkaXNjb3ZlciBIVFRQLzMgc3VwcG9ydCBmcm9tIHlvdXIgZXhjaGFuZ2Ugd2l0aCBp dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgJmx0O3F1aWMtYm91 bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCk1heSBMaXU8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxOSwgMjAxOSA1OjI0IEFNPGJyPg0KPGI+VG86PC9iPiBx dWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IERpc2NvdmVyaW5nIGFuIEhUVFAvMyBF bmRwb2ludCBpbiAzMDIgUmVkaXJlY3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JbiZuYnNwO2RyYWZ0LWlldGYtcXVpYy1odHRwLTE5LCB3ZSB1c2UgcmVzcG9uc2UgaGVh ZGVyICZxdW90O0FsdC1TdmMmcXVvdDsgdG8gZGlzY292ZXIgYW4gSFRUUC8zIGVuZHBvaW50Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gMzAy IHJlZGlyZWN0IGNhc2U8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1 b3Q7Ij7vvIw8L3NwYW4+d2hpY2ggaGVhZGVyIHNob3VsZCB3ZSB1c2UgdG8gcmVjb2duaXplIHRo ZSB0YXJnZXQgZW5kcG9pbnQgc3VwcG9ydCBIVFRQLzMgPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsIE1heTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR22MB098333C09C57CE58D37AE0C1DA270CY4PR22MB0983namp_-- From nobody Fri Apr 19 12:41:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC462120391 for ; Fri, 19 Apr 2019 12:41:31 -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 5IhD5KjK9LCe for ; Fri, 19 Apr 2019 12:41:28 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750133.outbound.protection.outlook.com [40.107.75.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 258D8120377 for ; Fri, 19 Apr 2019 12:41:25 -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:X-MS-Exchange-SenderADCheck; bh=uEUNcXYnEEwV7yHDbjXugvAYmaTgKwot5nVEwvOWMVg=; b=VWwsg65aQRNnTEGTcCj2W7RcNOOyUVJSS/yImH2Nuy1JAVMczbIbZauv84V8lJtg1fkDrJdlWNDKsht/ckKqmtZt42UBW8i7xBtXlX1T3NXfK+6OCKKBJKDyDyvpMao8SkUG8Pj2Y/mWuTRw/wHREP2Ykhn6fNAGV/ZDWFN7Lt0= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0152.namprd22.prod.outlook.com (10.169.183.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.14; Fri, 19 Apr 2019 19:41:23 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::bc8f:9757:f4f4:7b86]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::bc8f:9757:f4f4:7b86%9]) with mapi id 15.20.1813.011; Fri, 19 Apr 2019 19:41:23 +0000 From: Mike Bishop To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG Subject: RE: Retry across versions Thread-Topic: Retry across versions Thread-Index: AQHU9n5ZQhc3P9xANUC1CJG4wbNGPaZD4qcQ Date: Fri, 19 Apr 2019 19:41:23 +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: [2601:600:8080:701:81d1:439e:6387:e9f0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 086d4089-8e25-40af-1675-08d6c4ff013b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:CY4PR22MB0152; x-ms-traffictypediagnostic: CY4PR22MB0152: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0012E6D357 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(376002)(366004)(396003)(39830400003)(199004)(189003)(66946007)(110136005)(54896002)(6306002)(5660300002)(9686003)(55016002)(99286004)(476003)(52536014)(53936002)(46003)(446003)(486006)(11346002)(14454004)(102836004)(6116002)(790700001)(66476007)(66556008)(508600001)(53546011)(316002)(68736007)(7696005)(74482002)(71200400001)(66574012)(6506007)(4744005)(186003)(2906002)(256004)(14444005)(3480700005)(81166006)(33656002)(76176011)(81156014)(8676002)(8936002)(76116006)(7116003)(229853002)(6246003)(86362001)(71190400001)(7736002)(74316002)(97736004)(6436002)(73956011)(25786009)(64756008)(66446008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0152; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Q4kT66QVMzLctrkjOGSywIp+QI6f/WMAypfzYxDEwVBMj549FM5DxzvFdVMs4PZYrDAZQP12u5BAW3f5ObnApN2x7korg3VyK/kSlx5EBOnWVp+oQ6wniyHUUWSIRUPlnRZuYLdfWCPoS/hd2S3LMgDRbnxHxm4Cvd+Mo60S5Wt+qyqRrJjgCTfakTyTKHxzN/md9BmiH3Gvk3F8gnqjWr1xK5bXSLgBU+4tj07Gak09Xn5m3kv+EBpUtu8+DFFaEqJ/leEEigV60xi8OSNhRd97gpXRWjj0AQK/s7A9dAhsDp1y1DCL3Ksmt20RydhzPd6+mPI2Zihwpa8tu5ANpjVXgq5mxIa3uu7zfk7Dfc1+IHzotTixjv0drRk5DZTonYfHdUV+q/v7bw3E7v77cKmmuFNvna9FSeGXD1y+v6k= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983336B6B9C196271E7D306DA270CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 086d4089-8e25-40af-1675-08d6c4ff013b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2019 19:41:23.4576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0152 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 19:41:32 -0000 --_000_CY4PR22MB0983336B6B9C196271E7D306DA270CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmV0cnkgaXMgYSB2ZXJzaW9uLXNwZWNpZmljIHBhY2tldC4NCg0KRnJvbTogUVVJQyA8cXVpYy1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0K U2VudDogRnJpZGF5LCBBcHJpbCAxOSwgMjAxOSAxMjowNiBBTQ0KVG86IElFVEYgUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJldHJ5IGFjcm9zcyB2ZXJzaW9ucw0KDQpEbyB3ZSBo YXZlIGFueXRoaW5nIHRoZSByZWxhdGVzIFJldHJ5IHBhY2tldHMgYWNyb3NzIHZlcnNpb25zPw0K DQpBIFJldHJ5IGNhbiBiZSB1c2VkIHRvIHZlcmlmeSBhIGNsaWVudCBhZGRyZXNzLCBidXQgaXQg Y2FuIGFsc28gYmUgdXNlZCB0byByb3V0ZSB0cmFmZmljIHRvIGEgbmV3IHNlcnZlciB2aWEgYSBj aGFuZ2UgaW4gRENJRCBpbiB0aGUgaW5pdGlhbCBwYWNrZXQuDQoNClNpbmNlIHZlcnNpb24gYWxp YXNpbmcgbWFrZXMgaXQgaGFyZCBmb3IgbG9hZCBiYWxhbmNlcnMgdG8gZGlyZWN0IHRyYWZmaWMg dG8gYSBzZXJ2ZXIgaGFuZGxpbmcgYSBzcGVjaWZpYyB2ZXJzaW9uLCBSZXRyeSBtaWdodCBiZSBh IHNvbHV0aW9uLiBIb3dldmVyLCB0aGlzIG9ubHkgd29ya3MgdG8gdGhlIGV4dGVuZCB0aGF0IFJl dHJ5IHdvcmtzIGFjcm9zcyB2ZXJzaW9ucy4NCg0KTWlra2VsDQoNCg== --_000_CY4PR22MB0983336B6B9C196271E7D306DA270CY4PR22MB0983namp_ 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 cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmV0cnkgaXMgYSB2ZXJzaW9uLXNwZWNpZmljIHBhY2tldC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBR VUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwg MTksIDIwMTkgMTI6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmV0cnkgYWNyb3NzIHZlcnNpb25zPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5EbyB3ZSBoYXZlIGFueXRoaW5nIHRoZSByZWxh dGVzIFJldHJ5IHBhY2tldHMgYWNyb3NzIHZlcnNpb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5BIFJldHJ5IGNhbiBiZSB1c2VkIHRvIHZlcmlmeSBhIGNsaWVudCBhZGRy ZXNzLCBidXQgaXQgY2FuIGFsc28gYmUgdXNlZCB0byByb3V0ZSB0cmFmZmljIHRvIGEgbmV3IHNl cnZlciB2aWEgYSBjaGFuZ2UgaW4gRENJRCBpbiB0aGUgaW5pdGlhbCBwYWNrZXQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNpbmNlIHZlcnNpb24gYWxpYXNpbmcgbWFrZXMg aXQgaGFyZCBmb3IgbG9hZCBiYWxhbmNlcnMgdG8gZGlyZWN0IHRyYWZmaWMgdG8gYSBzZXJ2ZXIg aGFuZGxpbmcgYSBzcGVjaWZpYyB2ZXJzaW9uLCBSZXRyeSBtaWdodCBiZSBhIHNvbHV0aW9uLiBI b3dldmVyLCB0aGlzIG9ubHkgd29ya3MgdG8NCiB0aGUgZXh0ZW5kIHRoYXQgUmV0cnkgd29ya3Mg YWNyb3NzIHZlcnNpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9z aWduXzE1NTU2NTc0MDI2MzI4NTE5NjgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5NaWtrZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CY4PR22MB0983336B6B9C196271E7D306DA270CY4PR22MB0983namp_-- From nobody Fri Apr 19 12:59:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A27F120187 for ; Fri, 19 Apr 2019 12:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh8RiYXNVbvO for ; Fri, 19 Apr 2019 12:59: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 6A55C12001B for ; Fri, 19 Apr 2019 12:59:16 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3JJvDMM004155; Fri, 19 Apr 2019 20:59:01 +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=+qZK+a9wmCWltZ9BlFrQ88dB7PTZCHE0h8YD+ZdlMQ0=; b=A2UGMWtmPvRbn95VNcqtF20Se2XNSnaCqHXTY+5NB8fWXRh4L/MtBq/ljbCsUBy6bk38 8UYK0L9EaKYFtkvu2CDJ/NTAJzvtD7VbWaqNRgn3gmDC/vpE0ZfS9xnE8cstkhvLKrvS ptCt5czie20zXeHGtakRuGvPSf+uFThrj0pVak8ZL05DqtKfLERKHwHUddnbOTq3FHwj Yjaih6cFw2sgGkkg5QHcDWNUlI4T91Pug14GsLw4OwxwcJJ/R5to8Kr/cGc7EFYgZV1M VwDLXL5LXkuKRR87fi1Pmcl7LuVLWa57+Y/L8a3KP9hj3NWBhEOjZzQvBWnP7NFSHozW 1A== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2ryjua0bb4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 20:59:01 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x3JJklhj010544; Fri, 19 Apr 2019 15:59:00 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ryjv00evy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 15:59:00 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 19 Apr 2019 14:58:59 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Fri, 19 Apr 2019 14:58:59 -0500 From: "Salz, Rich" To: Martin Duke , "Brian Trammell (IETF)" CC: Gorry Fairhurst , Roberto Peon , "Mirja Kuehlewind" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , "Border, John" Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? Thread-Topic: Is "Version Greasing" a new benfit or a new obstacle? Thread-Index: AQHU73o3+GFqMkv2N02v8sFZR7OdZKY18DKAgAACAICAAAdtgIAADYsAgAAcxQCAAMryAIAABNSAgAZaAACAAAJpgIAAHasAgAbDpwD//9UGgA== Date: Fri, 19 Apr 2019 19:58:59 +0000 Message-ID: <2B820FED-517F-401F-B7A4-88733892DA52@akamai.com> References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.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.18.0.190414 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.129] Content-Type: multipart/alternative; boundary="_000_2B820FED517F401FB7A488733892DA52akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-19_11:, , 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=724 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904190140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-19_11:, , 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=732 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904190141 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 19:59:18 -0000 --_000_2B820FED517F401FB7A488733892DA52akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkNhbiBCcmlhbiAob3IgYW55b25lIGVsc2UpIGNvbW1lbnQgb24gd2hhdCB0aGUgdGhyZWF0IG1v ZGVsIHdhcyB0aGF0IGNhdXNlZCBtaWRkbGVib3hlcyB0byBkcm9wIFRMUyAxLjMgd2hlbiBpdCB1 c2VkIHRoZSBhY3R1YWwgdmVyc2lvbiBmaWVsZD8NCg0K4oCcc2FmZXR54oCdDQoNCkxlc3MgZmxp cHBhbnRseSwgdGhleSBkaWRu4oCZdCB1bmRlcnN0YW5kIHRoZSBuZXcgdmVyc2lvbiBzbyB0aGV5 IGNvdWxkIG5vdCBiZSBzdXJlIGl0IHdhcyBva2F5IHRvIHBhc3MgdGhyb3VnaCwgdGhleSBkaWRu 4oCZdCBrbm93IGhvdyB0byBkbyBjb250ZW50IGluc3BlY3Rpb24sIFRMUyBvZmZsb2FkLCBldGMu DQoNCg== --_000_2B820FED517F401FB7A488733892DA52akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7A107865B335944B9DF255044A80E16E@akamai.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 c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwv Yj5DYW4gQnJpYW4gKG9yIGFueW9uZSBlbHNlKSBjb21tZW50IG9uIHdoYXQgdGhlIHRocmVhdCBt b2RlbCB3YXMgdGhhdCBjYXVzZWQgbWlkZGxlYm94ZXMgdG8gZHJvcCBUTFMgMS4zIHdoZW4gaXQg dXNlZCB0aGUgYWN0dWFsIHZlcnNpb24gZmllbGQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKA nHNhZmV0eeKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXNzIGZsaXBwYW50bHksIHRoZXkg ZGlkbuKAmXQgdW5kZXJzdGFuZCB0aGUgbmV3IHZlcnNpb24gc28gdGhleSBjb3VsZCBub3QgYmUg c3VyZSBpdCB3YXMgb2theSB0byBwYXNzIHRocm91Z2gsIHRoZXkgZGlkbuKAmXQga25vdyBob3cg dG8gZG8gY29udGVudCBpbnNwZWN0aW9uLCBUTFMgb2ZmbG9hZCwgZXRjLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2B820FED517F401FB7A488733892DA52akamaicom_-- From nobody Fri Apr 19 14:48:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F918120475 for ; Fri, 19 Apr 2019 14:48:17 -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 9rI7oRDF4KFJ for ; Fri, 19 Apr 2019 14:48:15 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 3260D1203FD for ; Fri, 19 Apr 2019 14:48:15 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id h21so5610974ljk.13 for ; Fri, 19 Apr 2019 14:48:15 -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=IEvxzTRJNv5S7Pna27oWR4IJdASk1Ofoo+VM8eknCrk=; b=TZxfHiYSrBxATlQ6ns7D923onzYK2bLq7HQcvh/IsgGmwogpFnJOJgGWGSyNqvfj5G toBM4mlLQ15eV752V3JRYlQXnPV9pcniD8PhGiVa86bUq/iTGDjIq1NGfOky6vhecMws osP69+WvcX45rlI26s7H7dWUMsdZVbOXuc4NQPfMMPKwqBS/76plCh+3RImqnWkqimzd FPeciLwUNERlNZ6d5NlxEPxQ/qRqbb7tzf1/r+XraubxqV7bVsY2WewqzRScBbNqnkxv 879/iW43/M8WvLNjRsjBK44yux7aHKXoGhHKXhKjQZcWaTxy21e4XW2tldwjlmJZ9t6m 94sw== 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=IEvxzTRJNv5S7Pna27oWR4IJdASk1Ofoo+VM8eknCrk=; b=tUI1fHdCyEX/+GjdcLEYcFPQBlknQ7Ihwx2ABDpLiJ2s5vcNEKMBGVIrcc5vbTdZAi Zd3u0+Txn8ZggZs7SNiGLgafRRrpMxougIQSeVNmq7kLDPRFwA2RObdWE2rq6H6NMJl2 KrBONiIjSYHCFO5Jea37lwAnUbXezkPTwhqJzkhxaAgqEN+9DWq9GwngfvxBHqRGpz3M DsKC0WIC2G4TpDXHmB+0iEoQz+aYCNiy08pC++1VQXcrL2ug47eG0ZSREUWmz2Bvt7B9 Ys9oqICUDxsVI0gkHDDeLYTO4pRFkH0FouIBpjjpxU+1+OvrM5taKT8phTCFq5shuBoJ jgSg== X-Gm-Message-State: APjAAAX8UmNw1A3WflzqYRq2tY3SHGJzObrYVgGmfUzLtv5H886C2Mqx iR66F6cordiYHDk1gyM1AxUcq8Xp9dD1YD2WcTc= X-Google-Smtp-Source: APXvYqzf2770XQ5ZsX7A41W9Nj/OrT2nbHyZXjNgXJXfnY5fzW31+hRX3rUKFrKPL8vZYLgxkXV76fBjo6+MMVBw2ng= X-Received: by 2002:a2e:8905:: with SMTP id d5mr3072978lji.59.1555710493200; Fri, 19 Apr 2019 14:48:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Fri, 19 Apr 2019 14:48:02 -0700 Message-ID: Subject: Re: Retry across versions To: Mike Bishop Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000052143b0586e913e0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 21:48:18 -0000 --00000000000052143b0586e913e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What Mike said. Though if version aliasing is incorporated, we may want to add some text around the treatment of Reset with aliases. On Fri, Apr 19, 2019 at 12:41 PM Mike Bishop wrote: > Retry is a version-specific packet. > > > > *From:* QUIC *On Behalf Of * Mikkel Fahn=C3=B8e > J=C3=B8rgensen > *Sent:* Friday, April 19, 2019 12:06 AM > *To:* IETF QUIC WG > *Subject:* Retry across versions > > > > Do we have anything the relates Retry packets across versions? > > > > A Retry can be used to verify a client address, but it can also be used t= o > route traffic to a new server via a change in DCID in the initial packet. > > > > Since version aliasing makes it hard for load balancers to direct traffic > to a server handling a specific version, Retry might be a solution. > However, this only works to the extend that Retry works across versions. > > > > Mikkel > > > --00000000000052143b0586e913e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What Mike said. Though if version aliasing is incorporated= , we may want to add some text around the treatment of Reset with aliases.<= /div>
O= n Fri, Apr 19, 2019 at 12:41 PM Mike Bishop <mbishop@evequefou.be> wrote:

Retry is a version-specific packet.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Friday, April 19, 2019 12:06 AM
To: IETF QUIC WG <quic@ietf.org>
Subject: Retry across versions

=C2=A0

Do we have anything the relates Retry packets across versions?<= u>

=C2=A0

A Retry can be used to verify a client address, but it can also= be used to route traffic to a new server via a change in DCID in the initi= al packet.

=C2=A0

Since version aliasing makes it hard for load balancers to dire= ct traffic to a server handling a specific version, Retry might be a soluti= on. However, this only works to the extend that Retry works across versions.

=C2=A0

Mikkel

=C2=A0

--00000000000052143b0586e913e0-- From nobody Fri Apr 19 15:49:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001BF1200D5 for ; Fri, 19 Apr 2019 15:49:08 -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 tFxZ58FKZI5P for ; Fri, 19 Apr 2019 15:49:05 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5411200D8 for ; Fri, 19 Apr 2019 15:49:05 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id g3so8391013wrx.9 for ; Fri, 19 Apr 2019 15:49: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=irF7qbQyQM2JSY0BTVl+Oh1H+BsatNTEPw2lb99K5sc=; b=VFBbC5/GfhQAFWEnm02YVVngQvV9VerMLHqwwOB5D8I2lSHu4jf27HoIOEiylfmqnU kmXV/wAJlKuE5GueH9k2HAKQifFQdv6/GLAC1SqkymDXWNr7gwx1NSB1YtpMC9FsbHrB kMSay2uaNfvZfACP6noVJM1SiNQfkrWtROqOPhrMC9pznLM+A2nVwbPdSGDTLzQVUxV6 0y6/77vYHkXZYB1iTbkflPCy8GR45TUpj4QyjOahQnMswyZlXkfx/UUR5DqjDtazXv+C cl95MZkom0vCtOsgJDjX8/74csIi++XP1O8SZ/wiU3E4RY0b+7JyBuJYzarn2MIQKp19 Hakg== 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=irF7qbQyQM2JSY0BTVl+Oh1H+BsatNTEPw2lb99K5sc=; b=kmjgHOlx/kRVPFc+Qbia9bTCtqYxxIpoSYU4R1lIaL01iXCFPBw+1YPJwfiwXgSo/M BiQwRJlJ7ClTpMBs7KRT09unDSbRvOUqTd0YELzMi2MpE/O4JedGQJ39GpZpOKg5W4Ug eGhxlCG5bryTDifKhsgHr2i+bZoXyVudf8fHzBKOG2+J+rLk5pwUFTSoWMI13iAPtkox bACpt50QhxzR83CfrrLRg/tZ9Edvon9tnJG3YGZCVW+irUrViSysjyDjI8GP3aYV2Q4w qXesFyz8TwEz3MyYYmzLN1qP/ozBG3+AdoFSwncStkol1mBLzS6r8aU9NJGq1unRz0yb +klw== X-Gm-Message-State: APjAAAVkxG/nQG16Vmi9qOPbxjKSimizCUbviIisFYkBWrO60Fceeb+b fFoc1YXkglKOw/A0Ed6BEv/1EAZf0DGQvIXO4+4= X-Google-Smtp-Source: APXvYqw6wN77A+HT9FvUk4s3pXXv5YOELWjEeMq1t/ZwIzPUIt/QBipcYchcap6MFYByTu+Pv1+Y1eiDU661H/L2iIg= X-Received: by 2002:adf:dbce:: with SMTP id e14mr4438124wrj.249.1555714143644; Fri, 19 Apr 2019 15:49:03 -0700 (PDT) MIME-Version: 1.0 References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <2B820FED-517F-401F-B7A4-88733892DA52@akamai.com> In-Reply-To: <2B820FED-517F-401F-B7A4-88733892DA52@akamai.com> From: Martin Duke Date: Fri, 19 Apr 2019 15:48:52 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: "Salz, Rich" Cc: "Brian Trammell (IETF)" , Gorry Fairhurst , Roberto Peon , Mirja Kuehlewind , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , "Border, John" Content-Type: multipart/alternative; boundary="000000000000e76e6e0586e9ecb9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 22:49:09 -0000 --000000000000e76e6e0586e9ecb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right. This is the exact use case that version greasing is supposed to avoid; i.e. a nontrivial amount of QUIC traffic greases, so middleboxes that do this kind of thing impose unacceptable performance penalties on users and don't make their way into the network. On Fri, Apr 19, 2019 at 12:59 PM Salz, Rich wrote: > *>*Can Brian (or anyone else) comment on what the threat model was that > caused middleboxes to drop TLS 1.3 when it used the actual version field? > > > > =E2=80=9Csafety=E2=80=9D > > > > Less flippantly, they didn=E2=80=99t understand the new version so they c= ould not > be sure it was okay to pass through, they didn=E2=80=99t know how to do c= ontent > inspection, TLS offload, etc. > > > --000000000000e76e6e0586e9ecb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right. This is the exact use case that version greasing is= supposed to avoid; i.e. a nontrivial amount of QUIC traffic greases, so mi= ddleboxes that do this kind of thing impose unacceptable performance penalt= ies on users and don't make their way into the network.

On Fri, Apr = 19, 2019 at 12:59 PM Salz, Rich <rsa= lz@akamai.com> wrote:

>Can= Brian (or anyone else) comment on what the threat model was that caused mi= ddleboxes to drop TLS 1.3 when it used the actual version field?<= /u>

=C2=A0

=E2=80=9Csafety=E2=80=9D

=C2=A0

Less flippantly, they didn=E2=80=99t understand the = new version so they could not be sure it was okay to pass through, they did= n=E2=80=99t know how to do content inspection, TLS offload, etc.<= /u>

=C2=A0

--000000000000e76e6e0586e9ecb9-- From nobody Fri Apr 19 19:00:24 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809EC1201B4 for ; Fri, 19 Apr 2019 19:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDdEEsfifdO3 for ; Fri, 19 Apr 2019 19:00:21 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 150FC1200B4 for ; Fri, 19 Apr 2019 19:00:20 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1CDC11B00243; Sat, 20 Apr 2019 03:00:08 +0100 (BST) Message-ID: <5CBA7D27.3050000@erg.abdn.ac.uk> Date: Sat, 20 Apr 2019 03:00:07 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Martin Duke CC: "Salz, Rich" , "Brian Trammell (IETF)" , Roberto Peon , Mirja Kuehlewind , =?UTF-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , "Border, John" Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <2B820FED-517F-401F-B7A4-88733892DA52@akamai.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 02:00:23 -0000 So... to check I understand that argument, it seems that some people expecs to see deployment of middleboxes that intercept QUIC - is that right? - if the middlebox doesn't exist, because it can't usefully add value, the version number does not need to be encrypted. - but if there are incentives to deploy middleboxes to do something (what?) then I could seee there could be a concern that these boxes could be implemented in a way that the implementers make them dependent on the version of QUIC. Gorry The first step is the part I don't understand, with TLS/TCP I understand the use-case existed. On 19/04/2019, 23:48, Martin Duke wrote: > Right. This is the exact use case that version greasing is supposed to > avoid; i.e. a nontrivial amount of QUIC traffic greases, so > middleboxes that do this kind of thing impose unacceptable performance > penalties on users and don't make their way into the network. > > On Fri, Apr 19, 2019 at 12:59 PM Salz, Rich > wrote: > > *>*Can Brian (or anyone else) comment on what the threat model was > that caused middleboxes to drop TLS 1.3 when it used the actual > version field? > > “safety” > > Less flippantly, they didn’t understand the new version so they > could not be sure it was okay to pass through, they didn’t know > how to do content inspection, TLS offload, etc. > From nobody Sat Apr 20 00:35:39 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9163B120099 for ; Sat, 20 Apr 2019 00:35: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 eNFgoQxPN3Qz for ; Sat, 20 Apr 2019 00:35:36 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 3493D120074 for ; Sat, 20 Apr 2019 00:35:36 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id h16so6254916ljg.11 for ; Sat, 20 Apr 2019 00:35:36 -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=P0C1Y+xpRI8uygEG1TzfEu180E/gufzc6Kj+TQI8Nc8=; b=qW4LF/kdZYLC0vXbDltB8NzhMTRjTRhlkt3VYl64T3SLesYAuewLeTznNOwcrIanmE 9NKFoXqGULAMQ5qDqM0AAQwflp0W59X1oAaXNHZ30sCX/W8PHMpGUYwmQDhjpQZ7Iv1u CLsgkXo5lbgdaMjjp8DpYtD9epzKy2dH+ywCdLZgYCZ5tW0YElZl7C32se/Z34vdlLVf Auhp+Dsz8u2oXpfBoO15ShmzTj48aWb4lVf2ksiB9N/IhAjLJs03VhzB/QD8R5QKU+xz wn07m/SJr58XI300Fi2yjTITp0Ua6qA6azkob8zjJCHTg9Ck7DjQcAqH/zsLt7x3fp7J fyAg== 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=P0C1Y+xpRI8uygEG1TzfEu180E/gufzc6Kj+TQI8Nc8=; b=nl/dMQgJuUMt0125u0cDdt511NSG/9VLo1NuwXi0MfFnz5xX6ACpzBRq/7sUCtxBa5 dWhSTWTSU0sR3UUpfv5waaGV6Tn8GesaibsEf/Jc1yV9KgIwcu7woBCVHATq0uqE5orH w5FAdHyiS1DHvV3rqOpoqiVEbwIXc44BbgXo9hR49/DyXWhDqcq3FLcbDE0c94SWlhvC A3OEM0oO/bl38deOcFN2akaqYqJswncevQ6FGxDkGSVzqcpigox87hQJd8UMdVFrcouP FbtJmXE//DHic78++uu2U9TxC5IWl+Q8V7ZIfn/xY3zQ3pDbax3Xl+SF4g9HOGyurLIj HJBg== X-Gm-Message-State: APjAAAWJNheYu3MGBvd150tdp/Ej4tEjeJcos/x+QnqEomAjB3jsbI46 2D7K5z7yFQAx1FyH+TCUhWcn7PsiI0ZSxppvHFM= X-Google-Smtp-Source: APXvYqx4EYk+/beHsWKoiuFSTk57Ut01DWMP+ygDmdQe3ugiLiztj0PPwC3jlzZXaJb5ZbeIya4uVIW3J3m+3ZTX11w= X-Received: by 2002:a2e:309:: with SMTP id 9mr4706021ljd.114.1555745734344; Sat, 20 Apr 2019 00:35:34 -0700 (PDT) MIME-Version: 1.0 References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <2B820FED-517F-401F-B7A4-88733892DA52@akamai.com> <5CBA7D27.3050000@erg.abdn.ac.uk> In-Reply-To: <5CBA7D27.3050000@erg.abdn.ac.uk> From: Watson Ladd Date: Sat, 20 Apr 2019 00:35:22 -0700 Message-ID: Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? To: "Gorry (erg)" Cc: Martin Duke , "Salz, Rich" , Roberto Peon , Mirja Kuehlewind , "Brian Trammell (IETF)" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , "Border, John" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 07:35:39 -0000 On Fri, Apr 19, 2019 at 7:00 PM Gorry Fairhurst wrot= e: > > So... to check I understand that argument, it seems that some people > expecs to see deployment of middleboxes that intercept QUIC - is that rig= ht? > > - if the middlebox doesn't exist, because it can't usefully add value, > the version number does not need to be encrypted. > - but if there are incentives to deploy middleboxes to do something > (what?) then I could seee there could be a concern that these boxes > could be implemented in a way that the implementers make them dependent > on the version of QUIC. The existence of the middlebox is sometimes a testament to the prowess of the sales team rather then the engineering team > > Gorry > > The first step is the part I don't understand, with TLS/TCP I understand > the use-case existed. > > On 19/04/2019, 23:48, Martin Duke wrote: > > Right. This is the exact use case that version greasing is supposed to > > avoid; i.e. a nontrivial amount of QUIC traffic greases, so > > middleboxes that do this kind of thing impose unacceptable performance > > penalties on users and don't make their way into the network. > > > > On Fri, Apr 19, 2019 at 12:59 PM Salz, Rich > > wrote: > > > > *>*Can Brian (or anyone else) comment on what the threat model was > > that caused middleboxes to drop TLS 1.3 when it used the actual > > version field? > > > > =E2=80=9Csafety=E2=80=9D > > > > Less flippantly, they didn=E2=80=99t understand the new version so = they > > could not be sure it was okay to pass through, they didn=E2=80=99t = know > > how to do content inspection, TLS offload, etc. > > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Apr 20 17:45:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E51120219 for ; Sat, 20 Apr 2019 17:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=VwfmN6eo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BbOWBydn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKyYOT5ZKGQS for ; Sat, 20 Apr 2019 17:45:22 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286F712016F for ; Sat, 20 Apr 2019 17:45:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 480A7530 for ; Sat, 20 Apr 2019 20:45:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 20 Apr 2019 20:45:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=VLQ7bDToHV0XvUeUfV9X1qVLzOYWVVM9CS3pN6uERO8=; b=VwfmN6eo rQemYo0uuC+Ypd4FzfC+1SzXK20kSheQVAcagaoY1c0JFw5VuEJSTwcfNWWctaSK AQ21Vza+nRnysS3q6Rj03LlOTV2HkvJo3hkGgJbayR822YDE7tl3XpcdOpec9IBv cFSMYCy3rRsDXw9Mugxw2bfbVaS96S7mNabZT0E/xfCRLlMpzfZwr+qRUYppqZd7 H2n4LTnfh6EozAitH6X9PpQHj1s2yabUiO3eUSfbVc7ZZBw3boVzLRTPqu3vbXfE 6dKumCSNchQWrhhmMKp+KXu2VF23yPJ4bUnJ/tjkJNj0xhhqthhW3GCcqvdZbw7j Yl/gNhjvnM0zQw== 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-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=VLQ7bDToHV0XvUeUfV9X1qVLzOYWV VM9CS3pN6uERO8=; b=BbOWBydnrJMRNwyUFsyOA75MlA+Rp9KeByB8czazKbWVV IfDeykkhTqj4nIHKcgD8qthMxhB2sxVUZL8Vjn/6mfZzvM6rM7aahLJPyoMdrrwD mKNwcvGPABxK5pLLvWzDSpGgkGpQoMSHOpeN3Ifx+hLvrDeCPvhfhS2KD4AcFoYF +qx7jO43y7ftqzGCPF+fJhzmDKZLTlK5g7BNE2lVxxm3zfcN2hjfnxtQ2n1kD3g5 9/Bt92xKLdm7Y+cx+KIiQlHnD1PhVRRC0FqGgKXm3CSJQDmJSJ/8fXSWoe1H7C8X tGstyFrfp9Gj79adsf5V8phRmGVsupdlLSdOJb+Sg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgedvgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepudduledrledrgeefrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 94E03103CB for ; Sat, 20 Apr 2019 20:45:18 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 7A0DBC7856 for ; Sun, 21 Apr 2019 00:45:15 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============5228284584058221563==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190421004515.7A0DBC7856@cloud.mnot.net> Date: Sun, 21 Apr 2019 00:45:15 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2019 00:45:26 -0000 --===============5228284584058221563== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+5/-11/=F0=9F=92=AC52) 5 issues created: - Clarify send state behavior for peer-created bidi stream (by agrover) https://github.com/quicwg/base-drafts/issues/2636 = - H3 GOAWAY should be symmetric and cover bidi and uni streams (by afrind) https://github.com/quicwg/base-drafts/issues/2632 = - Define under-utilization (by janaiyengar) https://github.com/quicwg/base-drafts/issues/2630 = - H3 GOAWAY guidance still refers to MAX_STREAM_ID (by LPardue) https://github.com/quicwg/base-drafts/issues/2629 = - HTTP/2 to HTTP/3 mapping section of http/3 is stale (by ianswett) https://github.com/quicwg/base-drafts/issues/2627 [-http] = 15 issues received 52 new comments: - #2580 Is path validation a SHOULD or a MUST -- pick one! (7 by janaiyen= gar, mikkelfj, larseggert, erickinnear, ianswett, igorlord) https://github.com/quicwg/base-drafts/issues/2580 [-transport] = - #2632 H3 GOAWAY should be symmetric and cover bidi and uni streams (7 b= y ianswett, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2632 [-http] = - #2582 Attacks Against Address Migration (6 by erickinnear, larseggert, = MikeBishop) https://github.com/quicwg/base-drafts/issues/2582 [-transport] = - #2629 H3 GOAWAY guidance still refers to MAX_STREAM_ID (5 by LPardue, d= tikhonov, afrind, MikeBishop) https://github.com/quicwg/base-drafts/issues/2629 = - #2534 ECN text disables ECN too aggressively (5 by mirjak, ianswett, ja= naiyengar, mikkelfj) https://github.com/quicwg/base-drafts/issues/2534 [-recovery] [-transpo= rt] [design] = - #2543 NEW_TOKEN token and encryption (5 by larseggert, kirsey, kazuho, = janaiyengar) https://github.com/quicwg/base-drafts/issues/2543 [-transport] [design] = - #2627 HTTP/2 to HTTP/3 mapping section of http/3 is stale (4 by MikeBis= hop, LPardue, ianswett) https://github.com/quicwg/base-drafts/issues/2627 [-http] = - #2434 Reserved versions are not version-dependent (3 by larseggert, mno= t, MikeBishop) https://github.com/quicwg/base-drafts/issues/2434 [-invariants] [-trans= port] = - #2587 Construction of address validation token (3 by kirsey, larseggert) https://github.com/quicwg/base-drafts/issues/2587 [-transport] = - #2545 MAX_PACKET_SIZE frame (2 by mnot, ianswett) https://github.com/quicwg/base-drafts/issues/2545 [-transport] = - #2607 RTT Initial measurement (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2607 [-recovery] [editoria= l] = - #2611 lost_pn can go negative (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2611 [-recovery] = - #2145 Don't change CID on peer CID change (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2145 [-transport] [design] = - #2541 Clients cannot abandon Initial packets while server can still sen= d initial close (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2541 [-transport] [design] = - #2551 Replace HTTP_MALFORMED_FRAME for something simpler (1 by LPardue) https://github.com/quicwg/base-drafts/issues/2551 [-http] [design] = 11 issues closed: - Don't change CID on peer CID change https://github.com/quicwg/base-draf= ts/issues/2145 [-transport] [design] = - lost_pn can go negative https://github.com/quicwg/base-drafts/issues/26= 11 [-recovery] = - Awkward text in "Sending Probe Packets" https://github.com/quicwg/base-= drafts/issues/2493 [-recovery] [editorial] = - H3 spec fails to warn about initial_max_stream_data_uni https://github.= com/quicwg/base-drafts/issues/2589 [-http] = - HTTP/3 unidirectional streams arms race https://github.com/quicwg/base-= drafts/issues/2559 [-http] [editorial] = - HTTP/2 to HTTP/3 mapping section of http/3 is stale https://github.com/= quicwg/base-drafts/issues/2627 [-http] = - Congestion control during application limited state https://github.com/= quicwg/base-drafts/issues/2554 [-recovery] [design] = - Crypto retx timeout should have higher priority than time based loss de= tection https://github.com/quicwg/base-drafts/issues/2565 [-recovery] = - Remember Fewer Transport Parameters for 0-RTT https://github.com/quicwg= /base-drafts/issues/2464 [-transport] [design] [has-proposal] = - HTTP/3 frame type registration render error https://github.com/quicwg/b= ase-drafts/issues/2549 [-http] [editorial] = - Construction of address validation token https://github.com/quicwg/base= -drafts/issues/2587 [-transport] = Pull requests ------------- * quicwg/base-drafts (+8/-12/=F0=9F=92=AC33) 8 pull requests submitted: - Stop requiring remote address to match during path validation (by erick= innear) https://github.com/quicwg/base-drafts/pull/2637 = - Targeted attacks in Security Considerations (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2635 [-transport] [editorial= ] = - Fix stale reference and edge case in GOAWAY text (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2634 [-http] [editorial] = - H2 comparison appendix spruce up (by LPardue) https://github.com/quicwg/base-drafts/pull/2633 = - -20 changelog (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2631 [editorial] = - Recommend of per-connection ID randomness for spin bit (by mirjak) https://github.com/quicwg/base-drafts/pull/2628 = - Use semicolons for section references (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2626 [editorial] = - Recovery release notes for draft 20 (by ianswett) https://github.com/quicwg/base-drafts/pull/2625 = 11 pull requests received 33 new comments: - #2573 introduce a version alias mechanism (10 by mikkelfj, marten-seema= nn, martinduke, MikeBishop) https://github.com/quicwg/base-drafts/pull/2573 [-transport] [design] = - #2621 lost_pn can no longer be negative (6 by mikkelfj, janaiyengar, ia= nswett) https://github.com/quicwg/base-drafts/pull/2621 [-recovery] [editorial] = - #2466 Bound 0-to-1-RTT Transition (3 by DavidSchinazi, janaiyengar, Mik= eBishop) https://github.com/quicwg/base-drafts/pull/2466 [-transport] [design] = - #2628 Recommend of per-connection ID randomness for spin bit (3 by mirj= ak, janaiyengar, MikeBishop) https://github.com/quicwg/base-drafts/pull/2628 [-transport] [design] = - #2501 Define Error when Empty Bits !=3D 0 (3 by martinduke, MikeBishop) https://github.com/quicwg/base-drafts/pull/2501 [-http] [design] = - #2613 Remove old spin bit references (2 by mirjak, larseggert) https://github.com/quicwg/base-drafts/pull/2613 = - #2624 Add details of marking packets lost on PTO (2 by janaiyengar, ian= swett) https://github.com/quicwg/base-drafts/pull/2624 [-recovery] [editorial] = - #2605 Reference RFC7661 for application limited (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2605 [-recovery] [design] = - #2623 My packet numbers go to -1 (1 by marten-seemann) https://github.com/quicwg/base-drafts/pull/2623 [-recovery] [editorial] = - #2631 -20 changelog (1 by ianswett) https://github.com/quicwg/base-drafts/pull/2631 [editorial] = - #1998 introduce a max_connection_ids transport parameter (1 by marten-s= eemann) https://github.com/quicwg/base-drafts/pull/1998 [-transport] [design] = 12 pull requests merged: - Recovery release notes for draft 20 https://github.com/quicwg/base-drafts/pull/2625 = - lost_pn can no longer be negative https://github.com/quicwg/base-drafts/pull/2621 [-recovery] [editorial] = - Add details of marking packets lost on PTO https://github.com/quicwg/base-drafts/pull/2624 [-recovery] [design] = - Remove old spin bit references https://github.com/quicwg/base-drafts/pull/2613 = - Define Error when Empty Bits !=3D 0 https://github.com/quicwg/base-drafts/pull/2501 [-http] [design] = - Add further guidance related to unidirectional stream TPs https://github.com/quicwg/base-drafts/pull/2612 [-http] [editorial] = - H2 comparison appendix spruce up https://github.com/quicwg/base-drafts/pull/2633 [-http] [editorial] = - Reference RFC7661 for application limited https://github.com/quicwg/base-drafts/pull/2605 [-recovery] [design] = - Refine Discussion of 0-RTT Transport Parameters https://github.com/quicwg/base-drafts/pull/2467 [-transport] [editorial= ] = - Clarify time threshold vs crypto timer https://github.com/quicwg/base-drafts/pull/2620 [-recovery] [editorial] = - Remove Unicode Character 'LEFT-TO-RIGHT OVERRIDE' (U+202D) https://github.com/quicwg/base-drafts/pull/2563 [-http] [editorial] = - Push stream data and PUSH_PROMISE reordering clarification https://github.com/quicwg/base-drafts/pull/2527 [-http] [editorial] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============5228284584058221563== 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 21, 2019

Issues

quicwg/base-drafts (+5/-11/=F0=9F=92=AC52)

5 issues created:

15 issues received 52 new comments:

11 issues closed:

Pull requests

quicwg/base-drafts (+8/-12/=F0=9F=92=AC33)

8 pull requests submitted:

11 pull requests received 33 new comments:

12 pull requests merged:

Repositories tracked by this digest:

--===============5228284584058221563==-- From nobody Mon Apr 22 09:14:05 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8103F120254 for ; Mon, 22 Apr 2019 09:13: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, 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 oPOtdDG7xLwr for ; Mon, 22 Apr 2019 09:13:55 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA2C120243 for ; Mon, 22 Apr 2019 09:13:54 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id t11so9339652lfl.12 for ; Mon, 22 Apr 2019 09:13:54 -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; bh=xTt7IfgdZdZUJ+IfRbBA8xQLFxtOs1TAtayKUC1Ojxk=; b=eQgkcsxpMCa+mVMZQjTi9KzwwT0kkTyL0h+zD/8fvKFE2o2ZDw4gGeKBdhCuNb8xrx Lhqv0ORMIOiNkboTzDdX5utNiEavvMZY3zmRY4LywjdA3+PxkCkcKQw2Tsw/HetZkbRa UX6ienSXqIv8f5Hhzp+CzoJQ6lDsg6SfY85lBuQA0dmhE1DHEjcv/PzA02dbAPONedFc OIZ6FVuxbUdcXu54Y+bcrm4vzfANGr/7sSeKigqi4eR1hOaVhSeq/qeTi2+/R5yQoqrm 75dAL9n9uuhYM0JQzVXtEzf2yZ1OLoeOJC6u8NBgQZFPqoIuUEw+BHOWcMumURcirXtF RNOA== 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=xTt7IfgdZdZUJ+IfRbBA8xQLFxtOs1TAtayKUC1Ojxk=; b=ilFIMYBsei7K0CZgXn24MfKpqf9vNkJl+BVt7N0/kGwTvOGK83FCyVP2k/8l+1eRS5 S46YuCs8jRgplEhRhCVBk42Y56Z86OaTSOex2ozRn/d24v03BsewHIJA+sglAkx0rIyy Jb6yNRsAFSWBbo2LwSdktF2WAV6tAS1Cq0aMiZmNMLWUk2MbBosqq7MZ7WUBSF7ZGR/4 rR7UYMmeWGDcpVgCrXH0SVctbDxpW91FhzC/7LMvlFHEqPSoU+BE5+i1w0soQ1z531KB 2WodgreNe6pf9GAfl7t1u5QtSWg/5HWuT2+M3ZFdT8U0UJglgCuZmmulQXMuSoBLtC4r w7DQ== X-Gm-Message-State: APjAAAWZ0xNZHxGGlMHZ0ADpRBGcOStw6OqD7SAh6kC++lfJ+vdjHRfh TLoqFwDMdEK6Ny4OQmMQGsRIECqwhTYfOlrhwtjShnNC X-Google-Smtp-Source: APXvYqzHSaalRdm1IUbiPx9aYzoPIxExsdBxD6Xa3FgG7SBc8SAZ5gYNydHQiJScC53HWGt1o+SY0N39m0cj1zynrTI= X-Received: by 2002:ac2:569a:: with SMTP id 26mr10734169lfr.7.1555949632516; Mon, 22 Apr 2019 09:13:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Mon, 22 Apr 2019 09:13:41 -0700 Message-ID: Subject: Re: Introducing MASQUE To: QUIC Content-Type: multipart/alternative; boundary="0000000000002278c9058720c152" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 16:14:04 -0000 --0000000000002278c9058720c152 Content-Type: text/plain; charset="UTF-8" Hi everyone, To follow up on this, we now have an IETF mailing list dedicated to MASQUE: masque@ietf.org We plan on continuing the conversation there, please join us if you're interested: https://www.ietf.org/mailman/listinfo/masque Thanks, David On Mon, Mar 18, 2019 at 12:51 PM David Schinazi wrote: > Hi QUIC enthusiasts, > > I'd like to share a draft I've recently uploaded: > https://tools.ietf.org/html/draft-schinazi-masque-00 > > It introduces MASQUE, a protocol for obfuscating a VPN server inside an > HTTP/3 web server. The proposal is pretty new so we'd love to hear some > opinions about it interacts with QUIC. > > We'll be presenting the draft in Prague - at secdispatch to review the > security aspects and in tsv-area to look into the transport impact. > > Thanks, > David > --0000000000002278c9058720c152 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ever= yone,

To follow up on this, we now have an IETF mailing = list dedicated to MASQUE:=C2=A0masque@ie= tf.org

We plan on continuing the conversation = there, please join us if you're interested:

Thanks,
David


On Mon, Mar 18, 2019 at 12:51 PM David Schinazi <= ;dschinazi.ietf@gmail.com&g= t; wrote:
Hi QUIC enthusiasts,

I'd like to share a = draft I've recently uploaded:

It introduce= s MASQUE, a protocol for obfuscating a VPN server inside an HTTP/3 web serv= er. The proposal is pretty new so we'd love to hear some opinions about= it interacts with QUIC.

We'll be presenting t= he draft in Prague - at secdispatch to review the security aspects and in t= sv-area to look into the transport impact.

Thanks,=
David



On 24 April 2019 at 08.06.31, Mikkel Fahn=C3=B8e J=C3=B8rge= nsen (mikkelfj@gmail.com) wrote:<= /p>

--000000000000d5a6540587408254-- From nobody Tue Apr 23 23:59:04 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4331201D7 for ; Tue, 23 Apr 2019 23:59: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, 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 kQS8t4GLzfCu for ; Tue, 23 Apr 2019 23:59:00 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE3F120111 for ; Tue, 23 Apr 2019 23:58:59 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x3O6wshq013774; Wed, 24 Apr 2019 08:58:54 +0200 Date: Wed, 24 Apr 2019 08:58:54 +0200 From: Willy Tarreau To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= Cc: IETF QUIC WG Subject: Re: PROXY protocol Message-ID: <20190424065854.GB13735@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 06:59:03 -0000 Hi Mikkel, On Tue, Apr 23, 2019 at 11:06:31PM -0700, Mikkel Fahne Jrgensen wrote: > Various cloud load balancers appear to be adding the PROXY protocol which > is a single line of text inserted in front of routed packets. > > https://blog.digitalocean.com/load-balancers-now-support-proxy-protocol/ > > I'm not deep into this issue, but it appears to also apply to binary > protocols. > > I wonder if there is something QUIC should address here in order to avoid > having to parse text headers routed packets. Well, if you want the original, it's here : https://www.haproxy.org/download/2.0/doc/proxy-protocol.txt As you see the text-only version was deprecated 5 years ago in favor of a binary one which is smaller, easier to parse and can be extended. Users want to have some TLS information transmitted with the header for example, which v2 supports but not v1. Since it is designed to be prepended to any payload, it would not be surprised if some QUIC implementations would manage to adapt it there. You would probably not want it for each packet though. A few years ago I've been asked to write a draft on it but sadly it went too low on my priority list so I never started this task :-/ I've found a list of products known for implementing it, I don't know if it's up to date : https://www.haproxy.com/blog/haproxy/proxy-protocol/ Hoping this helps, Willy From nobody Wed Apr 24 00:02:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CA41201EC for ; Wed, 24 Apr 2019 00:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=gjdLUYyD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oOgRZZdI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-202f5nCnHr for ; Wed, 24 Apr 2019 00:02:32 -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 201C31201D3 for ; Wed, 24 Apr 2019 00:02:32 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E9235221E9; Wed, 24 Apr 2019 03:02:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 24 Apr 2019 03:02:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=TkPtnpe94Ae7Wy6OYXcApvtsMSfI6C DRp4WFFyL9bjI=; b=gjdLUYyDtS5OYLIYGktHTgUF1MYGCUTG/pGgsXJbpriWt7 rg8n9meaSQPArVC4NMH8zy7v8B1zJcnX5t/+i8eA5l8TWfrYAAWb92s8XCwCMme6 h0OlnH/hb3sVcTGrYeEqx7bHWww/u/ooj6oEsCtieI+lOwoy5Zg1guS62PHbIJIw qqwKf7KK5RJ8kcayyiIxKSukNxPsKRoRb6tzGNKcFjC8Srg6fqhueyrv39eObik4 goUY2KUQlTqpvKBa58WyVrskMkjzO3zbFE+0Y74CNHZRXS1xvflfK59NPa2EnCa5 rjdUPesQzE3vAoDxSfJlTJBPcvofAYhvbn7zYQaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=TkPtnp e94Ae7Wy6OYXcApvtsMSfI6CDRp4WFFyL9bjI=; b=oOgRZZdIBvuLOrC0D4bQ9M J0KI3wYVwM6GuA7xhGxXxlO4d5woMXad1PoIHbNPczjUv2oirvsP12MdMSunwZfd 3VyoDa7jhX0oRfrgzXmS+kdmtrTuhRyS+nJjR3LvH64ROWatKvjSgXeAORX8b0b8 hCUYgr0m5MVCt9UqHpr4L/gibyrcZnANRC8aoz3Hb41Hrbmw4zpalVP9B1uhM63M NVGRkbgkpo80skt7mljEdmiq61gdmFTKnsXKTHJFvbYQd58Snl+UN1U+3TSVxlIp yLykc0VYdgdVnRe62XABkkvfj4R9O+6Xg+40BGknqGCpZ4SK1fIi7Kf8KvG9U/Uw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeelgdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from someonesproblem.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 1AB00103CC; Wed, 24 Apr 2019 03:02:27 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Consensus Call: endpoints don't know how many connection IDs the peer is willing to store #1994 Message-Id: <6660ECD9-CBFD-4980-8454-B595633CA30E@mnot.net> Date: Wed, 24 Apr 2019 17:02:25 +1000 Cc: Lars Eggert To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.8) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 07:02:34 -0000 Regarding: The editors believe that this PR resolved the issue: ....... and discussion so far seems to support consensus to do so. If = you object, please do so on the issue or in response to this message; = absent any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 24 00:02:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732BD120316 for ; Wed, 24 Apr 2019 00:02:41 -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 OzDGfsaUn4-X for ; Wed, 24 Apr 2019 00:02:38 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.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 58380120313 for ; Wed, 24 Apr 2019 00:02:38 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3O72YH7009504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Apr 2019 09:02:35 +0200 Received: from [IPv6:2a00:79e0:42:206:11ac:fb6e:206f:93e3] ([IPv6:2a00:79e0:42:206:11ac:fb6e:206f:93e3]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3O72YKn037660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Apr 2019 09:02:34 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: PROXY protocol From: "Brian Trammell (IETF)" In-Reply-To: Date: Wed, 24 Apr 2019 09:02:34 +0200 Cc: IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <2613919B-5463-4AB8-8A9D-56AA11E8362E@trammell.ch> References: To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.102.3) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 07:02:49 -0000 hi Mikkel, Thanks, I hadn't seen this. Looking at the description here, ISTM that this protocol is solely = applied between the front-end and the back-end within a provider, and = seems pretty strongly to assume the FE-BE protocol is HTTP/1.1.=20 Certainly someone will probably try to encap H2 or H3 in a plaintext = protocol like this one, and if they do that, well, it seems a form of = self-harm we're not well-placed to prevent. Martin Duke's load balancers draft could be expanded to provide a = QUIC-friendlier way to do the same thing (e.g. by encoding indexes to = metadata available by a third service in the CID), or if we really want = an encapsulation-based alternative (because it seems like PROXY will = deploy widely around QUIC regardless), then we can define one that has = less fiddly framing and the possibility to add encapsulation protection = between the FE and the BE. Cheers, Brian > On 24 Apr 2019, at 08:07, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: >=20 > some background >=20 > = https://blog.digitalocean.com/load-balancers-now-support-proxy-protocol/ >=20 >=20 > On 24 April 2019 at 08.06.31, Mikkel Fahn=C3=B8e J=C3=B8rgensen = (mikkelfj@gmail.com) wrote: >=20 >> Various cloud load balancers appear to be adding the PROXY protocol = which is a single line of text inserted in front of routed packets. >>=20 >> = https://blog.digitalocean.com/load-balancers-now-support-proxy-protocol/ >>=20 >> I=E2=80=99m not deep into this issue, but it appears to also apply to = binary protocols. >>=20 >> I wonder if there is something QUIC should address here in order to = avoid having to parse text headers routed packets. >>=20 >> For reverse proxy HTTP there is the X-Forwarded family of headers but = the PROXY protocol is for cases where this does not apply. >>=20 >> In particular, an application might want to know the original IP and = port of a QUIC connection before it passed through a load balancer, for = example for IP whitelisting. >>=20 >>=20 >> Mikkel From nobody Wed Apr 24 00:12:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5501202EB for ; Wed, 24 Apr 2019 00:12:05 -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, 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 k2qgOvIKEuWW for ; Wed, 24 Apr 2019 00:12:04 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 55457120089 for ; Wed, 24 Apr 2019 00:12:03 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x3O7BvaV013799; Wed, 24 Apr 2019 09:11:57 +0200 Date: Wed, 24 Apr 2019 09:11:57 +0200 From: Willy Tarreau To: "Brian Trammell (IETF)" Cc: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , IETF QUIC WG Subject: Re: PROXY protocol Message-ID: <20190424071157.GC13735@1wt.eu> References: <2613919B-5463-4AB8-8A9D-56AA11E8362E@trammell.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2613919B-5463-4AB8-8A9D-56AA11E8362E@trammell.ch> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 07:12:06 -0000 Hi Brian, On Wed, Apr 24, 2019 at 09:02:34AM +0200, Brian Trammell (IETF) wrote: > hi Mikkel, > > Thanks, I hadn't seen this. > > Looking at the description here, ISTM that this protocol is solely applied > between the front-end and the back-end within a provider, and seems pretty > strongly to assume the FE-BE protocol is HTTP/1.1. No in fact it was designed for anything TCP-based in part as a simpler alternative to Postfix's XCLIENT for dumb reverse proxies, and in order to work with HTTP as a first real use case, but it is quite used with SMTP and SQL. Please check the links I sent in the other e-mail in this thread. I find it a bit sad that DigitalOcean didn't put the references to the protocol's definition by the way. > Certainly someone will probably try to encap H2 or H3 in a plaintext protocol > like this one, and if they do that, well, it seems a form of self-harm we're > not well-placed to prevent. The v2 of the protocol dropped the plaintext approach. I'm not saying that it's the best solution for QUIC either, maybe we'll need to encode stuff that wasn't planned there or which would make the protocol inefficient for this stuff. Cheers, Willy From nobody Wed Apr 24 00:17:56 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6BE120308 for ; Wed, 24 Apr 2019 00:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y61aFHepVFYr for ; Wed, 24 Apr 2019 00:17:53 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40AB5120089 for ; Wed, 24 Apr 2019 00:17:53 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id m188so13819564ioa.9 for ; Wed, 24 Apr 2019 00:17:53 -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=2mDMY3Uo/SgiVQnKPLIkwQAnQjmoGU7fsTyi84N0lKo=; b=kvmlRDObMSlGhQipjqcvIEoGz1MsaKbSJEozx8TIpvnbEU+VdAh9Bbc2k620M9nJhf H+T87UPTb58uqGZ00/S6joXXfkWH7NeCTmy8gS85+5dxeAwzy+izDxUbfIt20DkNWyFU KLcbRk/U6y61s4uEWiOVk134OvOBGctFb/fD+lGGm1sXEWwhKTG62JdgRMmgnhciVPBn NN9LvS4q9JW7hA7zQmFdKGLDBOwByC1P32oyEf6qvrL7pxNngBdKp99AgdAivgWHMpuv IYrfjlfd8twyEeugxEP6dG9gig7dfTKZpYFcJPX4N8K9gMYW9NBxNHnbd0XQdWIrIiDr YPVQ== 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=2mDMY3Uo/SgiVQnKPLIkwQAnQjmoGU7fsTyi84N0lKo=; b=C3nTk/y4k+1O01i9+Dj8gpGiHqTnr5q9mUYIA9N1afFSozIlQ5zB3mL4yBjX5sV7Xj UPHOznDVXviMhFS34UEGFRf7RubDZgINzpWXsErTDKTiDVZBdLrwXPI1YN3E1zX8esFa gzvPmWfQvrM70urcsvmSuqkCt64Su/Bixh23kfsDEAEmcVc9bPP2AscrQFifYTlphd5t MRZuMGJ4fHQ0O3LVUJLWslonoC0ktimO2/eaQMwfjnKdB3ups9iuyj1oBdDG5+Cu63w5 UcafRo+5GyqDliWSRIrPBWbeMPIHhzce63hqAeWVWO6/8+j/ot0BHdCToYoc1uaJ9WtP JVsg== X-Gm-Message-State: APjAAAWPbyD1hE33petCgoz3feINF1ay80AZqZQYFZ46Wyp/8+3rBkzh 0T084QOjf0wNQND+UecPH8oWv4nYncXU0HJNdQ9hhw== X-Google-Smtp-Source: APXvYqwnhUcA5D0zJLzyjAGiDpm0T4DEyzPGjnryELkj4sYbJCLWvyZBY2Pw+HzEG5MIKYWuCSZzsTRh8W7AZ63OU88= X-Received: by 2002:a5e:df07:: with SMTP id f7mr20811956ioq.166.1556090272466; Wed, 24 Apr 2019 00:17:52 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Apr 2019 00:17:51 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <20190424065854.GB13735@1wt.eu> References: <20190424065854.GB13735@1wt.eu> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 24 Apr 2019 00:17:51 -0700 Message-ID: Subject: Re: PROXY protocol To: Willy Tarreau Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000edc9c10587417f7b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 07:17:55 -0000 --000000000000edc9c10587417f7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Perhaps QUIC should recommend load balancers that are QUIC aware to inject PROXY headers only for initial packets and that they should use the binary format and initial packets should allow space for such headers in the initial padding. Perhaps the 1200 byte requirement is already sufficient. The problem with this approach is that the detection of initial packets is version dependent and versions want to hide from the world, it seems. So this appears to tied to invariants. Tarreau covered what I was about to respond to Trammel on HTTP/1.1. As I also said before, X-Forwarded-* is already widely used in that scenario, and also for HTTPS TLS terminated at load balancer. Mikkel On 24 April 2019 at 08.58.57, Willy Tarreau (w@1wt.eu) wrote: Hi Mikkel, On Tue, Apr 23, 2019 at 11:06:31PM -0700, Mikkel Fahn=C3=B8e J=C3=B8rgensen= wrote: > Various cloud load balancers appear to be adding the PROXY protocol which > is a single line of text inserted in front of routed packets. > > https://blog.digitalocean.com/load-balancers-now-support-proxy-protocol/ > > I'm not deep into this issue, but it appears to also apply to binary > protocols. > > I wonder if there is something QUIC should address here in order to avoid > having to parse text headers routed packets. Well, if you want the original, it's here : https://www.haproxy.org/download/2.0/doc/proxy-protocol.txt As you see the text-only version was deprecated 5 years ago in favor of a binary one which is smaller, easier to parse and can be extended. Users want to have some TLS information transmitted with the header for example, which v2 supports but not v1. Since it is designed to be prepended to any payload, it would not be surprised if some QUIC implementations would manage to adapt it there. You would probably not want it for each packet though. A few years ago I've been asked to write a draft on it but sadly it went too low on my priority list so I never started this task :-/ I've found a list of products known for implementing it, I don't know if it's up to date : https://www.haproxy.com/blog/haproxy/proxy-protocol/ Hoping this helps, Willy --000000000000edc9c10587417f7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Perhaps QUIC should = recommend load balancers that are QUIC aware to inject
PROXY headers only for initial pa= ckets and that they should use the binary format
and initial packets should allow space = for such headers in the initial padding. Perhaps the 1200 byte requirement = is already sufficient.

So this appears = to tied to invariants.


Mikkel

On 24= April 2019 at 08.58.57, Willy Tarreau (w@1wt.e= u) wrote:

<= div>
Hi Mikkel,

On Tue, Apr 23, 2019 at 11:06:31PM -0700, Mikkel Fahn=C3=B8e J=C3=B8rge= nsen wrote:
> Various cloud load balancers appear to be adding the PROXY protoco= l which
> is a single line of text inserted in front of routed packets.
> =20
> https://blog.digitalocean.com/load-balancers-now-support= -proxy-protocol/
> =20
> I'm not deep into this issue, but it appears to also apply to = binary
> protocols.
> =20
> I wonder if there is something QUIC should address here in order t= o avoid
> having to parse text headers routed packets.

Well, if you want the original, it's here :

https://www.haproxy.org/download/2.0/doc/proxy-protocol.txt

As you see the text-only version was deprecated 5 years ago in favor of
a binary one which is smaller, easier to parse and can be extended. Use= rs
want to have some TLS information transmitted with the header for examp= le,
which v2 supports but not v1. Since it is designed to be prepended to a= ny
payload, it would not be surprised if some QUIC implementations would
manage to adapt it there. You would probably not want it for each packe= t
though.

A few years ago I've been asked to write a draft on it but sadly it= went
too low on my priority list so I never started this task :-/

I've found a list of products known for implementing it, I don'= t know if
it's up to date :

h= ttps://www.haproxy.com/blog/haproxy/proxy-protocol/

Hoping this helps,
Willy
--000000000000edc9c10587417f7b-- From nobody Wed Apr 24 00:21:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D141202FD for ; Wed, 24 Apr 2019 00:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MijJFt1TNtsu for ; Wed, 24 Apr 2019 00:21:25 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24563120089 for ; Wed, 24 Apr 2019 00:21:25 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id a190so4569284ite.4 for ; Wed, 24 Apr 2019 00:21: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 :cc; bh=K3+tEarNzBMAjIbrcEueZreT8FgjRASmsuGXBtEswpU=; b=vdL89kzqzipcrMu5y86MQzlryyvUR4B5OS4/jTBN2CJRtbsy5TXtzZPj0EqZ0bbk7n K5ZQKHrqp+oXc1UEduz1OiDLljozKnoYreqKMCf9RE38MF5eGAxWikzQ+yQqalK+dQvP klmZZdIqmul8McP/XVKS4H7xk1MzNgAt5ZGMiwOGL5oWgI56UEkJWGYH21aKi8pDmpId xXRbpcXYbwM5sf6admwgcGdOq4VFdelSSUfPVbdtluwk3kvtHp7aenrOyUgry6OlGOOo MaQkZfvHEd1kAnhfuginUDf1DS632HO/+nMa0Pj6mTcFlfKKZCNsKkHzna9l/XSDIV5H JAjA== 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=K3+tEarNzBMAjIbrcEueZreT8FgjRASmsuGXBtEswpU=; b=oXG+5jz9wsJiloIes88HEjMFFgMdGVAQ2DIZ0P97VOw35bLMsS5SMYpgBvrePGtDIs 6QAwDvQpFBNXlxdVaWtQm7/Dcv7c64zDGb5jv4eRsZeQHl8K8DYq9TpHpC1BG8nFP698 f5nVvZpZYUOgs6UVobESuUCcTkYjGYCuwK0vbfVdZR9g8UMq763aUS+I68nO5U63VODI lTkTD26BEppTJbDuu3ZAZ9kt2yd10/B2eHQVscX8fLQhS3IxrGk23rP3Oyxae1fvtIss 4p/vjPcSdPJ0602WsKek1UveiyMYBoS3J/kNNHtdxynfdel9NChuRS0zIdBNo0zau2pV Is7g== X-Gm-Message-State: APjAAAXjwvjNqY7jhwRP3bvgEoyDi4s+WVrPCnJ4My8iSUhrM+PRQMFm L/p5eMegtHdfDFFGlGRJoIU83OyM0on4BphRGRE= X-Google-Smtp-Source: APXvYqxYwDL0jCH5xQYqwfqBPGaANxqIZiNR4n3dJ7SKnV/Al1+ydb7F3FYlafYwKfLgngzIilU33L3iGOflc+3VB5U= X-Received: by 2002:a02:c043:: with SMTP id u3mr11739204jam.35.1556090484474; Wed, 24 Apr 2019 00:21:24 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Apr 2019 00:21:24 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20190424065854.GB13735@1wt.eu> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 24 Apr 2019 00:21:23 -0700 Message-ID: Subject: Re: PROXY protocol To: Willy Tarreau Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000090c8560587418cd8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 07:21:28 -0000 --00000000000090c8560587418cd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Google Cloud also uses the text version (version 1) of the PROXY protocol: https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#proxy-proto= col On 24 April 2019 at 09.17.51, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@g= mail.com) wrote: Perhaps QUIC should recommend load balancers that are QUIC aware to inject PROXY headers only for initial packets and that they should use the binary format and initial packets should allow space for such headers in the initial padding. Perhaps the 1200 byte requirement is already sufficient. The problem with this approach is that the detection of initial packets is version dependent and versions want to hide from the world, it seems. So this appears to tied to invariants. Tarreau covered what I was about to respond to Trammel on HTTP/1.1. As I also said before, X-Forwarded-* is already widely used in that scenario, and also for HTTPS TLS terminated at load balancer. Mikkel On 24 April 2019 at 08.58.57, Willy Tarreau (w@1wt.eu) wrote: Hi Mikkel, On Tue, Apr 23, 2019 at 11:06:31PM -0700, Mikkel Fahn=C3=B8e J=C3=B8rgensen= wrote: > Various cloud load balancers appear to be adding the PROXY protocol which > is a single line of text inserted in front of routed packets. > > https://blog.digitalocean.com/load-balancers-now-support-proxy-protocol/ > > I'm not deep into this issue, but it appears to also apply to binary > protocols. > > I wonder if there is something QUIC should address here in order to avoid > having to parse text headers routed packets. Well, if you want the original, it's here : https://www.haproxy.org/download/2.0/doc/proxy-protocol.txt As you see the text-only version was deprecated 5 years ago in favor of a binary one which is smaller, easier to parse and can be extended. Users want to have some TLS information transmitted with the header for example, which v2 supports but not v1. Since it is designed to be prepended to any payload, it would not be surprised if some QUIC implementations would manage to adapt it there. You would probably not want it for each packet though. A few years ago I've been asked to write a draft on it but sadly it went too low on my priority list so I never started this task :-/ I've found a list of products known for implementing it, I don't know if it's up to date : https://www.haproxy.com/blog/haproxy/proxy-protocol/ Hoping this helps, Willy --00000000000090c8560587418cd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Google Cloud also us= es the text version (version 1) of the PROXY protocol:



On 24 April 2019 at 09.17.51, Mikkel Fahn=C3=B8e J=C3=B8rgensen (<= a href=3D"mailto:mikkelfj@gmail.com">mikkelfj@gmail.com) wrote:

Perhaps QUIC should recommend load balancers that are QUIC aware to inject
PROXY headers only for initial packets and that they should use the binary format
and initial packets should allow space for such headers in the initial padding. Perhaps the 1200 byte requirement is already sufficient.

The problem with this approach is that the detection of initial packets is version dependent and versions want to hide from the world, it seems.
So this appears to tied to invariants.

Tarreau covered what I was about to respond to Trammel on HTTP/1.1. As I also said before, X-Forwarded-* is already widely used in that scenario, and also for HTTPS TLS terminated at load balancer.

Mikkel

On 24 April 2019 at 08.58.57, Willy Tarreau (w@1wt.eu) wrote:

Hi Mikkel,

On Tue, Apr 23, 2019 at 11:06:31PM -0700, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> Various cloud load balancers appear to be adding the PROXY protocol which
> is a single line of text inserted in front of routed packets.
>
> https://blog.digitalocean.com/load-balancers-now-support-proxy-pr= otocol/
>
> I'm not deep into this issue, but it appears to also apply to binary
> protocols.
>
> I wonder if there is something QUIC should address here in order to avoid
> having to parse text headers routed packets.

Well, if you want the original, it's here :

htt= ps://www.haproxy.org/download/2.0/doc/proxy-protocol.txt

As you see the text-only version was deprecated 5 years ago in favor of
a binary one which is smaller, easier to parse and can be extended. Users
want to have some TLS information transmitted with the header for example,
which v2 supports but not v1. Since it is designed to be prepended to any
payload, it would not be surprised if some QUIC implementations would
manage to adapt it there. You would probably not want it for each packet
though.

A few years ago I've been asked to write a draft on it but sadly it went
too low on my priority list so I never started this task :-/

I've found a list of products known for implementing it, I don't know if
it's up to date :

https://ww= w.haproxy.com/blog/haproxy/proxy-protocol/

Hoping this helps,
Willy
 --00000000000090c8560587418cd8-- From nobody Wed Apr 24 02:35:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62209120150 for ; Wed, 24 Apr 2019 02:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQH1LZMixYRj for ; Wed, 24 Apr 2019 02:35:21 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E42B120089 for ; Wed, 24 Apr 2019 02:35:21 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 83E281B000FD for ; Wed, 24 Apr 2019 10:35:18 +0100 (BST) Message-ID: <5CC02DD5.3040102@erg.abdn.ac.uk> Date: Wed, 24 Apr 2019 10:35:17 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: quic@ietf.org Subject: Comments on QUIC transport - draft-ietf-quic-transport-20 References: <2613919B-5463-4AB8-8A9D-56AA11E8362E@trammell.ch> In-Reply-To: <2613919B-5463-4AB8-8A9D-56AA11E8362E@trammell.ch> 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.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 09:35:24 -0000 I have just read QUIC transport, prior to doing a detailed read of the congestion control spec) and have a number of comments on the text and one more involved question on the decision on what to do with congestion control when there is a path change. I 'll send the latter issue later. (The editors can break these up into issues in the git if this seems useful to them). Gorry ————— The following comments/questions mainly relate to text: — NiT: Section 4: “ It is necessary to limit the amount of data that a receiver could buffer,” - Is this correct? (i.e. do we wish to limit what it can do or what it needs to buffer - is this a maximum limit or a minimal requirement? (I suspect the latter). --- Question: Section 4: “The implementation SHOULD provide an interface to QUIC to tell it about its buffering limits so that there is not excessive buffering at multiple layers.” - This seems an odd place to me to make a subtle new requirement on the IP-layer/interface: This lower-layer implementation interface requirement is buried in the spec. This seems that it could go unnoticed, and isn’t really a requirement of the protocol, but of the layer below. — Nit: Section 4: “that the sender receives an update before running out of flow control credit, even if one of the packets is lost.” - the requirement could be misread as ONLY one packet is lost, whereas I think it means if one or more packets are lost. — Nit: Section 4: “That is, once a receiver advertises an offset, it MAY advertise a smaller offset, but this has no effect.” - No effect on what? - presumably something at the sender? — Nit: Section 4: “Implementations might choose to increase limits as streams close to keep the number of streams available to peers roughly consistent.” - could this be changed to “are closed” or something to avoid misreading of the word “close”. — NiT: Section 5: “A Version Negotiation (Section 17.2.1) packet echoes the connection IDs selected by the client, both to ensure correct routing “: - not strictly routing? Isn’t this “forwarding”. (The word routing is used again in the section and in section 7.2 — Section 5: NiT: “different IP or port” - could you say: “different IP address or transport port” --- Section 5.1.1: NiT: “The connection ID randomly selected by the client in the Initial packet and any connection ID provided by a Retry packet are not assigned sequence numbers unless a server opts to retain them as its initial connection ID.” - could this sentence be simplified, it is hard to parse and long. (Or insert a comma) — Section 5.2: NiT: “ or - for servers -“ - what is the meaning of the minus signs? does it imply “particularly” or “only”, I was unsure. — Section 5.2.1: Nit: “Packets that don't match an existing connection are discarded.” - can we remove “don’t” and explain what does match? - Is this something like: “Packets with a Connection ID that does not match an existing connection are discarded.” --- Section 5.2.1: Nit: “Due to packet reordering or loss, clients might receive packets for a connection that are encrypted with a key it has not yet computed.” “ - Is it possible to say something like: “Packet reordering or loss, might cause a client to receive packets for a connection that were encrypted with a key that it has not yet computed.” — Section 8.1.2: - The title seems a little odd to me? Future? — Section 9.3.3.: ?: “ An off-path attacker that can observe packets might forward copies of genuine packets to endpoints. “ - This may make total sense to some people, but to me an “off path” observer has no access to the data on the path. Maybe someone could work this text in a way that doesn’t cause this confusion. — Section 9.3.3.: NiT: “If the copied packet arrives before the genuine packet, this will appear as a NAT rebinding.” I think the pathology is the same as a NAT rebinding, but it isn’t one. The text could be clear that this appears as if there had been a NAT rebidding? — Section 9.3.3.: ?: “The attack is more reliable “ - The term reliable does have certain implications in transport documents, if this isn’t intended could this phrased as a higher likelihood of success or something like that? - similarly “attack is reliably faster “ - explain how the path can be reliable, or please choose another word? — Issue: Section 10.4.2.: ?" “using a second iteration of a preimage-resistant function. - Maybe I am alone, but I did not understand what was intended by this, and where this was defined: is this I-D: --- Section 19.1: Question: “Padding can be used to increase an initial client packet to the minimum required size, or to provide protection against traffic analysis for protected packets.” - I suggest this also can be used to perform path packet probing in DPLPMTUD, and the text should somehow be improved to permit this. — Section 9.4: “The capacity available on the new path might not be the same as the old path.” - I disagree in the words here, because I think the normal IETF transport assumption is much stronger than “might”, and the draft should say something like: “The endpoint should not assume the capacity available on the new path isbe the same as the old path.” — Section 9.4: NiT: “On confirming a peer's ownership of its new address, an endpoint SHOULD immediately reset the congestion controller and round-trip time estimator for the new path.” - To be clear, does this reset require setting the CC to the initial value for a connection? — RFC2119: “A sender can make exceptions for probe packets” - Is that “MAY” - that would seem entirely reasonable. — “ While multiple paths might be used during connection migration, a single congestion control context and a single loss recovery context (as described in [QUIC-RECOVERY]) may be adequate. “ - I think the present I-D should not make these claims, because this seems like a CC decision. I actually do not understand this specific claim as currently presented. — Section 9.7: Ref: “The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the destination CID. “ - Please cite RFC3976 (which contains details on how to set flow labels).— — Section 12.3: NiT: “and acknowledged in packets which are also Initial packets” - Change /which/ to /that/. — Section 14.2: Ref: “An endpoint MUST NOT increase PMTU based on ICMP messages.” - please add citation to [RFC1191] [RFC8201], so the reader knows this is true of any protocol. — Section 21.2: Question: “ Once a connection is established QUIC endpoints might accept some unauthenticated ICMP packets (see Section 14.2), but the use of these packets is extremely limited. “ - Why is this a good idea, please explain what these would be used for? — Section 21.5: “ An adversarial sender might intentionally send fragments of stream data in order to cause disproportionate receive buffer memory commitment and/or creation of a large and inefficient data structure.” - Is this memory commitment at the target? (I assume so, but it would be easier to read if it said this). - From nobody Wed Apr 24 02:36:21 2019 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 64128120089; Wed, 24 Apr 2019 02:36: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-manageability-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <155609857433.32027.14061932842710023353@ietfa.amsl.com> Date: Wed, 24 Apr 2019 02:36:14 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 09:36:15 -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 : Manageability of the QUIC Transport Protocol Authors : Mirja Kuehlewind Brian Trammell Filename : draft-ietf-quic-manageability-04.txt Pages : 21 Date : 2019-04-24 Abstract: This document discusses manageability of the QUIC transport protocol, focusing on caveats impacting network operations involving QUIC traffic. Its intended audience is network operators, as well as content providers that rely on the use of QUIC-aware middleboxes, e.g. for load balancing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-manageability-04 https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-manageability-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 24 02:36:37 2019 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 BD1061203DB; Wed, 24 Apr 2019 02:36:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-applicability-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <155609858770.32117.2843733954066703634@ietfa.amsl.com> Date: Wed, 24 Apr 2019 02:36:27 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 09:36:35 -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 : Applicability of the QUIC Transport Protocol Authors : Mirja Kuehlewind Brian Trammell Filename : draft-ietf-quic-applicability-04.txt Pages : 15 Date : 2019-04-24 Abstract: This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC, and implementors of these application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-applicability-04 https://datatracker.ietf.org/doc/html/draft-ietf-quic-applicability-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-applicability-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 24 17:55:22 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5290A12026E for ; Wed, 24 Apr 2019 17:55:21 -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 F57GbkGn8W2b for ; Wed, 24 Apr 2019 17:55:18 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF641201D4 for ; Wed, 24 Apr 2019 17:55:18 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id j11so16144624lfm.0 for ; Wed, 24 Apr 2019 17:55:18 -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=hQneddQJDhDOkcrjwR6s08cocME574J4mW4gjKKf+es=; b=ZfFhoynuaVOjtufphFzjX0yRzKPfPmUoinRg4uc7nprIqlAdwW4LO73uwpC4rdI7az zRxJTd5CEyaoGmmnMNK7TBKXgE3RU8bfqmbkYIY0aOlvvj2rrI4rlFljS5szStOH+fpZ RNS3unL8N9KRQLecC7Tl6EWceJwl9Kxg1nsYoLCBnhe+EId4VUPhiOmcN1GEbwahWE0S 4fbvv88R4eWAwa0fYzjBQ9hQpkaj7wPDhSxWG6GQcSosmPUHkUMMtl6iOWR3ZGAqEgxn n6t9Qo3yKCoFmX1eDp9hhLMrHkNs0LBekBIWx6tfpYQNIslV+l5V/1Hrzaoe2dy+jZzC oyxg== 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=hQneddQJDhDOkcrjwR6s08cocME574J4mW4gjKKf+es=; b=Xs6vr0IwcG7gtil/gcNYODFPBF/tCBxVtIJVFPrrho91OKcXty8J3S4TLqwAB39kL1 W0tiux5+gIDvN9zEyzjEEkuJ5F+CVEGRon5FySWyKAanv52yOXGKjzKgonRtqAkcfu8/ wiPZhTJrALUwl4YMUkHsQxxFa34N5JdHY4tbf8Wy9kn8E2XbeM7+QwIdnwxGYeh6sZpA FXnYrczyE1bhGjxvJ56SgKGgqpom06Zis772lqkBPZSbMU7OLQySgNuLZQUFZgwq/TZ4 d5ZQHalTuUjpvSxYx/s2KyrTx+wRZd5LEVTXhSh8aINBrKoRb7cyE0YPEYWgBIBlVlgf P+bw== X-Gm-Message-State: APjAAAUudfIs4w6OxZA/wF/b1eZMpzRMobzV3Pz/yZYsfAFShDTm5U+e DjR57EGZHnHvqLWzR146UPkU9rr7nzYyj/ITlrjkc2nL X-Google-Smtp-Source: APXvYqws2yL9/5u88W8X2OKGSrWEAnyMISAzjSGY9KufJGs0g0JImCCBuXGO6vC831fcxAQpuGPTI3t/ZJ51UFalNkA= X-Received: by 2002:a19:c38d:: with SMTP id t135mr18826894lff.164.1556153716131; Wed, 24 Apr 2019 17:55:16 -0700 (PDT) MIME-Version: 1.0 References: <2613919B-5463-4AB8-8A9D-56AA11E8362E@trammell.ch> <5CC02DD5.3040102@erg.abdn.ac.uk> In-Reply-To: <5CC02DD5.3040102@erg.abdn.ac.uk> From: Jana Iyengar Date: Thu, 25 Apr 2019 09:55:05 +0900 Message-ID: Subject: Re: Comments on QUIC transport - draft-ietf-quic-transport-20 To: gorry@erg.abdn.ac.uk Cc: QUIC WG Content-Type: multipart/alternative; boundary="000000000000774ae90587504589" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 00:55:21 -0000 --000000000000774ae90587504589 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your detailed read, Gorry, will respond soon. On Wed, Apr 24, 2019 at 6:35 PM Gorry Fairhurst wrote: > > I have just read QUIC transport, prior to doing a detailed read of the > congestion control spec) and have a number of comments on the text and > one more involved question on the decision on what to do with congestion > control when there is a path change. I 'll send the latter issue later. > (The editors can break these up into issues in the git if this seems > useful to them). > > Gorry > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > The following comments/questions mainly relate to text: > =E2=80=94 > NiT: Section 4: > =E2=80=9C It is necessary to limit the amount of data that a receiver cou= ld > buffer,=E2=80=9D > - Is this correct? (i.e. do we wish to limit what it can do or what it > needs to buffer - is this a maximum limit or a minimal requirement? (I > suspect the latter). > --- > Question: Section 4: > =E2=80=9CThe implementation SHOULD provide an interface to QUIC to tell= it > about its buffering limits so that there is not excessive buffering > at multiple layers.=E2=80=9D > - This seems an odd place to me to make a subtle new requirement on the > IP-layer/interface: This lower-layer implementation interface > requirement is buried in the spec. This seems that it could go > unnoticed, and isn=E2=80=99t really a requirement of the protocol, but of= the > layer below. > =E2=80=94 > Nit: Section 4: > =E2=80=9Cthat the sender receives an update before running out of flow= control > credit, even if one of the packets is lost.=E2=80=9D > - the requirement could be misread as ONLY one packet is lost, whereas I > think it means if one or more packets are lost. > =E2=80=94 > Nit: Section 4: > =E2=80=9CThat is, once a receiver > advertises an offset, it MAY advertise a smaller offset, but this has > no effect.=E2=80=9D > - No effect on what? - presumably something at the sender? > =E2=80=94 > Nit: Section 4: > =E2=80=9CImplementations might choose to increase limits as > streams close to keep the number of streams available to peers > roughly consistent.=E2=80=9D > - could this be changed to =E2=80=9Care closed=E2=80=9D or something to a= void misreading > of the word =E2=80=9Cclose=E2=80=9D. > =E2=80=94 > NiT: Section 5: > =E2=80=9CA Version Negotiation (Section 17.2.1) packet echoes the connect= ion > IDs selected by the client, both to ensure correct routing =E2=80=9C: > - not strictly routing? Isn=E2=80=99t this =E2=80=9Cforwarding=E2=80=9D. = (The word routing is > used again in the section and in section 7.2 > =E2=80=94 > Section 5: > NiT: =E2=80=9Cdifferent IP or port=E2=80=9D > - could you say: > =E2=80=9Cdifferent IP address or transport port=E2=80=9D > --- > Section 5.1.1: > NiT: =E2=80=9CThe connection > ID randomly selected by the client in the Initial packet and any > connection ID provided by a Retry packet are not assigned sequence > numbers unless a server opts to retain them as its initial connection > ID.=E2=80=9D > - could this sentence be simplified, it is hard to parse and long. (Or > insert a comma) > =E2=80=94 > Section 5.2: > NiT: =E2=80=9C or - for servers -=E2=80=9C > - what is the meaning of the minus signs? does it imply =E2=80=9Cparticul= arly=E2=80=9D > or =E2=80=9Conly=E2=80=9D, I was unsure. > =E2=80=94 > Section 5.2.1: > Nit: =E2=80=9CPackets that don't match an existing connection are discard= ed.=E2=80=9D > - can we remove =E2=80=9Cdon=E2=80=99t=E2=80=9D and explain what does mat= ch? > - Is this something like: =E2=80=9CPackets with a Connection ID that does= not > match an existing > connection are discarded.=E2=80=9D > --- > Section 5.2.1: > Nit: =E2=80=9CDue to packet reordering or loss, clients might receive pac= kets for a > connection that are encrypted with a key it has not yet computed.=E2= =80=9D > =E2=80=9C > - Is it possible to say something like: =E2=80=9CPacket reordering or los= s, > might cause a client to receive packets for a connection that were > encrypted with a key that it has not yet computed.=E2=80=9D > =E2=80=94 > Section 8.1.2: > - The title seems a little odd to me? Future? > =E2=80=94 > Section 9.3.3.: > ?: =E2=80=9C An off-path attacker that can observe packets might forward = copies of > genuine packets to endpoints. =E2=80=9C > - This may make total sense to some people, but to me an =E2=80=9Coff pat= h=E2=80=9D > observer has no access to the data on the path. Maybe someone could work > this text in a way that doesn=E2=80=99t cause this confusion. > =E2=80=94 > Section 9.3.3.: > NiT: =E2=80=9CIf the copied packet arrives before > the genuine packet, this will appear as a NAT rebinding.=E2=80=9D > I think the pathology is the same as a NAT rebinding, but it isn=E2=80=99= t one. > The text could be clear that this appears as if there had been a NAT > rebidding? > =E2=80=94 > Section 9.3.3.: > ?: =E2=80=9CThe attack is more reliable =E2=80=9C > - The term reliable does have certain implications in transport > documents, if this isn=E2=80=99t intended could this phrased as a higher > likelihood of success or something like that? > - similarly =E2=80=9Cattack is reliably faster =E2=80=9C > - explain how the path can be reliable, or please choose another word? > =E2=80=94 > Issue: Section 10.4.2.: > ?" =E2=80=9Cusing a second iteration of a preimage-resistant function. > - Maybe I am alone, but I did not understand what was intended by this, > and where this was defined: is this I-D: > --- > Section 19.1: > Question: =E2=80=9CPadding can be used to > increase an initial client packet to the minimum required size, or to > provide protection against traffic analysis for protected packets.=E2= =80=9D > - I suggest this also can be used to perform path packet probing in > DPLPMTUD, and the text should somehow be improved to permit this. > =E2=80=94 > Section 9.4: > =E2=80=9CThe capacity available on the new path might not be the same as = the > old path.=E2=80=9D > - I disagree in the words here, because I think the normal IETF > transport assumption is much stronger than =E2=80=9Cmight=E2=80=9D, and t= he draft should > say something like: > =E2=80=9CThe endpoint should not assume the capacity available on the new= path > isbe the same as the > old path.=E2=80=9D > =E2=80=94 > Section 9.4: > NiT: =E2=80=9COn confirming a peer's ownership of its new address, an end= point > SHOULD immediately reset the congestion controller and round-trip > time estimator for the new path.=E2=80=9D > - To be clear, does this reset require setting the CC to the initial > value for a connection? > =E2=80=94 > RFC2119: =E2=80=9CA sender can make exceptions for probe packets=E2=80= =9D > - Is that =E2=80=9CMAY=E2=80=9D - that would seem entirely reasonable. > =E2=80=94 > =E2=80=9C While multiple paths might be used during connection migratio= n, a > single congestion control context and a single loss recovery context > (as described in [QUIC-RECOVERY]) may be adequate. =E2=80=9C > - I think the present I-D should not make these claims, because this > seems like a CC decision. I actually do not understand this specific > claim as currently presented. > =E2=80=94 > Section 9.7: > Ref: =E2=80=9CThe IPv6 flow label SHOULD be a pseudo-random function of t= he source > and destination addresses, source and destination UDP ports, and the > destination CID. =E2=80=9C > - Please cite RFC3976 (which contains details on how to set flow labels).= =E2=80=94 > =E2=80=94 > Section 12.3: > NiT: =E2=80=9Cand acknowledged in packets which are also Initial packets= =E2=80=9D > - Change /which/ to /that/. > =E2=80=94 > Section 14.2: > Ref: =E2=80=9CAn endpoint MUST NOT increase PMTU based on ICMP messages.= =E2=80=9D > - please add citation to [RFC1191] [RFC8201], so the reader knows this > is true of any protocol. > =E2=80=94 > Section 21.2: > Question: =E2=80=9C Once a connection is established QUIC endpoints mig= ht > accept some > unauthenticated ICMP packets (see Section 14.2), but the use of these > packets is extremely limited. =E2=80=9C > - Why is this a good idea, please explain what these would be used for? > =E2=80=94 > Section 21.5: > =E2=80=9C An adversarial sender might intentionally send fragments of s= tream > data in order to cause disproportionate receive buffer memory > commitment and/or creation of a large and inefficient data structure.= =E2=80=9D > - Is this memory commitment at the target? (I assume so, but it would be > easier to read if it said this). > - > > > --000000000000774ae90587504589 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your detailed read, Gorry, will respond soon.
On= Wed, Apr 24, 2019 at 6:35 PM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:

I have just read QUIC transport, prior to doing a detailed read of the
congestion control spec) and have a number of comments on the text and
one more involved question on the decision on what to do with congestion control when there is a path change. I 'll send the latter issue later.=
(The editors can break these up into issues in the git if this seems
useful to them).

Gorry

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
The following comments/questions mainly relate to text:
=E2=80=94
NiT: Section 4:
=E2=80=9C It is necessary to limit the amount of data that a receiver could=
=C2=A0 =C2=A0 buffer,=E2=80=9D
- Is this correct? (i.e. do we wish to limit what it can do or what it
needs to buffer - is this a maximum limit or a minimal requirement? (I
suspect the latter).
---
Question: Section 4:
=C2=A0 =E2=80=9CThe implementation SHOULD provide an interface to QUIC to t= ell it
=C2=A0 =C2=A0 about its buffering limits so that there is not excessive buf= fering
=C2=A0 =C2=A0 at multiple layers.=E2=80=9D
- This seems an odd place to me to make a subtle new requirement on the IP-layer/interface: This lower-layer implementation interface
requirement is buried in the spec. This seems that it could go
unnoticed, and isn=E2=80=99t really a requirement of the protocol, but of t= he
layer below.
=E2=80=94
Nit: Section 4:
=C2=A0 =C2=A0=E2=80=9Cthat the sender receives an update before running out= of flow control
=C2=A0 =C2=A0 credit, even if one of the packets is lost.=E2=80=9D
- the requirement could be misread as ONLY one packet is lost, whereas I think it means if one or more packets are lost.
=E2=80=94
Nit: Section 4:
=C2=A0 =E2=80=9CThat is, once a receiver
=C2=A0 =C2=A0 advertises an offset, it MAY advertise a smaller offset, but = this has
=C2=A0 =C2=A0 no effect.=E2=80=9D
- No effect on what? - presumably something at the sender?
=E2=80=94
Nit: Section 4:
=C2=A0 =C2=A0=E2=80=9CImplementations might choose to increase limits as =C2=A0 =C2=A0 streams close to keep the number of streams available to peer= s
=C2=A0 =C2=A0 roughly consistent.=E2=80=9D
- could this be changed to =E2=80=9Care closed=E2=80=9D or something to avo= id misreading
of the word =E2=80=9Cclose=E2=80=9D.
=E2=80=94
NiT: Section 5:
=E2=80=9CA Version Negotiation (Section 17.2.1) packet echoes the connectio= n
=C2=A0 =C2=A0 IDs selected by the client, both to ensure correct routing = =E2=80=9C:
- not strictly routing? Isn=E2=80=99t this =E2=80=9Cforwarding=E2=80=9D. (T= he word routing is
used again in the section and in section 7.2
=E2=80=94
Section 5:
NiT: =E2=80=9Cdifferent IP or port=E2=80=9D
- could you say:
=E2=80=9Cdifferent IP address or transport port=E2=80=9D
---
Section 5.1.1:
NiT: =E2=80=9CThe connection
=C2=A0 =C2=A0 ID randomly selected by the client in the Initial packet and = any
=C2=A0 =C2=A0 connection ID provided by a Retry packet are not assigned seq= uence
=C2=A0 =C2=A0 numbers unless a server opts to retain them as its initial co= nnection
=C2=A0 =C2=A0 ID.=E2=80=9D
- could this sentence be simplified, it is hard to parse and long. (Or
insert a comma)
=E2=80=94
Section 5.2:
NiT: =E2=80=9C=C2=A0 or - for servers -=E2=80=9C
- what is the meaning of the minus signs? does it imply =E2=80=9Cparticular= ly=E2=80=9D
or =E2=80=9Conly=E2=80=9D, I was unsure.
=E2=80=94
Section 5.2.1:
Nit: =E2=80=9CPackets that don't match an existing connection are disca= rded.=E2=80=9D
- can we remove =E2=80=9Cdon=E2=80=99t=E2=80=9D and explain what does match= ?
- Is this something like: =E2=80=9CPackets with a Connection ID that does n= ot
match an existing
=C2=A0 =C2=A0 connection are discarded.=E2=80=9D
---
Section 5.2.1:
Nit: =E2=80=9CDue to packet reordering or loss, clients might receive packe= ts for a
=C2=A0 =C2=A0 connection that are encrypted with a key it has not yet compu= ted.=E2=80=9D
=E2=80=9C
- Is it possible to say something like: =E2=80=9CPacket reordering or loss,=
might cause a client=C2=A0 to receive packets for a connection that were encrypted with a key that it has not yet computed.=E2=80=9D
=E2=80=94
Section 8.1.2:
- The title seems a little odd to me? Future?
=E2=80=94
Section 9.3.= 3.:
?: =E2=80=9C An off-path attacker that can observe packets might forward co= pies of
=C2=A0 =C2=A0 genuine packets to endpoints.=C2=A0 =E2=80=9C
- This may make total sense to some people, but to me an =E2=80=9Coff path= =E2=80=9D
observer has no access to the data on the path. Maybe someone could work this text in a way that doesn=E2=80=99t cause this confusion.
=E2=80=94
=C2=A0 Section 9.3.3.:
NiT: =E2=80=9CIf the copied packet arrives before
=C2=A0 =C2=A0 the genuine packet, this will appear as a NAT rebinding.=E2= =80=9D
I think the pathology is the same as a NAT rebinding, but it isn=E2=80=99t = one.
The text could be clear that this appears as if there had been a NAT
rebidding?
=E2=80=94
Section 9.3.= 3.:
?: =E2=80=9CThe attack is more reliable =E2=80=9C
- The term reliable does have certain implications in transport
documents, if this isn=E2=80=99t intended could this phrased as a higher likelihood of success or something like that?
- similarly =E2=80=9Cattack is reliably faster =E2=80=9C
- explain how the path can be reliable, or please choose another word?
=E2=80=94
Issue: Section 10.4.2.:
?" =E2=80=9Cusing a second iteration of a preimage-resistant function.=
- Maybe I am alone, but I=C2=A0 did not understand what was intended by thi= s,
and where this was defined: is this I-D:
---
Section 19.1:
Question: =E2=80=9CPadding can be used to
=C2=A0 =C2=A0 increase an initial client packet to the minimum required siz= e, or to
=C2=A0 =C2=A0 provide protection against traffic analysis for protected pac= kets.=E2=80=9D
- I suggest this also can be used to perform path packet probing in
DPLPMTUD, and the text should somehow be improved to permit this.
=E2=80=94
Section 9.4:
=E2=80=9CThe capacity available on the new path might not be the same as th= e
=C2=A0 =C2=A0 old path.=E2=80=9D
- I disagree in the words here, because I think the normal IETF
transport assumption is much stronger than =E2=80=9Cmight=E2=80=9D, and the= draft should
say something like:
=E2=80=9CThe endpoint should not assume the capacity available on the new p= ath
isbe the same as the
=C2=A0 =C2=A0 old path.=E2=80=9D
=E2=80=94
Section 9.4:
NiT: =E2=80=9COn confirming a peer's ownership of its new address, an e= ndpoint
=C2=A0 =C2=A0 SHOULD immediately reset the congestion controller and round-= trip
=C2=A0 =C2=A0 time estimator for the new path.=E2=80=9D
- To be clear, does this reset require setting the CC to the initial
value for a connection?
=E2=80=94
RFC2119:=C2=A0 =E2=80=9CA sender can make exceptions for probe packets=E2= =80=9D
- Is that =E2=80=9CMAY=E2=80=9D - that would seem entirely reasonable.
=E2=80=94
=E2=80=9C=C2=A0 =C2=A0While multiple paths might be used during connection = migration, a
=C2=A0 =C2=A0 single congestion control context and a single loss recovery = context
=C2=A0 =C2=A0 (as described in [QUIC-RECOVERY]) may be adequate. =E2=80=9C<= br> - I think the present I-D should not make these claims, because this
seems like a CC decision. I actually do not understand this specific
claim as currently presented.
=E2=80=94
Section 9.7:
Ref: =E2=80=9CThe IPv6 flow label SHOULD be a pseudo-random function of the= source
=C2=A0 =C2=A0 and destination addresses, source and destination UDP ports, = and the
=C2=A0 =C2=A0 destination CID. =E2=80=9C
- Please cite RFC3976 (which contains details on how to set flow labels).= =E2=80=94
=E2=80=94
Section 12.3:
NiT: =E2=80=9Cand acknowledged in packets which are also Initial packets=E2= =80=9D
- Change /which/ to /that/.
=E2=80=94
Section 14.2:
Ref: =E2=80=9CAn endpoint MUST NOT increase PMTU based on ICMP messages.=E2= =80=9D
- please add citation to=C2=A0 [RFC1191] [RFC8201], so the reader knows thi= s
is true of any protocol.
=E2=80=94
Section 21.2:
Question: =E2=80=9C=C2=A0 =C2=A0Once a connection is established QUIC endpo= ints might
accept some
=C2=A0 =C2=A0 unauthenticated ICMP packets (see Section 14.2), but the use = of these
=C2=A0 =C2=A0 packets is extremely limited. =E2=80=9C
- Why is this a good idea, please explain what these would be used for?
=E2=80=94
Section 21.5:
=E2=80=9C=C2=A0 =C2=A0An adversarial sender might intentionally send fragme= nts of stream
=C2=A0 =C2=A0 data in order to cause disproportionate receive buffer memory=
=C2=A0 =C2=A0 commitment and/or creation of a large and inefficient data st= ructure.=E2=80=9D
- Is this memory commitment at the target? (I assume so, but it would be easier to read if it said this).
-


--000000000000774ae90587504589-- From nobody Thu Apr 25 04:17:14 2019 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 111301200A2; Thu, 25 Apr 2019 04:17:12 -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: magnus.westerlund@ericsson.com, lars@eggert.org, quic@ietf.org, quic-chairs@ietf.org Subject: quic - New Meeting Session Request for IETF 105 X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155619103203.23467.14429090916385218907.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2019 04:17:12 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 11:17:12 -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 Hours, 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm iccrg httpbis tls Second Priority: saag rtcweb People who must be present: Sean Turner Mark Nottingham Magnus Westerlund Jana Iyengar Martin Thomson Brian Trammell Mirja Kuehlewind 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. Please avoid colliding with all BOFs. --------------------------------------------------------- From nobody Thu Apr 25 23:49:27 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0012F120137 for ; Thu, 25 Apr 2019 23:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BarKvnoQVUa1 for ; Thu, 25 Apr 2019 23:49:24 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6011120106 for ; Thu, 25 Apr 2019 23:49:23 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 8F1C1400E6 for ; Fri, 26 Apr 2019 09:49:21 +0300 (EEST) Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id E834A88BC6A for ; Fri, 26 Apr 2019 09:48:22 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_D7486042-3B5C-4512-B09F-E4247111A33A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Consensus Call: client should send PING in Initial or Handshake, but PINGs are forbidden in these packets Message-Id: <90528B66-48F6-4788-AE0E-9EF141592476@eggert.org> Date: Fri, 26 Apr 2019 09:48:22 +0300 To: QUIC IETF mailing list X-MailScanner-ID: E834A88BC6A.A2CFE X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 06:49:26 -0000 --Apple-Mail=_D7486042-3B5C-4512-B09F-E4247111A33A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Regarding: The editors believe that this PR resolved the issue: ...and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. Regards, Lars (for the chairs) --Apple-Mail=_D7486042-3B5C-4512-B09F-E4247111A33A 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAlzCqbYACgkQHbmKvSnu NPhsUBAAjJh1Z1JnAaJuuWqOg7zQC5TBNNRneJTGU8shTk+UJR07CVCu2zVgrpFe WHbKfZLjIc1l1QO2E7BT/ILN3NcgmAIw1H65SFwxz98qnFPO1TT9JaI/a0Q11Zzg rkUApcQmnfU/KZFLvXuZ9zuAYHYeLwrVNuMC+YStMZ5PnBFxeX/Eu7nmmmEYSwG3 vLfjxK2NFj3yIX4j9eHDmsLMkcMYd0M+x0d0X7dmF/FeTe1Nn7maPupzwynZBS1K 8v1U/r5dbAwSPPXR4zmEpU0YWqhZ7yQmd4F2Xn3+Ew4dqmtvvsqJFgvarW8WzEq4 9iXYKge1Q+ToZ8fzjPB/5+OdFuPhPcc/z7Nb3lJz7P3tq2jilgZ/ql8XgPHl/VY7 zbW21wbyx7b3gA1PbeaND10O9aWBtZUWNlrhRJiEQyQPNZWzQRIvLjSkCFJ8HISC L+jlFyB1eInwvK72HqLmYdOaJN3GYuuXn26IFO+gwIHPDi7s+J/Kx+AoQ2cP+nXp KKpo7UI9HEKpe1OT+j0XKvtFnfXba6416zC/0/T4EpegTHrkHJkCvYq1iwD/bN82 0Ihm/aRgXeardIrrVp3ZKfc/FnTtFL+lKNvvaq3rz37nDGOLB9Pf9I3yIOs7/4Qf 1nwmH5Hj3ct64A/5L1zCMJPSfLujXKrl51zczOm4kxFvTARJy7g= =3B2e -----END PGP SIGNATURE----- --Apple-Mail=_D7486042-3B5C-4512-B09F-E4247111A33A-- From nobody Fri Apr 26 14:43:16 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AA6120483 for ; Fri, 26 Apr 2019 14:43: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, 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 tceODEWYJ8dQ for ; Fri, 26 Apr 2019 14:43:12 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A141200EF for ; Fri, 26 Apr 2019 14:43:11 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id r6so6309535wrm.4 for ; Fri, 26 Apr 2019 14:43:11 -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=QkQilZcIQmpQyCXV4YKdPFrA4ifPoLyZ256r+lHiI64=; b=A1J3ic2OMn4DQYMCyvmjevnY2+6MyrtSSjSeRD0kpyF0Eb6r4Qzn5QwGR0RUu4L9Rj WqB3rq+yY9UGtIxt+FvvUOFpDst93u82iFpiyAQlCPBHy3HPi//rKAKUXSyodaCjAZvg 2mdDbpLMVwllMZYrYiyGuMG6PQn/TNDn2TtzdQZ+lHtqTmyrDAvyFotDvgAKrVAUBobf YbeEzrhDUNqfDQmXSu7Vh9QgvUrYU8BK+DDlyAK/SZkFtwmeQqeP0ixFmGr5edbSqTQH B5P4CAQq2KAKN3SJhK6dAHtuSaO4TSImNnrS/9DnE6Xk/+Mnoemy3eTINKYeecEIT+ZB UiBw== 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=QkQilZcIQmpQyCXV4YKdPFrA4ifPoLyZ256r+lHiI64=; b=fUM0iWBrouTfcVn/9KZyWGgnTcItEDMrHfScq4OVTvDg/r1vuwccvmfwohXtDu7QPl jkFSRmpsJkPFBVCPiMTgm6PuZtdg0nHBJFblntAxZAoMKzJqiUFV0QjGafqqQVLZ5zjQ W+DF279fjLp1Jv1w3nyvLBf9wx8nd09PanNe1np3Zv6N3rqRw8DGiFOE9GoZxAot7Nu0 HnrCQ651jFtGs/wtxpCplCybUwARtpy8gRwWqMjF4O+6c0QDb8W2+vp12G7jdUZilmO7 UoXoVUPN7qRmZqCmOXodsk1OKetOCwf3yi7XHWr/CAZgs+A2XDIR1W0bFZ2J42FL/4Ys tI+A== X-Gm-Message-State: APjAAAV0nJiMTSp2GgjNYBNMaD6d6HqW6UWengAKwIQs8aJq7EzltSvp JuzMj2AKq1XWl+tTn2hOR5hea41SYaY6vWPc5Ag4JMyaREc= X-Google-Smtp-Source: APXvYqxj82g1dAlp6f1pxWe/VKHjSLrJV00NSBT21DerEU5+Grk7ESWxVFKiKocwnHo+FKZ09JyQ4ve/+clJD6It8xs= X-Received: by 2002:a5d:4492:: with SMTP id j18mr30178851wrq.212.1556314989872; Fri, 26 Apr 2019 14:43:09 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Fri, 26 Apr 2019 14:42:59 -0700 Message-ID: Subject: Connection ID Space To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000214ecb058775d2ce" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 21:43:15 -0000 --000000000000214ecb058775d2ce Content-Type: text/plain; charset="UTF-8" Although it is quite late in the day for this objection, I find that we already bumping up against the limits of the 18 byte connection ID. Inevitably, this touches on some issues we're exploring in the quic-load-balancers draft , which isn't adopted, and many of you are no doubt happily ignoring. There are basically three uses of the 144 bits of CID entropy in QUIC-LB: 1) Server ID encoding -- as there are only so many servers one might have, 16 bits is usually enough for this. 2) "Private" server entropy -- the load balancer doesn't care what the bits are, but they're protected by crypto. The server created and encrypted the CID, so it can use this for its local purposes, but no one else can. The amount of this depends, but if you're using a 256-bit block cipher it's something like 240 bits -- plenty 3) "Public" entropy -- not encrypted, these bits are readable by anyone who is familiar with the encoding scheme. With a 16 B encryption block, we have only 16 bits to play with here. QUIC-LB is already taking 2 of these last bits for config rotation, which allows server pools to incrementally deploy new CID keys or encoding schemes. So we're down to 14 bits. The public entropy is useful for a growing pile of trusted hardware devices that are presumably not going to perform CID decryption. On f5 boxes, we have a hardware disaggregator for the many dataplane processors and threads that are operating. Today, we'd use perhaps 8 of the bits, but in future architectures even 14 might not quite be enough. And now, having chatting with Manasi Deval from Intel after her Prague talk about hardware offload, I'm fairly sure we're going to need 4 to cheaply encode the connection ID length, at least for servers that want to use this service. If we ever wanted a solution that allowed multiple tiers of load balancing, which is not currently in scope for QUIC-LB, we don't have nearly enough space. I see three options: 1) Ignore the problem -- this may restrict the number of use cases of QUIC in the future, especially as Connection ID lengths are part of the invariants. 2) Redefine the DCIL and SCIL fields to be half the connection ID length. Thus CIDs would always have even lengths but could run up to 30 Bytes. For what it's worth, this also enables 2B CIDs. This is heavyweight as a diff to the current spec but is the most futureproof. There are, of course, other mappings with different properties but similar bureaucratic costs. 3) There are two reserved bits in the relevant header types. If we allowed them to not resolve to zero post-protection, and therefore opened them to encode QUIC-LB config rotation in the clear, this would mitigate the problem and I am fairly confident that these bits would vary enough to not ossify. This is a lightweight protocol change but may just partly relieve the pressure we're feeling now. What are people's initial attitudes? Unless there is strong consensus for Option #1 I can file an issue and we can get it on an agenda to discuss in person. Martin --000000000000214ecb058775d2ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Although it is quite late in the day for this objecti= on, I find that we already bumping up against the limits of the 18 byte con= nection ID.

Inevitably, this touches on some issue= s we're exploring in the qu= ic-load-balancers draft, which isn't adopted, and many of you are n= o doubt happily ignoring.

There are basically thre= e uses of the 144 bits of CID entropy in QUIC-LB:

<= div>1) Server ID encoding -- as there are only so many servers one might ha= ve, 16 bits is usually enough for this.
2) "Private" se= rver entropy -- the load balancer doesn't care what the bits are, but t= hey're protected by crypto. The server created and encrypted the CID, s= o it can use this for its local purposes, but no one else can. The amount o= f this depends, but if you're using a 256-bit block cipher it's som= ething like 240 bits -- plenty
3)=C2=A0 "Public" en= tropy -- not encrypted, these bits are readable by anyone who is familiar w= ith the encoding scheme. With a 16 B encryption block, we have only 16 bits= to play with here.

QUIC-LB is already taking 2 of= these last bits for config rotation, which allows server pools to incremen= tally deploy new CID keys or encoding schemes. So we're down to 14 bits= .

The public entropy is useful for a growing pile = of trusted hardware devices that are presumably not going to perform CID de= cryption. On f5 boxes, we have a hardware disaggregator for the many datapl= ane processors and threads that are operating. Today, we'd use perhaps = 8 of the bits, but in future architectures even 14 might not quite be enoug= h.


And now, having chatting with Ma= nasi Deval from Intel after her Prague talk about hardware offload, I'm= fairly sure we're going to need 4 to cheaply encode the connection ID = length, at least for servers that want to use this service.

If we ever wanted a solution that allowed multiple tiers of load= balancing, which is not currently in scope for QUIC-LB, we don't have = nearly enough space.

I see three options:
1) Ignore the prob= lem -- this may restrict the number of use cases of QUIC in the future, esp= ecially as Connection ID lengths are part of the invariants.
2) R= edefine the DCIL and SCIL fields to be half the connection ID length. Thus = CIDs would always have even lengths but could run up to 30 Bytes. For what = it's worth, this also enables 2B CIDs. This is heavyweight as a diff to= the current spec but is the most futureproof. There are, of course, other = mappings with different properties but similar bureaucratic costs.
3) There are two reserved bits in the relevant header types. If we al= lowed them to not resolve to zero post-protection, and therefore opened the= m to encode QUIC-LB config rotation in the clear, this would mitigate the p= roblem and I am fairly confident that these bits would vary enough to not o= ssify. This is a lightweight protocol change but may just partly relieve th= e pressure we're feeling now.

What are people&= #39;s initial attitudes? Unless there is strong consensus for Option #1 I c= an file an issue and we can get it on an agenda to discuss in person.
=

Martin

--000000000000214ecb058775d2ce-- From nobody Fri Apr 26 14:48:32 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D57120052 for ; Fri, 26 Apr 2019 14:48:31 -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 TDp9J7n57tpr for ; Fri, 26 Apr 2019 14:48:29 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A431201B3 for ; Fri, 26 Apr 2019 14:48:29 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id r6so6325685wrm.4 for ; Fri, 26 Apr 2019 14:48:29 -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=p12vln28Twq8GZpNLypqlmIHxW6aldgyOnchYWLxzpE=; b=AxD9VSuauWFJjGMqnEEVXPPOR15pAsDne9wleTss6Ecg8EFzGrJuDDr1SQH8Nz6lWo IBX42YatVeiX+FcEn14amxflM3X8lNAqqHJlloJH+feXi/WT4xlx3GNoMnyXODp0uuGk RFVq4yfc3UNJHmoNCcJLURgURJa5ny9KLpsL9b6bn9OMefwshcIm2uY3Yy5W0uxD1oLV bK4IDobtD0Z+cHsRpPUYqFEbpJHON7A3Ph9eUIEsAtbwOb4+R4hcrJ/qL8SfORgv7LkP f1DC7CkhvHOGnXrdJVirDb3bWiBzx/EQ+Qr0vCl5IbuILqb844UBp8Q83ZUcVtLASDbC K2MA== 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=p12vln28Twq8GZpNLypqlmIHxW6aldgyOnchYWLxzpE=; b=DCXPXCc5Syijq3onh3af52tioQs77NxFv+GprIIwS+fLSb8/2D0HFvA466+NH2JRGp asTa1KOAZsp6ryi0s9+VmNOTnH3XLDV1uoKy1I3l8dbE1sManAnJeHjA8M02WOimEJ0b XkHX0WOHM3mLQBbMFgteuP5Vtx7kiaZCtVooFF6oAf3NrzEPXsNvceDdCldh7aHJE48Y 9FIJH12psAOpuehVO9AxJSaKvQ8oNxBnbX4/clsN3h7N+EHm5/dlNZwEzPgnofO0Ci24 NmCtlXJLmPy1VaoXX6UDEar4N7Qe3R2wuVrQznZRdy+7kXwj2y/zm2uBkRRjWDntj2X/ dcwg== X-Gm-Message-State: APjAAAV0g/Hz3I4e8sqDwrGObVWcZ1VtONPzmbj4NJiJt9sFHr5qi9U6 xgAQNMCfEo0JppOdsQ3PIgRZWjFsHBYfDuoI7JI= X-Google-Smtp-Source: APXvYqxP1beXRQfY8pRW38gzIs8sGDaIr37YS3UQLKuuQvoXVh/z3ANFcPr1r9WxcZZy1zRSYg2HpoPomJttVaWowVU= X-Received: by 2002:a5d:5542:: with SMTP id g2mr9587569wrw.58.1556315307675; Fri, 26 Apr 2019 14:48:27 -0700 (PDT) MIME-Version: 1.0 References: <20190424065854.GB13735@1wt.eu> In-Reply-To: From: Martin Duke Date: Fri, 26 Apr 2019 14:48:16 -0700 Message-ID: Subject: Re: PROXY protocol To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Willy Tarreau , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000001299a1058775e582" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 21:48:31 -0000 --0000000000001299a1058775e582 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection implies messing with the packet stream, which will break everything unless we do it on the Initial Packet or put it outside the UDP payload (using the UDP option draft or something) QUIC-LB, as a framework, in not particularly well-suited to per-connection signaling. But if someone has a design I'm happy to consider integrating it into my draft. On Wed, Apr 24, 2019 at 12:21 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Google Cloud also uses the text version (version 1) of the PROXY protocol= : > > > https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#proxy-pro= tocol > > > On 24 April 2019 at 09.17.51, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) > wrote: > > Perhaps QUIC should recommend load balancers that are QUIC aware to injec= t > PROXY headers only for initial packets and that they should use the binar= y > format > and initial packets should allow space for such headers in the initial > padding. Perhaps the 1200 byte requirement is already sufficient. > > The problem with this approach is that the detection of initial packets i= s > version dependent and versions want to hide from the world, it seems. > So this appears to tied to invariants. > > Tarreau covered what I was about to respond to Trammel on HTTP/1.1. As I > also said before, X-Forwarded-* is already widely used in that scenario, > and also for HTTPS TLS terminated at load balancer. > > Mikkel > > On 24 April 2019 at 08.58.57, Willy Tarreau (w@1wt.eu) wrote: > > Hi Mikkel, > > On Tue, Apr 23, 2019 at 11:06:31PM -0700, Mikkel Fahn=C3=B8e J=C3=B8rgens= en wrote: > > Various cloud load balancers appear to be adding the PROXY protocol whi= ch > > is a single line of text inserted in front of routed packets. > > > > https://blog.digitalocean.com/load-balancers-now-support-proxy-protocol= / > > > > I'm not deep into this issue, but it appears to also apply to binary > > protocols. > > > > I wonder if there is something QUIC should address here in order to avo= id > > having to parse text headers routed packets. > > Well, if you want the original, it's here : > > https://www.haproxy.org/download/2.0/doc/proxy-protocol.txt > > As you see the text-only version was deprecated 5 years ago in favor of > a binary one which is smaller, easier to parse and can be extended. Users > want to have some TLS information transmitted with the header for example= , > which v2 supports but not v1. Since it is designed to be prepended to any > payload, it would not be surprised if some QUIC implementations would > manage to adapt it there. You would probably not want it for each packet > though. > > A few years ago I've been asked to write a draft on it but sadly it went > too low on my priority list so I never started this task :-/ > > I've found a list of products known for implementing it, I don't know if > it's up to date : > > https://www.haproxy.com/blog/haproxy/proxy-protocol/ > > Hoping this helps, > Willy > > --0000000000001299a1058775e582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Injection implies messing with the packet stream, whi= ch will break everything unless we do it on the Initial Packet or put it ou= tside the UDP payload (using the UDP option draft or something)
<= br>
QUIC-LB, as a framework, in not particularly well-suited to p= er-connection signaling. But if someone has a design I'm happy to consi= der integrating it into my draft.

On Wed, Apr 24, 2019 at 12:21 AM= Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Google Cloud also uses the= text version (version 1) of the PROXY protocol:


On 24 April = 2019 at 09.17.51, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

Perhaps QUIC should recommend load balancers that are QUIC aware to inject
PROXY headers only for initial packets and that they should use the binary format
and initial packets should allow space for such headers in the initial padding. Perhaps the 1200 byte requirement is already sufficient.

The problem with this approach is that the detection of initial packets is version dependent and versions want to hide from the world, it seems.
So this appears to tied to invariants.

Tarreau covered what I was about to respond to Trammel on HTTP/1.1. As I also said before, X-Forwarded-* is already widely used in that scenario, and also for HTTPS TLS terminated at load balancer.

Mikkel

On 24 April 2019 at 08.5= 8.57, Willy Tarreau (w@1wt.eu) wrote:

Hi Mikkel,

On Tue, Apr 23, 2019 at 11:06:31PM -0700, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> Various cloud load balancers appear to be adding the PROXY protocol which
> is a single line of text inserted in front of routed packets.
>
> https://blog.digitalocean.com/load-balancers-no= w-support-proxy-protocol/
>
> I'm not deep into this issue, but it appears to also apply to binary
> protocols.
>
> I wonder if there is something QUIC should address here in order to avoid
> having to parse text headers routed packets.

Well, if you want the original, it's here :

https://www.haproxy.org/download/2.0/doc/proxy-protocol.txt<= /a>

As you see the text-only version was deprecated 5 years ago in favor of
a binary one which is smaller, easier to parse and can be extended. Users
want to have some TLS information transmitted with the header for example,
which v2 supports but not v1. Since it is designed to be prepended to any
payload, it would not be surprised if some QUIC implementations would
manage to adapt it there. You would probably not want it for each packet
though.

A few years ago I've been asked to write a draft on it but sadly it went
too low on my priority list so I never started this task :-/

I've found a list of products known for implementing it, I don't know if
it's up to date :

https://www.haproxy.com/blog/haproxy/proxy-protocol/

Hoping this helps,
Willy
--0000000000001299a1058775e582-- From nobody Fri Apr 26 15:37:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9E012013A for ; Fri, 26 Apr 2019 15:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 o60PhWtwR9dd for ; Fri, 26 Apr 2019 15:37:17 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E3C1200E9 for ; Fri, 26 Apr 2019 15:37:16 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id y5so5415970wma.2 for ; Fri, 26 Apr 2019 15:37: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=E3Y29+DKRGECPJzRJ150OQjBnBOclc0mDKNDxeXs2KY=; b=qeFKR8ZhvAPeHAH49mfCMtt3gd/otBHYH57x0a1VdOdjDLgNmbtGICe89iuAasBhn8 I/u/atnYe9Kd/YTeR2FWh9AA3wVvzDr6PhTixlmqC+uA9VbqShWIVYflz8buTwHcr51V RVvx3nI5Eev9OXcNQE49YCsfRpo0mUnsm/FMTDstzBBlJe6uffh97+2R1YuTK99k9Nlk kFBIfcozhWD2pxwLssDCCtkjCIIibTm1KIaAFq6GxQd27HRYYQdxIoP5Z1lRuTSzqQFx 65TmDvxeX3QOCUCaSAOHcTzvK+w2WAGfGZtgGkXazH+6jDbPYq2MVPF38eGTbwjYZH2g fvbQ== 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=E3Y29+DKRGECPJzRJ150OQjBnBOclc0mDKNDxeXs2KY=; b=C9d7Tc/6/kXIethqzGeTZH8MOVhStGomnW32Vz1MGTpVxlK7oAOGyHgHqDB/CXxLXe eCoaitzD8vOnKJRUyLD2vXNE0VlhwnIINnzehxkksXUDxdPnNRvwnL5Eh0saPjqKYjRY Ku9EERnG4XP29NSAu6qaVZJje1Uf5EZAyaLyTwe00evIbU6t1szZcS+HifOUtKbjRbPu zN7Br2eqSqO21qRUHN1eh4ZIgqv1FY9wg54/ITXmkwbtj8MT+6jeb7l3Ts8QpTfFni0L i0ihzWjtXit2CKhh4X1JUv0xiLYGK3gK1kguVHUQd+L/KSIjWdsqCyR2KaAbZsOu3Qev O66Q== X-Gm-Message-State: APjAAAWAX8o8hxt6lzc0x3tTKUQOXsXaAfpwnowSK8NmbWpYeuyses8U n4puhfwUfH5VXdq55Iv5pgQwwxYGWOP3BfJ/OhonIA== X-Google-Smtp-Source: APXvYqwv+i4XSct+CJD78ZBqVkwff7yBxi9qgFlCiCFrKixDO2KJ3kCGjlPdkWGe4PkhXuLWPRWt3DfNwu7ookIT/ic= X-Received: by 2002:a1c:9e96:: with SMTP id h144mr9879110wme.33.1556318234891; Fri, 26 Apr 2019 15:37:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Hamilton Date: Fri, 26 Apr 2019 15:37:01 -0700 Message-ID: Subject: Re: Connection ID Space To: Martin Duke Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000008cc7bc05877693c7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 22:37:20 -0000 --0000000000008cc7bc05877693c7 Content-Type: text/plain; charset="UTF-8" Do I understand correctly that this would be a change to the invariants? On Fri, Apr 26, 2019 at 2:43 PM Martin Duke wrote: > Although it is quite late in the day for this objection, I find that we > already bumping up against the limits of the 18 byte connection ID. > > Inevitably, this touches on some issues we're exploring in the quic-load-balancers > draft > , > which isn't adopted, and many of you are no doubt happily ignoring. > > There are basically three uses of the 144 bits of CID entropy in QUIC-LB: > > 1) Server ID encoding -- as there are only so many servers one might have, > 16 bits is usually enough for this. > 2) "Private" server entropy -- the load balancer doesn't care what the > bits are, but they're protected by crypto. The server created and encrypted > the CID, so it can use this for its local purposes, but no one else can. > The amount of this depends, but if you're using a 256-bit block cipher it's > something like 240 bits -- plenty > 3) "Public" entropy -- not encrypted, these bits are readable by anyone > who is familiar with the encoding scheme. With a 16 B encryption block, we > have only 16 bits to play with here. > > QUIC-LB is already taking 2 of these last bits for config rotation, which > allows server pools to incrementally deploy new CID keys or encoding > schemes. So we're down to 14 bits.. > > The public entropy is useful for a growing pile of trusted hardware > devices that are presumably not going to perform CID decryption. On f5 > boxes, we have a hardware disaggregator for the many dataplane processors > and threads that are operating. Today, we'd use perhaps 8 of the bits, but > in future architectures even 14 might not quite be enough. > > > And now, having chatting with Manasi Deval from Intel after her Prague > talk about hardware offload, I'm fairly sure we're going to need 4 to > cheaply encode the connection ID length, at least for servers that want to > use this service. > > If we ever wanted a solution that allowed multiple tiers of load > balancing, which is not currently in scope for QUIC-LB, we don't have > nearly enough space. > > I see three options: > 1) Ignore the problem -- this may restrict the number of use cases of QUIC > in the future, especially as Connection ID lengths are part of the > invariants. > 2) Redefine the DCIL and SCIL fields to be half the connection ID length. > Thus CIDs would always have even lengths but could run up to 30 Bytes. For > what it's worth, this also enables 2B CIDs. This is heavyweight as a diff > to the current spec but is the most futureproof. There are, of course, > other mappings with different properties but similar bureaucratic costs. > 3) There are two reserved bits in the relevant header types. If we allowed > them to not resolve to zero post-protection, and therefore opened them to > encode QUIC-LB config rotation in the clear, this would mitigate the > problem and I am fairly confident that these bits would vary enough to not > ossify. This is a lightweight protocol change but may just partly relieve > the pressure we're feeling now. > > What are people's initial attitudes? Unless there is strong consensus for > Option #1 I can file an issue and we can get it on an agenda to discuss in > person. > > Martin > > --0000000000008cc7bc05877693c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do I understand correctly that this would= be a change to the invariants?=C2=A0

On Fri, Apr 26, 2019 at 2:43 PM = Martin Duke <martin.h.duke@gm= ail.com> wrote:
Although it is quite late in the day for this = objection, I find that we already bumping up against the limits of the 18 b= yte connection ID.

Inevitably, this touches on som= e issues we're exploring in the quic-load-balancers draft, whic= h isn't adopted, and many of you are no doubt happily ignoring.

There are basically three uses of the 144 bits of CID ent= ropy in QUIC-LB:

1) Server ID encoding -- as t= here are only so many servers one might have, 16 bits is usually enough for= this.
2) "Private" server entropy -- the load balancer= doesn't care what the bits are, but they're protected by crypto. T= he server created and encrypted the CID, so it can use this for its local p= urposes, but no one else can. The amount of this depends, but if you're= using a 256-bit block cipher it's something like 240 bits -- plenty
3)=C2=A0 "Public" entropy -- not encrypted, these bit= s are readable by anyone who is familiar with the encoding scheme. With a 1= 6 B encryption block, we have only 16 bits to play with here.
QUIC-LB is already taking 2 of these last bits for config rotat= ion, which allows server pools to incrementally deploy new CID keys or enco= ding schemes. So we're down to 14 bits..

The p= ublic entropy is useful for a growing pile of trusted hardware devices that= are presumably not going to perform CID decryption. On f5 boxes, we have a= hardware disaggregator for the many dataplane processors and threads that = are operating. Today, we'd use perhaps 8 of the bits, but in future arc= hitectures even 14 might not quite be enough.


=
And now, having chatting with Manasi Deval from Intel after her = Prague talk about hardware offload, I'm fairly sure we're going to = need 4 to cheaply encode the connection ID length, at least for servers tha= t want to use this service.

If we ever wanted a solution that allowed multiple tiers of load= balancing, which is not currently in scope for QUIC-LB, we don't have = nearly enough space.

I see three options:
1) Ignore the prob= lem -- this may restrict the number of use cases of QUIC in the future, esp= ecially as Connection ID lengths are part of the invariants.
2) R= edefine the DCIL and SCIL fields to be half the connection ID length. Thus = CIDs would always have even lengths but could run up to 30 Bytes. For what = it's worth, this also enables 2B CIDs. This is heavyweight as a diff to= the current spec but is the most futureproof. There are, of course, other = mappings with different properties but similar bureaucratic costs.
3) There are two reserved bits in the relevant header types. If we al= lowed them to not resolve to zero post-protection, and therefore opened the= m to encode QUIC-LB config rotation in the clear, this would mitigate the p= roblem and I am fairly confident that these bits would vary enough to not o= ssify. This is a lightweight protocol change but may just partly relieve th= e pressure we're feeling now.

What are people&= #39;s initial attitudes? Unless there is strong consensus for Option #1 I c= an file an issue and we can get it on an agenda to discuss in person.
=

Martin

--0000000000008cc7bc05877693c7-- From nobody Fri Apr 26 21:03:25 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1091203C1 for ; Fri, 26 Apr 2019 21:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 LMbhyXyIthE2 for ; Fri, 26 Apr 2019 21:03:20 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655211203BF for ; Fri, 26 Apr 2019 21:03:20 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id k16so7138845wrn.5 for ; Fri, 26 Apr 2019 21:03:20 -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=PctX26thy4JcgqlJA6WrUpTT+vFqx3hihHPs5GbQTxI=; b=PXRLo7LLJMHuNdoE3zeyzTnRBSkoI71DdU0L2q7Jnmtbl0Lw/4ubkP2LLtmcPaSDlY DLOsOcepo60DYK3sTmnrMp9150tK+d7I9ytQzNH+bfMjHHbbWtIe7sxoM912G6qamxCb fBkrRAIT+VfLi46ABpdI+/kD3/t/LJNEckaYfLBlex3+UQTvBmr0bg3dL4SgMBObjMOC ozblVWTomdZc5yfq/+eiXhwXqzxdexLBhrvUDpylGWSmFKCWzcnQN2H8lGTNUrArN/5S xL1nAfBJ03fCKUrhsf3wUnuZ1SbOMnLYCTKt1yIXAis7NR4mLwTLNmxY93dVCR3qJZLs V9LA== 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=PctX26thy4JcgqlJA6WrUpTT+vFqx3hihHPs5GbQTxI=; b=Ci2d/19HYtnUzuY8jiwmZGzIO1sd5LGfxYZECu+/RNZ4m0b6TtSxOnYV8vvIpkbsg9 MMY+sJQTNqi6tHZa4yAJTWFywnQrJdSvRokfqL+r1pwjgPRTVorfdJc7s2ZGbJTFaSPt qmg4UDoOjYlXNm79qasfefmp2U9nemlgQgEzXaSe9lmR99SA2sFe2yThgGxzH3Q3k9qW lHn1KzwnaL2d2rtv4XVaz7OrTnFNU9VHkcBshUjfHore0UuPOwjr6qedD2LW8A4ZO1Uc KlxG5oa7Hs8S0j9ayytd26Mitnwj1bLQY7TG3llO1SHVzFHL0NpF00j2jMNFUkYfAcDd 3A1A== X-Gm-Message-State: APjAAAVH//Sz/dUkmmMJxlCFbg640VVfTfFOZuqg6nLaaxKkmWsi19nA cm8+0F9IbBYMSqQ+Ay/lPX3EyGBTbjhs4SgpS5M= X-Google-Smtp-Source: APXvYqzZd7l6h0d85/LfxPkxeexJCSi2jaNAMzP9rhRA/F5ltICnnRtIECFaIn/vxAk4Cl9nF8bv2CpFs5H3yzCcdm4= X-Received: by 2002:a5d:4492:: with SMTP id j18mr31002952wrq.212.1556337798665; Fri, 26 Apr 2019 21:03:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Fri, 26 Apr 2019 21:02:55 -0700 Message-ID: Subject: Re: Connection ID Space To: Ryan Hamilton Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000a3db2d05877b21f9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 27 Apr 2019 04:03:23 -0000 --000000000000a3db2d05877b21f9 Content-Type: text/plain; charset="UTF-8" Option 2 would be a change to the invariants. On Fri, Apr 26, 2019, 15:37 Ryan Hamilton wrote: > Do I understand correctly that this would be a change to the invariants? > > On Fri, Apr 26, 2019 at 2:43 PM Martin Duke > wrote: > >> Although it is quite late in the day for this objection, I find that we >> already bumping up against the limits of the 18 byte connection ID. >> >> Inevitably, this touches on some issues we're exploring in the quic-load-balancers >> draft >> , >> which isn't adopted, and many of you are no doubt happily ignoring. >> >> There are basically three uses of the 144 bits of CID entropy in QUIC-LB: >> >> 1) Server ID encoding -- as there are only so many servers one might >> have, 16 bits is usually enough for this. >> 2) "Private" server entropy -- the load balancer doesn't care what the >> bits are, but they're protected by crypto. The server created and encrypted >> the CID, so it can use this for its local purposes, but no one else can. >> The amount of this depends, but if you're using a 256-bit block cipher it's >> something like 240 bits -- plenty >> 3) "Public" entropy -- not encrypted, these bits are readable by anyone >> who is familiar with the encoding scheme. With a 16 B encryption block, we >> have only 16 bits to play with here. >> >> QUIC-LB is already taking 2 of these last bits for config rotation, which >> allows server pools to incrementally deploy new CID keys or encoding >> schemes. So we're down to 14 bits.. >> >> The public entropy is useful for a growing pile of trusted hardware >> devices that are presumably not going to perform CID decryption. On f5 >> boxes, we have a hardware disaggregator for the many dataplane processors >> and threads that are operating. Today, we'd use perhaps 8 of the bits, but >> in future architectures even 14 might not quite be enough. >> >> >> And now, having chatting with Manasi Deval from Intel after her Prague >> talk about hardware offload, I'm fairly sure we're going to need 4 to >> cheaply encode the connection ID length, at least for servers that want to >> use this service. >> >> If we ever wanted a solution that allowed multiple tiers of load >> balancing, which is not currently in scope for QUIC-LB, we don't have >> nearly enough space. >> >> I see three options: >> 1) Ignore the problem -- this may restrict the number of use cases of >> QUIC in the future, especially as Connection ID lengths are part of the >> invariants. >> 2) Redefine the DCIL and SCIL fields to be half the connection ID length. >> Thus CIDs would always have even lengths but could run up to 30 Bytes. For >> what it's worth, this also enables 2B CIDs. This is heavyweight as a diff >> to the current spec but is the most futureproof. There are, of course, >> other mappings with different properties but similar bureaucratic costs. >> 3) There are two reserved bits in the relevant header types. If we >> allowed them to not resolve to zero post-protection, and therefore opened >> them to encode QUIC-LB config rotation in the clear, this would mitigate >> the problem and I am fairly confident that these bits would vary enough to >> not ossify. This is a lightweight protocol change but may just partly >> relieve the pressure we're feeling now. >> >> What are people's initial attitudes? Unless there is strong consensus for >> Option #1 I can file an issue and we can get it on an agenda to discuss in >> person. >> >> Martin >> >> --000000000000a3db2d05877b21f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Option 2 would be a change to the invariants.

On Fri, Apr = 26, 2019, 15:37 Ryan Hamilton <rch@goo= gle.com> wrote:
Do I understand correctly that this would be a change= to the invariants?=C2=A0

On Fri, Apr 26, 2019 at 2:43 PM Martin Duke = <martin.h.duke@gmail.com> wrote:
Although it is quite= late in the day for this objection, I find that we already bumping up agai= nst the limits of the 18 byte connection ID.

Inevi= tably, this touches on some issues we're exploring in the quic-load-balancers draft, which isn'= ;t adopted, and many of you are no doubt happily ignoring.

There are basically three uses of the 144 bits of CID entropy in Q= UIC-LB:

1) Server ID encoding -- as there are = only so many servers one might have, 16 bits is usually enough for this.
2) "Private" server entropy -- the load balancer doesn= 9;t care what the bits are, but they're protected by crypto. The server= created and encrypted the CID, so it can use this for its local purposes, = but no one else can. The amount of this depends, but if you're using a = 256-bit block cipher it's something like 240 bits -- plenty
3)=C2=A0 "Public" entropy -- not encrypted, these bits are rea= dable by anyone who is familiar with the encoding scheme. With a 16 B encry= ption block, we have only 16 bits to play with here.

QUIC-LB is already taking 2 of these last bits for config rotation, whic= h allows server pools to incrementally deploy new CID keys or encoding sche= mes. So we're down to 14 bits..

The public ent= ropy is useful for a growing pile of trusted hardware devices that are pres= umably not going to perform CID decryption. On f5 boxes, we have a hardware= disaggregator for the many dataplane processors and threads that are opera= ting. Today, we'd use perhaps 8 of the bits, but in future architecture= s even 14 might not quite be enough.


And now, having chatting with Manasi Deval from Intel after her Prague ta= lk about hardware offload, I'm fairly sure we're going to need 4 to= cheaply encode the connection ID length, at least for servers that want to= use this service.

If we ever wanted a solution that allowed multiple tiers of load= balancing, which is not currently in scope for QUIC-LB, we don't have = nearly enough space.

I see three options:
1) Ignore the prob= lem -- this may restrict the number of use cases of QUIC in the future, esp= ecially as Connection ID lengths are part of the invariants.
2) R= edefine the DCIL and SCIL fields to be half the connection ID length. Thus = CIDs would always have even lengths but could run up to 30 Bytes. For what = it's worth, this also enables 2B CIDs. This is heavyweight as a diff to= the current spec but is the most futureproof. There are, of course, other = mappings with different properties but similar bureaucratic costs.
3) There are two reserved bits in the relevant header types. If we al= lowed them to not resolve to zero post-protection, and therefore opened the= m to encode QUIC-LB config rotation in the clear, this would mitigate the p= roblem and I am fairly confident that these bits would vary enough to not o= ssify. This is a lightweight protocol change but may just partly relieve th= e pressure we're feeling now.

What are people&= #39;s initial attitudes? Unless there is strong consensus for Option #1 I c= an file an issue and we can get it on an agenda to discuss in person.
=

Martin

--000000000000a3db2d05877b21f9-- From nobody Sat Apr 27 17:45:24 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBDD120169 for ; Sat, 27 Apr 2019 17:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=qHP1hN3A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G7gnWTSy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXwt4tec4f35 for ; Sat, 27 Apr 2019 17:45:19 -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 66ECD1200E5 for ; Sat, 27 Apr 2019 17:45:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8231B2108A for ; Sat, 27 Apr 2019 20:45:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 27 Apr 2019 20:45:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=Juw0X5bcR3W8FoFu6QcB+tszOI3S4YsmyYX0o2T3o2Q=; b=qHP1hN3A 6PuJ0diARQY3kPXhQrQKsAv7HFbfmtZlkHNJB1REuA5Qr0bJyzPfSi4nJ3YDFSaG I39OziqDzCv+IknpVTs/MZ80+OEtrgKFaUO3/UdP+VDQqPRaxCehm7HP/G4M5ppq FxXS9VWnAKPhEL2+hKglldDKzBLyk//UnCoXaUa981F0483bKs1QI1Ss0Ue0Fm1a z2ETmTZGaaunoBLNEIIgEY0K3iwM8/ThHJDGf7X8+pQbd0i8hl+eL1B+7ehZXSUx MauSqZu9cpLOnKAv+8jhIaXcmL773fQIb3aVGeXlRtWHPX/HR79bDaY1J3bk+3kW RgRN9PmLGFf0Qw== 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-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Juw0X5bcR3W8FoFu6QcB+tszOI3S4 YsmyYX0o2T3o2Q=; b=G7gnWTSyfOzlUOv58bnUIh858V+1ZpioWtw67n0Lay5Tw tslRUgHVZk9DqDLl66RgVeZUTykaxMPsdD3b03ZPuEyiG16EIyceFJIbkQYyVP++ B07w6f1LDYvLhjqWD6ohJ/f8Uvyi5yPDuLwRXi+ROk9z2Gz995LgOeJfRCmYoCPq fIDEmIl2WbrFDavzpucIaeeCR43h/HzWrSSdD9VmML6HBglCBTyCDZIkSJtWMlRd Xeu7pxf4FYXTySkU8zt7UDIV2kixD7q9AKGRIQ6qu+weBJ6tGOOxdPm9GqetmeeE RpPn9OaT1r/Sb3YAFPnFLMSBhGaqXv8sr8cc6IqNw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrheelgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepudduledrledrgeefrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id C528CE40E3 for ; Sat, 27 Apr 2019 20:45:16 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 6A4DBC03F8 for ; Sun, 28 Apr 2019 00:45:13 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============3569652911668839564==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190428004513.6A4DBC03F8@cloud.mnot.net> Date: Sun, 28 Apr 2019 00:45:13 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 00:45:24 -0000 --===============3569652911668839564== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+10/-9/=F0=9F=92=AC55) 10 issues created: - Section 9.4 of Transport contains transport and congestion control func= tions (by gorryfair) https://github.com/quicwg/base-drafts/issues/2654 = - Packet-threshold loss detection poorly interacts with packet coalescing= (by janaiyengar) https://github.com/quicwg/base-drafts/issues/2653 [-recovery] [design] = - QUIC timers would be simpler if the Handshake timer was unified with th= e PTO timer (by ianswett) https://github.com/quicwg/base-drafts/issues/2650 [-recovery] [design] = - is persistent congestion per pn_spance? (by yangchi) https://github.com/quicwg/base-drafts/issues/2649 = - Crypto timeout value should include rttvar (by janaiyengar) https://github.com/quicwg/base-drafts/issues/2648 [-recovery] [design] = - Retire My Own CID (by nibanks) https://github.com/quicwg/base-drafts/issues/2645 = - RTT measurement using PATH_* frames (by rpaulo) https://github.com/quicwg/base-drafts/issues/2644 = - Connection migration strategies (by rpaulo) https://github.com/quicwg/base-drafts/issues/2643 = - client should send PING in Initial or Handshake, but PINGs are forbidde= n in these packets (by marten-seemann) https://github.com/quicwg/base-drafts/issues/2640 = - max_ack_delay is unknown when a new connection is established (by marte= n-seemann) https://github.com/quicwg/base-drafts/issues/2638 = 21 issues received 55 new comments: - #2632 H3 GOAWAY should be symmetric and cover bidi and uni streams (9 b= y RyanAtGoogle, martinthomson, MikeBishop, LPardue, ianswett) https://github.com/quicwg/base-drafts/issues/2632 [-http] [design] = - #2638 max_ack_delay is unknown when a new connection is established (6 = by kazuho, marten-seemann, janaiyengar, ianswett) https://github.com/quicwg/base-drafts/issues/2638 [-recovery] [design] = - #2645 Retire My Own CID (6 by erickinnear, ianswett, MikeBishop, nibank= s) https://github.com/quicwg/base-drafts/issues/2645 = - #2599 Use short headers for stateless reset (4 by mnot, ianswett) https://github.com/quicwg/base-drafts/issues/2599 [-transport] [design]= [has-proposal] = - #2644 RTT measurement using PATH_* frames (4 by rpaulo, martinthomson, = ianswett) https://github.com/quicwg/base-drafts/issues/2644 [-recovery] [editoria= l] = - #2649 is persistent congestion per pn_space? (3 by yangchi, ianswett) https://github.com/quicwg/base-drafts/issues/2649 [-recovery] = - #2434 Reserved versions are not version-dependent (2 by marten-seemann,= mnot) https://github.com/quicwg/base-drafts/issues/2434 [-invariants] [-trans= port] = - #2582 Attacks Against Address Migration (2 by martinthomson, mnot) https://github.com/quicwg/base-drafts/issues/2582 [-transport] = - #2464 Remember Fewer Transport Parameters for 0-RTT (2 by mnot, MikeBis= hop) https://github.com/quicwg/base-drafts/issues/2464 [-transport] [design]= [has-consensus] = - #1994 endpoints don't know how many connection IDs the peer is willing = to store (2 by mnot, janaiyengar) https://github.com/quicwg/base-drafts/issues/1994 [-transport] [design]= [has-proposal] = - #2511 Some correctness issues in the HTTP/3 drafts are stream errors, n= ot connection errors (2 by DaanDeMeyer, MikeBishop) https://github.com/quicwg/base-drafts/issues/2511 [-http] [design] = - #2640 client should send PING in Initial or Handshake, but PINGs are fo= rbidden in these packets (2 by ianswett) https://github.com/quicwg/base-drafts/issues/2640 [-recovery] [-transpo= rt] = - #2643 Connection migration strategies (2 by rpaulo, ianswett) https://github.com/quicwg/base-drafts/issues/2643 = - #2531 spin bit intro: information can't be used "for" techniques (2 by = martinthomson, mnot) https://github.com/quicwg/base-drafts/issues/2531 [-spin-exp] [editoria= l] = - #2580 Is path validation a SHOULD or a MUST -- pick one! (1 by larsegge= rt) https://github.com/quicwg/base-drafts/issues/2580 [-transport] [design] = - #1834 Flow control for post-handshake CRYPTO messages (1 by mnot) https://github.com/quicwg/base-drafts/issues/1834 [-tls] [design] [has-= proposal] = - #2611 lost_pn can go negative (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2611 [-recovery] = - #2650 Recovery would be simpler if the Handshake timer was unified with= the PTO timer (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2650 [-recovery] [design] = - #2653 Packet-threshold loss detection poorly interacts with packet coal= escing (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2653 [-recovery] [design] = - #2543 NEW_TOKEN token and encryption (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2543 [-transport] [design] = - #2516 Semantics of SETTINGS_MAX_HEADER_LIST_SIZE (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2516 [-http] = 9 issues closed: - spin bit intro: information can't be used "for" techniques https://gith= ub.com/quicwg/base-drafts/issues/2531 [-spin-exp] [editorial] = - H3 GOAWAY guidance still refers to MAX_STREAM_ID https://github.com/qui= cwg/base-drafts/issues/2629 [-http] = - Use short headers for stateless reset https://github.com/quicwg/base-dr= afts/issues/2599 [-transport] [design] [has-proposal] = - Flow control for post-handshake CRYPTO messages https://github.com/quic= wg/base-drafts/issues/1834 [-tls] [design] [has-proposal] = - Remove size optimization for Initial packets https://github.com/quicwg/= base-drafts/issues/2522 [-transport] [design] [has-consensus] = - VN packets may be dropped more often when the QUIC bit is 0 https://git= hub.com/quicwg/base-drafts/issues/2400 [-transport] [design] [has-consensus= ] = - Connection migration strategies https://github.com/quicwg/base-drafts/i= ssues/2643 = - client should send PING in Initial or Handshake, but PINGs are forbidde= n in these packets https://github.com/quicwg/base-drafts/issues/2640 [-reco= very] [-transport] = - Reserved versions are not version-dependent https://github.com/quicwg/b= ase-drafts/issues/2434 [-invariants] [-transport] = Pull requests ------------- * quicwg/base-drafts (+8/-8/=F0=9F=92=AC12) 8 pull requests submitted: - Merge crypto timeout into PTO (by ianswett) https://github.com/quicwg/base-drafts/pull/2655 = - Move "Discarding Keys and Packet State" up (by ianswett) https://github.com/quicwg/base-drafts/pull/2652 = - Remove lost_pn and avoid integer underflow (by ianswett) https://github.com/quicwg/base-drafts/pull/2651 = - Clarify that unlinkability is required for NEW_TOKEN tokens. Changes = =E2=80=A6 (by martinthomson) https://github.com/quicwg/base-drafts/pull/2647 [-transport] [design] = - use max_ack_delay =3D 0 before receving the TPs (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2646 = - Don't send PING in Initial or Handshake (by ianswett) https://github.com/quicwg/base-drafts/pull/2642 [-recovery] [design] = - remove incorrect sentence from DetectLostPackets description (by marten= -seemann) https://github.com/quicwg/base-drafts/pull/2641 = - fix typo (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2639 = 5 pull requests received 12 new comments: - #2646 use max_ack_delay =3D 0 before receving the TPs (6 by kazuho, mar= ten-seemann, martinthomson) https://github.com/quicwg/base-drafts/pull/2646 [-recovery] [-transport= ] [design] = - #2628 Recommend of per-connection ID randomness for spin bit (2 by mart= inthomson, mnot) https://github.com/quicwg/base-drafts/pull/2628 [-transport] = - #2642 Don't send PING in Initial or Handshake (2 by martinthomson, ians= wett) https://github.com/quicwg/base-drafts/pull/2642 [-recovery] [design] = - #1998 introduce a max_connection_ids transport parameter (1 by ianswett) https://github.com/quicwg/base-drafts/pull/1998 [-transport] [design] [= has-proposal] = - #2639 fix typo (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2639 = 8 pull requests merged: - -20 changelog https://github.com/quicwg/base-drafts/pull/2631 [editorial] = - Fix stale reference and edge case in GOAWAY text https://github.com/quicwg/base-drafts/pull/2634 [-http] [editorial] = - Mandate the use of short header for stateless reset https://github.com/quicwg/base-drafts/pull/2600 [-transport] [design] = - Specify behavior for post-handshake CRYPTO messages https://github.com/quicwg/base-drafts/pull/2524 [-transport] [design] = - Remove exception for Initial padding https://github.com/quicwg/base-drafts/pull/2523 [-transport] [design] = - Set the QUIC bit in Version Negotiation https://github.com/quicwg/base-drafts/pull/2561 [-transport] [design] = - remove incorrect sentence from DetectLostPackets description https://github.com/quicwg/base-drafts/pull/2641 = - fix typo https://github.com/quicwg/base-drafts/pull/2639 = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============3569652911668839564== 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 28, 2019

Issues

quicwg/base-drafts (+10/-9/=F0=9F=92=AC55)

10 issues created:

21 issues received 55 new comments:

9 issues closed:

Pull requests

quicwg/base-drafts (+8/-8/=F0=9F=92=AC12)

8 pull requests submitted:

5 pull requests received 12 new comments:

8 pull requests merged:

Repositories tracked by this digest:

--===============3569652911668839564==-- From nobody Mon Apr 29 15:56:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5809120780 for ; Mon, 29 Apr 2019 15:56:37 -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 TUEG_QPeBcRI for ; Mon, 29 Apr 2019 15:56:35 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7FBF1200DE for ; Mon, 29 Apr 2019 15:56:34 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id o33so4095771uae.12 for ; Mon, 29 Apr 2019 15:56:34 -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=k68aH6uL6YhVx3KyHfx/Mi+PmC9gnWFCUey4TgQEvPA=; b=IrQLwpnoKd3lgxqQKJDP5whvuXCDVhw4ZHecw6feiquYnAmo27aRP6jX7ceWI1QTjv b93gddqSqy+0BW3DgF+9KyY9qNKd1+jbwc7yhSLFwHvehNTmT7UfowHPhE8qpGy3nL5S bYutkJVMasmGeNVVHSahWXd2e2/2iVj3GSjY1MRdnklQJE/lug4NKoSdw2oT6Y8ajbU9 UYwq3RN2Xkicl2uDiEKWMIaYdd6QH0P6ZFkuX/GsQ/cUm7vwPVqVfVTYHuJffUBeSfvm oL4FX/s9YkEK2TsYXHo8Ngn855st/RzXeVEalfYlG8TMb9lQDW37z8cut33cX6EhX43s MgWA== 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=k68aH6uL6YhVx3KyHfx/Mi+PmC9gnWFCUey4TgQEvPA=; b=Li9+FSzj3FdKsV/2KLVVwtyS06EyjdYoAmGDSvcOu97eLMkP6fRxzlm09V8T/uO4Ah wAtrdpCAIEYqHNyXaVg5pHh1mX5FM03ehLShRl/9nrFU8UfFvjGn/3np63lT51vy4GX4 RrXyZcTu7lXj/l9Z0ZNyQyqcCX2GewWUhT9ojmRchdyNWJSsyfmBDwG19qAabgC6NAfl ilaHLN6lQARawIlPgBRiz336R5qQiDeXHFE7soS24/pyfZEauWPW70OOkBMqaTBajZUQ DgNiRGgAn6GNAiluP5N3kF6IYMBPshHKUtyeOp7xQsWRvXnqyAeJ3q6ZI/+UbAS/3HAE +KsA== X-Gm-Message-State: APjAAAUx44m+Bg2MgdSSRMcQYbqlTGcYyA2uOSijaqAv6KocGzMMokvU eDn6AhKb3+YMeJiU1l9q/Y1TE1VMwcaxajGTuToiEZlL X-Google-Smtp-Source: APXvYqxoqbI4jYzYbn0VEsOPhvFP41KqY/iTIrJN142VmJhMgOT5Nm7h7k4iHMCARyjzqrj9ngDANtpGcLJ6s60FY0k= X-Received: by 2002:ab0:3ec:: with SMTP id 99mr1650535uau.59.1556578593001; Mon, 29 Apr 2019 15:56:33 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Mon, 29 Apr 2019 15:56:21 -0700 Message-ID: Subject: Submission of WebTransport API to WICG (and refactoring of the WebRTC-QUIC API) To: QUIC WG Content-Type: multipart/alternative; boundary="00000000000019d7740587b3328b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 22:56:38 -0000 --00000000000019d7740587b3328b Content-Type: text/plain; charset="UTF-8" Feedback on the WebRTC-QUIC P2P API has come from developers who are primarily interested in client/server use cases rather than peer-to-peer use cases involving WebRTC. For those developers, it is desirable to avoid dependencies on ICE. As a result, a specification focusing on client/server use cases has been created. Since this specification supports a wider range of client/server use cases it has been renamed the "WebTransport API" and has been submitted to W3C WICG . The WebTransport explainer is here and the WebTransport API specification is here . In order to avoid duplicating the content in the WebTransport API, the WebRTC-QUIC P2P API has been reworked to reference objects defined in the WebTransport API instead . Note that there are still a few dangling references left that should be fixed soon . Since much of the material in the former WebRTC-QUIC API now resides in the WebTransport API document, people interested in the evolution of the API would be advised to monitor discussion in the W3C WICG where it is expected that discussion of client/server aspects will take place. The W3C ORTC CG will focus on P2P aspects requiring a dependency on ICE, which are defined here . --00000000000019d7740587b3328b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Feedback on the WebRTC-QUIC P2P API has come from developers who are primarily interested i= n client/server use cases rather than peer-to-peer use cases involving WebRTC= . =C2=A0For those developers, it is desirable to avoid dependencies on ICE.

=C2=A0

As a result, a specification focusing on client/server use cases has been created.=C2=A0 S= ince this specification supports a wider range of client/server use cases it has= been renamed the =C2=A0"WebTransport API" and has been submitted to W3C WICG.=C2= =A0=C2=A0

=C2=A0

The WebTransport explainer is here and the WebTransp= ort API specification is here.

=C2=A0

In order to avoid duplicating the content in the WebTransport API, the WebRTC-QUIC P2P API ha= s been reworked to reference objects defined in the WebTransport API instead. =C2=A0=C2=A0Note that there are still a few dangling reference= s left that should be fixed soon.

=C2=A0

Since much of the material in the former WebRTC-QUIC API now resides in the WebTransport API document, people interested in the evolution of the API would be advised to monitor discussion in the W3C WICG where it is expected that dis= cussion of client/server aspects will take place.

=C2=A0

The W3C ORTC CG will focus on P2P aspects requiring a dependency on ICE, which are defined her= e.=C2=A0

--00000000000019d7740587b3328b-- From nobody Tue Apr 30 10:50:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C89012031D for ; Tue, 30 Apr 2019 10:50:29 -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 jIlk11VDtL8u for ; Tue, 30 Apr 2019 10:50:24 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770091.outbound.protection.outlook.com [40.107.77.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 7FF9A12031E for ; Tue, 30 Apr 2019 10:50:24 -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:X-MS-Exchange-SenderADCheck; bh=WFdI0ShD+BfbJ+/7G66fxoQE/cgFBwYHJnz+yAxQPH4=; b=jrm4GaQtk5YXPqS73r39ObzuA5lqk8OEhWfFhX3hqBEqHqvYUe+XcTi0dmYuiRKgNqOeINdHACgLp0rKDvXgd62RNAYarSon3fD+1Il5F/ACY/SRw45HzhDLprP09dNIWj9tcuiWEiMjGSAdlFzYOtYwjNEyeR62VfRfawLIdWU= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0568.namprd22.prod.outlook.com (10.172.138.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.15; Tue, 30 Apr 2019 17:50:21 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::5e:10a3:8225:425]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::5e:10a3:8225:425%5]) with mapi id 15.20.1835.010; Tue, 30 Apr 2019 17:50:21 +0000 From: Mike Bishop To: Martin Duke , Ryan Hamilton CC: IETF QUIC WG Subject: RE: Connection ID Space Thread-Topic: Connection ID Space Thread-Index: AQHU/Hke5LQf5oR0tESJhMqZbEzX16ZPCC6AgABbDoCABZxCoA== Date: Tue, 30 Apr 2019 17:50:21 +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-ms-office365-filtering-correlation-id: 36178aa3-a3ee-42c3-99a6-08d6cd945116 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:CY4PR22MB0568; x-ms-traffictypediagnostic: CY4PR22MB0568: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(39830400003)(376002)(396003)(199004)(189003)(3846002)(6116002)(2906002)(66476007)(81156014)(66066001)(790700001)(73956011)(66556008)(76116006)(5660300002)(64756008)(4326008)(81166006)(25786009)(66946007)(66446008)(446003)(508600001)(53936002)(76176011)(8676002)(14454004)(110136005)(52536014)(6246003)(236005)(9686003)(99286004)(97736004)(256004)(11346002)(316002)(33656002)(55016002)(8936002)(74482002)(7736002)(6306002)(7696005)(6436002)(26005)(86362001)(6506007)(186003)(74316002)(486006)(229853002)(476003)(54896002)(102836004)(68736007)(3480700005)(7116003)(606006)(71190400001)(71200400001)(53546011)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0568; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5VxfPV6P3iWHlawPPb0hkV/uaWGWIh2u9q0iuDIAfDdz1DE3r1hlaTOzi8OrdvFzKHPt6fLHTeHqHTZ5WxVKs3Y3BxQkQqrsH4h1bVLVQNwAWOFlc8pCwOSAX4flKZXIp7mLeKa00ntCoim248VVeI1h2tVxSZJ0e7c11ZKXnHNaKBxC/MXiCn5R3d7y+o4ugY+atngmh/pGbeDz7dB7a4b+X7g4sE5od08RQ6cApTdljJsRQImgKEWHUzTGJ3WhZ3bG33tE5P+dyd7IBBnU3X0whu+u0Dq1bTzItHmUHSH+F/5irjKhq6d1PMvlaeXnjIvvfQB0dYg6A6Cz1kuQO2qla3O0bNzmD17+CBeb+JvDrL99xAI3OZEs9ad/XeL2MpoImuoMAEd4PK/QDt7cIwWVjn/ANvVYwT/KU0NpOUQ= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB098376AEF8602968191281A8DA3A0CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 36178aa3-a3ee-42c3-99a6-08d6cd945116 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 17:50:21.7522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0568 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 17:50:29 -0000 --_000_CY4PR22MB098376AEF8602968191281A8DA3A0CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gaW4gdGhlIHNlbWktaWdub3JpbmcgUVVJQy1MQiBjYW1wLCBhcyBJIGJlbGlldmUgaXTi gJlzIGFuIGltcG9ydGFudCBwcm9ibGVtIGZvciBvdGhlciBwZW9wbGUgdG8gc29sdmUgcmlnaHQg bm93LiAgKFRoYW5rcywgTWFydGluISkNCg0KDQoNCkkgdGFrZSBubyBwYXJ0aWN1bGFyIHBvc2l0 aW9uIG9uIHdoZXRoZXIgdGhlIDE4IGJ5dGUgbWF4aW11bSBpcyB0b28gc21hbGw7IGl0IGZlZWxz IGV4Y2VwdGlvbmFsbHkgbGFyZ2UgdG8gbWUsIGJ1dCBpZiB3ZeKAmXJlIGdldHRpbmcgYWN0dWFs IGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2UgdGhhdCBzaG93cyBvdGhlcndpc2UsIEnigJltIGhh cHB5IHRvIGhhdmUgdGhlIGRhdGEuICBJZiBpdCBuZWVkcyB0byBjaGFuZ2UsIEkgYWdyZWUgdGhh dCBPcHRpb24gMiBhcHBlYXJzIHRoZSBtb3N0IGZ1dHVyZXByb29mLCBhbmQgaWYgc29tZXRoaW5n IG5lZWRzIHRvIGNoYW5nZSBpbiB0aGUgaW52YXJpYW50cywgdGhpcyBpcyBhbG1vc3QgdGhlIGxh dGVzdCB3ZSBjb3VsZCBwb3NzaWJseSBkbyBpdC4gIE5vdyBvciBuZXZlci4NCg0KDQoNCkkgdGhp bmsgT3B0aW9uIDFhIGlzIHRvIG5vdGUgdGhhdCB0aGUgaW52YXJpYW50cyBkb27igJl0IGxpbWl0 IHRoZSBsZW5ndGggb2YgQ0lEcyBpbiBhIGdpdmVuIHZlcnNpb24gaW4gc2hvcnQtaGVhZGVyIHBh Y2tldHM7IGEgZnV0dXJlIHZlcnNpb24gY291bGQgZGVmaW5lIG11Y2ggbGFyZ2VyIENJRHMgdG8g YmUgdmFsaWQgcG9zdC1oYW5kc2hha2UuICBDb3VwbGVkIHdpdGggYSB3YXkgdG8gZW5jb3VyYWdl L3JlcXVpcmUgY2xpZW50cyB0byBtb3ZlIG9mZiBvZiB0aGUgaGFuZHNoYWtlIENJRCBpbW1lZGlh dGVseSBwb3N0LWhhbmRzaGFrZSwgdGhpcyBtaWdodCBiZSBzdWZmaWNpZW50IGZvciB0aGUgcmVh bCB3b3JsZC4NCg0KDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIE1hcnRpbiBEdWtlDQpTZW50OiBGcmlkYXksIEFwcmlsIDI2LCAyMDE5IDk6MDMgUE0N ClRvOiBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbT4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1 aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQ29ubmVjdGlvbiBJRCBTcGFjZQ0KDQoNCg0KT3B0 aW9uIDIgd291bGQgYmUgYSBjaGFuZ2UgdG8gdGhlIGludmFyaWFudHMuDQoNCg0KDQpPbiBGcmks IEFwciAyNiwgMjAxOSwgMTU6MzcgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb208bWFpbHRv OnJjaEBnb29nbGUuY29tPj4gd3JvdGU6DQoNCiAgIERvIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkg dGhhdCB0aGlzIHdvdWxkIGJlIGEgY2hhbmdlIHRvIHRoZSBpbnZhcmlhbnRzPw0KDQoNCg0KICAg T24gRnJpLCBBcHIgMjYsIDIwMTkgYXQgMjo0MyBQTSBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVr ZUBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPj4gd3JvdGU6DQoNCiAg ICAgIEFsdGhvdWdoIGl0IGlzIHF1aXRlIGxhdGUgaW4gdGhlIGRheSBmb3IgdGhpcyBvYmplY3Rp b24sIEkgZmluZCB0aGF0IHdlIGFscmVhZHkgYnVtcGluZyB1cCBhZ2FpbnN0IHRoZSBsaW1pdHMg b2YgdGhlIDE4IGJ5dGUgY29ubmVjdGlvbiBJRC4NCg0KDQoNCiAgICAgIEluZXZpdGFibHksIHRo aXMgdG91Y2hlcyBvbiBzb21lIGlzc3VlcyB3ZSdyZSBleHBsb3JpbmcgaW4gdGhlIHF1aWMtbG9h ZC1iYWxhbmNlcnMgZHJhZnQ8aHR0cHM6Ly9naXRodWIuY29tL21hcnRpbmR1a2UvZHJhZnQtZHVr ZS1xdWljLWxvYWQtYmFsYW5jZXJzL2Jsb2IvbWFzdGVyL2RyYWZ0LWR1a2UtcXVpYy1sb2FkLWJh bGFuY2Vycy5tZD4sIHdoaWNoIGlzbid0IGFkb3B0ZWQsIGFuZCBtYW55IG9mIHlvdSBhcmUgbm8g ZG91YnQgaGFwcGlseSBpZ25vcmluZy4NCg0KDQoNCiAgICAgIFRoZXJlIGFyZSBiYXNpY2FsbHkg dGhyZWUgdXNlcyBvZiB0aGUgMTQ0IGJpdHMgb2YgQ0lEIGVudHJvcHkgaW4gUVVJQy1MQjoNCg0K DQoNCiAgICAgIDEpIFNlcnZlciBJRCBlbmNvZGluZyAtLSBhcyB0aGVyZSBhcmUgb25seSBzbyBt YW55IHNlcnZlcnMgb25lIG1pZ2h0IGhhdmUsIDE2IGJpdHMgaXMgdXN1YWxseSBlbm91Z2ggZm9y IHRoaXMuDQoNCiAgICAgIDIpICJQcml2YXRlIiBzZXJ2ZXIgZW50cm9weSAtLSB0aGUgbG9hZCBi YWxhbmNlciBkb2Vzbid0IGNhcmUgd2hhdCB0aGUgYml0cyBhcmUsIGJ1dCB0aGV5J3JlIHByb3Rl Y3RlZCBieSBjcnlwdG8uIFRoZSBzZXJ2ZXIgY3JlYXRlZCBhbmQgZW5jcnlwdGVkIHRoZSBDSUQs IHNvIGl0IGNhbiB1c2UgdGhpcyBmb3IgaXRzIGxvY2FsIHB1cnBvc2VzLCBidXQgbm8gb25lIGVs c2UgY2FuLiBUaGUgYW1vdW50IG9mIHRoaXMgZGVwZW5kcywgYnV0IGlmIHlvdSdyZSB1c2luZyBh IDI1Ni1iaXQgYmxvY2sgY2lwaGVyIGl0J3Mgc29tZXRoaW5nIGxpa2UgMjQwIGJpdHMgLS0gcGxl bnR5DQoNCiAgICAgIDMpICAiUHVibGljIiBlbnRyb3B5IC0tIG5vdCBlbmNyeXB0ZWQsIHRoZXNl IGJpdHMgYXJlIHJlYWRhYmxlIGJ5IGFueW9uZSB3aG8gaXMgZmFtaWxpYXIgd2l0aCB0aGUgZW5j b2Rpbmcgc2NoZW1lLiBXaXRoIGEgMTYgQiBlbmNyeXB0aW9uIGJsb2NrLCB3ZSBoYXZlIG9ubHkg MTYgYml0cyB0byBwbGF5IHdpdGggaGVyZS4NCg0KDQoNCiAgICAgIFFVSUMtTEIgaXMgYWxyZWFk eSB0YWtpbmcgMiBvZiB0aGVzZSBsYXN0IGJpdHMgZm9yIGNvbmZpZyByb3RhdGlvbiwgd2hpY2gg YWxsb3dzIHNlcnZlciBwb29scyB0byBpbmNyZW1lbnRhbGx5IGRlcGxveSBuZXcgQ0lEIGtleXMg b3IgZW5jb2Rpbmcgc2NoZW1lcy4gU28gd2UncmUgZG93biB0byAxNCBiaXRzLi4NCg0KDQoNCiAg ICAgIFRoZSBwdWJsaWMgZW50cm9weSBpcyB1c2VmdWwgZm9yIGEgZ3Jvd2luZyBwaWxlIG9mIHRy dXN0ZWQgaGFyZHdhcmUgZGV2aWNlcyB0aGF0IGFyZSBwcmVzdW1hYmx5IG5vdCBnb2luZyB0byBw ZXJmb3JtIENJRCBkZWNyeXB0aW9uLiBPbiBmNSBib3hlcywgd2UgaGF2ZSBhIGhhcmR3YXJlIGRp c2FnZ3JlZ2F0b3IgZm9yIHRoZSBtYW55IGRhdGFwbGFuZSBwcm9jZXNzb3JzIGFuZCB0aHJlYWRz IHRoYXQgYXJlIG9wZXJhdGluZy4gVG9kYXksIHdlJ2QgdXNlIHBlcmhhcHMgOCBvZiB0aGUgYml0 cywgYnV0IGluIGZ1dHVyZSBhcmNoaXRlY3R1cmVzIGV2ZW4gMTQgbWlnaHQgbm90IHF1aXRlIGJl IGVub3VnaC4NCg0KDQoNCg0KDQogICAgICBBbmQgbm93LCBoYXZpbmcgY2hhdHRpbmcgd2l0aCBN YW5hc2kgRGV2YWwgZnJvbSBJbnRlbCBhZnRlciBoZXIgUHJhZ3VlIHRhbGsgYWJvdXQgaGFyZHdh cmUgb2ZmbG9hZCwgSSdtIGZhaXJseSBzdXJlIHdlJ3JlIGdvaW5nIHRvIG5lZWQgNCB0byBjaGVh cGx5IGVuY29kZSB0aGUgY29ubmVjdGlvbiBJRCBsZW5ndGgsIGF0IGxlYXN0IGZvciBzZXJ2ZXJz IHRoYXQgd2FudCB0byB1c2UgdGhpcyBzZXJ2aWNlLg0KDQoNCg0KICAgICAgSWYgd2UgZXZlciB3 YW50ZWQgYSBzb2x1dGlvbiB0aGF0IGFsbG93ZWQgbXVsdGlwbGUgdGllcnMgb2YgbG9hZCBiYWxh bmNpbmcsIHdoaWNoIGlzIG5vdCBjdXJyZW50bHkgaW4gc2NvcGUgZm9yIFFVSUMtTEIsIHdlIGRv bid0IGhhdmUgbmVhcmx5IGVub3VnaCBzcGFjZS4NCg0KDQoNCiAgICAgIEkgc2VlIHRocmVlIG9w dGlvbnM6DQoNCiAgICAgIDEpIElnbm9yZSB0aGUgcHJvYmxlbSAtLSB0aGlzIG1heSByZXN0cmlj dCB0aGUgbnVtYmVyIG9mIHVzZSBjYXNlcyBvZiBRVUlDIGluIHRoZSBmdXR1cmUsIGVzcGVjaWFs bHkgYXMgQ29ubmVjdGlvbiBJRCBsZW5ndGhzIGFyZSBwYXJ0IG9mIHRoZSBpbnZhcmlhbnRzLg0K DQogICAgICAyKSBSZWRlZmluZSB0aGUgRENJTCBhbmQgU0NJTCBmaWVsZHMgdG8gYmUgaGFsZiB0 aGUgY29ubmVjdGlvbiBJRCBsZW5ndGguIFRodXMgQ0lEcyB3b3VsZCBhbHdheXMgaGF2ZSBldmVu IGxlbmd0aHMgYnV0IGNvdWxkIHJ1biB1cCB0byAzMCBCeXRlcy4gRm9yIHdoYXQgaXQncyB3b3J0 aCwgdGhpcyBhbHNvIGVuYWJsZXMgMkIgQ0lEcy4gVGhpcyBpcyBoZWF2eXdlaWdodCBhcyBhIGRp ZmYgdG8gdGhlIGN1cnJlbnQgc3BlYyBidXQgaXMgdGhlIG1vc3QgZnV0dXJlcHJvb2YuIFRoZXJl IGFyZSwgb2YgY291cnNlLCBvdGhlciBtYXBwaW5ncyB3aXRoIGRpZmZlcmVudCBwcm9wZXJ0aWVz IGJ1dCBzaW1pbGFyIGJ1cmVhdWNyYXRpYyBjb3N0cy4NCg0KICAgICAgMykgVGhlcmUgYXJlIHR3 byByZXNlcnZlZCBiaXRzIGluIHRoZSByZWxldmFudCBoZWFkZXIgdHlwZXMuIElmIHdlIGFsbG93 ZWQgdGhlbSB0byBub3QgcmVzb2x2ZSB0byB6ZXJvIHBvc3QtcHJvdGVjdGlvbiwgYW5kIHRoZXJl Zm9yZSBvcGVuZWQgdGhlbSB0byBlbmNvZGUgUVVJQy1MQiBjb25maWcgcm90YXRpb24gaW4gdGhl IGNsZWFyLCB0aGlzIHdvdWxkIG1pdGlnYXRlIHRoZSBwcm9ibGVtIGFuZCBJIGFtIGZhaXJseSBj b25maWRlbnQgdGhhdCB0aGVzZSBiaXRzIHdvdWxkIHZhcnkgZW5vdWdoIHRvIG5vdCBvc3NpZnku IFRoaXMgaXMgYSBsaWdodHdlaWdodCBwcm90b2NvbCBjaGFuZ2UgYnV0IG1heSBqdXN0IHBhcnRs eSByZWxpZXZlIHRoZSBwcmVzc3VyZSB3ZSdyZSBmZWVsaW5nIG5vdy4NCg0KDQoNCiAgICAgIFdo YXQgYXJlIHBlb3BsZSdzIGluaXRpYWwgYXR0aXR1ZGVzPyBVbmxlc3MgdGhlcmUgaXMgc3Ryb25n IGNvbnNlbnN1cyBmb3IgT3B0aW9uICMxIEkgY2FuIGZpbGUgYW4gaXNzdWUgYW5kIHdlIGNhbiBn ZXQgaXQgb24gYW4gYWdlbmRhIHRvIGRpc2N1c3MgaW4gcGVyc29uLg0KDQoNCg0KICAgICAgTWFy dGluDQoNCg0KDQo= --_000_CY4PR22MB098376AEF8602968191281A8DA3A0CY4PR22MB0983namp_ 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 bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGluIHRoZSBzZW1pLWlnbm9yaW5nIFFVSUMtTEIgY2Ft cCwgYXMgSSBiZWxpZXZlIGl04oCZcyBhbiBpbXBvcnRhbnQgcHJvYmxlbSBmb3Igb3RoZXIgcGVv cGxlIHRvIHNvbHZlIHJpZ2h0IG5vdy4mbmJzcDsgKFRoYW5rcywgTWFydGluISk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB0YWtlIG5vIHBhcnRpY3VsYXIgcG9zaXRpb24gb24gd2hldGhlciB0 aGUgMTggYnl0ZSBtYXhpbXVtIGlzIHRvbyBzbWFsbDsgaXQgZmVlbHMgZXhjZXB0aW9uYWxseSBs YXJnZSB0byBtZSwgYnV0IGlmIHdl4oCZcmUgZ2V0dGluZyBhY3R1YWwgaW1wbGVtZW50YXRpb24g ZXhwZXJpZW5jZSB0aGF0IHNob3dzIG90aGVyd2lzZSwgSeKAmW0gaGFwcHkgdG8gaGF2ZSB0aGUg ZGF0YS4mbmJzcDsgSWYgaXQgbmVlZHMgdG8gY2hhbmdlLA0KIEkgYWdyZWUgdGhhdCBPcHRpb24g MiBhcHBlYXJzIHRoZSBtb3N0IGZ1dHVyZXByb29mLCBhbmQgaWYgc29tZXRoaW5nIG5lZWRzIHRv IGNoYW5nZSBpbiB0aGUgaW52YXJpYW50cywgdGhpcyBpcyBhbG1vc3QgdGhlIGxhdGVzdCB3ZSBj b3VsZCBwb3NzaWJseSBkbyBpdC4mbmJzcDsgTm93IG9yIG5ldmVyLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHRoaW5rIE9wdGlvbiAxYSBpcyB0byBub3RlIHRoYXQgdGhlIGludmFyaWFudHMg ZG9u4oCZdCBsaW1pdCB0aGUgbGVuZ3RoIG9mIENJRHMgaW4gYSBnaXZlbiB2ZXJzaW9uIGluIHNo b3J0LWhlYWRlciBwYWNrZXRzOyBhIGZ1dHVyZSB2ZXJzaW9uIGNvdWxkIGRlZmluZSBtdWNoIGxh cmdlciBDSURzIHRvIGJlIHZhbGlkIHBvc3QtaGFuZHNoYWtlLiZuYnNwOyBDb3VwbGVkIHdpdGgg YSB3YXkgdG8gZW5jb3VyYWdlL3JlcXVpcmUNCiBjbGllbnRzIHRvIG1vdmUgb2ZmIG9mIHRoZSBo YW5kc2hha2UgQ0lEIGltbWVkaWF0ZWx5IHBvc3QtaGFuZHNoYWtlLCB0aGlzIG1pZ2h0IGJlIHN1 ZmZpY2llbnQgZm9yIHRoZSByZWFsIHdvcmxkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYg T2YgPC9iPg0KTWFydGluIER1a2U8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAyNiwg MjAxOSA5OjAzIFBNPGJyPg0KPGI+VG86PC9iPiBSeWFuIEhhbWlsdG9uICZsdDtyY2hAZ29vZ2xl LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IENvbm5lY3Rpb24gSUQgU3BhY2U8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9wdGlvbiAyIHdvdWxkIGJlIGEgY2hhbmdlIHRvIHRoZSBp bnZhcmlhbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRnJpLCBBcHIgMjYsIDIwMTksIDE1OjM3IFJ5YW4gSGFtaWx0b24gJmx0OzxhIGhyZWY9Im1h aWx0bzpyY2hAZ29vZ2xlLmNvbSI+cmNoQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssc2Fucy1zZXJpZiI+RG8gSSB1bmRlcnN0YW5kIGNvcnJlY3RseSB0aGF0IHRoaXMg d291bGQgYmUgYSBjaGFuZ2UgdG8gdGhlIGludmFyaWFudHM/Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEFw ciAyNiwgMjAxOSBhdCAyOjQzIFBNIE1hcnRpbiBEdWtlICZsdDs8YSBocmVmPSJtYWlsdG86bWFy dGluLmguZHVrZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4uaC5kdWtlQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHRob3VnaCBpdCBpcyBxdWl0ZSBs YXRlIGluIHRoZSBkYXkgZm9yIHRoaXMgb2JqZWN0aW9uLCBJIGZpbmQgdGhhdCB3ZSBhbHJlYWR5 IGJ1bXBpbmcgdXAgYWdhaW5zdCB0aGUgbGltaXRzIG9mIHRoZSAxOCBieXRlIGNvbm5lY3Rpb24g SUQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkluZXZpdGFibHksIHRoaXMgdG91Y2hlcyBvbiBzb21lIGlzc3VlcyB3ZSdyZSBleHBsb3Jpbmcg aW4gdGhlDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWFydGluZHVrZS9kcmFmdC1kdWtl LXF1aWMtbG9hZC1iYWxhbmNlcnMvYmxvYi9tYXN0ZXIvZHJhZnQtZHVrZS1xdWljLWxvYWQtYmFs YW5jZXJzLm1kIiB0YXJnZXQ9Il9ibGFuayI+DQpxdWljLWxvYWQtYmFsYW5jZXJzIGRyYWZ0PC9h Piwgd2hpY2ggaXNuJ3QgYWRvcHRlZCwgYW5kIG1hbnkgb2YgeW91IGFyZSBubyBkb3VidCBoYXBw aWx5IGlnbm9yaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGVyZSBhcmUgYmFzaWNhbGx5IHRocmVlIHVzZXMgb2YgdGhlIDE0NCBiaXRz IG9mIENJRCBlbnRyb3B5IGluIFFVSUMtTEI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIFNlcnZlciBJRCBlbmNvZGluZyAtLSBhcyB0aGVy ZSBhcmUgb25seSBzbyBtYW55IHNlcnZlcnMgb25lIG1pZ2h0IGhhdmUsIDE2IGJpdHMgaXMgdXN1 YWxseSBlbm91Z2ggZm9yIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4yKSAmcXVvdDtQcml2YXRlJnF1b3Q7IHNlcnZlciBlbnRyb3B5IC0t IHRoZSBsb2FkIGJhbGFuY2VyIGRvZXNuJ3QgY2FyZSB3aGF0IHRoZSBiaXRzIGFyZSwgYnV0IHRo ZXkncmUgcHJvdGVjdGVkIGJ5IGNyeXB0by4gVGhlIHNlcnZlciBjcmVhdGVkIGFuZCBlbmNyeXB0 ZWQgdGhlIENJRCwgc28gaXQgY2FuIHVzZSB0aGlzIGZvciBpdHMgbG9jYWwgcHVycG9zZXMsIGJ1 dCBubyBvbmUgZWxzZSBjYW4uIFRoZSBhbW91bnQgb2YgdGhpcw0KIGRlcGVuZHMsIGJ1dCBpZiB5 b3UncmUgdXNpbmcgYSAyNTYtYml0IGJsb2NrIGNpcGhlciBpdCdzIHNvbWV0aGluZyBsaWtlIDI0 MCBiaXRzIC0tIHBsZW50eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MykmbmJzcDsgJnF1b3Q7UHVibGljJnF1b3Q7IGVudHJvcHkgLS0gbm90IGVu Y3J5cHRlZCwgdGhlc2UgYml0cyBhcmUgcmVhZGFibGUgYnkgYW55b25lIHdobyBpcyBmYW1pbGlh ciB3aXRoIHRoZSBlbmNvZGluZyBzY2hlbWUuIFdpdGggYSAxNiBCIGVuY3J5cHRpb24gYmxvY2ss IHdlIGhhdmUgb25seSAxNiBiaXRzIHRvIHBsYXkgd2l0aCBoZXJlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RVUlDLUxCIGlzIGFscmVhZHkg dGFraW5nIDIgb2YgdGhlc2UgbGFzdCBiaXRzIGZvciBjb25maWcgcm90YXRpb24sIHdoaWNoIGFs bG93cyBzZXJ2ZXIgcG9vbHMgdG8gaW5jcmVtZW50YWxseSBkZXBsb3kgbmV3IENJRCBrZXlzIG9y IGVuY29kaW5nIHNjaGVtZXMuIFNvIHdlJ3JlIGRvd24gdG8gMTQgYml0cy4uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwdWJsaWMgZW50 cm9weSBpcyB1c2VmdWwgZm9yIGEgZ3Jvd2luZyBwaWxlIG9mIHRydXN0ZWQgaGFyZHdhcmUgZGV2 aWNlcyB0aGF0IGFyZSBwcmVzdW1hYmx5IG5vdCBnb2luZyB0byBwZXJmb3JtIENJRCBkZWNyeXB0 aW9uLiBPbiBmNSBib3hlcywgd2UgaGF2ZSBhIGhhcmR3YXJlIGRpc2FnZ3JlZ2F0b3IgZm9yIHRo ZSBtYW55IGRhdGFwbGFuZSBwcm9jZXNzb3JzIGFuZCB0aHJlYWRzIHRoYXQgYXJlIG9wZXJhdGlu Zy4NCiBUb2RheSwgd2UnZCB1c2UgcGVyaGFwcyA4IG9mIHRoZSBiaXRzLCBidXQgaW4gZnV0dXJl IGFyY2hpdGVjdHVyZXMgZXZlbiAxNCBtaWdodCBub3QgcXVpdGUgYmUgZW5vdWdoLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBub3cs IGhhdmluZyBjaGF0dGluZyB3aXRoIE1hbmFzaSBEZXZhbCBmcm9tIEludGVsIGFmdGVyIGhlciBQ cmFndWUgdGFsayBhYm91dCBoYXJkd2FyZSBvZmZsb2FkLCBJJ20gZmFpcmx5IHN1cmUgd2UncmUg Z29pbmcgdG8gbmVlZCA0IHRvIGNoZWFwbHkgZW5jb2RlIHRoZSBjb25uZWN0aW9uIElEIGxlbmd0 aCwgYXQgbGVhc3QgZm9yIHNlcnZlcnMgdGhhdCB3YW50IHRvIHVzZSB0aGlzIHNlcnZpY2UuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdl IGV2ZXIgd2FudGVkIGEgc29sdXRpb24gdGhhdCBhbGxvd2VkIG11bHRpcGxlIHRpZXJzIG9mIGxv YWQgYmFsYW5jaW5nLCB3aGljaCBpcyBub3QgY3VycmVudGx5IGluIHNjb3BlIGZvciBRVUlDLUxC LCB3ZSBkb24ndCBoYXZlIG5lYXJseSBlbm91Z2ggc3BhY2UuDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzZWUgdGhyZWUgb3B0aW9uczo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIEln bm9yZSB0aGUgcHJvYmxlbSAtLSB0aGlzIG1heSByZXN0cmljdCB0aGUgbnVtYmVyIG9mIHVzZSBj YXNlcyBvZiBRVUlDIGluIHRoZSBmdXR1cmUsIGVzcGVjaWFsbHkgYXMgQ29ubmVjdGlvbiBJRCBs ZW5ndGhzIGFyZSBwYXJ0IG9mIHRoZSBpbnZhcmlhbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgUmVkZWZpbmUgdGhlIERDSUwgYW5kIFND SUwgZmllbGRzIHRvIGJlIGhhbGYgdGhlIGNvbm5lY3Rpb24gSUQgbGVuZ3RoLiBUaHVzIENJRHMg d291bGQgYWx3YXlzIGhhdmUgZXZlbiBsZW5ndGhzIGJ1dCBjb3VsZCBydW4gdXAgdG8gMzAgQnl0 ZXMuIEZvciB3aGF0IGl0J3Mgd29ydGgsIHRoaXMgYWxzbyBlbmFibGVzIDJCIENJRHMuIFRoaXMg aXMgaGVhdnl3ZWlnaHQgYXMgYSBkaWZmIHRvIHRoZSBjdXJyZW50DQogc3BlYyBidXQgaXMgdGhl IG1vc3QgZnV0dXJlcHJvb2YuIFRoZXJlIGFyZSwgb2YgY291cnNlLCBvdGhlciBtYXBwaW5ncyB3 aXRoIGRpZmZlcmVudCBwcm9wZXJ0aWVzIGJ1dCBzaW1pbGFyIGJ1cmVhdWNyYXRpYyBjb3N0cy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIFRo ZXJlIGFyZSB0d28gcmVzZXJ2ZWQgYml0cyBpbiB0aGUgcmVsZXZhbnQgaGVhZGVyIHR5cGVzLiBJ ZiB3ZSBhbGxvd2VkIHRoZW0gdG8gbm90IHJlc29sdmUgdG8gemVybyBwb3N0LXByb3RlY3Rpb24s IGFuZCB0aGVyZWZvcmUgb3BlbmVkIHRoZW0gdG8gZW5jb2RlIFFVSUMtTEIgY29uZmlnIHJvdGF0 aW9uIGluIHRoZSBjbGVhciwgdGhpcyB3b3VsZCBtaXRpZ2F0ZSB0aGUgcHJvYmxlbSBhbmQgSSBh bSBmYWlybHkNCiBjb25maWRlbnQgdGhhdCB0aGVzZSBiaXRzIHdvdWxkIHZhcnkgZW5vdWdoIHRv IG5vdCBvc3NpZnkuIFRoaXMgaXMgYSBsaWdodHdlaWdodCBwcm90b2NvbCBjaGFuZ2UgYnV0IG1h eSBqdXN0IHBhcnRseSByZWxpZXZlIHRoZSBwcmVzc3VyZSB3ZSdyZSBmZWVsaW5nIG5vdy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBh cmUgcGVvcGxlJ3MgaW5pdGlhbCBhdHRpdHVkZXM/IFVubGVzcyB0aGVyZSBpcyBzdHJvbmcgY29u c2Vuc3VzIGZvciBPcHRpb24gIzEgSSBjYW4gZmlsZSBhbiBpc3N1ZSBhbmQgd2UgY2FuIGdldCBp dCBvbiBhbiBhZ2VuZGEgdG8gZGlzY3VzcyBpbiBwZXJzb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcnRpbjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR22MB098376AEF8602968191281A8DA3A0CY4PR22MB0983namp_-- From nobody Tue Apr 30 12:14:47 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC81200EC for ; Tue, 30 Apr 2019 12:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 PZiSZCpiz-dT for ; Tue, 30 Apr 2019 12:14:44 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CC912011E for ; Tue, 30 Apr 2019 12:14:43 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id i31so8842507qti.13 for ; Tue, 30 Apr 2019 12:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=D0QMUIugyrJkknX1TCrhL1wOAMhpHa65jjFLl3Vi0D4=; b=HugJVRU3jfyS//lr+XxjrgAJBK3cyKiemo+FVPqGkmDszqrCJex+rNa5I9Wj9ExtLD dAQcGTo5LFcVLHbHsqR4BpDeznA06CysZq+gEcHLOwE+H21kPp52OynV8YZBuhr0xagM b8mmmLkqPqchmzjf+wWBo39/kF92YOVVSNCaZ6iOQs6HyL78AtICcMZMvxda/bNt0VIr hVrOttc4T0YvGTSwcdksSZ+BaE1mn7DAAAQOyaIQHCjSLApXGRgynNM8OTbslT4Of5A6 rp5McfEnQVR9vazdSxWqlE+G2pQYanOPqnCfeQCxkmsHLiTzkGRWg039inFZbjVNQfkE WazA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=D0QMUIugyrJkknX1TCrhL1wOAMhpHa65jjFLl3Vi0D4=; b=k2L0QXVbmSgVsA3Gp9VhzYvXS+8HBkVAq5QQHpAzQoyPMY2MscSN6aN6OPc8AHOUcD hmpTCyrX9QgL16U5WRPC3/5IZmcvOpGqfaiI7qzZbbOHAH1HBfdajZTgG3a0V8D8Y6Yi Y4lxgqkyUE8/N2be2+re/jPo+4h78u39FHymllsX7rOFDnLhgxdy8anMGu7TAZFH65B0 Tiv3UncZKnA4DpED0DzQ9hGdAUWRkxULYZCVlZ9SLVdNpyePvHqjdRwdeFHJqu3RwTG3 zptVsr4Zet9dSITmO7f0ZlEPRdqvP4Yb2nb2XLyhIOvJgKGoMDPG2OMLSu859IDX5qCZ 7YLw== X-Gm-Message-State: APjAAAXYaYhqyw5biPGjfKbOGyvePPSvPwBItjVfEqUPXJ/sUHt3VpOt bT5DiYK8wu7eXEMqkWELDcGaWmpT X-Google-Smtp-Source: APXvYqyERZzNX9FVKTNi8isqB1KersBTtK5rOO9AJHnVGK78mAT8HKv5oEZGtxSp6h67jpdX/EjofA== X-Received: by 2002:ac8:26fc:: with SMTP id 57mr56578001qtp.265.1556651682694; Tue, 30 Apr 2019 12:14:42 -0700 (PDT) Received: from [192.168.11.58] (D8FF7f43.cst.lightpath.net. [216.255.127.67]) by smtp.gmail.com with ESMTPSA id t7sm18796276qte.74.2019.04.30.12.14.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2019 12:14:42 -0700 (PDT) To: quic@ietf.org From: John Wason Subject: QUIC for robotics and other time-sensitive applications Message-ID: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> Date: Tue, 30 Apr 2019 15:14:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 19:14:46 -0000 Greetings QUIC WG, The discussion on Issue #92 of webrtc-quic suggested that I post my requirements to this list. I am a robotics engineer and the developer of Robot Raconteur, a communication framework for robotics and automation systems (https://github.com/robotraconteur/robotraconteur). Robotics applications require different data types and QoS when compared to business or web applications. Robotics applications need real-time communication of isochronous data, for instance constant updates on the position of the joints of the robot, alongside generic non-time-sensitive data. Currently most robotics applications are using TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add more confusion to the situation, there is the recent introduction of IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP and UDP to achieve hard real-time performance. While there are many robotics protocols out there, only Robot Raconteur and OPC/UA are compatible with existing web and cloud infrastructure. (Some limited support for ROS/ROS2 has become available on AWS, but the design of ROS does not play very well outside of local networks.*) Robot Raconteur implements web browser and web server support by allowing the websocket protocol to be used. Clients can use a URL that specifies that the connection is a websocket, and incoming TCP connections can detect if the connection is the Robot Raconteur protocol or an incoming websocket connection. Robot Raconteur running inside an ASP.NET web server has been demonstrated, and there is no technical reason that other server technologies cannot accept Robot Raconteur connections through websockets. (OPC/UA uses SOAP for its web based transport, but support is very poor and only available in a few implementations.) The main issue limiting Robot Raconteur for more demanding applications is the use of TCP for data transport. TCP suffers from "head-of-line" blocking, which means that if stale data encounters an error it can stop fresh data from reaching the other peer. There is also the problem of large messages blocking the transmission of smaller, more time sensitive messages on the connection. QUIC appears to solve most of these problems, and the webrtc-quic support under development provides a lot of new and interesting opportunities for integrating robotics applications with web technology. By adopting QUIC, the resulting software will remain completely compatible with web infrastructure. Transmitting time-sensitive data requires the ability to multiplex (and prioritize) messages and drop messages if the data contained becomes stale. The multiplexing issue is solved using the "streams as messages" concept in QUIC, with built in priority handling. This design looks very promising, and considerably simpler to use compared to SCTP streams. The current issue that is somewhat questionable is the implementation of partial reliability. The discussion right now is focused on DATAGRAM extensions (draft-pauly-quic-datagram-02), which allow for "raw" access to the socket so protocols such as RTP can tunnel through QUIC. This requirement is quite a bit different than what is required for an application like Robot Raconteur. Robot Raconteur is based on message passing, where either the entire message is received or the entire message is cancelled because the data contained is stale. The message may be considerably larger than MTU, and the QoS may be "partial," meaning that a set number of attempts may be made to resend, and/or there is an expiration time on the message. This capability is discussed in draft-lubashev-quic-partial-reliability-03, and is similar to how SCTP handles partial reliability. If only a raw DATAGRAM capability is provided, then partial reliability will need to be built on top of QUIC, defeating the purpose of using QUIC for this application. Other applications such as online gaming have very similar performance requirements, so I think that the partial reliability capability will be important to many future users. The complexity and required effort to add the partial reliability capability to QUIC is low, so I hope that this capability is not abandoned. Robot Raconteur has received a grant from the United States ARM Institute and New York State to begin commercializing the technology. This project will be done in partnership with Wason Technology, LLC, Rensselaer Polytechnic Institute, Southwest Research Institute, and United Technologies Research Center. The project starts soon, and considerable development effort will be invested in the Robot Raconteur technology starting early summer. Integrating QUIC is one of the tasks that I hope to undertake during this project. Please let me know if you have any questions about Robot Raconteur or the requirements for QUIC in robotics applications.     -John Wason (* I am aware that there are some caveats to how ROS/ROS2 interact with the wider world, but the technologies are not built on or compatible with web standards so an in depth discussion is not relevant for the current topic. ROS does have a UDP transport, but it is not commonly used.) -- John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com From nobody Tue Apr 30 14:38:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CB31202DF for ; Tue, 30 Apr 2019 14:38:18 -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 jPYzzOvl3UNA for ; Tue, 30 Apr 2019 14:38:15 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96218120329 for ; Tue, 30 Apr 2019 14:38:15 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id v143so7282111itc.1 for ; Tue, 30 Apr 2019 14:38:15 -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=FbYlCsiqrAviDo6VZ/udEeEfw6OrE5gPHSdTtQWvKWM=; b=OVqAWQIgrC8Gil8vB4EmZYJcKWSt4Xp8NvZkCvmuCxjLw50HcD+SI/Sxhf6XEhrEWY 1D7kW2eTSdO7wJGq3idRCIuISjQxRMlyeCS8UTX6J/vjieq4AnZ+iRSaNOYOS24jyXKm DiuGl8xOU4Qvz+/XFZ/J1xzgSTcSz25gCJP3XBKGh1N5cv5MqLnnST4pejnlUqBGDL3X PaHmK/dEpyF1xIhhR7OKVwIKEpJPFTlkLTSSTpUVT1HYHxmL7Gi1aUjyUmVkEOYwgsnS C2Xe7UXmrF8a5mvsBHMJGb8oMbKnQfC5z0+ZsoNXVI4WsEk4DFKl9BQi7FaUByTNIK8I hQYQ== 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=FbYlCsiqrAviDo6VZ/udEeEfw6OrE5gPHSdTtQWvKWM=; b=Qc0MNjG5gtishqJAt6BTSGE4y/iIPHkrt2mkKVdGvefT1oMAFpR0piJa2O0bhC90OG CeWEmB7LmTQL2VBB7RfN9XtS5tLGYXsmTixijS6+lubLW58V0kmxS/vRj26RcvR5W793 tZiQb23Myb3bP2/3rawQez7+6rejJbyUSqfaWfM75j22oL4rvuZ+Kcvr6veL0x7Hm0gU JW54/KZni4OCCAbgYpiIgEqA69hxJyWb9jjlmeQBP2Saymbc+XzTu6mek4hBJ7JSfcK2 UzjlM/mCM32CSObgLVA9bTOR/B0+RjdhRWaa2I10EYGbQbJ8io3mTFqB9YB+sHsfdwJZ dkKg== X-Gm-Message-State: APjAAAWr3BVuqCurYNXmylYeyyqWCD1p04MBeOgoMzh3HLq+hmVeCim7 TxoWqKTWq8r1wgy7IiuFX7XEp47TaS0C8bsLPek= X-Google-Smtp-Source: APXvYqzHCkwjuPK98mc6yuyg6ra5/cBsv80JFkd8TAyUGe5HjJNN6Z9tjvPTG/WMYkCHpnK+o4eqqajiAijMA832bok= X-Received: by 2002:a02:8563:: with SMTP id g90mr21042261jai.11.1556660294567; Tue, 30 Apr 2019 14:38:14 -0700 (PDT) MIME-Version: 1.0 References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> In-Reply-To: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> From: Ted Hardie Date: Tue, 30 Apr 2019 14:37:48 -0700 Message-ID: Subject: Re: QUIC for robotics and other time-sensitive applications To: John Wason Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e4cbac0587c6373e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 21:38:19 -0000 --000000000000e4cbac0587c6373e Content-Type: text/plain; charset="UTF-8" Hi John, Thanks for the message. If you have not already reviewed the work of DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the IETF, it might be useful to do so, as there are a number of elements of your use case which appeared to be shared with their work. In particular, it might be useful to consider whether the integration of their proposed IP data plane ( https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1) with QUIC would be valuable in achieving your timing goals. best regard, Ted Hardie On Tue, Apr 30, 2019 at 12:15 PM John Wason wrote: > Greetings QUIC WG, > > The discussion on Issue #92 of webrtc-quic suggested that I post my > requirements to this list. > > I am a robotics engineer and the developer of Robot Raconteur, a > communication framework for robotics and automation systems > (https://github.com/robotraconteur/robotraconteur). Robotics > applications require different data types and QoS when compared to > business or web applications. Robotics applications need real-time > communication of isochronous data, for instance constant updates on the > position of the joints of the robot, alongside generic > non-time-sensitive data. Currently most robotics applications are using > TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form > of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add > more confusion to the situation, there is the recent introduction of > IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP > and UDP to achieve hard real-time performance. > > While there are many robotics protocols out there, only Robot Raconteur > and OPC/UA are compatible with existing web and cloud infrastructure. > (Some limited support for ROS/ROS2 has become available on AWS, but the > design of ROS does not play very well outside of local networks.*) Robot > Raconteur implements web browser and web server support by allowing the > websocket protocol to be used. Clients can use a URL that specifies that > the connection is a websocket, and incoming TCP connections can detect > if the connection is the Robot Raconteur protocol or an incoming > websocket connection. Robot Raconteur running inside an ASP.NET web > server has been demonstrated, and there is no technical reason that > other server technologies cannot accept Robot Raconteur connections > through websockets. (OPC/UA uses SOAP for its web based transport, but > support is very poor and only available in a few implementations.) > > The main issue limiting Robot Raconteur for more demanding applications > is the use of TCP for data transport. TCP suffers from "head-of-line" > blocking, which means that if stale data encounters an error it can stop > fresh data from reaching the other peer. There is also the problem of > large messages blocking the transmission of smaller, more time sensitive > messages on the connection. QUIC appears to solve most of these > problems, and the webrtc-quic support under development provides a lot > of new and interesting opportunities for integrating robotics > applications with web technology. By adopting QUIC, the resulting > software will remain completely compatible with web infrastructure. > > Transmitting time-sensitive data requires the ability to multiplex (and > prioritize) messages and drop messages if the data contained becomes > stale. The multiplexing issue is solved using the "streams as messages" > concept in QUIC, with built in priority handling. This design looks very > promising, and considerably simpler to use compared to SCTP streams. The > current issue that is somewhat questionable is the implementation of > partial reliability. The discussion right now is focused on DATAGRAM > extensions (draft-pauly-quic-datagram-02), which allow for "raw" access > to the socket so protocols such as RTP can tunnel through QUIC. This > requirement is quite a bit different than what is required for an > application like Robot Raconteur. Robot Raconteur is based on message > passing, where either the entire message is received or the entire > message is cancelled because the data contained is stale. The message > may be considerably larger than MTU, and the QoS may be "partial," > meaning that a set number of attempts may be made to resend, and/or > there is an expiration time on the message. This capability is discussed > in draft-lubashev-quic-partial-reliability-03, and is similar to how > SCTP handles partial reliability. If only a raw DATAGRAM capability is > provided, then partial reliability will need to be built on top of QUIC, > defeating the purpose of using QUIC for this application. Other > applications such as online gaming have very similar performance > requirements, so I think that the partial reliability capability will be > important to many future users. > > The complexity and required effort to add the partial reliability > capability to QUIC is low, so I hope that this capability is not abandoned. > > Robot Raconteur has received a grant from the United States ARM > Institute and New York State to begin commercializing the technology. > This project will be done in partnership with Wason Technology, LLC, > Rensselaer Polytechnic Institute, Southwest Research Institute, and > United Technologies Research Center. The project starts soon, and > considerable development effort will be invested in the Robot Raconteur > technology starting early summer. Integrating QUIC is one of the tasks > that I hope to undertake during this project. > > Please let me know if you have any questions about Robot Raconteur or > the requirements for QUIC in robotics applications. > > -John Wason > > (* I am aware that there are some caveats to how ROS/ROS2 interact with > the wider world, but the technologies are not built on or compatible > with web standards so an in depth discussion is not relevant for the > current topic. ROS does have a UDP transport, but it is not commonly used.) > > -- > John Wason, Ph.D. > Wason Technology, LLC > 16 Sterling Lake Rd > Tuxedo, NY 10987 > (518) 279-6234 > wason@wasontech.com > > --000000000000e4cbac0587c6373e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,
=
Thanks for the message.=C2=A0 If you have not already review= ed the work of DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the IETF, = it might be useful to do so, as there are a number of elements of your use = case which appeared to be shared with their work.=C2=A0 In particular, it m= ight be useful to consider whether the integration of their proposed IP dat= a plane (https://datatracker.ietf.org/doc/draft-ietf-detnet= -dp-sol-ip/?include_text=3D1) with QUIC would be valuable in achieving = your timing goals.


best regard,

Ted Hardie

On Tue, Apr 30, 2019= at 12:15 PM John Wason <johnwas= on1@gmail.com> wrote:
Greetings QUIC WG,

The discussion on Issue #92 of webrtc-quic suggested that I post my
requirements to this list.

I am a robotics engineer and the developer of Robot Raconteur, a
communication framework for robotics and automation systems
(https://github.com/robotraconteur/robotraconteur). Robotics
applications require different data types and QoS when compared to
business or web applications. Robotics applications need real-time
communication of isochronous data, for instance constant updates on the position of the joints of the robot, alongside generic
non-time-sensitive data. Currently most robotics applications are using TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add
more confusion to the situation, there is the recent introduction of
IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP
and UDP to achieve hard real-time performance.

While there are many robotics protocols out there, only Robot Raconteur and OPC/UA are compatible with existing web and cloud infrastructure.
(Some limited support for ROS/ROS2 has become available on AWS, but the design of ROS does not play very well outside of local networks.*) Robot Raconteur implements web browser and web server support by allowing the websocket protocol to be used. Clients can use a URL that specifies that the connection is a websocket, and incoming TCP connections can detect
if the connection is the Robot Raconteur protocol or an incoming
websocket connection. Robot Raconteur running inside an ASP.NET web
server has been demonstrated, and there is no technical reason that
other server technologies cannot accept Robot Raconteur connections
through websockets. (OPC/UA uses SOAP for its web based transport, but
support is very poor and only available in a few implementations.)

The main issue limiting Robot Raconteur for more demanding applications is the use of TCP for data transport. TCP suffers from "head-of-line&q= uot;
blocking, which means that if stale data encounters an error it can stop fresh data from reaching the other peer. There is also the problem of
large messages blocking the transmission of smaller, more time sensitive messages on the connection. QUIC appears to solve most of these
problems, and the webrtc-quic support under development provides a lot
of new and interesting opportunities for integrating robotics
applications with web technology. By adopting QUIC, the resulting
software will remain completely compatible with web infrastructure.

Transmitting time-sensitive data requires the ability to multiplex (and prioritize) messages and drop messages if the data contained becomes
stale. The multiplexing issue is solved using the "streams as messages= "
concept in QUIC, with built in priority handling. This design looks very promising, and considerably simpler to use compared to SCTP streams. The current issue that is somewhat questionable is the implementation of
partial reliability. The discussion right now is focused on DATAGRAM
extensions (draft-pauly-quic-datagram-02), which allow for "raw" = access
to the socket so protocols such as RTP can tunnel through QUIC. This
requirement is quite a bit different than what is required for an
application like Robot Raconteur. Robot Raconteur is based on message
passing, where either the entire message is received or the entire
message is cancelled because the data contained is stale. The message
may be considerably larger than MTU, and the QoS may be "partial,"= ;
meaning that a set number of attempts may be made to resend, and/or
there is an expiration time on the message. This capability is discussed in draft-lubashev-quic-partial-reliability-03, and is similar to how
SCTP handles partial reliability. If only a raw DATAGRAM capability is
provided, then partial reliability will need to be built on top of QUIC, defeating the purpose of using QUIC for this application. Other
applications such as online gaming have very similar performance
requirements, so I think that the partial reliability capability will be important to many future users.

The complexity and required effort to add the partial reliability
capability to QUIC is low, so I hope that this capability is not abandoned.=

Robot Raconteur has received a grant from the United States ARM
Institute and New York State to begin commercializing the technology.
This project will be done in partnership with Wason Technology, LLC,
Rensselaer Polytechnic Institute, Southwest Research Institute, and
United Technologies Research Center. The project starts soon, and
considerable development effort will be invested in the Robot Raconteur technology starting early summer. Integrating QUIC is one of the tasks
that I hope to undertake during this project.

Please let me know if you have any questions about Robot Raconteur or
the requirements for QUIC in robotics applications.

=C2=A0=C2=A0=C2=A0=C2=A0 -John Wason

(* I am aware that there are some caveats to how ROS/ROS2 interact with the wider world, but the technologies are not built on or compatible
with web standards so an in depth discussion is not relevant for the
current topic. ROS does have a UDP transport, but it is not commonly used.)=

--
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.co= m

--000000000000e4cbac0587c6373e-- From nobody Tue Apr 30 14:51:46 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2D61203C5 for ; Tue, 30 Apr 2019 14:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, 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 Zfm7rpAOS_ua for ; Tue, 30 Apr 2019 14:51:41 -0700 (PDT) Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B701203D1 for ; Tue, 30 Apr 2019 14:51:41 -0700 (PDT) Received: by mail-yw1-xc2f.google.com with SMTP id u14so7085365ywe.1 for ; Tue, 30 Apr 2019 14:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ZxxVJsNIEK2U142vZ/lzubtTEwjHU7wZz/tiEZChK+s=; b=nCXK4yHZ0T9fVk/qc5kLfKW7O/jYoDdXo1XXZo8+m2lrJ5Et9YIaGJ5qVWT6kAV0zV D5ptkCVaL1PgkauTi/y83TMQ8HqdrD2O2zU/2KuFu7aWRxP6wqj1HmCxj83iuJcaJkCg FIJA+co4xonTmaRRjlb4vYe4bMKRmAeoEENQFjo1nghwT3P+5usdYPOOP9Sqb/3sEHxf 2Z9JmKWeO/OBIbGl2+2aBqxfvcwrGltLc1SKdAw80FMWsmns5n+s7govnvuEx3F6e4XO uXjC1ddhvU/Hx9d+pV9//JY8LrBoDbdOjvkoHT+BrnRCQy1EVOrnwxOW63byIcHtT2eG rUGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ZxxVJsNIEK2U142vZ/lzubtTEwjHU7wZz/tiEZChK+s=; b=QW4tTAvzhGJETB+FelGe20wVi1MBtDov6u1mU6q9mbPvFP0QcV0aQSnUg0EIGXa8hv 0cvC6oP/DKk1GiO5c9OWMTk2GVYOuGIcJuk4RA7+Ox667gez4nzLvWpaOnguDUBjG96g mmKd6f/+shm2tK1I87TC29+9TZG0PrDkdXzwZ1KAF4kVifN/tDIQqz3MC0OntwZ0Z3Ku UV+drR0mRLFXqI70yMwk7EQSCKxnZXhjA3tU76a8F11ZLF5D8wv+y4jl1WCtKCwMBRfD +1jKWMkjwye1u/4xjqukBUzELPb+NZID/YO8PdZCeMjq0ifz09H0s/T/9q6JM2azsw43 Nmtg== X-Gm-Message-State: APjAAAUW4hvWNXxoNK+hd5RqHtXDd3qadduumMTDgDzTGgvY3KsDtqRg wIZ0YQSnDAs1aDzZbQSdsO7fnX2v X-Google-Smtp-Source: APXvYqx5nKS75sbU1PPq6zms/v93zTET3euAgslFS7KJBxvfvOcmnReS26YMYhYn+GZdoVCjBNk6+Q== X-Received: by 2002:a25:9d06:: with SMTP id i6mr57735687ybp.347.1556661100195; Tue, 30 Apr 2019 14:51:40 -0700 (PDT) Received: from [192.168.11.58] (D8FF7f43.cst.lightpath.net. [216.255.127.67]) by smtp.gmail.com with ESMTPSA id t85sm5089799ywc.92.2019.04.30.14.51.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2019 14:51:39 -0700 (PDT) Subject: Re: QUIC for robotics and other time-sensitive applications To: Ted Hardie Cc: IETF QUIC WG References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> From: John Wason Message-ID: Date: Tue, 30 Apr 2019 17:51:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AAFE7B29E72D876856BF135D" Content-Language: en-US Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 21:51:44 -0000 This is a multi-part message in MIME format. --------------AAFE7B29E72D876856BF135D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Ted, this looks very interesting. Based on these documents the DETNET sits below the level of QUIC that we are currently discussing and would mainly affect the IP header format of the resulting UDP packets. The QUIC protocol will still require some form of partial reliability to function on a DETNET network.     -John Wason On 4/30/2019 5:37 PM, Ted Hardie wrote: > Hi John, > > Thanks for the message.  If you have not already reviewed the work of > DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the > IETF, it might be useful to do so, as there are a number of elements > of your use case which appeared to be shared with their work.  In > particular, it might be useful to consider whether the integration of > their proposed IP data plane > (https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1) > with QUIC would be valuable in achieving your timing goals. > > > best regard, > > Ted Hardie > > On Tue, Apr 30, 2019 at 12:15 PM John Wason > wrote: > > Greetings QUIC WG, > > The discussion on Issue #92 of webrtc-quic suggested that I post my > requirements to this list. > > I am a robotics engineer and the developer of Robot Raconteur, a > communication framework for robotics and automation systems > (https://github.com/robotraconteur/robotraconteur). Robotics > applications require different data types and QoS when compared to > business or web applications. Robotics applications need real-time > communication of isochronous data, for instance constant updates > on the > position of the joints of the robot, alongside generic > non-time-sensitive data. Currently most robotics applications are > using > TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or > some form > of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To > add > more confusion to the situation, there is the recent introduction of > IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP > and UDP to achieve hard real-time performance. > > While there are many robotics protocols out there, only Robot > Raconteur > and OPC/UA are compatible with existing web and cloud infrastructure. > (Some limited support for ROS/ROS2 has become available on AWS, > but the > design of ROS does not play very well outside of local networks.*) > Robot > Raconteur implements web browser and web server support by > allowing the > websocket protocol to be used. Clients can use a URL that > specifies that > the connection is a websocket, and incoming TCP connections can > detect > if the connection is the Robot Raconteur protocol or an incoming > websocket connection. Robot Raconteur running inside an ASP.NET > web > server has been demonstrated, and there is no technical reason that > other server technologies cannot accept Robot Raconteur connections > through websockets. (OPC/UA uses SOAP for its web based transport, > but > support is very poor and only available in a few implementations.) > > The main issue limiting Robot Raconteur for more demanding > applications > is the use of TCP for data transport. TCP suffers from "head-of-line" > blocking, which means that if stale data encounters an error it > can stop > fresh data from reaching the other peer. There is also the problem of > large messages blocking the transmission of smaller, more time > sensitive > messages on the connection. QUIC appears to solve most of these > problems, and the webrtc-quic support under development provides a > lot > of new and interesting opportunities for integrating robotics > applications with web technology. By adopting QUIC, the resulting > software will remain completely compatible with web infrastructure. > > Transmitting time-sensitive data requires the ability to multiplex > (and > prioritize) messages and drop messages if the data contained becomes > stale. The multiplexing issue is solved using the "streams as > messages" > concept in QUIC, with built in priority handling. This design > looks very > promising, and considerably simpler to use compared to SCTP > streams. The > current issue that is somewhat questionable is the implementation of > partial reliability. The discussion right now is focused on DATAGRAM > extensions (draft-pauly-quic-datagram-02), which allow for "raw" > access > to the socket so protocols such as RTP can tunnel through QUIC. This > requirement is quite a bit different than what is required for an > application like Robot Raconteur. Robot Raconteur is based on message > passing, where either the entire message is received or the entire > message is cancelled because the data contained is stale. The message > may be considerably larger than MTU, and the QoS may be "partial," > meaning that a set number of attempts may be made to resend, and/or > there is an expiration time on the message. This capability is > discussed > in draft-lubashev-quic-partial-reliability-03, and is similar to how > SCTP handles partial reliability. If only a raw DATAGRAM > capability is > provided, then partial reliability will need to be built on top of > QUIC, > defeating the purpose of using QUIC for this application. Other > applications such as online gaming have very similar performance > requirements, so I think that the partial reliability capability > will be > important to many future users. > > The complexity and required effort to add the partial reliability > capability to QUIC is low, so I hope that this capability is not > abandoned. > > Robot Raconteur has received a grant from the United States ARM > Institute and New York State to begin commercializing the technology. > This project will be done in partnership with Wason Technology, LLC, > Rensselaer Polytechnic Institute, Southwest Research Institute, and > United Technologies Research Center. The project starts soon, and > considerable development effort will be invested in the Robot > Raconteur > technology starting early summer. Integrating QUIC is one of the > tasks > that I hope to undertake during this project. > > Please let me know if you have any questions about Robot Raconteur or > the requirements for QUIC in robotics applications. > >      -John Wason > > (* I am aware that there are some caveats to how ROS/ROS2 interact > with > the wider world, but the technologies are not built on or compatible > with web standards so an in depth discussion is not relevant for the > current topic. ROS does have a UDP transport, but it is not > commonly used.) > > -- > John Wason, Ph.D. > Wason Technology, LLC > 16 Sterling Lake Rd > Tuxedo, NY 10987 > (518) 279-6234 > wason@wasontech.com > -- John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com --------------AAFE7B29E72D876856BF135D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks Ted, this looks very interesting. Based on these documents the DETNET sits below the level of QUIC that we are currently discussing and would mainly affect the IP header format of the resulting UDP packets. The QUIC protocol will still require some form of partial reliability to function on a DETNET network.

    -John Wason

On 4/30/2019 5:37 PM, Ted Hardie wrote:
Hi John,

Thanks for the message.  If you have not already reviewed the work of DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the IETF, it might be useful to do so, as there are a number of elements of your use case which appeared to be shared with their work.  In particular, it might be useful to consider whether the integration of their proposed IP data plane (https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1) with QUIC would be valuable in achieving your timing goals.


best regard,

Ted Hardie

On Tue, Apr 30, 2019 at 12:15 PM John Wason <johnwason1@gmail.com> wrote:
Greetings QUIC WG,

The discussion on Issue #92 of webrtc-quic suggested that I post my
requirements to this list.

I am a robotics engineer and the developer of Robot Raconteur, a
communication framework for robotics and automation systems
(https://github.com/robotraconteur/robotraconteur). Robotics
applications require different data types and QoS when compared to
business or web applications. Robotics applications need real-time
communication of isochronous data, for instance constant updates on the
position of the joints of the robot, alongside generic
non-time-sensitive data. Currently most robotics applications are using
TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form
of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add
more confusion to the situation, there is the recent introduction of
IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP
and UDP to achieve hard real-time performance.

While there are many robotics protocols out there, only Robot Raconteur
and OPC/UA are compatible with existing web and cloud infrastructure.
(Some limited support for ROS/ROS2 has become available on AWS, but the
design of ROS does not play very well outside of local networks.*) Robot
Raconteur implements web browser and web server support by allowing the
websocket protocol to be used. Clients can use a URL that specifies that
the connection is a websocket, and incoming TCP connections can detect
if the connection is the Robot Raconteur protocol or an incoming
websocket connection. Robot Raconteur running inside an ASP.NET web
server has been demonstrated, and there is no technical reason that
other server technologies cannot accept Robot Raconteur connections
through websockets. (OPC/UA uses SOAP for its web based transport, but
support is very poor and only available in a few implementations.)

The main issue limiting Robot Raconteur for more demanding applications
is the use of TCP for data transport. TCP suffers from "head-of-line"
blocking, which means that if stale data encounters an error it can stop
fresh data from reaching the other peer. There is also the problem of
large messages blocking the transmission of smaller, more time sensitive
messages on the connection. QUIC appears to solve most of these
problems, and the webrtc-quic support under development provides a lot
of new and interesting opportunities for integrating robotics
applications with web technology. By adopting QUIC, the resulting
software will remain completely compatible with web infrastructure.

Transmitting time-sensitive data requires the ability to multiplex (and
prioritize) messages and drop messages if the data contained becomes
stale. The multiplexing issue is solved using the "streams as messages"
concept in QUIC, with built in priority handling. This design looks very
promising, and considerably simpler to use compared to SCTP streams. The
current issue that is somewhat questionable is the implementation of
partial reliability. The discussion right now is focused on DATAGRAM
extensions (draft-pauly-quic-datagram-02), which allow for "raw" access
to the socket so protocols such as RTP can tunnel through QUIC. This
requirement is quite a bit different than what is required for an
application like Robot Raconteur. Robot Raconteur is based on message
passing, where either the entire message is received or the entire
message is cancelled because the data contained is stale. The message
may be considerably larger than MTU, and the QoS may be "partial,"
meaning that a set number of attempts may be made to resend, and/or
there is an expiration time on the message. This capability is discussed
in draft-lubashev-quic-partial-reliability-03, and is similar to how
SCTP handles partial reliability. If only a raw DATAGRAM capability is
provided, then partial reliability will need to be built on top of QUIC,
defeating the purpose of using QUIC for this application. Other
applications such as online gaming have very similar performance
requirements, so I think that the partial reliability capability will be
important to many future users.

The complexity and required effort to add the partial reliability
capability to QUIC is low, so I hope that this capability is not abandoned.

Robot Raconteur has received a grant from the United States ARM
Institute and New York State to begin commercializing the technology.
This project will be done in partnership with Wason Technology, LLC,
Rensselaer Polytechnic Institute, Southwest Research Institute, and
United Technologies Research Center. The project starts soon, and
considerable development effort will be invested in the Robot Raconteur
technology starting early summer. Integrating QUIC is one of the tasks
that I hope to undertake during this project.

Please let me know if you have any questions about Robot Raconteur or
the requirements for QUIC in robotics applications.

     -John Wason

(* I am aware that there are some caveats to how ROS/ROS2 interact with
the wider world, but the technologies are not built on or compatible
with web standards so an in depth discussion is not relevant for the
current topic. ROS does have a UDP transport, but it is not commonly used.)

--
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com

-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
--------------AAFE7B29E72D876856BF135D-- From nobody Tue Apr 30 17:31:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206EA1200DE for ; Tue, 30 Apr 2019 17:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=Qb4jTR2j; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MkQnUlYy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEOGMou-_VqA for ; Tue, 30 Apr 2019 17:31:46 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490D11200C4 for ; Tue, 30 Apr 2019 17:31:46 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AAA735EC for ; Tue, 30 Apr 2019 20:31:45 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 30 Apr 2019 20:31:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=rcA8W ajv1jny69JyNeG8k+axYdgx+hRa/U90Eto8G3I=; b=Qb4jTR2jWSawsMlsD5pYr V70AiD+EcfVj4lTckKxuC401vy58mDCnivSJOQB1Noxqr9i2aPfpTOVsgkKUyvnJ 7vLFDsEJTAqYg0c+g0ARVhWL5Yzg9vYv4gYNo34hu7XAYetuXNoPp8BrX7msNi31 llV2PzHxmz4Cn2oHLTJBfJcE4ehV/cWpADttom18ig1zEMEKwWybaMA07dY949vO 8hco9GPmla+lwoBJzMZZsN82OMAFzWlyLRU8e4R0MKV22WnxLFBpQ73wGJHgW7/Z 2ELJ5Besj46NSEsFVe5QG3AGIiS1jz4AC/01m1Hpk+ICzZwClH4/KZ8pJTjXsK0/ w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=rcA8Wajv1jny69JyNeG8k+axYdgx+hRa/U90Eto8G 3I=; b=MkQnUlYyF/dOXKLkFxV4JKxSRHQHdQZz1a0tS+ZtlENm1ZpZ/RUIWmx2g BaD+88mTlQMZxZ+lCsmudO7j/388vsP6gXGownS6agF6bL9n/4UXYt45qNtIQisE 3JqikkqylzUtKj66Pbj1Arrhs1ZT+xlpLgikZ1axloiA02ItPfQE4Ed55OhHp7c8 /plfmPKtmHIWrKDXKKj4IBii1ojLV75M2OQkIdUyRGvy5i6cGIXyQ67DPwGdeuIC LXhwxXpsFsPh3S1uRO5pi8t7GHzAZnVqs89wkEZpFZPmRhXk4VeypiG7Innd3f1B +TTYKpDG6l2gLd8KJi0aEmBOS4dVg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieeigdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 104BD7C199; Tue, 30 Apr 2019 20:31:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-448-g5cc1c91-fmstable-20190429v1 Mime-Version: 1.0 Message-Id: <2d1ff788-399f-4a20-9dda-82b159398b60@www.fastmail.com> In-Reply-To: References: Date: Tue, 30 Apr 2019 20:31:47 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Connection ID Space Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 00:31:48 -0000 On Wed, May 1, 2019, at 03:50, Mike Bishop wrote: > I think Option 1a is to note that the invariants don=E2=80=99t limit t= he length=20 > of CIDs in a given version in short-header packets; a future version=20= > could define much larger CIDs to be valid post-handshake. Coupled with= =20 > a way to encourage/require clients to move off of the handshake CID=20= > immediately post-handshake, this might be sufficient for the real worl= d. That's on the TODO list anyway, as we agreed to remove the 0/4-18 restri= ction for the short packet header a while back.