From nobody Fri Aug 2 14:24: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 B91F8120189 for ; Fri, 2 Aug 2019 14:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=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 4Fn8-5MpkyLc for ; Fri, 2 Aug 2019 14:24:17 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130051.outbound.protection.outlook.com [40.107.13.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A7712013D for ; Fri, 2 Aug 2019 14:24:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lFAITihHQVwpYFwSl/XbL0w4nBW+Tyv1VOFVQ933Bwl2A+8RRsa/2apik+gmLFuSvFeqEGGEfzGIY4mbZU/y70y7G45enZtDIpazqIi150yRCooTbNxcziecApCXBvYXLqZLUyYqbi0XmeiHcfemAXV6miMBlUL+MQoy6GwWCv3Ja0OaCzIQAXPkqmK5LzXWq+e3JHlw4YctAbUA9d3JmaEi2F4bq0wVnZOSqklowOztf6bD6qZJX5wp8rNbAtPJJgAaJdcMna75rrYsxcxeM8c8s+VmT5Dd/V6xV3peWxzcYq/qFnTYZO8X3fo8+1Y+SAKHOOkiQqUyyEaqVzV4hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Db5MLtNNgUtXYgOQ+mPt6gebGOfiu+ijrLM5i+J+Cro=; b=ewrSf+5wG0IDo720JrVWDhx/0FomrCycvSWl87ISgdfTEDqmTa0rnan+CIiQPRuxQDpnKN+AWoypY5wOR+xb1maVsXzkoO1BA3HW+fHnv+WwZ78RkWUTlu9sSV7lomYyzyVAZcnVvjCvgOeo4Bs6eVqbWqbDrQB+mYPc8geXDMYM/OM7jKGTd93iSePXXaHPwS+UflVTAceYnE80FP9YxBomT6rUyqOJ/L23qe3IIwRj1WUWSQ9NI8z+kU1l0Oe3Ty1zQ/AnM6GmsPlysnyhkKsqVG4xsg3dQi8tI+9UBetYFXGaVQ3peo0MeCKG8dt3FJNRh947Wovp3d2+tKt4QA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Db5MLtNNgUtXYgOQ+mPt6gebGOfiu+ijrLM5i+J+Cro=; b=pe7mSWp2hbccvPs6tY5+/uv9Ei3XNMvqccWhFXWOD/R2MTZdJ/8+9HTQFzEjLxbMimaSAkwwTQd9cQh9TZFZ6ro8hG2bE+Q2XbrXHS2CGMbTA/pCX43sNLjRazRfOfWgKC8bGREOgTiptdT9R+SmTY62jGwF6KztyJDv+3F+q4k= Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB3180.eurprd07.prod.outlook.com (10.170.245.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.10; Fri, 2 Aug 2019 21:24:13 +0000 Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::fcb3:30af:89e8:99c9]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::fcb3:30af:89e8:99c9%7]) with mapi id 15.20.2136.010; Fri, 2 Aug 2019 21:24:13 +0000 From: Ingemar Johansson S To: Bjorn Mellem CC: Tommy Pauly , Roberto Peon , Robin MARX , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , QUIC WG , Christian Huitema , Ingemar Johansson S Subject: RE: Updated DATAGRAM -03 draft Thread-Topic: Updated DATAGRAM -03 draft Thread-Index: AQHVPAi5RGl8N8lyN0SYGyNU0RUUwKbOVJ+wgADlXwCAGSwZkA== Date: Fri, 2 Aug 2019 21:24:13 +0000 Message-ID: References: <2F2121D0-503B-48CF-99E1-A9CE9192FF87@apple.com> 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: [90.235.12.119] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f734122-b3a2-477d-b6dd-08d7178fc416 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB3180; x-ms-traffictypediagnostic: HE1PR07MB3180: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1850; x-forefront-prvs: 011787B9DD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(136003)(396003)(346002)(39860400002)(54094003)(199004)(189003)(66066001)(4326008)(81156014)(478600001)(107886003)(7116003)(6306002)(86362001)(7736002)(81166006)(5070765005)(74316002)(476003)(486006)(7696005)(11346002)(790700001)(966005)(256004)(186003)(440504004)(53546011)(102836004)(517774005)(606006)(26005)(6246003)(8676002)(446003)(6116002)(2906002)(71190400001)(76176011)(54906003)(14454004)(236005)(316002)(5660300002)(54896002)(6436002)(6506007)(14444005)(3846002)(52536014)(6916009)(53936002)(229853002)(76116006)(99286004)(8936002)(66574012)(33656002)(15650500001)(99936001)(66556008)(7110500001)(2420400007)(9686003)(66946007)(66476007)(66616009)(64756008)(68736007)(71200400001)(55016002)(25786009)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3180; 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: ggYdQml8jpFFsTNbwCE+/5+tCBElk6njK6ZQ83en5lvMh8BvZjVuaaK/rhjUo+NkMAyHon0qsuuSRDQNl7B8b8P7TBFUeNyuFUoHwBfQQqCg4WzS+oPUkJSYQldrYrViIbfbmfPivDNyWDqQ7h4FdGJRq3RAzp7yh6r7UVEdJRlFXKlCVKgABp9MOQ4kpMlFczPdSSb3Rrx/GVD7ns2JCp2l43NVWSkMh/Wh2+U9zJlqGV6KHxxg5S4BEGleeGot+DswstY8npl4w0fKtDuvDlZGnw3hgCtQLYq2K6wik3rcJJU7tNlUDhWA3EMam/rxKGj5GOFuBMg8EzNc3nmdADwGmRcXACF07tjTU5p09ESpXCeyYTj849LukzQ9sHLQVxiVjLcp26fBlvPw4W42HBwtOop2hWOf+y/aVdFUwh8= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0278_01D54989.5E9B4940" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f734122-b3a2-477d-b6dd-08d7178fc416 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2019 21:24:13.2270 (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-CrossTenant-userprincipalname: ingemar.s.johansson@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3180 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, 02 Aug 2019 21:24:22 -0000 ------=_NextPart_000_0278_01D54989.5E9B4940 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0279_01D54989.5E9B4940" ------=_NextPart_001_0279_01D54989.5E9B4940 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Bj=C3=B6rn + others I am personally more in favor of having the network congestion control = on the transport layer, similar to how it is being done in RFC8298 = (SCReAM). With that said, it is to me an open question which network = congestion control that best serves the combination of real time media = and other media such as file transfers, that is a possible outcome with = QUIC as generally used transport protocol. It can for instance be = interesting to see how well BBRv2 fares with realtime media. =20 As regards to APIs: SCReAM has a built it push-back signal from the network congestion = control to the media rate control(ers), this pushes down the media = bitrate slightly when a network queue starts to build up. My experience = is that SCReAM works without this push-back signal with the drawback = that queues can more easily build up on the sender side. The bottom line = is thus that a push-back signal from network congestion control to the = media rate controllers can be useful. =20 /Ingemar =20 From: Bjorn Mellem =20 Sent: den 17 juli 2019 21:52 To: Ingemar Johansson S Cc: Tommy Pauly ; Roberto Peon ; Robin = MARX ; Mikkel Fahn=C3=B8e J=C3=B8rgensen = ; QUIC WG ; Christian Huitema = Subject: Re: Updated DATAGRAM -03 draft =20 In Google's work on WebRTC-over-QUIC, we've generally used the GCC = (Google Congestion Control) scheme described in this draft: = https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02. =20 We're moving toward an approach that essentially tunnels media over a = QUIC datagram flow. In doing this, I've made a couple of observations = about congestion-controlled datagrams: =20 1. In cases where we control the QUIC implementation, it's simple = enough to make it use GCC. However, we'd like to be able to use it = through interfaces like WebTransport = (https://github.com/WICG/web-transport = , = https://tools.ietf.org/html/draft-vvv-webtransport-overview-00), where = we do not control the QUIC transport directly. (This could probably be = solved with appropriate APIs for configuring WebTransport's congestion = control.) =20 2. GCC is work-in-progress. There are fairly regular changes aimed at = improving its performance in various edge cases. In order to deploy = changes we either need an extremely broad API or control of the = transport. =20 While this might seem like an API problem, among the proposed solutions = is "don't congestion control datagrams (let the application do that) and = implement a circuit-breaker instead". That would obviously require that = the transport does not congestion control datagrams, either. =20 There are other possibilities that might work for real-time media, such = as exposing timing information and allowing an application to set a = *lower* rate if it wants to preserve latency. But what about tunneling = other protocols over QUIC datagrams? Do we expect those to work within = QUIC's congestion control? Disable the upper-layer protocol's = congestion control? Or hook the two together in some cooperative = manner? =20 Bjorn =20 On Tue, Jul 16, 2019 at 11:31 PM Ingemar Johansson S = > wrote: +1.=20 In the general non-QoS scenario it is to prefer that the streams share = one connection and thus one congestion control.=20 =20 My experiments with SCReAM (RFC8298) shows that this can be made to work = quite well on RTP streams, an implementation of this is found at = https://github.com/EricssonResearch/scream. It is however = not straightforward to get perfect prioritization such as 70% of the = bandwidth goes to stream A and 30% to stream B when it comes to = real-time low latency media. The key reason is that the low latency goal = means that there are often no packets to schedule as extra delay due to = queueing in the sender should be avoided, variations on source rates = from video encoder makes it more challenging.=20 In comparison, =E2=80=9CInfinite=E2=80=9D bitrate sources such as file = transfers are much easier to work with as they provide data ready to = schedule for transmission on the sender side until the file transfer is = done. In the SCReAM case I have so far managed to get something like ball-park = weighted fairness, fig 7 in = = https://www.hindawi.com/journals/wcmc/2018/3142496/ shows how it works = in a real test scenario over a LTE access.=20 =20 I mentioned non-QoS scenarios. In scenarios where an underlying network = supports QoS (such as 4G/5G), then it can be beneficial to use two or = more connections, which are then scheduled over different bearers. =20 /Ingemar =20 From: Tommy Pauly >=20 Sent: den 16 juli 2019 14:47 To: Roberto Peon > Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen >; QUIC WG >; Christian Huitema >; Robin MARX > Subject: Re: Updated DATAGRAM -03 draft =20 I definitely agree that sharing one connection, where the frames are all = subject to a shared congestion control, will provide the most control = and the best results. =20 What it does bring up, however, is the need for text regarding = prioritization in the document, similar to the =E2=80=9CStream = Prioritization=E2=80=9D section in the main transport document. The = application should be able to indicate to the quic implementation the = relative priority of a flow of datagrams with regards to other streams = and other flows, thus indicating how to schedule frames when congestion = control opens up. This is also a way in which having a flow identifier = known at the transport can be useful (although this identifier could be = used strictly locally to get a similar effect).=20 =20 Thanks, Tommy =20 On Jul 15, 2019, at 6:23 PM, Roberto Peon > wrote: =EF=BB=BF=20 Using two connections would be unfortunate-- this will almost always = guarantee worse results than even the most simple proportional = prioritization or fair-share scheduling because you can cause self = contention and dilute your measurement accuracy. -=3DR _____ =20 From: QUIC > on = behalf of Mikkel Fahn=C3=B8e J=C3=B8rgensen > Sent: Monday, July 15, 2019 12:12:09 PM To: QUIC WG; Christian Huitema; Robin MARX Cc: Tommy Pauly Subject: Re: Updated DATAGRAM -03 draft=20 =20 You could also carry two connections, one for video and one for game = status updates. =20 I=E2=80=99m wondering if there is, or should be, a way to accomplish = this on a single connection. I asked something similar a long time ago and I don=E2=80=99t think = there is any amition for managing bandwidth in this for on a single = connection, at least for QUIC v1. =20 =20 On 15 July 2019 at 21.04.58, Christian Huitema (huitema@huitema.net = ) wrote: On 7/15/2019 3:03 AM, Robin MARX wrote:=20 > Hello Tommy,=20 >=20 > Good to see the updated draft.=20 > I do wonder about the decision to enforce congestion control for=20 > DATAGRAM frames and the effect this will have on the gaming use case. = > As also discussed in Prague, real-time gaming often requires a set=20 > update rate frequency (e.g., 30-60 messages per second) for=20 > responsiveness. =20 > I wonder if congestion controlling the frames (e.g., delaying/dropping = > them) will produce some weird edge cases that really mess with this=20 > setup. =20 > It's a bit difficult to assess because the messages are usually=20 > relatively small (though they could be mixed with larger messages,=20 > e.g., RPCs) and you could make the argument that, if there is actual=20 > congestion, the packets will be dropped in the network either way. =20 > You could also say that custom game-focused implementations will just=20 > ignore the text and do their own logic as needed.=20 >=20 > So I'm not sure the text needs changes, I just wanted to mention that=20 > it might not be optimal for the real-time gaming use case and that it=20 > might be capable footgun with some weird edge cases if people do stick = > to the text.=20 Not really. If the network is congested and the video game still=20 persists sending frequent messages the most likely outcome will be=20 queuing and losses, and thus bad game play. The proper behavior in a=20 congested network is to switch to a low bandwidth mode of some kind --=20 maybe a lower frame rate, or a lower resolution. This is pretty much the = same issue as voice or video over IP: if the network is congested, it=20 makes sense to use a higher compression rate. With congestion control,=20 the application can detect the upset of congestion and adopt these=20 strategies. That's generally much better than to just passively accept=20 queues and losses.=20 -- Christian Huitema=20 ------=_NextPart_001_0279_01D54989.5E9B4940 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Bj=C3=B6rn + = others

I am personally more in favor of = having the network congestion control on the transport layer, similar to = how it is being done in RFC8298 (SCReAM). With that said, it is to me an = open question which network congestion control that best serves the = combination of real time media and other media such as file transfers, = that is a possible outcome with QUIC as generally used transport = protocol. It can for instance be interesting to see how well BBRv2 fares = with realtime media.

 

As regards to = APIs:

SCReAM has a built it push-back = signal from the network congestion control to the media rate = control(ers), this pushes down the media bitrate slightly when a network = queue starts to build up. My experience is that SCReAM works without = this push-back signal with the drawback that queues can more easily = build up on the sender side. The bottom line is thus that a push-back = signal from network congestion control to the media rate controllers can = be useful.

 

/Ingemar

 

From: Bjorn Mellem = <mellem@google.com>
Sent: den 17 juli 2019 = 21:52
To: Ingemar Johansson S = <ingemar.s.johansson@ericsson.com>
Cc: Tommy Pauly = <tpauly@apple.com>; Roberto Peon <fenix@fb.com>; Robin MARX = <robin.marx@uhasselt.be>; Mikkel Fahn=C3=B8e J=C3=B8rgensen = <mikkelfj@gmail.com>; QUIC WG <quic@ietf.org>; Christian = Huitema <huitema@huitema.net>
Subject: Re: Updated = DATAGRAM -03 draft

 

In = Google's work on WebRTC-over-QUIC, we've generally used the GCC (Google = Congestion Control) scheme described in this draft: https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02= .

 

We're moving toward an approach = that essentially tunnels media over a QUIC datagram flow.  In doing = this, I've made a couple of observations about congestion-controlled = datagrams:

 

 1. In cases where we = control the QUIC implementation, it's simple enough to make it use = GCC.  However, we'd like to be able to use it through interfaces = like WebTransport (https://github.com/WICG/web-transport, https://tools.ietf.org/html/draft-vvv-webtransport-over= view-00), where we do not control the QUIC transport directly.  = (This could probably be solved with appropriate APIs for configuring = WebTransport's congestion control.)

 

 2. GCC is = work-in-progress.  There are fairly regular changes aimed at = improving its performance in various edge cases.  In order to = deploy changes we either need an extremely broad API or control of the = transport.

 

While this might seem like an = API problem, among the proposed solutions is "don't congestion = control datagrams (let the application do that) and implement a = circuit-breaker instead".  That would obviously require that = the transport does not congestion control datagrams, = either.

 

There are other possibilities = that might work for real-time media, such as exposing timing information = and allowing an application to set a *lower* rate if it wants to = preserve latency.  But what about tunneling other protocols over = QUIC datagrams?  Do we expect those to work within QUIC's = congestion control?  Disable the upper-layer protocol's congestion = control?  Or hook the two together in some cooperative = manner?

 

Bjorn

 

On Tue, Jul 16, 2019 at 11:31 PM Ingemar Johansson S = <ingemar.s.johansson@ericsson.com> = wrote:

+1.

In the general non-QoS scenario it is to prefer that the = streams share one connection and thus one congestion control. =

 

My experiments with SCReAM (RFC8298) shows that this can be = made to work quite well on RTP streams, an implementation of this is = found at https://github.com/EricssonResearch/scream. It is however not straightforward to get perfect = prioritization such as 70% of the bandwidth goes to stream A and 30% to = stream B when it comes to real-time low latency media. The key reason is = that the low latency goal means that there are often no packets to = schedule as extra delay due to queueing in the sender should be avoided, = variations on source rates from video encoder makes it more challenging. =

In comparison, =E2=80=9CInfinite=E2=80=9D bitrate sources = such as file transfers are much easier to work with as they provide data = ready to schedule for transmission on the sender side until the file = transfer is done.

In the SCReAM case I have so far managed to get something = like ball-park weighted fairness, fig 7 in https://www.hindawi.com/journals/wcmc/2018/3142496/ shows how it works in a real test scenario over a = LTE access.

 

I mentioned = non-QoS scenarios. In scenarios where an underlying = network supports QoS (such as 4G/5G), then it can be beneficial to use = two or more connections, which are then scheduled over different = bearers.

 

/Ingemar

 

From: Tommy Pauly <tpauly@apple.com>
Sent: den 16 juli = 2019 14:47
To: Roberto Peon <fenix@fb.com>
Cc: Mikkel Fahn=C3=B8e = J=C3=B8rgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.org>; = Christian Huitema <huitema@huitema.net>; Robin MARX <robin.marx@uhasselt.be>
Subject: Re: = Updated DATAGRAM -03 draft

 <= /o:p>

I = definitely agree that sharing one connection, where the frames are all = subject to a shared congestion control, will provide the most control = and the best results.

 <= /o:p>

What it = does bring up, however, is the need for text regarding prioritization in = the document, similar to the =E2=80=9CStream Prioritization=E2=80=9D = section in the main transport document. The application should be able = to indicate to the quic implementation the relative priority of a flow = of datagrams with regards to other streams and other flows, thus = indicating how to schedule frames when congestion control opens up. This = is also a way in which having a flow identifier known at the transport = can be useful (although this identifier could be used strictly locally = to get a similar effect). 

 <= /o:p>

Thanks,=

Tommy

 <= /p>

On Jul 15, 2019, = at 6:23 PM, Roberto Peon <fenix@fb.com> = wrote:

=EF=BB=BF =

Using two = connections would be unfortunate-- this will almost always guarantee = worse results than even the most simple proportional prioritization or = fair-share scheduling because you can cause self contention and dilute = your measurement accuracy.

-=3DR

From: QUIC = <quic-bounces@ietf.org> on behalf of Mikkel = Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Sent: Monday, = July 15, 2019 12:12:09 PM
To: QUIC WG; Christian Huitema; = Robin MARX
Cc: Tommy Pauly
Subject: Re: Updated = DATAGRAM -03 draft

 <= /o:p>

You could = also carry two connections, one for video and one for game status = updates.

 

I=E2=80=99m= wondering if there is, or should be, a way to accomplish this on a = single connection.

I asked = something similar a long time ago and I don=E2=80=99t think there is any = amition for managing bandwidth in this for on a single connection, at = least for QUIC v1.

 

 <= /o:p>

On= 15 July 2019 at 21.04.58, Christian Huitema (huitema@huitema.net) = wrote:


On 7/15/2019 = 3:03 AM, Robin MARX wrote:
> Hello Tommy,
>
> Good = to see the updated draft.
> I do wonder about the decision to = enforce congestion control for
> DATAGRAM frames and the effect = this will have on the gaming use case. 
> As also discussed = in Prague, real-time gaming often requires a set
> update rate = frequency (e.g., 30-60 messages per second) for
> = responsiveness. 
> I wonder if congestion controlling the = frames (e.g., delaying/dropping
> them) will produce some weird = edge cases that really mess with this
> setup. 
> = It's a bit difficult to assess because the messages are usually
> = relatively small (though they could be mixed with larger messages, =
> e.g., RPCs) and you could make the argument that, if there is = actual
> congestion, the packets will be dropped in the network = either way. 
> You could also say that custom game-focused = implementations will just
> ignore the text and do their own = logic as needed.
>
> So I'm not sure the text needs = changes, I just wanted to mention that
> it might not be optimal = for the real-time gaming use case and that it
> might be capable = footgun with some weird edge cases if people do stick
> to the = text.


Not really. If the network is congested and the video = game still
persists sending frequent messages the most likely = outcome will be
queuing and losses, and thus bad game play. The = proper behavior in a
congested network is to switch to a low = bandwidth mode of some kind --
maybe a lower frame rate, or a lower = resolution. This is pretty much the
same issue as voice or video = over IP: if the network is congested, it
makes sense to use a higher = compression rate. With congestion control,
the application can = detect the upset of congestion and adopt these
strategies. That's = generally much better than to just passively accept
queues and = losses.

-- Christian Huitema =

------=_NextPart_001_0279_01D54989.5E9B4940-- ------=_NextPart_000_0278_01D54989.5E9B4940 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 CSqGSIb3DQEJBTEPFw0xOTA4MDIyMTI0MDJaMCMGCSqGSIb3DQEJBDEWBBRccQa+4fIefE/E9OPD 7TY1OvJR2jBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAJw2xWbl7YyqvrfBZ5BlB4XPVPzYjuNf6zqAzagV F0Kmep/EfXWVjXBavZishu/CuDNCkD775u1zJ+GhdfrZrW9Nwm07pislxq05Zuy1dzVgFL3dFo1U 16fbY9OecA4JHxs3jnpUig+sZP83Vxh2Kl1nnR/Sx7aylDO387/6AaevKfzwergqIcnyqxr2/XTb WJS4kmnuEHXbV6GTEx6rtIkjEBguXm02kgve7TsEsTB+K75tlImFR9UwDNdYIrKAgOG/yqkrJk21 LzftGPr73ZmkajffwCfM79hYSAIusQJHzbAeAW/IgdCjIDsdoUFCIwYykga1FKRu6PYWFcUfTewA AAAAAAA= ------=_NextPart_000_0278_01D54989.5E9B4940-- From nobody Sat Aug 3 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 46BA5120152 for ; Sat, 3 Aug 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=IN97d3/9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EZLV5NFy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUXSACWxpJ05 for ; Sat, 3 Aug 2019 17:45:20 -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 294A11200F7 for ; Sat, 3 Aug 2019 17:45:20 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5C85F21650 for ; Sat, 3 Aug 2019 20:45:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 03 Aug 2019 20:45:19 -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= fm3; bh=9ct2AW3mllqRbD+8CtCYTonpx9dNZwUAvhhbxpYDKjo=; b=IN97d3/9 I1tmKXb/FGMEQ3umI5YlZUZ1oDZTJgll7QwNp4zbVz7CSF0fAl3OFdumhsw+CaAB aGVapLSMLRQsEn25oMQ5QOwOUOmM7WpkfuLzu1wQuCaRn7ekwjLVokgowwqXw8aG PikHvKfWjl+MErX7t8WXAF87dDD3zyHE0qAxPiCj/QCw9wrXkaW+U7Q/GcrWm4lG FBp6b8qCvo/ZlSvyYhlwe5ecRmiPe8FkvUdNDQHnigzQzZA+VW8KX7o20hTYG4YY w179hyRq5DgBxGAg5sDxm8E0mcoHn+OL0oe7IXntCwuk/gBOG66aD0xNVAz7iyN+ v1AHzCs43Tovyw== 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=fm3; bh=9ct2AW3mllqRbD+8CtCYTonpx9dNZ wUAvhhbxpYDKjo=; b=EZLV5NFyE2XHfIhqjAuuRReV7/W1+0nsnDTrlKkXphT4D kM1KfHkjU+WFLT6YHPDZMuwvfxf2rpxwRsS+iQA3NRtTs1fnKv77qJtkjMNTFIPd bcSatCr/PjHrewvFEbaH6kLnPpNkmqcIgEl29f8waEO5MQ4hSeQxX9ciBZxSIIOx w6ysZRLlSwQgAu9gTGRUaY0a3ACuVpVa8RIPa7fpIxnRQ6YClB3AEasFxqw5/Oes UVDttpAMe+3mygHZFK/sglb14YSiF589UqS3UESyV9dZ/fWxhq03OFClN40M4LPt Gyq7bIDDv9L6WA7/EhED9QXhcXwSnvVhDNSqZhgdg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddtfedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusggppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeduudelrdelrdegfedrvdegudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 83B568005A for ; Sat, 3 Aug 2019 20:45:17 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 6ACF9C111B for ; Sun, 4 Aug 2019 00:45:14 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============3454674062198489337==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190804004514.6ACF9C111B@cloud.mnot.net> Date: Sun, 4 Aug 2019 00:45:14 +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, 04 Aug 2019 00:45:23 -0000 --===============3454674062198489337== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+5/-7/=F0=9F=92=AC33) 5 issues created: - Byte order of IP addresses in PreferredAddress (by maskit) https://github.com/quicwg/base-drafts/issues/2951 = - When to send the SETTINGS frame (by kazuho) https://github.com/quicwg/base-drafts/issues/2945 = - Layout of PreferredAddress (by rpaulo) https://github.com/quicwg/base-drafts/issues/2944 = - The Appendix A of quic-tls is wrong (by choury) https://github.com/quicwg/base-drafts/issues/2934 = - Omission of DCIL change in draft-ietf-quic-transport-22? (by evagld) https://github.com/quicwg/base-drafts/issues/2932 = 11 issues received 33 new comments: - #2945 When to send the SETTINGS frame (18 by kazuho, nharper, DavidSchi= nazi, martinthomson, LPardue, ianswett, lnicco, dtikhonov, afrind) https://github.com/quicwg/base-drafts/issues/2945 [-http] = - #2790 Binding settings into session tickets (5 by DavidSchinazi, martin= thomson, nharper, ianswett) https://github.com/quicwg/base-drafts/issues/2790 [-http] = - #2944 Layout of PreferredAddress (2 by DavidSchinazi, martinthomson) https://github.com/quicwg/base-drafts/issues/2944 = - #2913 Connection Reuse - Use RFC2119 terminology (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2913 [-http] [design] = - #2792 Timing side-channel on key updates (1 by chris-wood) https://github.com/quicwg/base-drafts/issues/2792 [-tls] [design] = - #2858 Signal error upon receipt of multiple trailing HEADERS (1 by Mike= Bishop) https://github.com/quicwg/base-drafts/issues/2858 [-http] [design] = - #2924 Remove PRIORITY (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2924 [-http] [design] = - #2932 Omission of DCIL change in draft-ietf-quic-transport-22? (1 by ma= rtinthomson) https://github.com/quicwg/base-drafts/issues/2932 [invalid] = - #2934 The Appendix A of quic-tls is wrong (1 by choury) https://github.com/quicwg/base-drafts/issues/2934 = - #2844 Client connection IDs are broken (1 by igorlord) https://github.com/quicwg/base-drafts/issues/2844 [-transport] [design] = - #2931 Non-ACK-eliciting packets never need to be ACKed (1 by dtikhonov) https://github.com/quicwg/base-drafts/issues/2931 = 7 issues closed: - HTTP/3 Cookie Crumbling https://github.com/quicwg/base-drafts/issues/27= 77 [-http] [design] = - Signal error upon receipt of multiple trailing HEADERS https://github.c= om/quicwg/base-drafts/issues/2858 [-http] [design] = - Replace HTTP_MALFORMED_FRAME for something simpler https://github.com/q= uicwg/base-drafts/issues/2551 [-http] [design] = - The Appendix A of quic-tls is wrong https://github.com/quicwg/base-draf= ts/issues/2934 = - Omission of DCIL change in draft-ietf-quic-transport-22? https://github= .com/quicwg/base-drafts/issues/2932 [invalid] = - Omission of DCIL change in draft-ietf-quic-transport-22? https://github= .com/quicwg/base-drafts/issues/2932 = - Non-ACK-eliciting packets never need to be ACKed https://github.com/qui= cwg/base-drafts/issues/2931 = Pull requests ------------- * quicwg/base-drafts (+16/-7/=F0=9F=92=AC15) 16 pull requests submitted: - Skip a packet number when sending one PTO packet (by ianswett) https://github.com/quicwg/base-drafts/pull/2952 [-recovery] [editorial] = - Remove mention of "protocol version selection" from TLS draft (by nharp= er) https://github.com/quicwg/base-drafts/pull/2950 = - Remove extra curly brace from HTTP draft (by nharper) https://github.com/quicwg/base-drafts/pull/2949 = - Fix nit in protocol overview in TLS draft (by nharper) https://github.com/quicwg/base-drafts/pull/2948 = - Describe interaction between QUIC and TLS regarding saved 0-RTT state (= by nharper) https://github.com/quicwg/base-drafts/pull/2947 = - Make Recovery Pseudocode Formatting Consistent (by ianswett) https://github.com/quicwg/base-drafts/pull/2946 [-recovery] [editorial] = - Update the PreferredAddress structure to accomodate a 20 byte CID. (by = rpaulo) https://github.com/quicwg/base-drafts/pull/2943 = - QPACK [editorial] Misc minor editorial changes. (by bencebeky) https://github.com/quicwg/base-drafts/pull/2942 = - QPACK [editorial] Update text on instructions and representations. (by = bencebeky) https://github.com/quicwg/base-drafts/pull/2941 = - QPACK [editorial] Post-base index is not relative index. (by bencebeky) https://github.com/quicwg/base-drafts/pull/2940 = - QPACK [design] Decoder MUST emit Header Acknowledgement. (by bencebeky) https://github.com/quicwg/base-drafts/pull/2939 = - QPACK [editorial] Update text on wire instructions. (by bencebeky) https://github.com/quicwg/base-drafts/pull/2938 = - QPACK [editorial] Update text to include both criteria of "blocking ent= ry". (by bencebeky) https://github.com/quicwg/base-drafts/pull/2937 = - QPACK [editorial] Reword paragraph on blocked stream limit. (by bencebe= ky) https://github.com/quicwg/base-drafts/pull/2936 = - QPACK [editorial] update RIC and Base on figures (by bencebeky) https://github.com/quicwg/base-drafts/pull/2935 = - Modify pseudo-code to enforce that zero must be encoded as zero. (by be= ncebeky) https://github.com/quicwg/base-drafts/pull/2933 = 10 pull requests received 15 new comments: - #2938 QPACK [editorial] Update text on wire instructions. (4 by bencebe= ky, LPardue) https://github.com/quicwg/base-drafts/pull/2938 = - #2939 QPACK [design] Decoder MUST emit Header Acknowledgement. (3 by be= ncebeky, martinthomson) https://github.com/quicwg/base-drafts/pull/2939 = - #2723 HTTP/3 Zero-weighting (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2723 [-http] = - #2948 Fix nit in protocol overview in TLS draft (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2948 [-tls] [editorial] = - #2950 Remove mention of "protocol version selection" from TLS draft (1 = by nharper) https://github.com/quicwg/base-drafts/pull/2950 = - #2761 allow PRIORITY frames referring to placeholders exceeding `SETTIN= G_NUM_PLACEHOLDERS` (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2761 [-http] = - #2898 HTTP Upgrade in H3 is silliness (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2898 [-http] = - #2947 Describe interaction between QUIC and TLS regarding saved 0-RTT s= tate (1 by nharper) https://github.com/quicwg/base-drafts/pull/2947 = - #2857 Define terms for application actions (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2857 [-http] [-transport] [d= esign] = - #2936 QPACK [editorial] Reword paragraph on blocked stream limit. (1 by= LPardue) https://github.com/quicwg/base-drafts/pull/2936 = 7 pull requests merged: - Add normative reference to RFC7540 8.1.2.5. https://github.com/quicwg/base-drafts/pull/2868 [-http] = - Tighten HEADERS and DATA frame order requirements. https://github.com/quicwg/base-drafts/pull/2867 [-http] = - Replace HTTP_MALFORMED_FRAME error code https://github.com/quicwg/base-drafts/pull/2662 [-http] [design] = - Remove mention of "protocol version selection" from TLS draft https://github.com/quicwg/base-drafts/pull/2950 [-tls] [editorial] = - Fix nit in protocol overview in TLS draft https://github.com/quicwg/base-drafts/pull/2948 [-tls] [editorial] = - Remove extra curly brace from HTTP draft https://github.com/quicwg/base-drafts/pull/2949 [-http] [editorial] = - Update the PreferredAddress structure to accomodate a 20 byte CID. https://github.com/quicwg/base-drafts/pull/2943 [-transport] [editorial= ] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============3454674062198489337== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday August 04, 2019

Issues

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

5 issues created:

11 issues received 33 new comments:

7 issues closed:

Pull requests

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

16 pull requests submitted:

10 pull requests received 15 new comments:

7 pull requests merged:

Repositories tracked by this digest:

--===============3454674062198489337==-- From nobody Mon Aug 5 10:03: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 8F2B412029A for ; Mon, 5 Aug 2019 10:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 ofYjzL813SBv for ; Mon, 5 Aug 2019 10:03:40 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1267120297 for ; Mon, 5 Aug 2019 10:03:39 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id BA290B004A for ; Mon, 5 Aug 2019 20:03:37 +0300 (EEST) Received: from [172.30.153.229] (Lumi.eggert.org [172.30.153.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id D813F69306F for ; Mon, 5 Aug 2019 20:03:30 +0300 (EEST) From: Lars Eggert Content-Type: multipart/alternative; boundary=Apple-Mail-C3B78AC8-F9C3-41D2-AB52-C48F525F82C7 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 5 Aug 2019 20:03:30 +0300 Subject: Fwd: QUIC IETF Draft 2019-07-09 possible error Message-Id: References: <61418F6F432040439478E7BE73F3AB210141E4A452@nova.intrusion.com> To: quic@ietf.org X-MailScanner-ID: D813F69306F.A36F9 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, 05 Aug 2019 17:03:43 -0000 --Apple-Mail-C3B78AC8-F9C3-41D2-AB52-C48F525F82C7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Redirecting from other list --=20 Sent from a mobile device; please excuse typos. Begin forwarded message: > Resent-From: > From: Daris Nevil > Date: August 1, 2019 at 19:20:35 GMT+3 > Resent-To: jri.ietf@gmail.com, mt@lowentropy.net, lars@eggert.org, mnot@mn= ot.net, magnus.westerlund@ericsson.com, ietf@kuehlewind.net > To: "draft-ietf-quic-transport@ietf.org" , "draft-ietf-quic-transport.authors@ietf.org" , "draft-ietf-quic-transport.chairs@ietf.org" , "draft-ietf-quic-transport.ad@ietf.org" , "draft-ietf-quic-transport.all@ietf.o= rg" > Subject: QUIC IETF Draft 2019-07-09 possible error >=20 > There may be an error in the IETF document draft-ietf-quic-transport-22: > =20 > https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include_text=3D= 1 > =20 > The issue begins on page 81 with the packet diagram. It shows both a =E2=80= =9CDCID Len(8)=E2=80=9D and =E2=80=9CSCID Len(8)=E2=80=9D. However, the des= cription of =E2=80=9CDCID Len=E2=80=9D says it provides the length for both D= estination Connection ID as well as Source Connection ID. In addition, the =E2= =80=9CDCID Len=E2=80=9D description states the Dest/Src lengths may be at mo= st 18 bytes, while the =E2=80=9CSCID Len=E2=80=9D description says it may be= up to 20 bytes. > =20 > This document from June 2019 shows a different Long Header Packet format t= hat contains a single byte for the DCID/SCID lengths. > =20 > https://docs.google.com/document/d/1FcpCJGTDEMblAs-Bm5TYuqhHyUqeWpqrItw2vk= MFsdY/edit > =20 > Can you clarify which Long Header Packet format is correct, and explain th= e possible descrepencies? > =20 > Kind regards, > Daris A Nevil > Intrusion Inc > 214-564-5317 cell > =20 --Apple-Mail-C3B78AC8-F9C3-41D2-AB52-C48F525F82C7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Redirecting from other list

-- 
Sent from a mobile device; ple= ase excuse typos.

Begin forwarded message:

There may be an error in the IETF document draft-ietf-quic-transpor= t-22:

 

https://datatracker.ietf.org/doc/draft-ietf-quic-tra= nsport/?include_text=3D1

 = ;

The issue begins on page 81 with the packe= t diagram.  It shows both a =E2=80=9CDCID Len(8)=E2=80=9D and =E2=80=9C= SCID Len(8)=E2=80=9D.  However, the description of =E2=80=9CDCID Len=E2= =80=9D says it provides the length for both Destination Connection ID as wel= l as Source Connection ID.  In addition, the =E2=80=9CDCID Len=E2=80=9D= description states the Dest/Src lengths may be at most 18 bytes, while the =E2= =80=9CSCID Len=E2=80=9D description says it may be up to 20 bytes.

 

This= document from June 2019 shows a different Long Header Packet format that co= ntains a single byte for the DCID/SCID lengths.

 

ht= tps://docs.google.com/document/d/1FcpCJGTDEMblAs-Bm5TYuqhHyUqeWpqrItw2vkMFsd= Y/edit

 

Can you clarify which Long Header Packet format is correct, a= nd explain the possible descrepencies?

=  

Kind regards,

Daris A Nevil

Intrus= ion Inc

214-564-5317 cell

 

= --Apple-Mail-C3B78AC8-F9C3-41D2-AB52-C48F525F82C7-- From nobody Mon Aug 5 10:31: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 69D5B1202E0 for ; Mon, 5 Aug 2019 10:31:34 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWYFkPiM4DFg for ; Mon, 5 Aug 2019 10:31:32 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 950801202D0 for ; Mon, 5 Aug 2019 10:31:32 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x75HQZ8a023049; Mon, 5 Aug 2019 10:31:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=hRXGsorbwEzX7o9lDnj5luKRClO7yuHsbtNHE17h/G4=; b=TK6qCSxgfc3CGiYGCldSVqu91kxK3LCwDRs0TbbOLxn2l/KBJmIpPBBkNzGofoin6ArQ qgHuKHNjj32oKEnQAKu33lunB4K8090t/cLKSxzNv+3mSQR+hXmGrtmWpBUe8NTZuE8l OTGYGQbGAVaRW8POajot46wFOUF+puW7Za+psa3eJVQnx90OwNHXeLP3vt6HrXK6QxPW 9EZeT0yjD2OoS/lvhCcL4sy4wzEClQxCvQLw6dtzJFtknZf08HYejIYWM3vXDKz+RWqg KSI3csWx3EV/EeIStu5nvnEnSxujaidhIOQYNf3v+nwtATnQwanjHfuqc8IWLTmAFPVT dA== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2u56um0507-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 05 Aug 2019 10:31:27 -0700 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PVR00JOBY0D9JG0@ma1-mtap-s03.corp.apple.com>; Mon, 05 Aug 2019 10:31:27 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PVR00J00XKEWH00@nwk-mmpp-sz11.apple.com>; Mon, 05 Aug 2019 10:31:26 -0700 (PDT) X-Va-A: X-Va-T-CD: eaacfa4ca8e8fccb52020b2fb6bbbed2 X-Va-E-CD: dd920f06178da89f8db7fa4436fa4ec0 X-Va-R-CD: 91d102065ce47bc090d35ecba7a4ed28 X-Va-CD: 0 X-Va-ID: b9565893-4312-48fb-9318-61dab8ce9a04 X-V-A: X-V-T-CD: eaacfa4ca8e8fccb52020b2fb6bbbed2 X-V-E-CD: dd920f06178da89f8db7fa4436fa4ec0 X-V-R-CD: 91d102065ce47bc090d35ecba7a4ed28 X-V-CD: 0 X-V-ID: ad3ae0b3-6f14-48b7-ae12-f30e57d339a8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-05_09:,, signatures=0 Received: from ekinnear1.scv.apple.com (ekinnear1.scv.apple.com [17.192.171.50]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PVR00M7BY0D9X20@nwk-mmpp-sz11.apple.com>; Mon, 05 Aug 2019 10:31:25 -0700 (PDT) Sender: ekinnear@apple.com From: Eric Kinnear Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_1B1F4C2F-43B7-4669-BC6B-07811BCE38B8" MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: QUIC IETF Draft 2019-07-09 possible error Date: Mon, 05 Aug 2019 10:31:25 -0700 In-reply-to: Cc: IETF QUIC WG , Lars Eggert To: Daris Nevil References: <61418F6F432040439478E7BE73F3AB210141E4A452@nova.intrusion.com> X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-05_09:, , signatures=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, 05 Aug 2019 17:31:44 -0000 --Apple-Mail=_1B1F4C2F-43B7-4669-BC6B-07811BCE38B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 See https://github.com/quicwg/base-drafts/issues/2932 = where someone else = noticed this as well. This has been updated in the latest editor=E2=80=99s draft = https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#long-header = via = https://github.com/quicwg/base-drafts/commit/913370291aa863a847126f7df9f9a= b3df7024196 = Thanks, Eric > On Aug 5, 2019, at 10:03 AM, Lars Eggert wrote: >=20 > Redirecting from other list >=20 > --=20 > Sent from a mobile device; please excuse typos. >=20 > Begin forwarded message: >=20 >> Resent-From: > >> From: Daris Nevil > >> Date: August 1, 2019 at 19:20:35 GMT+3 >> Resent-To: jri.ietf@gmail.com , = mt@lowentropy.net , lars@eggert.org = , mnot@mnot.net , = magnus.westerlund@ericsson.com , = ietf@kuehlewind.net >> To: "draft-ietf-quic-transport@ietf.org = " = >, = "draft-ietf-quic-transport.authors@ietf.org = " = >, = "draft-ietf-quic-transport.chairs@ietf.org = " = >, = "draft-ietf-quic-transport.ad@ietf.org = " = >, = "draft-ietf-quic-transport.all@ietf.org = " = > >> Subject: QUIC IETF Draft 2019-07-09 possible error >>=20 >> There may be an error in the IETF document = draft-ietf-quic-transport-22: >> =20 >> = https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include_text=3D= 1 = >> =20 >> The issue begins on page 81 with the packet diagram. It shows both a = =E2=80=9CDCID Len(8)=E2=80=9D and =E2=80=9CSCID Len(8)=E2=80=9D. = However, the description of =E2=80=9CDCID Len=E2=80=9D says it provides = the length for both Destination Connection ID as well as Source = Connection ID. In addition, the =E2=80=9CDCID Len=E2=80=9D description = states the Dest/Src lengths may be at most 18 bytes, while the =E2=80=9CSC= ID Len=E2=80=9D description says it may be up to 20 bytes. >> =20 >> This document from June 2019 shows a different Long Header Packet = format that contains a single byte for the DCID/SCID lengths. >> =20 >> = https://docs.google.com/document/d/1FcpCJGTDEMblAs-Bm5TYuqhHyUqeWpqrItw2vk= MFsdY/edit = >> =20 >> Can you clarify which Long Header Packet format is correct, and = explain the possible descrepencies? >> =20 >> Kind regards, >> Daris A Nevil >> Intrusion Inc >> 214-564-5317 cell --Apple-Mail=_1B1F4C2F-43B7-4669-BC6B-07811BCE38B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 See https://github.com/quicwg/base-drafts/issues/2932 wher= e someone else noticed this as well.

This has been updated in the latest = editor=E2=80=99s draft
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#l= ong-header
via
https://github.com/quicwg/base-drafts/commit/913370291aa863a847= 126f7df9f9ab3df7024196

Thanks,
Eric


On Aug 5, 2019, at 10:03 AM, Lars Eggert <lars@eggert.org> = wrote:

Redirecting from other = list

-- 
Sent from a = mobile device; please excuse typos.

Begin forwarded message:

Resent-From: <alias-bounces@ietf.org>
From: Daris Nevil <dnevil@intrusion.com>
Date: August 1, 2019 at 19:20:35 = GMT+3
Resent-To: jri.ietf@gmail.com, mt@lowentropy.net, lars@eggert.org, mnot@mnot.net, magnus.westerlund@ericsson.com, ietf@kuehlewind.net
To: "draft-ietf-quic-transport@ietf.org" <draft-ietf-quic-transport@ietf.org>,  "draft-ietf-quic-transport.authors@ietf.org" <draft-ietf-quic-transport.authors@ietf.org>, "draft-ietf-quic-transport.chairs@ietf.org" <draft-ietf-quic-transport.chairs@ietf.org>, "draft-ietf-quic-transport.ad@ietf.org" <draft-ietf-quic-transport.ad@ietf.org>, "draft-ietf-quic-transport.all@ietf.org" <draft-ietf-quic-transport.all@ietf.org>
Subject: QUIC IETF = Draft 2019-07-09 possible error

There may be an error in the IETF document = draft-ietf-quic-transport-22:
 
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?inc= lude_text=3D1
 
The issue begins on page 81 with the packet diagram.  It = shows both a =E2=80=9CDCID Len(8)=E2=80=9D and =E2=80=9CSCID = Len(8)=E2=80=9D.  However, the description of =E2=80=9CDCID Len=E2=80= =9D says it provides the length for both Destination Connection ID as = well as Source Connection ID.  In addition, the =E2=80=9CDCID = Len=E2=80=9D description states the Dest/Src lengths may be at most 18 = bytes, while the =E2=80=9CSCID Len=E2=80=9D description says it may be = up to 20 bytes.
 
This document from June 2019 shows a different Long Header = Packet format that contains a single byte for the DCID/SCID lengths.
 
https://docs.google.com/document/d/1FcpCJGTDEMblAs-Bm5TYuqhHyUq= eWpqrItw2vkMFsdY/edit
 
Can you clarify which Long Header Packet format is correct, = and explain the possible descrepencies?
 
Kind regards,
Daris A = Nevil
Intrusion = Inc
214-564-5317 = cell

= --Apple-Mail=_1B1F4C2F-43B7-4669-BC6B-07811BCE38B8-- From nobody Tue Aug 6 15:48: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 9122612006E for ; Tue, 6 Aug 2019 15:48:46 -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=hU3o9FwT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iq7yJ1k7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSG9pH1s1WBz for ; Tue, 6 Aug 2019 15:48:43 -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 9DA19120099 for ; Tue, 6 Aug 2019 15:48:43 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C71B32179E; Tue, 6 Aug 2019 18:48:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 06 Aug 2019 18:48:42 -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=fm3; bh=hfU4EtBL1BqVtPaCzQFPL40lGdRp3h gS5+fehHstSAo=; b=hU3o9FwT+MR+z6DXbVkf1StyzUuodCb+bLiUS2FmJn5d38 B5Ci7Wm+9sW8QCgOczGLyyCe2aqVmoS7Fvx+pdvYWR4/yaops+tJ7qyk0iBbAcgY hGXtVXx5ZfzWnS87IAm1SfKsnya3YCngah8JpvGHFY6ZR6MQoBXdsUjcAZmsdSWy SZv0fLByTdoDlLRcIdFbuqHQuabtiCIOl5GYf8ZXDbSt0aJtKj9hbUP8GGryYYWT w0SjHcn2OxtvihF1CMK4NeTjQCaA/atKA7ZHAHFwmAB6coL3IietFq7buBIBOcvB NVfwPxCXVo8OaSQhYFMHx+E3Lcp4fFVyMmfwYdUg== 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=fm3; bh=hfU4Et BL1BqVtPaCzQFPL40lGdRp3hgS5+fehHstSAo=; b=iq7yJ1k7XycxCTahKZ7fz2 TfE0qkCXyupUGrpL6sTOK+VCbuIZv/bm+f6lXmUg6piqWfkp4XNaNWadRDW90Wgr siNrzsiYmc5uLoawAlRbaLZ7DQeF4AbHFMGh9s7ABEWuEUD9eYzwAX2DtQ3T4xP/ J+9XskGOvVdEw/bUCkhg0tv8zbOWfiD3BcOvU9ftcZaxhOJDxfOTCHpWYc+P6oYw Sp044BOYVznN4YNpcf1rg6IA42SQDu+nxrOsd3gCfmCGENog+z86YZLmDQWN8cEM YgnsETGIio2V/xPqdmY1jFp8SlC9sX6B4AxqGaBK/hl0F4zMVkToKXqFSexgvJ6g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduuddgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E4BF380090; Tue, 6 Aug 2019 18:48:39 -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.11\)) Subject: Consensus Calls on Recent Transport/TLS Issues Message-Id: Date: Wed, 7 Aug 2019 08:48:35 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.104.11) 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, 06 Aug 2019 22:48:46 -0000 The following issues have proposals for resolution, and discussion so = far seems to support consensus to accept them. If you object, please do = so on the issue or in response to this message (changing the Subject = appropriately!). Absent any pushback, we'll direct the editors to = incorporate them next week. See for the current = state of issues in the Late Stage process, itself defined at = . * #2170: Embed QUIC version in expansion The proposal is to close with no action. * #2920: Should server TP encryption be a requirement for the = cryptographic handshake? The proposal is: * #2842: Does it make sense to try 0-RTT after Retry? The proposal is: * #2840: Does rejecting 0-RTT data prohibit ACKing 0-RTT data? The proposal is: * #2825: Exceeding Max STREAM ID should be a connection error The proposal is: * #2805: Rationalize terminology around transport/application = interactions The proposal is: * #2763: Coordinating spin The proposal is: * #2760: NEW_TOKEN should be symmetric The proposal is to close with no action (although it may be taken up = in post-QUICv1 work) * #2685: CC state after a change of path? The proposal is: * #2670: Remove ack_delay_exponent TP The proposal is to close with no action. * #2550: Apply GREASE to transport parameters The proposal is: * #2389: Be clearer about the purpose of disable_migration The proposal is: * #2388: Articulate principles for definition of error codes The proposal is: * #2342: Spoofed connection migration as a DoS vector The proposal is: -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 6 17:02: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 4E48B12008B for ; Tue, 6 Aug 2019 17:02:57 -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_HELO_NONE=0.001, 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 L0iz6kQA1xJv for ; Tue, 6 Aug 2019 17:02:55 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB76612009C for ; Tue, 6 Aug 2019 17:02:55 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id v20so34371677uao.3 for ; Tue, 06 Aug 2019 17:02:55 -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=0My8kAJwvlP8IHn/Mrx8r1zXOn0HNOA8lD2DXHTcEew=; b=iV47rxKz35rKqvw+FS6y2h2igH77f7MjU9UDBQmJixlY8k0ifopUlCMD69S+OnzaHS c4/MY6IB2s6By4QT8fW8Acpnieb/mAwNb2Nz06unwGixaJw+ZYV4fOdlwo3xc44Nf1tX nPqnzogqVEXSlf9stVHazW3s4MO8ft0IyvSJ5nm7Ga7hUBafU77c35eJG5s5/7kxMjba OGVg1HSE3v4XnxfZiLzKiSn+/N71QAFRGwPBt3jhaf6eYUbz7kGZ1XfIvvsWxVu4LCzP +So+5dPYRJcTkkl6R9IqFI4hu5iF1DVNep+uKGX8MLIdiryVfgG7ghuNp4WFy6xin8ly MfNQ== 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=0My8kAJwvlP8IHn/Mrx8r1zXOn0HNOA8lD2DXHTcEew=; b=Rh+V2KxF/93CvYvCxt8La+GGrUZGmVU4y1a4ZFBrp4rY+kj8o5A9LyXcFSHXRwITRT f5cWUD4SbJdXO5nYbMhLK7zjFr2gnQ9+y8pvkwEO9CpU/BmkI77RKaBhK41tAGbkOp+Y h/+y2gD63H/ZYheJN34J/0DL4vYU9HNMRc7ffJDHZsGgRgu0F2i/PCISUMmx/2hQfYrc N6zQ5FMbhdht23mFiNftvgFJMEUBnza+LobcFgoDyY9uFF+n4cALtjePAzAYtOews8UC tpgZtVvJ9o/KzEytAim2zuiM0NCOxJapP4nFtyvbwSHC/XZs0jwiky6++XxVMBHMRXrk 3ksA== X-Gm-Message-State: APjAAAX/ZYpNCkR+4uEeoftPl7b75jRtyt61/hEl5psnb8FIGv7LxITH JNHzt+xprfN8oMz9+gYOadGUQs5jyqIxK+reo8yaSQjX X-Google-Smtp-Source: APXvYqxAPm1q4DdLQYo5tIMXtk0vQhHGVPrCy0sBnz4Kt8CqZ22CRW761ndi+zQX8xSH3Gn1xjxNWEQ8g8MXzYevaW4= X-Received: by 2002:ab0:7491:: with SMTP id n17mr3882936uap.102.1565136174650; Tue, 06 Aug 2019 17:02:54 -0700 (PDT) MIME-Version: 1.0 From: Lucas Pardue Date: Wed, 7 Aug 2019 01:02:55 +0100 Message-ID: Subject: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME To: QUIC WG Content-Type: multipart/alternative; boundary="000000000000b71a2b058f7ba94c" 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, 07 Aug 2019 00:02:57 -0000 --000000000000b71a2b058f7ba94c Content-Type: text/plain; charset="UTF-8" Hello WG, As part of the HTTP error analysis and feedback, in June I created issue #2809 "Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME" [1]. In short, HTTP_WRONG_STREAM is used for connection errors when a non-allowed frame is received by a peer (e.g a server receiving PUSH_PROMISE), or when a request sequence is malformed. HTTP_UNEXPECTED_FRAME is used for connection errors when an allowed frame is received on the wrong type of stream (e.g. a client receiving PUSH_PROMISE on the control stream). Issue 2809 suggests combining these error codes but I've yet to make a PR. In the meantime, a fair amount of error code refactoring has taken place and I'm not sure how much demand there is for the change. If you have an opinion on this I'd appreciate feedback here or on the ticket. Cheers Lucas [1] https://github.com/quicwg/base-drafts/issues/2809 --000000000000b71a2b058f7ba94c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello WG,

As part of the HTT= P error analysis and feedback, in June I created issue #2809 "Rational= ise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME" [1].
<= br>
In short,=20 HTTP_WRONG_STREAM is used for connection errors when a non-allowed frame is= received by a peer (e.g a server receiving PUSH_PROMISE), or when a reques= t sequence is malformed. HTTP_UNEXPECTED_FRAME is used for connection error= s when an allowed frame is received on the wrong type of stream (e.g. a cli= ent receiving PUSH_PROMISE on the control stream).

Issue 2809 suggests combining these error codes but I've yet to make a= PR. In the meantime, a fair amount of error code refactoring has taken pla= ce and I'm not sure how much demand there is for the change.
=

If you have an opinion on this I'd appreciate feedb= ack here or on the ticket.

Cheers
L= ucas

--000000000000b71a2b058f7ba94c-- From nobody Tue Aug 6 17:28: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 00FA3120304 for ; Tue, 6 Aug 2019 17:28:35 -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=t6AKErUB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=z6Am0w02 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7IDuvnfkCx6 for ; Tue, 6 Aug 2019 17:28:33 -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 613FC1206A9 for ; Tue, 6 Aug 2019 17:28:33 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BF53F21910 for ; Tue, 6 Aug 2019 20:28:32 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 06 Aug 2019 20:28:32 -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=fm2; bh=2tCxvsXiCTSJGq+mAfqm51v3uUoy4mh +SKrX5y9pXWI=; b=t6AKErUBArIc90t/ZgBKL21QW1pSdePoCyTga82Uwp7xRlv aWSsw9TIYO3OMC60hftgpqq2EEYIGOxvX1hXqacPGnFH3DS79S1XJtdGTI9pWW6z 1/DU5wLo4FB6oFWUrQ+GBwKgNuoLFpRoi1VD4yvu65Lm3xMr3H8pNmUy9Ya2sFEi W54TV0fLc/+UTYlW1jp+QvyjamtGwGSLuOT1xJHD4h/Ke2uiPASBr67Ho+bvv+jU t0nPppcXJbc2yvS9jQzy9RkQMqUMDllgoebhFE7G7hE850XCEtDyIhhnbgmAZHsd a+zCVeCfeO6ghnqoYhgXbHOU4brrkvbCMJmSBJQ== 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=fm3; bh=2tCxvs XiCTSJGq+mAfqm51v3uUoy4mh+SKrX5y9pXWI=; b=z6Am0w02F2iDD0RGqG1f8V /hrbTU3LtfyWS7WKs5TtotZ62Ydu1+2AQkRArMpmBQhrzfgYqPqhlWJYIdbOazI8 GQXUlW8pZm9HKPR9lbaFmeKS+AyiHyO4/yAm0HWSuKDfeHhU5wRxbGDERMmPD60O qjda0dNMxH8oiRXv6JEwBk0CdGWMl+8BjaTucTsxv9jOJpbCghiJ6/QdKdKW9o7m MCZglx9qeDq10sqcyfE0FNFdNiRd77MKMw8nXbmvHspmosBfd4b1qrABLFf9M17m 4v1WYvBougbVYlEH1b72Jeru6L6bG9/ZW625affH5t8T3kOGsJuFP4pjKCT/LB3Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduuddgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 79545E00A2; Tue, 6 Aug 2019 20:28:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2 Mime-Version: 1.0 Message-Id: <608f1832-2ac3-4459-875e-bdc9a86ad8b8@www.fastmail.com> In-Reply-To: References: Date: Wed, 07 Aug 2019 10:28:35 +1000 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME 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, 07 Aug 2019 00:28:41 -0000 On Wed, Aug 7, 2019, at 10:03, Lucas Pardue wrote: > As part of the HTTP error analysis and feedback, in June I created > issue #2809 "Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME" > [1]. The notion of a signal for "I got a frame that I understood, but it was in the wrong place" is fine. Good even. But I don't see a need to have two such signals. So I'm in favour of collapsing the two. I don't understand the distinction between these signals as it stands anyway. However, I'm also concerned that this is going to get wrapped up in the usual compliance test mess. If I hook up different parsers on different streams and my request stream parser doesn't know about SETTINGS at all, so ignores it when it suddenly appears on a request stream, is the test case going to fail when I don't generate HTTP_FRAME_IN_THE_WRONG_PLACE? From nobody Tue Aug 6 17:47: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 F06321200B2 for ; Tue, 6 Aug 2019 17:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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_HELO_NONE=0.001, 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 6FHwtYMxTXsG for ; Tue, 6 Aug 2019 17:47:31 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6426A12009C for ; Tue, 6 Aug 2019 17:47:31 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id m23so59586399vso.1 for ; Tue, 06 Aug 2019 17:47: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; bh=8NNivtKVmhtVVriViSNwhZvpFWbtQyaqdk4wmqqNC8A=; b=YJfKjHByv8XhgJ7qk82Ol2jgnzR7LjhdgHk4QGIZm04cF88UiS3EVZHzhPdN7hZiOv Zqmh0D9Eg6bZO0XN4Phw6YS22KEf5Hpnstq2b9mhFjNRa29OAMzkXWN9Mzex+tECcE8p ThCfw92G7pI/qzwqwugHoM33NHlfrygL62Kxzdz+6thsl0P3qUuc/1tNdATqqAiiRZiW 0KsN5b9f+gp4+nHFV0/f/0k1D6CvJMhVFqcu0ALxo9F0MQimUrmfbcMqbJ+NHQ8uyrJ5 5nXfMv6Sue5yQiuoFbQrhA5lRjQ8PKlvUhXqLdW0AhZ1NbT3eUgWW9dFcKc10ywLaKEd Wqjg== 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=8NNivtKVmhtVVriViSNwhZvpFWbtQyaqdk4wmqqNC8A=; b=GT4llgg0UvuFueUDpZ8FE14zViLqwRYnFr5b7r0V/ITGbXdkSiJmfSC9YTD0ZH+hUB cZ2pjj1t8hkr+T8kydT2ReF5lSLkReaJfbl9SSEpcxWQwa9jtuT/i/2eqPj2gYxQFcbc pXz8YKZUWCUtydsObDGZeyxuCE62TeIClmLImsyJdWm0zH8RjsIOVfouRTQKFeHIJAjf aMv3wG7mr2FTwJ3y/fnsFaeyAmqPy/0kP/LWM5txGyBvWyZIgdcipFfA/uWcERS3xfdW pmYiOyyg2XWZ5MGpznKG5SrMdSgDCm5cjgpBos+aoE21h62cEVMIZ6xQEVS0O0hkdw7W k/Sg== X-Gm-Message-State: APjAAAV8PL2B2LZ2N4w5GBBMG66WKPmYTkoJNKazbBj23wmRKBQ6RQRT nt0/n1DLKetfV+9fRSICfqU/r0GUCM6222lqkGvHKw== X-Google-Smtp-Source: APXvYqyTTbCV8EbP0G7PJYfNpWMPH9/DniL1OYrbxn0miWVF3Oeov0dOnGdcdPaOsF3wfDY+g454mh1GP0GQqsfakNo= X-Received: by 2002:a67:d00d:: with SMTP id r13mr4390164vsi.100.1565138850466; Tue, 06 Aug 2019 17:47:30 -0700 (PDT) MIME-Version: 1.0 References: <608f1832-2ac3-4459-875e-bdc9a86ad8b8@www.fastmail.com> In-Reply-To: <608f1832-2ac3-4459-875e-bdc9a86ad8b8@www.fastmail.com> From: Lucas Pardue Date: Wed, 7 Aug 2019 01:47:26 +0100 Message-ID: Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="00000000000034d42b058f7c49aa" 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, 07 Aug 2019 00:47:33 -0000 --00000000000034d42b058f7c49aa Content-Type: text/plain; charset="UTF-8" On Wed, Aug 7, 2019 at 1:29 AM Martin Thomson wrote: > > However, I'm also concerned that this is going to get wrapped up in the > usual compliance test mess. If I hook up different parsers on different > streams and my request stream parser doesn't know about SETTINGS at all, so > ignores it when it suddenly appears on a request stream, is the test case > going to fail when I don't generate HTTP_FRAME_IN_THE_WRONG_PLACE? > My intention would be to keep the exisiting error rules and behaviour. Each stream type has a set of allowed Frames, as outlined in Section 7 / Table 1. If your request stream parser totally ignores a mandatory HTTP/3 frame like SETTINGS, it is presently non-conformant (for whatever you choose that to mean). --00000000000034d42b058f7c49aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 7, 2019 at 1:29 AM Martin= Thomson <mt@lowentropy.net>= wrote:

However, I'm also concerned that this is going to get wrapped up in the= usual compliance test mess.=C2=A0 If I hook up different parsers on differ= ent streams and my request stream parser doesn't know about SETTINGS at= all, so ignores it when it suddenly appears on a request stream, is the te= st case going to fail when I don't generate HTTP_FRAME_IN_THE_WRONG_PLA= CE?

My intention would be to keep the e= xisiting error rules and behaviour. Each stream type has a set of allowed F= rames, as outlined in Section 7 / Table 1. If your request stream parser to= tally ignores a mandatory HTTP/3 frame like SETTINGS, it is presently non-c= onformant (for whatever you choose that to mean).

=
--00000000000034d42b058f7c49aa-- From nobody Wed Aug 7 06:26: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 BE6E412004E for ; Wed, 7 Aug 2019 06:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, 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 YIAG3EsMf4AF for ; Wed, 7 Aug 2019 06:26:50 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50C8120086 for ; Wed, 7 Aug 2019 06:26:49 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id v20so35020982uao.3 for ; Wed, 07 Aug 2019 06:26:49 -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=E1OTUHDONeh5x8eI4B/aUBKObWsnOL2WozzvMCMtnzw=; b=VMcMVSn4F4mK2F+630HRkL/HAy1N/eIWOu9wIOFPIA70AgPLHrHiwIJpBENGIRCow5 HqnCsjk5IovPxAklvtuvUH3R6viIBCpEjDKr6JfwtNNHbTdXRR6jfcbCPnOidDg0MaZ5 SB3n7wfZcd/dNcLxa5sWV0ApzR1Gr1X3K6CuWU44quKMKfXeqX2+9DPF7gKxPuAj9bGz fSLJSECHFhflfEaWQ856okxfwA7qLYOggguom06A+OELf9zHCjFvO0XkMFsa6AXchC2M rO8u47mpRfFq6bpnRz24VJL5uCbzx9io7HnI6POA752zmTc8kxODjHVK2LvVZaqzqQwO OPew== 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=E1OTUHDONeh5x8eI4B/aUBKObWsnOL2WozzvMCMtnzw=; b=RUuALOHWLkiZ8ADGfn1cisgICyrkqakE8ESp/d9/eWvyDNILawn1jOzfVK++UNYHKR wqPm3iiYdg2JKKkvshjnb84k7WFchqzmn9hKa5oZHpdVnTPyrTVzYKoNFp5YcpdC+fMv KzWvmEkshhWHxq4riaR8ahdrTv6Rd3Uxhvhd2vvX2/+QBEjvO2MS/zEFu/g7Q1J5WCXP X6Q5+j9ZXMErsXnEPcLkzn/jW7UPwnt4Wc83Zs5BmD8o1o+uNzDdhlPb8FBeiT+Gkanj RaM8fRcCLwNUDX0JAmcr4EBv/BLxJyBlE1cmJ9J6d5h3ui9FQEdLPY3prafUJYUXH4nJ vjng== X-Gm-Message-State: APjAAAVftWwyGwzWNyZ7D/OHhgXERYY40+7rbA6jlEnyuN3QGKbVHRa9 G3zzbMRTDg8WAwxYOmqpEWmkpll17x8diPUuaTvQ7w== X-Google-Smtp-Source: APXvYqy2Ox4k3PVsN6CBRH6J/zGR3mq0hHlAaGsehYrkJ6/O++k44uEeFrH9wBFh1lGc/sFQl/x3HIN7Sycf6mT7gdE= X-Received: by 2002:ab0:2b7:: with SMTP id 52mr6044048uah.23.1565184408593; Wed, 07 Aug 2019 06:26:48 -0700 (PDT) MIME-Version: 1.0 References: <608f1832-2ac3-4459-875e-bdc9a86ad8b8@www.fastmail.com> In-Reply-To: From: Ian Swett Date: Wed, 7 Aug 2019 09:26:36 -0400 Message-ID: Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME To: Lucas Pardue Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="000000000000aeffdd058f86e4d7" 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, 07 Aug 2019 13:26:52 -0000 --000000000000aeffdd058f86e4d7 Content-Type: text/plain; charset="UTF-8" The distinction seems fairly clear to me and I'm happy keeping the draft as is. On Tue, Aug 6, 2019 at 8:47 PM Lucas Pardue wrote: > > > On Wed, Aug 7, 2019 at 1:29 AM Martin Thomson wrote: > >> >> However, I'm also concerned that this is going to get wrapped up in the >> usual compliance test mess. If I hook up different parsers on different >> streams and my request stream parser doesn't know about SETTINGS at all, so >> ignores it when it suddenly appears on a request stream, is the test case >> going to fail when I don't generate HTTP_FRAME_IN_THE_WRONG_PLACE? >> > > My intention would be to keep the exisiting error rules and behaviour. > Each stream type has a set of allowed Frames, as outlined in Section 7 / > Table 1. If your request stream parser totally ignores a mandatory HTTP/3 > frame like SETTINGS, it is presently non-conformant (for whatever you > choose that to mean). > > > --000000000000aeffdd058f86e4d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The distinction seems fairly clear to me and I'm happy= keeping the draft as is.

On Tue, Aug 6, 2019 at 8:47 PM Lucas Pardue <lucaspardue.24.7@gmail.com&= gt; wrote:


On Wed, Aug 7, 2019 at 1:29 AM Martin Thom= son <mt@lowentrop= y.net> wrote:

However, I'm also concerned that this is going to get wrapped up in the= usual compliance test mess.=C2=A0 If I hook up different parsers on differ= ent streams and my request stream parser doesn't know about SETTINGS at= all, so ignores it when it suddenly appears on a request stream, is the te= st case going to fail when I don't generate HTTP_FRAME_IN_THE_WRONG_PLA= CE?

My intention would be to keep the e= xisiting error rules and behaviour. Each stream type has a set of allowed F= rames, as outlined in Section 7 / Table 1. If your request stream parser to= tally ignores a mandatory HTTP/3 frame like SETTINGS, it is presently non-c= onformant (for whatever you choose that to mean).

=
--000000000000aeffdd058f86e4d7-- From nobody Wed Aug 7 07:05: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 647A6120041 for ; Wed, 7 Aug 2019 07:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbbO-iaJzmW4 for ; Wed, 7 Aug 2019 07:05:28 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86AD12003E for ; Wed, 7 Aug 2019 07:05:28 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id j19so28056506otq.2 for ; Wed, 07 Aug 2019 07:05:28 -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=/ufVa1e0bcdbbf21QDS69Bq6PNQvEEZNBEdjFvUtSI0=; b=kjjP006Q4j3skB0ee5soUyJBfYtJrb4SnfcLA5FS5rl0MunIH4h2cneWGrJIJinOcV Kj6y4Yf/RDhD/U6oaErb4vYChwYXvG4dGJipxG20rHOz+qJTHxq7gLnEG1ttii7UfQQh +lV5b4WnBvmPpktypNzQJPQRWNjGTjs72nCHIx3d6tScd9CWHF1pR/1Zv9SLR2OMKlrJ URBufE1oH6TIZQKww0z/f+lfF7MhSZL0+E5iBdNGBKa+z7oHQjc9C3CFZ+gPowxtqHVA L4S5kEXZncts0K/jMxISS0RaVUmzCXrMCo8YPvVC4s/KYtaUcn0+V2i+hCw0bes+MBgE 4Jkw== 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=/ufVa1e0bcdbbf21QDS69Bq6PNQvEEZNBEdjFvUtSI0=; b=gJEVn2JAczEyzFa0V2KOg+54FIFhkxVfn2iCp3EIlRNRDGWw04f34sC5JWwo1z723x Wmz3aWo4qjvwesReCm0Nzpi8IwQISQNeY049Yr01p4wjts6Nkcgnd8fW9NO5dZ6R9JiR rHf4HiIjp/Et4SQrpwue2jQGqOyVkNIVsAS4cKjUka/IanvCmKArMaeB3hTB8lz6hPL/ 1X4m1keSi76HGCvR9XjHg32W6HCBadAOOiQO8t9JilYtrirVocPNyzNd+XXAKJ0KtiSP /EXQRaHnh7/IsQCfldSg1wIbQnIY7f/IxlqlctHd0jcKRAZndoIKRabTBKahHRwF8B8U vrew== X-Gm-Message-State: APjAAAWRSGTj8y9ic6GStXV5fXwcitqqIqKsTPgXJmYTZMu2XXxyS7Fl Pi3VwmJR0ZOq4Rnic1/lI1uWVLSQPsHamLZnXQg= X-Google-Smtp-Source: APXvYqxVh7TALxLrXMtlTFdcjp6yye1lCh9EB1Cj7ifnbA6DgX3LWG5td4JWsHtDBQ8ArHo8oGb8Vt7JDw9F12bJ+ZA= X-Received: by 2002:a5d:960f:: with SMTP id w15mr9355089iol.24.1565186727968; Wed, 07 Aug 2019 07:05:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daan De Meyer Date: Wed, 7 Aug 2019 16:05:17 +0200 Message-ID: Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME To: Lucas Pardue Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 07 Aug 2019 14:05:30 -0000 (I accidentally only replied to Ian so I'm reposting to the entire list) Is there a significant amount of added value by having both HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME? If these errors will only be used for debugging and compliance testing in practice, I think we can definitely get away with just reporting HTTP_UNEXPECTED_FRAME whenever a frame is received that isn't supposed to be received at that point in the connection on that stream. As a very minor nitpick, having only HTTP_UNEXPECTED_FRAME also simplifies error handling in implementations as a default case can be added on a switch on frame type that throws HTTP_UNEXPECTED_FRAME for every frame type that isn't explicitly handled in the switch statement. Currently, one has to differentiate between frame types that should be reported as HTTP_WRONG_STREAM and frame types that should be reported as HTTP_UNEXPECTED_FRAME. My recommendation would be to replace all usages of HTTP_WRONG_STREAM by HTTP_UNEXPECTED_FRAME as in my opinion having both does not add significant value. Regards, Daan De Meyer On Wed, 7 Aug 2019 at 02:03, Lucas Pardue wrot= e: > > Hello WG, > > As part of the HTTP error analysis and feedback, in June I created issue = #2809 "Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME" [1]. > > In short, HTTP_WRONG_STREAM is used for connection errors when a non-allo= wed frame is received by a peer (e.g a server receiving PUSH_PROMISE), or w= hen a request sequence is malformed. HTTP_UNEXPECTED_FRAME is used for conn= ection errors when an allowed frame is received on the wrong type of stream= (e.g. a client receiving PUSH_PROMISE on the control stream). > > Issue 2809 suggests combining these error codes but I've yet to make a PR= . In the meantime, a fair amount of error code refactoring has taken place = and I'm not sure how much demand there is for the change. > > If you have an opinion on this I'd appreciate feedback here or on the tic= ket. > > Cheers > Lucas > > [1] https://github.com/quicwg/base-drafts/issues/2809 From nobody Thu Aug 8 12:15: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 74C5712019C for ; Thu, 8 Aug 2019 12:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 RcfDS23OvEmy for ; Thu, 8 Aug 2019 12:15:52 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750132.outbound.protection.outlook.com [40.107.75.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61078120192 for ; Thu, 8 Aug 2019 12:15:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k74qmDwCgus5ZE2jv7YlsJ6QaHoD92wZkDB/41m6PSll3yM7jXGG6ejNyEMhUDEoqZXAwzKS933c45ezokBooUEJ1ZsXxU31+E1J+Od93ce01Ht6wnOChXP5LM4mp5EcVE9TOuPxLvHBA5wUeX/7TTw/bzJ/B6meMnPvzOx2D1jGWBa0WeJ3x6PZsMI1QcBdfdM0AUaZIEtCrhjbeO8WY8f4PREGisne+6gyKQUQHda2AZ9tW7HFQ127GVWosYq6+8n/8tx6ymDQnYXAcgPde2aHFZWiLO8CgLSMfF3lUS9IYt0iXWiCESYpC0CotvdGi7I7JJEUowepm/DXFChy4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dyXG5rNUDdi/bffVmFKirxGWY7W34+PI0S6v796HedY=; b=PG1d/mCngZVKgy+XC3Gr/vFM4xyjaZWJjftLjWHRTfGTzau9UcON8YEFieFzrwacMRzR8n9eUXmOCaiOKVlRyZtPuyPgMA5C3tirOfne+fZWNCpUHydPkAGiB53uolTl134dmWWCZ+insG9R3Ry1GXb+KsYHhL1w0VMMuNnfQt9xK2UekgHMl5gijXSp3Mh6ygGRA2LfiYyXimKbxb7+gvl1kD6DPJBbY2Ymu7owb5X3ysQ1rj3iakbm/jdtGrqAKeGwh2eFGmLHWQMeMoUENJwmNIsMvpXVFc78NHWzkwdJuZzPPTlDdWORdZkUWpIUhISi9QulHL9dBuLV52x5kg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=evequefou.be;dmarc=pass action=none header.from=evequefou.be;dkim=pass header.d=evequefou.be;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dyXG5rNUDdi/bffVmFKirxGWY7W34+PI0S6v796HedY=; b=MZ0gyQk8yagccK3dqH2rFZvs8id8hbJe0DLdDyjTHeD6oJPjDX/4ITsDL0qWrvSZw/lasMjxcC47lcoLGfhO/rp/nAJI7flDCIFYCG7H129PXcZZOURI1SOIycNinV1BYI8nPtj/jLi3P9wN1WN3Zkdj5QMFvLcAuMfCC3IkJWw= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0456.namprd22.prod.outlook.com (10.173.195.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.20; Thu, 8 Aug 2019 19:15:49 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::4190:c9d6:bf3f:2432]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::4190:c9d6:bf3f:2432%4]) with mapi id 15.20.2157.015; Thu, 8 Aug 2019 19:15:48 +0000 From: Mike Bishop To: Daan De Meyer , Lucas Pardue CC: QUIC WG Subject: RE: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME Thread-Topic: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME Thread-Index: AQHVTLOC2OqR449G9kmbKW6d1/yIBKbvuOCAgAHkLdA= Date: Thu, 8 Aug 2019 19:15:48 +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: [2600:2b00:9323:fe01:b9d1:269e:154e:50a9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 57081c41-68b9-4d82-9eb4-08d71c34d263 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0456; x-ms-traffictypediagnostic: CY4PR22MB0456: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39830400003)(346002)(366004)(376002)(136003)(13464003)(55674003)(189003)(199004)(5660300002)(7736002)(81156014)(71190400001)(71200400001)(74316002)(76176011)(8676002)(81166006)(8936002)(52536014)(14444005)(256004)(229853002)(7696005)(53546011)(6506007)(102836004)(86362001)(316002)(110136005)(99286004)(6246003)(4326008)(53936002)(25786009)(6436002)(9686003)(54896002)(6306002)(55016002)(236005)(186003)(76116006)(14454004)(66946007)(606006)(64756008)(66556008)(66446008)(66476007)(33656002)(966005)(6116002)(790700001)(2906002)(508600001)(46003)(11346002)(476003)(486006)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0456; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: jsNwau3c986M0/wJzCKSGAvyeWdZHRwIsalXXa0upqJlhDkU8PU+v4KW5UwwDvlVaodmUaWiZinicBhs5ueu9Mqv4+T1Pe+gWOYGUO890wPRehJLqBmTqy09U5pDSjAr3+SEG2TIczPmYSkqx9aNPr90LR6ICC2W5AqpM3xBkcomrQlN7YWRsvhPJLuSoH1PP/5eC0QGbJgTekX5Uhx2lnhbI577sD+MBH5UAGv7gmjCO5klaJL00vxcej8i94CHWLkklRt9pR/2pqvs75X/k42o2zS7c1k2gNl3D+/s5EqiLtqpC7xdoxe0lMzxv7yYEjH7V3Q8GgyHb71uFoJ0Fg+rFS8H0SeQA+WvMykMDI3B9rAvIDJ7l3mZRvMAE7BKCWG56x+fmupoMWKRJP1E8xXmiQqApUJSdG0a4tns+Bw= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB09839B9D42D8DD8AB087FDDBDAD70CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 57081c41-68b9-4d82-9eb4-08d71c34d263 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 19:15:48.8176 (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-CrossTenant-userprincipalname: iGG5rNJO7E3Y8xdcVLgfKpROAm+CqkmkqgS7N8dzAnXx7IhI/JeLcOaEqiGykrBT4Ic0OTvS5/nx2AnTtt10Wg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0456 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, 08 Aug 2019 19:15:56 -0000 --_000_CY4PR22MB09839B9D42D8DD8AB087FDDBDAD70CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCB3b3VsZCBiZSBhIGRhbmdlcm91cyBjb2RpbmcgcGF0dGVybi4gIFlvdSdyZSByZXF1aXJl ZCB0byBpZ25vcmUgZnJhbWVzIHlvdSBkb27igJl0IHVuZGVyc3RhbmQgLS0gdGhhdCdzIHdoYXQg YWxsb3dzIHVubmVnb3RpYXRlZCBleHRlbnNpb24gZnJhbWVzLiAgVGhlc2UgZXJyb3IgY29kZXMg YXJlIGV4cGxpY2l0bHkgZm9yIGZyYW1lcyB0aGF0IHlvdSAqZG8qIHVuZGVyc3RhbmQgYW5kIHRo ZXJlZm9yZSBrbm93IHRoYXQgdGhleSBzaG91bGRuJ3QgYmUgdXNlZCBpbiB0aGUgd2F5IHRoZXkg YXJlLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgPHF1aWMt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERhYW4gRGUgTWV5ZXINClNlbnQ6IFdlZG5l c2RheSwgQXVndXN0IDcsIDIwMTkgMTA6MDUgQU0NClRvOiBMdWNhcyBQYXJkdWUgPGx1Y2FzcGFy ZHVlLjI0LjdAZ21haWwuY29tPg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogUmF0aW9uYWxpc2UgSFRUUF9XUk9OR19TVFJFQU0gYW5kIEhUVFBfVU5FWFBFQ1RFRF9G UkFNRQ0KDQoNCg0KKEkgYWNjaWRlbnRhbGx5IG9ubHkgcmVwbGllZCB0byBJYW4gc28gSSdtIHJl cG9zdGluZyB0byB0aGUgZW50aXJlIGxpc3QpDQoNCg0KDQpJcyB0aGVyZSBhIHNpZ25pZmljYW50 IGFtb3VudCBvZiBhZGRlZCB2YWx1ZSBieSBoYXZpbmcgYm90aCBIVFRQX1dST05HX1NUUkVBTSBh bmQgSFRUUF9VTkVYUEVDVEVEX0ZSQU1FPyBJZiB0aGVzZSBlcnJvcnMgd2lsbCBvbmx5IGJlIHVz ZWQgZm9yIGRlYnVnZ2luZyBhbmQgY29tcGxpYW5jZSB0ZXN0aW5nIGluIHByYWN0aWNlLCBJIHRo aW5rIHdlIGNhbiBkZWZpbml0ZWx5IGdldCBhd2F5IHdpdGgganVzdCByZXBvcnRpbmcgSFRUUF9V TkVYUEVDVEVEX0ZSQU1FIHdoZW5ldmVyIGEgZnJhbWUgaXMgcmVjZWl2ZWQgdGhhdCBpc24ndCBz dXBwb3NlZCB0byBiZSByZWNlaXZlZCBhdCB0aGF0IHBvaW50IGluIHRoZSBjb25uZWN0aW9uIG9u IHRoYXQgc3RyZWFtLg0KDQoNCg0KQXMgYSB2ZXJ5IG1pbm9yIG5pdHBpY2ssIGhhdmluZyBvbmx5 IEhUVFBfVU5FWFBFQ1RFRF9GUkFNRSBhbHNvIHNpbXBsaWZpZXMgZXJyb3IgaGFuZGxpbmcgaW4g aW1wbGVtZW50YXRpb25zIGFzIGEgZGVmYXVsdCBjYXNlIGNhbiBiZSBhZGRlZCBvbiBhIHN3aXRj aCBvbiBmcmFtZSB0eXBlIHRoYXQgdGhyb3dzIEhUVFBfVU5FWFBFQ1RFRF9GUkFNRSBmb3IgZXZl cnkgZnJhbWUgdHlwZSB0aGF0IGlzbid0IGV4cGxpY2l0bHkgaGFuZGxlZCBpbiB0aGUgc3dpdGNo IHN0YXRlbWVudC4gQ3VycmVudGx5LCBvbmUgaGFzIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBm cmFtZSB0eXBlcyB0aGF0IHNob3VsZCBiZSByZXBvcnRlZCBhcyBIVFRQX1dST05HX1NUUkVBTSBh bmQgZnJhbWUgdHlwZXMgdGhhdCBzaG91bGQgYmUgcmVwb3J0ZWQgYXMgSFRUUF9VTkVYUEVDVEVE X0ZSQU1FLg0KDQoNCg0KTXkgcmVjb21tZW5kYXRpb24gd291bGQgYmUgdG8gcmVwbGFjZSBhbGwg dXNhZ2VzIG9mIEhUVFBfV1JPTkdfU1RSRUFNIGJ5IEhUVFBfVU5FWFBFQ1RFRF9GUkFNRSBhcyBp biBteSBvcGluaW9uIGhhdmluZyBib3RoIGRvZXMgbm90IGFkZCBzaWduaWZpY2FudCB2YWx1ZS4N Cg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpEYWFuIERlIE1leWVyDQoNCg0KDQpPbiBXZWQsIDcgQXVn IDIwMTkgYXQgMDI6MDMsIEx1Y2FzIFBhcmR1ZSA8bHVjYXNwYXJkdWUuMjQuN0BnbWFpbC5jb208 bWFpbHRvOmx1Y2FzcGFyZHVlLjI0LjdAZ21haWwuY29tPj4gd3JvdGU6DQoNCj4NCg0KPiBIZWxs byBXRywNCg0KPg0KDQo+IEFzIHBhcnQgb2YgdGhlIEhUVFAgZXJyb3IgYW5hbHlzaXMgYW5kIGZl ZWRiYWNrLCBpbiBKdW5lIEkgY3JlYXRlZCBpc3N1ZSAjMjgwOSAiUmF0aW9uYWxpc2UgSFRUUF9X Uk9OR19TVFJFQU0gYW5kIEhUVFBfVU5FWFBFQ1RFRF9GUkFNRSIgWzFdLg0KDQo+DQoNCj4gSW4g c2hvcnQsIEhUVFBfV1JPTkdfU1RSRUFNIGlzIHVzZWQgZm9yIGNvbm5lY3Rpb24gZXJyb3JzIHdo ZW4gYSBub24tYWxsb3dlZCBmcmFtZSBpcyByZWNlaXZlZCBieSBhIHBlZXIgKGUuZyBhIHNlcnZl ciByZWNlaXZpbmcgUFVTSF9QUk9NSVNFKSwgb3Igd2hlbiBhIHJlcXVlc3Qgc2VxdWVuY2UgaXMg bWFsZm9ybWVkLiBIVFRQX1VORVhQRUNURURfRlJBTUUgaXMgdXNlZCBmb3IgY29ubmVjdGlvbiBl cnJvcnMgd2hlbiBhbiBhbGxvd2VkIGZyYW1lIGlzIHJlY2VpdmVkIG9uIHRoZSB3cm9uZyB0eXBl IG9mIHN0cmVhbSAoZS5nLiBhIGNsaWVudCByZWNlaXZpbmcgUFVTSF9QUk9NSVNFIG9uIHRoZSBj b250cm9sIHN0cmVhbSkuDQoNCj4NCg0KPiBJc3N1ZSAyODA5IHN1Z2dlc3RzIGNvbWJpbmluZyB0 aGVzZSBlcnJvciBjb2RlcyBidXQgSSd2ZSB5ZXQgdG8gbWFrZSBhIFBSLi4gSW4gdGhlIG1lYW50 aW1lLCBhIGZhaXIgYW1vdW50IG9mIGVycm9yIGNvZGUgcmVmYWN0b3JpbmcgaGFzIHRha2VuIHBs YWNlIGFuZCBJJ20gbm90IHN1cmUgaG93IG11Y2ggZGVtYW5kIHRoZXJlIGlzIGZvciB0aGUgY2hh bmdlLg0KDQo+DQoNCj4gSWYgeW91IGhhdmUgYW4gb3BpbmlvbiBvbiB0aGlzIEknZCBhcHByZWNp YXRlIGZlZWRiYWNrIGhlcmUgb3Igb24gdGhlIHRpY2tldC4NCg0KPg0KDQo+IENoZWVycw0KDQo+ IEx1Y2FzDQoNCj4NCg0KPiBbMV0gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0 cy9pc3N1ZXMvMjgwOQ0KDQoNCg== --_000_CY4PR22MB09839B9D42D8DD8AB087FDDBDAD70CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjAzMzI2MDc0Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3ODYxODU0NDggNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5UaGF0IHdvdWxkIGJlIGEgZGFuZ2Vyb3VzIGNvZGluZyBwYXR0ZXJuLiZuYnNwOyBZ b3UncmUgcmVxdWlyZWQgdG8gaWdub3JlIGZyYW1lcyB5b3UgZG9u4oCZdCB1bmRlcnN0YW5kIC0t IHRoYXQncyB3aGF0IGFsbG93cyB1bm5lZ290aWF0ZWQgZXh0ZW5zaW9uIGZyYW1lcy4mbmJzcDsg VGhlc2UgZXJyb3IgY29kZXMgYXJlIGV4cGxpY2l0bHkgZm9yIGZyYW1lcyB0aGF0IHlvdSAqZG8q IHVuZGVyc3RhbmQgYW5kIHRoZXJlZm9yZQ0KIGtub3cgdGhhdCB0aGV5IHNob3VsZG4ndCBiZSB1 c2VkIGluIHRoZSB3YXkgdGhleSBhcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogUVVJQyAmbHQ7cXVpYy1ib3VuY2Vz QGlldGYub3JnJmd0OyBPbiBCZWhhbGYgT2YgRGFhbiBEZSBNZXllcjxicj4NClNlbnQ6IFdlZG5l c2RheSwgQXVndXN0IDcsIDIwMTkgMTA6MDUgQU08YnI+DQpUbzogTHVjYXMgUGFyZHVlICZsdDts dWNhc3BhcmR1ZS4yNC43QGdtYWlsLmNvbSZndDs8YnI+DQpDYzogUVVJQyBXRyAmbHQ7cXVpY0Bp ZXRmLm9yZyZndDs8YnI+DQpTdWJqZWN0OiBSZTogUmF0aW9uYWxpc2UgSFRUUF9XUk9OR19TVFJF QU0gYW5kIEhUVFBfVU5FWFBFQ1RFRF9GUkFNRTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KEkgYWNjaWRl bnRhbGx5IG9ubHkgcmVwbGllZCB0byBJYW4gc28gSSdtIHJlcG9zdGluZyB0byB0aGUgZW50aXJl IGxpc3QpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklzIHRoZXJlIGEgc2lnbmlmaWNh bnQgYW1vdW50IG9mIGFkZGVkIHZhbHVlIGJ5IGhhdmluZyBib3RoIEhUVFBfV1JPTkdfU1RSRUFN IGFuZCBIVFRQX1VORVhQRUNURURfRlJBTUU/IElmIHRoZXNlIGVycm9ycyB3aWxsIG9ubHkgYmUg dXNlZCBmb3IgZGVidWdnaW5nIGFuZCBjb21wbGlhbmNlIHRlc3RpbmcgaW4gcHJhY3RpY2UsIEkg dGhpbmsgd2UgY2FuIGRlZmluaXRlbHkgZ2V0IGF3YXkgd2l0aCBqdXN0DQogcmVwb3J0aW5nIEhU VFBfVU5FWFBFQ1RFRF9GUkFNRSB3aGVuZXZlciBhIGZyYW1lIGlzIHJlY2VpdmVkIHRoYXQgaXNu J3Qgc3VwcG9zZWQgdG8gYmUgcmVjZWl2ZWQgYXQgdGhhdCBwb2ludCBpbiB0aGUgY29ubmVjdGlv biBvbiB0aGF0IHN0cmVhbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QXMgYSB2ZXJ5 IG1pbm9yIG5pdHBpY2ssIGhhdmluZyBvbmx5IEhUVFBfVU5FWFBFQ1RFRF9GUkFNRSBhbHNvIHNp bXBsaWZpZXMgZXJyb3IgaGFuZGxpbmcgaW4gaW1wbGVtZW50YXRpb25zIGFzIGEgZGVmYXVsdCBj YXNlIGNhbiBiZSBhZGRlZCBvbiBhIHN3aXRjaCBvbiBmcmFtZSB0eXBlIHRoYXQgdGhyb3dzIEhU VFBfVU5FWFBFQ1RFRF9GUkFNRSBmb3IgZXZlcnkgZnJhbWUgdHlwZSB0aGF0IGlzbid0IGV4cGxp Y2l0bHkNCiBoYW5kbGVkIGluIHRoZSBzd2l0Y2ggc3RhdGVtZW50LiBDdXJyZW50bHksIG9uZSBo YXMgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGZyYW1lIHR5cGVzIHRoYXQgc2hvdWxkIGJlIHJl cG9ydGVkIGFzIEhUVFBfV1JPTkdfU1RSRUFNIGFuZCBmcmFtZSB0eXBlcyB0aGF0IHNob3VsZCBi ZSByZXBvcnRlZCBhcyBIVFRQX1VORVhQRUNURURfRlJBTUUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPk15IHJlY29tbWVuZGF0aW9uIHdvdWxkIGJlIHRvIHJlcGxhY2UgYWxsIHVzYWdl cyBvZiBIVFRQX1dST05HX1NUUkVBTSBieSBIVFRQX1VORVhQRUNURURfRlJBTUUgYXMgaW4gbXkg b3BpbmlvbiBoYXZpbmcgYm90aCBkb2VzIG5vdCBhZGQgc2lnbmlmaWNhbnQgdmFsdWUuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkRhYW4gRGUgTWV5ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gV2Vk LCA3IEF1ZyAyMDE5IGF0IDAyOjAzLCBMdWNhcyBQYXJkdWUgJmx0OzxhIGhyZWY9Im1haWx0bzps dWNhc3BhcmR1ZS4yNC43QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmx1Y2FzcGFyZHVlLjI0LjdAZ21haWwuY29tPC9zcGFuPjwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIZWxs byBXRyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQXMgcGFydCBvZiB0 aGUgSFRUUCBlcnJvciBhbmFseXNpcyBhbmQgZmVlZGJhY2ssIGluIEp1bmUgSSBjcmVhdGVkIGlz c3VlICMyODA5ICZxdW90O1JhdGlvbmFsaXNlIEhUVFBfV1JPTkdfU1RSRUFNIGFuZCBIVFRQX1VO RVhQRUNURURfRlJBTUUmcXVvdDsgWzFdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBJbiBzaG9ydCwgSFRUUF9XUk9OR19TVFJFQU0gaXMgdXNlZCBmb3IgY29ubmVjdGlv biBlcnJvcnMgd2hlbiBhIG5vbi1hbGxvd2VkIGZyYW1lIGlzIHJlY2VpdmVkIGJ5IGEgcGVlciAo ZS5nIGEgc2VydmVyIHJlY2VpdmluZyBQVVNIX1BST01JU0UpLCBvciB3aGVuIGEgcmVxdWVzdCBz ZXF1ZW5jZSBpcyBtYWxmb3JtZWQuIEhUVFBfVU5FWFBFQ1RFRF9GUkFNRSBpcyB1c2VkIGZvciBj b25uZWN0aW9uIGVycm9ycw0KIHdoZW4gYW4gYWxsb3dlZCBmcmFtZSBpcyByZWNlaXZlZCBvbiB0 aGUgd3JvbmcgdHlwZSBvZiBzdHJlYW0gKGUuZy4gYSBjbGllbnQgcmVjZWl2aW5nIFBVU0hfUFJP TUlTRSBvbiB0aGUgY29udHJvbCBzdHJlYW0pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBJc3N1ZSAyODA5IHN1Z2dlc3RzIGNvbWJpbmluZyB0aGVzZSBlcnJvciBjb2Rl cyBidXQgSSd2ZSB5ZXQgdG8gbWFrZSBhIFBSLi4gSW4gdGhlIG1lYW50aW1lLCBhIGZhaXIgYW1v dW50IG9mIGVycm9yIGNvZGUgcmVmYWN0b3JpbmcgaGFzIHRha2VuIHBsYWNlIGFuZCBJJ20gbm90 IHN1cmUgaG93IG11Y2ggZGVtYW5kIHRoZXJlIGlzIGZvciB0aGUgY2hhbmdlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJZiB5b3UgaGF2ZSBhbiBvcGluaW9uIG9uIHRo aXMgSSdkIGFwcHJlY2lhdGUgZmVlZGJhY2sgaGVyZSBvciBvbiB0aGUgdGlja2V0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBDaGVlcnM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgTHVjYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgWzFdIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFz ZS1kcmFmdHMvaXNzdWVzLzI4MDkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMv aXNzdWVzLzI4MDk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR22MB09839B9D42D8DD8AB087FDDBDAD70CY4PR22MB0983namp_-- From nobody Thu Aug 8 12:16: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 137AC120192 for ; Thu, 8 Aug 2019 12:15:58 -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 3xL2QWG4Eknr for ; Thu, 8 Aug 2019 12:15:54 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810118.outbound.protection.outlook.com [40.107.81.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F84812018E for ; Thu, 8 Aug 2019 12:15:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tl+OMs2adgSaUSC2WzWSmbtOfCQl1E3V637x1o3K4g7FFmiWRJa1TG2ee7Jt0NxUM6fqhTjgJllfsOlGnV5rqrqEnlS+v5NA3nJ7pOUTUdiSvj7KKw9eTo0GgqgzgJmpzdoK4GJGP35+rEg1Q4k5DQ3ngP2PjKvL6mSAh5lH9dD7nw7mc3obFsGC7qGg0VTwffvqYmZLRHAlzgU4bVxhqVLK/iv39Ibdb+yYf3w3vy+r/K1dPfIapzvLW+3TfNvPzpeMiJT+p7/FhtAYBmZ7PDI8SnSLiBDHErAx7r8Z29q6QBUTSh9+FNQ7vyNLytXaOxwkk3Wg/EJV6IXyKQ9c6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DO1V5MXO0qha0pmsmrJ7UrxIaGtTA8xCoFYuH1eUOvU=; b=aBqH578sI9G3HjqJukDz615hZZMnDWKQL7chdeJYYn97/VMZlXhmR6uSyDAmzLg5/7LPqiaf8xiZnr97xay1K2IlMepnJsBmyPE3CDhLn8onWR4U0jnGBPcKtCE0tgPQiETBRfL2rj0uPL116iiY801wTTqI5IhAJAXJKf9zgG34w6+Yphgs3v7+vlqiEtxkzQbFwfyYReof0Ud+CEOs6CG5D4VL2i4jT35ibgMw+ywCUayU8YAViCBnFkrZ4fjRTW3nGsyqJUpdilreCU03pVwzKnMVZA5euRP5x+a7mdCObr1DQpJOLSUCdWZ6rlvsyHboXqaAiDITj0rXaANmPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DO1V5MXO0qha0pmsmrJ7UrxIaGtTA8xCoFYuH1eUOvU=; b=doAIwOnN61q3ujHVevIZdwjHS+N3op3pTH0CawSUW8PfowbFgwwIVwrrB0ur71xgeWvNSMxvdh2DjmobthVzzxTfpYNlxpJqZ9zf5mF8MAdB7NVOxNFZslcss2Tfi3BVs6dUD80fSg5L8ryDnz5DRHYLFtTr+xeqc2s7xmQbo+I= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0792.namprd22.prod.outlook.com (10.171.170.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.18; Thu, 8 Aug 2019 19:15:52 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::4190:c9d6:bf3f:2432]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::4190:c9d6:bf3f:2432%4]) with mapi id 15.20.2157.015; Thu, 8 Aug 2019 19:15:52 +0000 From: Mike Bishop To: Martin Thomson , "quic@ietf.org" Subject: RE: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME Thread-Topic: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME Thread-Index: AQHVTLOC2OqR449G9kmbKW6d1/yIBKbu1LKAgALMmwA= Date: Thu, 8 Aug 2019 19:15:52 +0000 Message-ID: References: <608f1832-2ac3-4459-875e-bdc9a86ad8b8@www.fastmail.com> In-Reply-To: <608f1832-2ac3-4459-875e-bdc9a86ad8b8@www.fastmail.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=mbishop@evequefou.be; x-originating-ip: [2600:2b00:9323:fe01:b9d1:269e:154e:50a9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2013293-972e-40ab-3c7e-08d71c34d4a1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0792; x-ms-traffictypediagnostic: CY4PR22MB0792: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39830400003)(396003)(136003)(366004)(13464003)(189003)(199004)(33656002)(99286004)(186003)(81166006)(66556008)(66476007)(76116006)(66946007)(110136005)(64756008)(6246003)(790700001)(53936002)(508600001)(25786009)(6436002)(229853002)(71190400001)(6116002)(9686003)(256004)(54896002)(6306002)(8936002)(14444005)(66446008)(2906002)(81156014)(8676002)(55016002)(74316002)(71200400001)(7736002)(316002)(14454004)(446003)(11346002)(486006)(476003)(2501003)(46003)(86362001)(102836004)(6506007)(53546011)(76176011)(7696005)(5660300002)(52536014); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0792; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 8xzgtweHeKNHgqhOccnQG9tnALRIaY14moh4zj3fewG2i93CsAhGqj/e/u6PLRKIb3Ej13nMKNUtLk1J0CSSGR5vCjUyyuBCoOkUUIeJNYuniEisHPEtfhAedJn8Le1FtVARxo/XuulqaCS148WMTbVgNx+zUrT5F2KXjTJEYZs+wZP3aFsEloC41twN1jgH/vg+8NxZXn1pFF0q1NPwYfkAgV+3AQL7F8H3nr7ZZ1qoO2y6JD+yJk3OY3L55xUCPIzS7aTSCwhkbAyA2MCW2fATP4WqPnYoZ5rx1m8XLmGkCN1sFIoWo64epRq5xQLvxX1JPib4VptfIwlPfsk2uqFWbrLLxfOTlMDaL1ZmwsbPavfjOanhoeQnW6A5YcFJY4md3mZYfO34/oL6gAul9Bel14p5e6GAsNuUP9zOfKA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR22MB098352FA3BDA1AAF6918BA75DAD70CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: f2013293-972e-40ab-3c7e-08d71c34d4a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 19:15:52.5019 (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-CrossTenant-userprincipalname: yjwPk66LV2sgSvxq+5JCobxMhnZsYe2T5KdJEedPEyyzYariFak66xqxyPlxV1OhI4agu1AuQu3G3yzUjKDtbA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0792 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, 08 Aug 2019 19:15:58 -0000 --_000_CY4PR22MB098352FA3BDA1AAF6918BA75DAD70CY4PR22MB0983namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As Lucas said, if you have a separate parser by stream type and the frames = defined for other streams simply aren't handled, that would violate the MUS= T-error requirements we currently have. You would fail a compliance test. I see a couple separable questions that we need to answer to move forward h= ere: * Should this even be possible? QUIC has established a pattern of maki= ng it impossible to send invalid values. An H3 incarnation of that pattern= would be to split the frame type spaces so there's no such thing as WRONG_= STREAM, just unknown frame types. Should WRONG_STREAM be possible to expre= ss? * If so, is this error easily detectable? We've established a principl= e that easily detected protocol violations will be required to generate an = error. The current text reflects this principle, since known frame types a= nd their valid streams are easily detectable. * If the pattern Martin suggests might be common, and therefore this= error isn't "easily detected," these would become SHOULD-error instead. * Only then, the original question, is there value in having separate e= rror codes? I find the separate frame type registries slightly attractive, but unless w= e cross-reserve values (which defeats the point), we'd be breaking the last= vestiges of HTTP/2 resemblance. It's also a pretty fundamental change for= a protocol on the edge of late-stage process. I don't think I'd want to b= ite that off unless the working group as a whole feels strongly that it's a= n improvement, and I'm not seeing that so far. I tend to think that misuse of known frame types is easily detectable and t= herefore Martin's hypothetical implementation is simply wrong. However, th= e value in the distinction between the two seems minimal. I'd vote for mer= ging. -----Original Message----- From: QUIC On Behalf Of Martin Thomson Sent: Tuesday, August 6, 2019 8:29 PM To: quic@ietf.org Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME On Wed, Aug 7, 2019, at 10:03, Lucas Pardue wrote: > As part of the HTTP error analysis and feedback, in June I created > issue #2809 "Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME" > [1]. The notion of a signal for "I got a frame that I understood, but it was in = the wrong place" is fine. Good even. But I don't see a need to have two s= uch signals. So I'm in favour of collapsing the two. I don't understand t= he distinction between these signals as it stands anyway. However, I'm also concerned that this is going to get wrapped up in the usu= al compliance test mess. If I hook up different parsers on different strea= ms and my request stream parser doesn't know about SETTINGS at all, so igno= res it when it suddenly appears on a request stream, is the test case going= to fail when I don't generate HTTP_FRAME_IN_THE_WRONG_PLACE? --_000_CY4PR22MB098352FA3BDA1AAF6918BA75DAD70CY4PR22MB0983namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As Lucas said, if you have a separate parser by s= tream type and the frames defined for other streams simply aren't handled, = that would violate the MUST-error requirements we currently have.  You= would fail a compliance test.

 

I see a couple separable questions that we need t= o answer to move forward here:

  • Should this= even be possible?  QUIC has established a pattern of making it im= possible to send invalid values.  An H3 incarnation of that pattern wo= uld be to split the frame type spaces so there’s no such thing as WRONG_STREAM, just unknown frame types.  Should WRON= G_STREAM be possible to express?
  • If so, is this error easily detectable= ?  We’ve established a principle that easily detected protoc= ol violations will be required to generate an error.  The current text= reflects this principle, since known frame types and their valid streams are easily detectable.
    • If the pattern= Martin suggests might be common, and therefore this error isn’t R= 20;easily detected,” these would become SHOULD-error instead.
  • Only then, the= original question, is there value in having separate error codes?

 

I find the separate frame type registries slightl= y attractive, but unless we cross-reserve values (which defeats the point),= we’d be breaking the last vestiges of HTTP/2 resemblance.  It&#= 8217;s also a pretty fundamental change for a protocol on the edge of late-stage process.  I don’t think I’d wan= t to bite that off unless the working group as a whole feels strongly that = it’s an improvement, and I’m not seeing that so far.=

 

I tend to think that misuse of known frame types = is easily detectable and therefore Martin’s hypothetical implementati= on is simply wrong.  However, the value in the distinction between the= two seems minimal.  I’d vote for merging.

 

-----Original Message-----
From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Thomson
Sent: Tuesday, August 6, 2019 8:29 PM
To: quic@ietf.org
Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME

 

On Wed, Aug 7, 2019, at 10:03, Lucas Pardue wrote= :

> As part of the HTTP error analysis and feedb= ack, in June I created

> issue #2809 "Rationalise HTTP_WRONG_STR= EAM and HTTP_UNEXPECTED_FRAME"

> [1].

 

The notion of a signal for "I got a frame th= at I understood, but it was in the wrong place" is fine.  Good ev= en.  But I don't see a need to have two such signals.  So I'm in = favour of collapsing the two.  I don't understand the distinction between these signals as it stands anyway.

 

However, I'm also concerned that this is going to= get wrapped up in the usual compliance test mess.  If I hook up diffe= rent parsers on different streams and my request stream parser doesn't know= about SETTINGS at all, so ignores it when it suddenly appears on a request stream, is the test case going to fail wh= en I don't generate HTTP_FRAME_IN_THE_WRONG_PLACE?

 

--_000_CY4PR22MB098352FA3BDA1AAF6918BA75DAD70CY4PR22MB0983namp_-- From nobody Thu Aug 8 12:29: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 238581200B8 for ; Thu, 8 Aug 2019 12:29:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAM2gZ1gnvtp for ; Thu, 8 Aug 2019 12:29:27 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0: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 0737A12002F for ; Thu, 8 Aug 2019 12:29:27 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id r6so123193677oti.3 for ; Thu, 08 Aug 2019 12:29:26 -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=tL5Z33zNtfZzZPzabCnoJIebDs6w48fDFvzuY2kE4YY=; b=qASgB+PI+RhVB0aOlChrKOCkLQOslNxI4Wp1Kv4H+71bVYlewsezamI/nM1gWreilj FIn4/4WxUACmsvwUhTO+tJEfZLDZmiua7VrAIuGOjyhVXp9/I/pgJPCjBWJX071+nrpc IXl1A0NWCU/qCX4LLuwKjdnyXn/6b+b+Dok7ngqHZLhNUeawCTwomUjvNPkVX2XY+A1R Jb5SeH8W3SAYZBYRBQZWyTufXTCoA+Xl4H4tx4OpRLWurLIVRNESnDvJrOzcbNYU10rF AyyKbMyR1UV2PuuPJ33TJnNR+mkBBzT7GDKTUgQj+qL29xPe6E+OY7g/NbsjT7p0A8Sj yvhA== 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=tL5Z33zNtfZzZPzabCnoJIebDs6w48fDFvzuY2kE4YY=; b=T9wwcYp9lEUcpCAGqah4ESypBzawW/UhbikRu/C2iZlk2tF2h1bXBUo+PkzR5yC/nn yWsg+4MJPfz9/hRRz/sW8215lvAQp5ZyRvFmAzjlKkV+tNwLYNU1O0Eyg5j+SFLqh203 YtqGVVjTiE+icjDkxpOLe+N4QMyJjVS3tYx+RumCYO44mVz7l/wUFXKt/NrOQfXzTiQP tn51yBZgvVWfTBeK8+OO54fAbGXEqW6JViAWLu2KO5uSJLP75JHhIMKP41q45APJ6l6+ RfpI9v6lJHI3L7cI4Mo+ru3SlQxScz9O20A0XNuTnmBUXe+RMyHf3F63mZ6jfWhaYV1b TZmg== X-Gm-Message-State: APjAAAVXSWK4wWW4Lr1XiOayWBasHqCCTYF2Kpt8PQhbMFwyG/mQafXU zkRtsXCMT2svANVuvCgtgmcBPx8p5ZlvF6nLrdM= X-Google-Smtp-Source: APXvYqy5gmNfP3MbJvIVHwLo8y2kSTwNCp7Xq0oEkZXmWifqOBD3J9EJ3L78hkItNk5sDuFp3TpzcngAAjEDezX3+tA= X-Received: by 2002:a02:c916:: with SMTP id t22mr17971542jao.24.1565292566303; Thu, 08 Aug 2019 12:29:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daan De Meyer Date: Thu, 8 Aug 2019 21:29:15 +0200 Message-ID: Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME To: Mike Bishop Cc: Lucas Pardue , 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, 08 Aug 2019 19:29:29 -0000 Of course, that's completely right. I forgot to mention that unknown frame types are already ignored when I'm parsing frames so when my implementation is at the point where it switches on frame type to determine the next action to take, all unknown frame types have already been ignored. Regards, Daan On Thu, 8 Aug 2019 at 21:15, Mike Bishop wrote: > > That would be a dangerous coding pattern. You're required to ignore fram= es you don=E2=80=99t understand -- that's what allows unnegotiated extensio= n frames. These error codes are explicitly for frames that you *do* unders= tand and therefore know that they shouldn't be used in the way they are. > > > > -----Original Message----- > From: QUIC On Behalf Of Daan De Meyer > Sent: Wednesday, August 7, 2019 10:05 AM > To: Lucas Pardue > Cc: QUIC WG > Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME > > > > (I accidentally only replied to Ian so I'm reposting to the entire list) > > > > Is there a significant amount of added value by having both HTTP_WRONG_ST= REAM and HTTP_UNEXPECTED_FRAME? If these errors will only be used for debug= ging and compliance testing in practice, I think we can definitely get away= with just reporting HTTP_UNEXPECTED_FRAME whenever a frame is received tha= t isn't supposed to be received at that point in the connection on that str= eam. > > > > As a very minor nitpick, having only HTTP_UNEXPECTED_FRAME also simplifie= s error handling in implementations as a default case can be added on a swi= tch on frame type that throws HTTP_UNEXPECTED_FRAME for every frame type th= at isn't explicitly handled in the switch statement. Currently, one has to = differentiate between frame types that should be reported as HTTP_WRONG_STR= EAM and frame types that should be reported as HTTP_UNEXPECTED_FRAME. > > > > My recommendation would be to replace all usages of HTTP_WRONG_STREAM by = HTTP_UNEXPECTED_FRAME as in my opinion having both does not add significant= value. > > > > Regards, > > > > Daan De Meyer > > > > On Wed, 7 Aug 2019 at 02:03, Lucas Pardue wr= ote: > > > > > > Hello WG, > > > > > > As part of the HTTP error analysis and feedback, in June I created issu= e #2809 "Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME" [1]. > > > > > > In short, HTTP_WRONG_STREAM is used for connection errors when a non-al= lowed frame is received by a peer (e.g a server receiving PUSH_PROMISE), or= when a request sequence is malformed. HTTP_UNEXPECTED_FRAME is used for co= nnection errors when an allowed frame is received on the wrong type of stre= am (e.g. a client receiving PUSH_PROMISE on the control stream). > > > > > > Issue 2809 suggests combining these error codes but I've yet to make a = PR.. In the meantime, a fair amount of error code refactoring has taken pla= ce and I'm not sure how much demand there is for the change. > > > > > > If you have an opinion on this I'd appreciate feedback here or on the t= icket. > > > > > > Cheers > > > Lucas > > > > > > [1] https://github.com/quicwg/base-drafts/issues/2809 > > From nobody Thu Aug 8 14:08: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 1F8651202E8 for ; Thu, 8 Aug 2019 14:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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_HELO_NONE=0.001, 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 qgITEEM-wbdU for ; Thu, 8 Aug 2019 14:08:17 -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 49C431202DD for ; Thu, 8 Aug 2019 14:08:17 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id 34so36979500uar.8 for ; Thu, 08 Aug 2019 14:08:17 -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=FBfUDjwZxXWYJVmvaDKBkZ87TmIBbmRELAPDpn09VZI=; b=q9ff01hAbZAMBnEjjd6Pscz0Tn6p9bqt4Mbk6UnWa9G8LXKZLmVQYadMV18LAdqPLC A8QQWp5q/p9XDkHw7H5xgTyWmvcqUImor6unmnfWDPLst1RvMjBAwLZb0AI/YedsEBUc yRykzDMaJoNO9x77zQVuXcfCXmmigganT+K6Blg5Hk5Ajio2Bm9qHMN1AFU0ajsOiK/c osTPUhrd5vxifrl5tR188tGskL3OTSwhJDEYnwXUx8kcLBeyajmXF3njmdP2bA8JvRAJ ZsCPjrKzgaTvVemoIRNP4AhJjVLOeEJNjBV4S8RATwLihBcbLhVs3jPT20fHiq/dI8Gc 1DNg== 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=FBfUDjwZxXWYJVmvaDKBkZ87TmIBbmRELAPDpn09VZI=; b=L5NoMr9UcZoTrfNv8ZeFnzZnyx+tKMtvtFCR/oPB3BlZGrShCDG3pAkrjYUceFvr0m SO+90hD/PVz2MP0cLoO5LLsakjd9/lSQa/rZkDY2XMMzI4SG2YIIkp0ag+4xewU92rXb D9VLzrx6VGaOdaa9NNNjm5N3wQ7fiyflhpDF0bd+Pi1+nTDfZw9gBMGXpim6I+sIq0JW eaGkrf05Ld4PtdRtabJQ3QgQTxsNM2sq9pG67rMjPH6Vqwhgq/I/iv3BYXkJ4SG+K5t6 zNbaHZLLP7lT4LR4L9WMZNYLZFJtEOxyD1kwtdmhzMTy7DBbaVbe2D9eIHE3r0oyye6c +gVQ== X-Gm-Message-State: APjAAAWg3LSb8QaButUkUFSVQVj6wRd+hv6iwGdKV7OZ8qEsH14VfCLt +CyvePEgcAsuTGN3lavJV0V3+LOHkcBDaFoaLgNLdnq2 X-Google-Smtp-Source: APXvYqw5D+ik445ibnDUAZMQLt7FIi79PQ0jqFz90QqamiKtsQvo0aMmSh+6zP6nePBb1YINAheUZuz2KafFKhNGI2Y= X-Received: by 2002:a9f:248b:: with SMTP id 11mr11198857uar.9.1565298496315; Thu, 08 Aug 2019 14:08:16 -0700 (PDT) MIME-Version: 1.0 References: <608f1832-2ac3-4459-875e-bdc9a86ad8b8@www.fastmail.com> In-Reply-To: From: Lucas Pardue Date: Thu, 8 Aug 2019 22:08:04 +0100 Message-ID: Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME To: Mike Bishop Cc: Martin Thomson , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d72461058fa17412" 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, 08 Aug 2019 21:08:19 -0000 --000000000000d72461058fa17412 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also overlooked something, HTTP_MALFORMED_FRAME was replaced with HTTP_FRAME_ERROR which is presently defiend for use when a frame layout is wrong, or its size is wrong. Is the case of syntax error sufficiently unique from used incorrectly error that HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME currently articulate? There is some overlap, so an more extreme step would be to merge them into HTTP_FRAME_ERROR. I'm undecided on the best course of action here, I don't even think preparing candidate PRs will help the conversation much because of the nature of the issue. On Thu, Aug 8, 2019 at 8:16 PM Mike Bishop wrote: > As Lucas said, if you have a separate parser by stream type and the frame= s > defined for other streams simply aren't handled, that would violate the > MUST-error requirements we currently have. You would fail a compliance > test. > > > > I see a couple separable questions that we need to answer to move forward > here: > > - *Should this even be possible?* QUIC has established a pattern of > making it impossible to send invalid values. An H3 incarnation of tha= t > pattern would be to split the frame type spaces so there=E2=80=99s no = such thing as > WRONG_STREAM, just unknown frame types. Should WRONG_STREAM be possib= le to > express? > - *If so, is this error easily detectable?* We=E2=80=99ve established= a > principle that easily detected protocol violations will be required to > generate an error. The current text reflects this principle, since kn= own > frame types and their valid streams are easily detectable. > - If the pattern Martin suggests might be common, and therefore > this error isn=E2=80=99t =E2=80=9Ceasily detected,=E2=80=9D these w= ould become SHOULD-error instead. > - Only then, the original question, *is there value in having separate > error codes?* > > > > I find the separate frame type registries slightly attractive, but unless > we cross-reserve values (which defeats the point), we=E2=80=99d be breaki= ng the > last vestiges of HTTP/2 resemblance. It=E2=80=99s also a pretty fundamen= tal change > for a protocol on the edge of late-stage process. I don=E2=80=99t think = I=E2=80=99d want > to bite that off unless the working group as a whole feels strongly that > it=E2=80=99s an improvement, and I=E2=80=99m not seeing that so far. > > > > I tend to think that misuse of known frame types is easily detectable and > therefore Martin=E2=80=99s hypothetical implementation is simply wrong. = However, > the value in the distinction between the two seems minimal. I=E2=80=99d = vote for > merging. > > > > -----Original Message----- > From: QUIC On Behalf Of Martin Thomson > Sent: Tuesday, August 6, 2019 8:29 PM > To: quic@ietf.org > Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME > > > > On Wed, Aug 7, 2019, at 10:03, Lucas Pardue wrote: > > > As part of the HTTP error analysis and feedback, in June I created > > > issue #2809 "Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME" > > > [1]. > > > > The notion of a signal for "I got a frame that I understood, but it was i= n > the wrong place" is fine. Good even. But I don't see a need to have two > such signals. So I'm in favour of collapsing the two. I don't understan= d > the distinction between these signals as it stands anyway. > > > > However, I'm also concerned that this is going to get wrapped up in the > usual compliance test mess. If I hook up different parsers on different > streams and my request stream parser doesn't know about SETTINGS at all, = so > ignores it when it suddenly appears on a request stream, is the test case > going to fail when I don't generate HTTP_FRAME_IN_THE_WRONG_PLACE? > > > --000000000000d72461058fa17412 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also overlooked something, HTTP_MALFORMED_FRAME was= replaced with HTTP_FRAME_ERROR which is presently defiend for use when a f= rame layout is wrong, or its size is wrong.

I= s the case of syntax error sufficiently unique from used incorrectly error = that=20 HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME=C2=A0 currently articulate? There is some overlap, so an more extreme step would = be to merge them into HTTP_FRAME_ERROR.

I'm un= decided on the best course of action here, I don't even think preparing= candidate PRs will help the conversation much because of the nature of the= issue.

On Thu, Aug 8, 2019 at 8:16 PM Mike Bishop <mbishop@evequefou.be> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

As Lucas said, if you = have a separate parser by stream type and the frames defined for other stre= ams simply aren't handled, that would violate the MUST-error requiremen= ts we currently have.=C2=A0 You would fail a compliance test.=

=C2=A0

I see a couple separab= le questions that we need to answer to move forward here:

  • Should this even b= e possible?=C2=A0 QUIC has established a pattern of making it impossibl= e to send invalid values.=C2=A0 An H3 incarnation of that pattern would be = to split the frame type spaces so there=E2=80=99s no such thing as WRONG_STREAM, just unknown frame types.=C2=A0 Should WRON= G_STREAM be possible to express?
  • If so, is this error easily detectable?=C2=A0 We=E2=80=99ve established a principle that easily detected protocol= violations will be required to generate an error.=C2=A0 The current text r= eflects this principle, since known frame types and their valid streams are easily detectable.<= /u>
    • If the pattern Martin= suggests might be common, and therefore this error isn=E2=80=99t =E2=80=9C= easily detected,=E2=80=9D these would become SHOULD-error instead.
  • Only then, the origin= al question, is there value in having separate error codes?

    • =C2=A0

    I find the separate fr= ame type registries slightly attractive, but unless we cross-reserve values= (which defeats the point), we=E2=80=99d be breaking the last vestiges of H= TTP/2 resemblance.=C2=A0 It=E2=80=99s also a pretty fundamental change for = a protocol on the edge of late-stage process.=C2=A0 I don=E2=80=99t think I=E2=80=99d= want to bite that off unless the working group as a whole feels strongly t= hat it=E2=80=99s an improvement, and I=E2=80=99m not seeing that so far.=

    =C2=A0

    I tend to think that m= isuse of known frame types is easily detectable and therefore Martin=E2=80= =99s hypothetical implementation is simply wrong.=C2=A0 However, the value = in the distinction between the two seems minimal.=C2=A0 I=E2=80=99d vote fo= r merging.

    =C2=A0

    -----Original Message-= ----
    From: QUIC <q= uic-bounces@ietf.org> On Behalf Of Martin Thomson
    Sent: Tuesday, August 6, 2019 8:29 PM
    To: quic@ietf.org Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME

    =C2=A0

    On Wed, Aug 7, 2019, a= t 10:03, Lucas Pardue wrote:

    > As part of the HT= TP error analysis and feedback, in June I created

    > issue #2809 "= ;Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME"

    > [1].

    =C2=A0

    The notion of a signal= for "I got a frame that I understood, but it was in the wrong place&q= uot; is fine.=C2=A0 Good even.=C2=A0 But I don't see a need to have two= such signals.=C2=A0 So I'm in favour of collapsing the two.=C2=A0 I do= n't understand the distinction between these signals as it stands anyway.

    =C2=A0

    However, I'm also = concerned that this is going to get wrapped up in the usual compliance test= mess.=C2=A0 If I hook up different parsers on different streams and my req= uest stream parser doesn't know about SETTINGS at all, so ignores it wh= en it suddenly appears on a request stream, is the test case going to fail wh= en I don't generate HTTP_FRAME_IN_THE_WRONG_PLACE?

    =C2=A0

--000000000000d72461058fa17412-- From nobody Thu Aug 8 17:49:07 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 5892C120025; Thu, 8 Aug 2019 17:49:05 -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, mnot@mnot.net, quic@ietf.org, quic-chairs@ietf.org Subject: quic - New Interim Meeting Request X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156531174528.7534.16115639949213407517.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2019 17:49:05 -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: Fri, 09 Aug 2019 00:49:06 -0000 A new interim meeting request has just been submitted by Mark Nottingham. This request requires approval by the Area Director of the Transport Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2019-quic-03 --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Mark Nottingham City: Cupertino Country: US Session 1: Date: 2019-10-16 Start Time: 09:30 America/Los_Angeles Duration: 07:30 Remote Participation Information: See arrangements page; note that remote participation requires registration. Agenda Note: See: https://github.com/quicwg/wg-materials/blob/master/interim-19-10/arrangements.md Session 2: Date: 2019-10-17 Start Time: 09:30 America/Los_Angeles Duration: 07:30 Remote Participation Information: See arrangements page; note that remote participation requires registration. Agenda Note: See: https://github.com/quicwg/wg-materials/blob/master/interim-19-10/arrangements.md --------------------------------------------------------- From nobody Thu Aug 8 20:48: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 D1EDB120177 for ; Thu, 8 Aug 2019 20:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHzL68Ah9Udm for ; Thu, 8 Aug 2019 20:48:10 -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 4A4AB120172 for ; Thu, 8 Aug 2019 20:48:10 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id t28so90827059lje.9 for ; Thu, 08 Aug 2019 20:48:10 -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=BOFlxSzakNP/5vx6OMxATyYXxdKIpqwj59eu8C2uWLs=; b=puXVeU5osEfnN8hT1Fcu61wPLfacRJ6775A2MlwCB0Q+QQ+ANSv9Mv/5ankTprPy7o b4st/PdeenswW3+2xTY1CxFOzSWj0uKoykur457P1h0EAjbLUdMeGiNw5amCUZtKxtk6 xaDZOE2cIAOZ/g4bfx9L3N6yysihNU4ejWe+q4HRUW4Le93izc8yB7QVbsWexFmc80gU AK1EbEwRnvVRPncJnYD86bCxyQ4LZGp7B5dfg4lL4jGj//YzZgK0zp097HC7XG05wcbE cgTk7qYOYc2DkAQMa1H74tGX3o41yPM2LvRaNyrvYN99OAqLGTrr5mYJl+UvLZ79BWcV gZEw== 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=BOFlxSzakNP/5vx6OMxATyYXxdKIpqwj59eu8C2uWLs=; b=A6sV7h1PGVm1HG0A4s/42o9cADWfdCqxubl/0t8iS5iURFykWIChxUThLgdTbvhftU X6ySoTHH4g6EY5WllidqG1HP4ezVINF4bZj9uIOFB6iNkoY4NQ4OrVOHGAmP/RZ/CTGr R7mweSTr9eET2x7hRu/TAar+8dpy7MldFtZi4skJiBXTw2AV0T0jIMnFMnOvfBpOTAkI E+I0zuXHi27yasqmbsAj4VPD17dLyEJwV1PUGiasA2k2t8Du9uA4h9HjqHS6LkHPZ3K+ 32GUXrAywIj+TraqaTqq0c5mulzA3AelVyy3BpugtezvDidSdHY67BVRV04Y6MmrK10i p25A== X-Gm-Message-State: APjAAAWs+XWMs5rlMcov4DnMuqErGK7Z8hcKuo9oUSaCnMrmVptxu5Dk aCuLSRt6fKirYlTQL2L3N+P/UHQRp3Phj6M8VQPeuoqe X-Google-Smtp-Source: APXvYqx3kxxjbPS2ypfiGrcb7S9IuAV4ZJlLHM7A+sjH+JxVT1QDBMocNj0qZp3WoeM1WiXGUBMqMuN+dcQYQL3Y2rE= X-Received: by 2002:a2e:3013:: with SMTP id w19mr10167513ljw.73.1565322488522; Thu, 08 Aug 2019 20:48:08 -0700 (PDT) MIME-Version: 1.0 References: <608f1832-2ac3-4459-875e-bdc9a86ad8b8@www.fastmail.com> In-Reply-To: From: Kazuho Oku Date: Fri, 9 Aug 2019 12:47:56 +0900 Message-ID: Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME To: Mike Bishop Cc: Martin Thomson , "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 09 Aug 2019 03:48:24 -0000 2019=E5=B9=B48=E6=9C=889=E6=97=A5(=E9=87=91) 4:16 Mike Bishop : > > As Lucas said, if you have a separate parser by stream type and the frame= s defined for other streams simply aren't handled, that would violate the M= UST-error requirements we currently have. You would fail a compliance test= . I think I tend to agree with Martin that this is an unnecessary complexity, and that we should change the detection rule to SHOULD (and also merge the two error codes to one). While it is true that we have been trying to be strict in HTTP/3, I am not sure if we are happy with enforcing every endpoint to detect a misuse of a frame on a stream that it is never expected to appear (e.g. receiving SETTINGS frame on a request stream). Having such rules as a MUST does not improve interoperability. It's purely about adding burden to the implementors. As an example, I have about 50 lines of code that implements these rules. I'd be in favor of removing these lines. https://github.com/h2o/h2o/blob/dc12a571985e48b9725463f89888dd5a9d2571f4/li= b/http3/common.c#L556-L603 > > > > I see a couple separable questions that we need to answer to move forward= here: > > Should this even be possible? QUIC has established a pattern of making i= t impossible to send invalid values. An H3 incarnation of that pattern wou= ld be to split the frame type spaces so there=E2=80=99s no such thing as WR= ONG_STREAM, just unknown frame types. Should WRONG_STREAM be possible to e= xpress? > If so, is this error easily detectable? We=E2=80=99ve established a prin= ciple that easily detected protocol violations will be required to generate= an error. The current text reflects this principle, since known frame typ= es and their valid streams are easily detectable. > > If the pattern Martin suggests might be common, and therefore this error = isn=E2=80=99t =E2=80=9Ceasily detected,=E2=80=9D these would become SHOULD-= error instead. > > Only then, the original question, is there value in having separate error= codes? > > > > I find the separate frame type registries slightly attractive, but unless= we cross-reserve values (which defeats the point), we=E2=80=99d be breakin= g the last vestiges of HTTP/2 resemblance. It=E2=80=99s also a pretty fund= amental change for a protocol on the edge of late-stage process. I don=E2= =80=99t think I=E2=80=99d want to bite that off unless the working group as= a whole feels strongly that it=E2=80=99s an improvement, and I=E2=80=99m n= ot seeing that so far. > > > > I tend to think that misuse of known frame types is easily detectable and= therefore Martin=E2=80=99s hypothetical implementation is simply wrong. H= owever, the value in the distinction between the two seems minimal. I=E2= =80=99d vote for merging. > > > > -----Original Message----- > From: QUIC On Behalf Of Martin Thomson > Sent: Tuesday, August 6, 2019 8:29 PM > To: quic@ietf.org > Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME > > > > On Wed, Aug 7, 2019, at 10:03, Lucas Pardue wrote: > > > As part of the HTTP error analysis and feedback, in June I created > > > issue #2809 "Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME" > > > [1]. > > > > The notion of a signal for "I got a frame that I understood, but it was i= n the wrong place" is fine. Good even. But I don't see a need to have two= such signals. So I'm in favour of collapsing the two. I don't understand= the distinction between these signals as it stands anyway. > > > > However, I'm also concerned that this is going to get wrapped up in the u= sual compliance test mess. If I hook up different parsers on different str= eams and my request stream parser doesn't know about SETTINGS at all, so ig= nores it when it suddenly appears on a request stream, is the test case goi= ng to fail when I don't generate HTTP_FRAME_IN_THE_WRONG_PLACE? > > --=20 Kazuho Oku From nobody Fri Aug 9 09:18:51 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 A3ED1120090; Fri, 9 Aug 2019 09:18:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: quic@ietf.org Subject: QUIC (quic) WG Interim Meeting: 2019-10-16 X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156536752957.15724.16296651130079693519@ietfa.amsl.com> Date: Fri, 09 Aug 2019 09:18:49 -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: Fri, 09 Aug 2019 16:18:50 -0000 The QUIC (quic) Working Group will hold a multi-day interim meeting. Session 1: 2019-10-16 09:30 to 17:00 America/Los_Angeles Session 2: 2019-10-17 09:30 to 17:00 America/Los_Angeles Meeting Location: Cupertino, US Agenda: Discussion of QUIC issues. Information about remote participation: See arrangements page; note that remote participation requires registration. See: https://github.com/quicwg/wg-materials/blob/master/interim-19-10/arrangements.md From nobody Sat Aug 10 20:15: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 DF03812089B for ; Sat, 10 Aug 2019 20:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=huA6XY6H; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eFFih3zr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvehYooVS69a for ; Sat, 10 Aug 2019 20:14:06 -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 3F61712091B for ; Sat, 10 Aug 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 53A4520E94 for ; Sat, 10 Aug 2019 20:45:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 10 Aug 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= fm3; bh=XiGoDsT0N2PTaE9Ql1HdVUVg3b5GKHS3RrJYvxwb9Uk=; b=huA6XY6H 1605wmOgTBDizo1JYVr3tTic+6qFLJ495xNW+TNZ0WvLklYqmFQhMxmtul56Ws9F +N/cQd4d1cgKnRO5+b7p6ZbqiTbSI+cKsv/NRxaF1koR7wXgl9kA6TxyYC6LyxWS yQJy9883q/7jmDlq9PygyJQKXyLfkemSItCjGqb7uRWRxdU8tLNPREPw7Rly+jR1 u+LF/yY3SLplK44SFUW6nYsLRGkpFeSsqBMuGVv+VUY9dnUqS5sStx3NiCu9LuGQ 322Yj3hkHUrR+P5MoCKoDSHTpToCt5ycfN63OxfA4pTZkJOK7oRZ5oz5VzyBzihx xCTnLP/4R1vCwQ== 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=fm3; bh=XiGoDsT0N2PTaE9Ql1HdVUVg3b5GK HS3RrJYvxwb9Uk=; b=eFFih3zrkeqWMDEmdODTJud2x9qSa52cQ6nz2bgOQV60y 7ZoEt4I76qZYukCAWS7vtE1VSMv3nHe08kRSN8M0jK1vOXo1ojHjRoVNBvgCGTBh 0dlP5PXn0i3Xt1wxhigHoL5GiqEjuTkaETtrthf+qTzlfzTYaFVladpKDcY6CraS CcfMCBehlKiBMif9AUBAJKR6ZrwhVSx1zD9gpa9EoTz+l2NEGAunneBEar1ed8Sr p1os3REJbHn2fooD1HOMPZltNVx/h5r4Ijk0dOD2kCmkZwPNf8+3220rztC34QA6 LOhvTs7s8XSw5u7/1C04PmS4SAWUXhBImvKpfT8dA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddvtddgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusggppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeduudelrdelrdegfedrvdegudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 9EAAA8005B for ; Sat, 10 Aug 2019 20:45:19 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 9CD7BC03E5 for ; Sun, 11 Aug 2019 00:45:16 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============2507547642187039200==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190811004516.9CD7BC03E5@cloud.mnot.net> Date: Sun, 11 Aug 2019 00:45:16 +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, 11 Aug 2019 03:15:03 -0000 --===============2507547642187039200== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+6/-6/=F0=9F=92=AC44) 6 issues created: - What if server does not send HTTP_EARLY_RESPONSE but starts sending res= ponse (by ddragana) https://github.com/quicwg/base-drafts/issues/2963 = - Can CRYPTO frames be sent in 0-RTT packets? (by tandf) https://github.com/quicwg/base-drafts/issues/2959 = - Are ECN counts per pn_space or unified across pn_spaces? (by YuanshanZ) https://github.com/quicwg/base-drafts/issues/2957 = - RECOMMENDED on non-interop requirement (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2956 = - It seems the minimal packet number length should be 14 bits (by NKTelne= t) https://github.com/quicwg/base-drafts/issues/2955 = - Consider merging WebSocket into HTTP/3 (by theoryfate) https://github.com/quicwg/base-drafts/issues/2953 = 7 issues received 44 new comments: - #2945 When to send the SETTINGS frame (20 by kazuho, janaiyengar, nharp= er, DavidSchinazi, martinthomson, davidben, ianswett, dtikhonov, LPardue) https://github.com/quicwg/base-drafts/issues/2945 [-http] [design] = - #2955 It seems the minimal packet number length should be 14 bits (11 b= y kazuho, marten-seemann, mikkelfj, NKTelnet, martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/2955 [-transport] = - #2953 Consider merging WebSocket into HTTP/3 (4 by DavidSchinazi, theor= yfate, ianswett, MikeBishop) https://github.com/quicwg/base-drafts/issues/2953 [-http] = - #2151 Where can you send CONNECTION_CLOSE (3 by martinthomson, mnot) https://github.com/quicwg/base-drafts/issues/2151 [-transport] [design]= [proposal-ready] = - #2541 Clients cannot abandon Initial packets while server can still sen= d initial close (3 by erickinnear, DavidSchinazi, mnot) https://github.com/quicwg/base-drafts/issues/2541 [-transport] [design] = - #2837 Does a Retry really need to change the CID? (2 by martinthomson, = MikeBishop) https://github.com/quicwg/base-drafts/issues/2837 [-transport] [editori= al] = - #2132 Provide guidelines on token validation (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2132 [-transport] [editori= al] = 6 issues closed: - Can CRYPTO frames be sent in 0-RTT packets? https://github.com/quicwg/b= ase-drafts/issues/2959 [-transport] [editorial] = - Application should be allowed to respond to STOP_SENDING instead of the= endpoint https://github.com/quicwg/base-drafts/issues/2884 [-transport] [e= ditorial] = - HTTP/2 in Peer Denial of Service? https://github.com/quicwg/base-drafts= /issues/2890 [-tls] [-transport] [editorial] = - It seems the minimal packet number length should be 14 bits https://git= hub.com/quicwg/base-drafts/issues/2955 [-transport] = - Appendix A of quic-tls is wrong https://github.com/quicwg/base-drafts/i= ssues/2885 [-tls] [editorial] = - Consider merging WebSocket into HTTP/3 https://github.com/quicwg/base-d= rafts/issues/2953 [-http] = Pull requests ------------- * quicwg/base-drafts (+6/-6/=F0=9F=92=AC14) 6 pull requests submitted: - ECN counts in the ACK frame should be in the same pn_space of the ACK f= rame (by YuanshanZ) https://github.com/quicwg/base-drafts/pull/2964 = - Talk more about multiple tokens (by martinthomson) https://github.com/quicwg/base-drafts/pull/2962 [-transport] [editorial= ] = - Repair rules for NEW_TOKEN (by martinthomson) https://github.com/quicwg/base-drafts/pull/2961 [-transport] [editorial= ] = - CRYPTO frames can not be sent in 0-RTT (by tandf) https://github.com/quicwg/base-drafts/pull/2960 = - Move server's SETTINGS to transport parameters (by nharper) https://github.com/quicwg/base-drafts/pull/2958 = - Clarify out of order acking (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2954 [-recovery] [editorial] = 8 pull requests received 14 new comments: - #2954 Clarify out of order acking (3 by rpaulo, janaiyengar) https://github.com/quicwg/base-drafts/pull/2954 [-recovery] [editorial] = - #2893 Remove DoS vector for spoofed connection migration (3 by erickinn= ear, pravb) https://github.com/quicwg/base-drafts/pull/2893 [-transport] = - #2752 ECN verification text (2 by martinthomson, janaiyengar) https://github.com/quicwg/base-drafts/pull/2752 [-transport] = - #2961 Repair rules for NEW_TOKEN (2 by martinthomson, marten-seemann) https://github.com/quicwg/base-drafts/pull/2961 [-transport] [editorial= ] = - #2853 transport: fix dangling ref to recovery (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2853 = - #2960 CRYPTO frames can not be sent in 0-RTT (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2960 [-tls] [editorial] = - #2898 HTTP Upgrade in H3 is silliness (1 by LPardue) https://github.com/quicwg/base-drafts/pull/2898 [-http] = - #2935 QPACK [editorial] update RIC and Base on figures (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2935 [-qpack] = 6 pull requests merged: - Clarify out of order acking https://github.com/quicwg/base-drafts/pull/2954 [-recovery] [editorial] = - CRYPTO frames can not be sent in 0-RTT https://github.com/quicwg/base-drafts/pull/2960 [-tls] [editorial] = - Firm up language around stream termination https://github.com/quicwg/base-drafts/pull/2888 [-transport] [editorial= ] = - Move wasteful packet stuff to -transport https://github.com/quicwg/base-drafts/pull/2896 [-tls] [-transport] [ed= itorial] = - Get test vectors in place for -23 https://github.com/quicwg/base-drafts/pull/2887 [-tls] [design] = - Make Recovery Pseudocode Formatting Consistent https://github.com/quicwg/base-drafts/pull/2946 [-recovery] [editorial] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============2507547642187039200== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday August 11, 2019

Issues

quicwg/base-drafts (+6/-6/=F0=9F=92=AC44)

6 issues created:

7 issues received 44 new comments:

6 issues closed:

Pull requests

quicwg/base-drafts (+6/-6/=F0=9F=92=AC14)

6 pull requests submitted:

8 pull requests received 14 new comments:

6 pull requests merged:

Repositories tracked by this digest:

--===============2507547642187039200==-- From nobody Mon Aug 12 16:35: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 C445F120019 for ; Mon, 12 Aug 2019 16:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxOzSw4J-JnY for ; Mon, 12 Aug 2019 16:35:52 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F8112000E for ; Mon, 12 Aug 2019 16:35:51 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id 10so1120588wmp.3 for ; Mon, 12 Aug 2019 16:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EmV1f105TYtOTUSPNb7mj2g9+MkEIpb6NyFCmaZJpQk=; b=blw2gzR07Qc5eM7hjXOQE0sC47r+5ct/EC+fNRaY3EeqpwRAZDw7cTa61EcSBdIJH1 95I1MS/R3klUWz9EkEk1gPX72kY7dEsIDmv4pWhCRudTSQeNra4gZOwPH5tuSfW1Pr5P MdiiH5Nz4eF2T5a5bx3uQN6aNFKBUzJNKrp5WMDgODL5C16jxKoXY5g/wDasnuKOqdaD u/y5fclOaAsAzP4ZlnqE7rtTXf3JRe3AeyPAGj09nQ/aaZZX46lZfbD6r9go0XuT2C+H YI+HWuzPkBqP4JT6MTAPKNFuxvYnNyZlIOmOoBSr7fCVT5uqaFLvGnbcR7J0yNTLzTFG vD+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EmV1f105TYtOTUSPNb7mj2g9+MkEIpb6NyFCmaZJpQk=; b=D1kcfmZpmBEHu5JM5q5+x3KmxA3jsyiPZdIEG/vMwCUdX75nNBkn5lCOSPPuNAM/fG NlKgBMSK5o2/LbVDzR3zLEgjMI9k0ER/vX/ObUiKs8jsLkJS+rGxtvaU+ReE5RB6d4Pb mk63v/HbqAnrtjZIijm2ciCn5ziYd/Mpnzd7DiH90/cqRAIaw/TwUGVNo/97OuauZooE 1G0vY/gYDchHT3QV+oZhzdWr9ebjOUmuv5gAALOk4rrexK9N8+m4FXxOWDFS4gdIaH1I E2kCgxlaYZAWcaWZVMPVSi6/m3VlTw/Y5SpGBtd7Ipx+Pzidb5d16YCnYri/PhBBuHYO x++Q== X-Gm-Message-State: APjAAAV1GvTmlKIATW1A0THqyuq8PAKo17Bg1YBaFtdgNjANPjB2Prxb 2ttmJYQhuHZ5n8dURiEHJ0jj4tYpEz7O9LqrsdDZ/JZt X-Google-Smtp-Source: APXvYqxjUvV5narteTXhPu2NsG4iLU3BgtSMf9eBMQLweiO73tmVgCZSnIe55hSvug9WHlxS/YEPM3PhTdurzOhFLJU= X-Received: by 2002:a1c:1d42:: with SMTP id d63mr1299362wmd.34.1565652949754; Mon, 12 Aug 2019 16:35:49 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Mon, 12 Aug 2019 16:35:38 -0700 Message-ID: Subject: HTTP3 Pseudoheaders To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e968c9058ff3fb2f" 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, 12 Aug 2019 23:35:54 -0000 --000000000000e968c9058ff3fb2f Content-Type: text/plain; charset="UTF-8" I'm carefully parsing the wording in sec. 4.1.1 and want to make sure I have this right: " Endpoints MUST NOT generate pseudo-header fields other than those defined in [HTTP2 ]. The restrictions on the use of pseudo-header fields in Section 8.1.2.1 of [HTTP2 ] also apply to HTTP/3. " In RFC 7540, 8.1.2.1 says Endpoints MUST NOT generate pseudo-header fields other than those defined in this document... Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests. Pseudo-header fields MUST NOT appear in trailers. Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed (Section 8.1.2.6 ). All pseudo-header fields MUST appear in the header block before regular header fields. Any request or response that contains a pseudo-header field that appears in a header block after a regular header field MUST be treated as malformed (Section 8.1.2.6 ). This notably does NOT include the further restrictions in 8.1.2.3: All HTTP/2 requests MUST include exactly one valid value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT request (Section 8.3 ). An HTTP request that omits mandatory pseudo-header fields is malformed (Section 8.1.2.6 ). To clarify, this last restriction on exactly one of these pseudoheaders is NOT relevant to HTTP/3? i.e. Clients are free to omit :method, :scheme, and :path from their requests? --000000000000e968c9058ff3fb2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm carefully parsing the wording in sec. 4.1.1 a= nd want to make sure I have this right:

" 
Endpoin=
ts MUST NOT
   generate pseudo-header fields other than those defined in [HTTP2].
   The restrictions on the use of pseudo-header fields in
   Section 8.1.2.1 of [HTTP2] also apply to HTTP/3.
"

In RFC 7540, 8.1.2.1 says 
Endpoin=
ts MUST NOT
   generate pseudo-header fields other than those defined in this
   document...

Pseudo-header fields defined for requests MUST NOT appear
   in responses; pseudo-header fields defined for responses MUST NOT
   appear in requests.  Pseudo-header fields MUST NOT appear in
   trailers.  Endpoints MUST treat a request or response that contains
   undefined or invalid pseudo-header fields as malformed
   (Section 8.1.2.6).

   All pseudo-header fields MUST appear in the header block before
   regular header fields.  Any request or response that contains a
   pseudo-header field that appears in a header block after a regular
   header field MUST be treated as malformed (Section 8.1.2.6).

This notably does NOT include the further restrictions in 8.1.2.3:

All HTTP/2 requests MUST include exac=
tly one valid value for the
   ":method", ":scheme", and ":path" pseudo-h=
eader fields, unless it is
   a CONNECT request (Section 8.3).  An HTTP request that omits
   mandatory pseudo-header fields is malformed (Section 8.1.2.6).

To clarify, this last restriction on exactly one of these p=
seudoheaders is NOT relevant to HTTP/3? i.e. Clients are free to omit :meth=
od, :scheme, and :path from their requests?
--000000000000e968c9058ff3fb2f-- From nobody Mon Aug 12 16:39: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 CD36A120019 for ; Mon, 12 Aug 2019 16:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RGxg-dUvgR6 for ; Mon, 12 Aug 2019 16:39:44 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC6D12000E for ; Mon, 12 Aug 2019 16:39:44 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id z1so106071711wru.13 for ; Mon, 12 Aug 2019 16:39: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; bh=+m85HLmUKsH8kDz6ostFE/QMcyhwhLV+KoQRkcPNjKE=; b=pvvtVIrOkpIedmcHysjrlsofNQ4jpCHTOxYnSKEGsFSF3EX1v0JfXEQZr1VVIM9Ywm ZY2+yS+yD6+Twzg75XiRO//0vey5ervLMddrEbNasaoi8AP7gprnNGhQSsjS5o8RfcCf n67OTaNJsU/AAYV50vgLktDcQgka9FP5zU2TaTn/Bubp5ugltERhOY54e2aKQ5NfyRaE 0iCuZMgtsNj2y0XJKn1y5ZwyOAm45prp166bSzDatRdi7RdWExWm8RUegHGwyfqL819N UjMDtdd3C0GB4b03leTOkJqHjNW5kUvWHPcCrcKyeEAvsxZWj1oMOabsLonk4fsF7qI1 RWVw== 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=+m85HLmUKsH8kDz6ostFE/QMcyhwhLV+KoQRkcPNjKE=; b=ksiIqYf7oQLejRcpqE1Lj3erdkdUY5MAhSujau1gSsjEyY0aF/f4xRO3byqWKjHfyO K0xfifpUKSr5EIb543zZ3qk+G6j/zE2y9rQ8bmUuMzLSx3rJJlr0h7Q1NCGGZx2PY6GQ Pgwc6JQMAG/baDT7gXw8atH6Wb059Z3AkXw67m7OO0jPR0ESIlv/EW3agmfkUpoFUqqW 0Uhw/uBam3psvuj3ll2JrHZhYejxvpPwGJPCZohx1bueZ7SaPqWvCLUnKlnLZ4T9u9wQ h2zUnC4dNaBubDG0Yh4Q0g9F4NJ1xAFj9XVDB3JrMckOjwNeYgLzUSrv+P1FvErPqR1H vICQ== X-Gm-Message-State: APjAAAV0YdhdmPjhil74074duj66XPGKy/L9M+WDGxSI2LPcqfZChsi5 lBdfwfFECxhoZ7OHcPRszNG22b0AFpzxaxYaFs5dHA== X-Google-Smtp-Source: APXvYqyDYi5hb4WxfRddqV3357skLflTarF5wzSdCDKKw60NDL/8Xk89mkCfYZsZtPvnOcc8s4eARFvjW2sbY0r3/k4= X-Received: by 2002:a5d:4b8b:: with SMTP id b11mr44232308wrt.294.1565653182223; Mon, 12 Aug 2019 16:39:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Mon, 12 Aug 2019 16:39:30 -0700 Message-ID: Subject: Re: HTTP3 Pseudoheaders To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c49c53058ff4094f" 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, 12 Aug 2019 23:39:47 -0000 --000000000000c49c53058ff4094f Content-Type: text/plain; charset="UTF-8" Obviously it would be weird to omit a :method or have more than one, so perhaps this is an oversight? On Mon, Aug 12, 2019 at 4:35 PM Martin Duke wrote: > I'm carefully parsing the wording in sec. 4.1.1 and want to make sure I > have this right: > > " > > Endpoints MUST NOT > generate pseudo-header fields other than those defined in [HTTP2 ]. > The restrictions on the use of pseudo-header fields in > Section 8.1.2.1 of [HTTP2 ] also apply to HTTP/3. > > " > > In RFC 7540, 8.1.2.1 says > > Endpoints MUST NOT > generate pseudo-header fields other than those defined in this > document... > > Pseudo-header fields defined for requests MUST NOT appear > in responses; pseudo-header fields defined for responses MUST NOT > appear in requests. Pseudo-header fields MUST NOT appear in > trailers. Endpoints MUST treat a request or response that contains > undefined or invalid pseudo-header fields as malformed > (Section 8.1.2.6 ). > > All pseudo-header fields MUST appear in the header block before > regular header fields. Any request or response that contains a > pseudo-header field that appears in a header block after a regular > header field MUST be treated as malformed (Section 8.1.2.6 ). > > This notably does NOT include the further restrictions in 8.1.2.3: > All HTTP/2 requests MUST include exactly one valid value for the > ":method", ":scheme", and ":path" pseudo-header fields, unless it is > a CONNECT request (Section 8.3 ). An HTTP request that omits > mandatory pseudo-header fields is malformed (Section 8.1.2.6 ). > > To clarify, this last restriction on exactly one of these pseudoheaders is NOT relevant to HTTP/3? i.e. Clients are free to omit :method, :scheme, and :path from their requests? > > --000000000000c49c53058ff4094f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Obviously it would be weird to omit a :method or have more= than one, so perhaps this is an oversight?

On Mon, Aug 12, 2019 at 4:35= PM Martin Duke <martin.h.duk= e@gmail.com> wrote:
I'm carefully parsing the wording in s= ec. 4.1.1 and want to make sure I have this right:

" 
Endpoints MUST NOT
   generate pseudo-header fields other than those defined in [HT=
TP2].
   The restrictions on the use of pseudo-header fields in
   Section 8.1.2.1 of [HTTP2] also apply to HTTP/3.
"

In RFC 7540, 8.1.2.1 says 
Endpoints MUST NOT
   generate pseudo-header fields other than those defined in this
   document...

Pseudo-header fields defined for requests MUST NOT appear
   in responses; pseudo-header fields defined for responses MUST NOT
   appear in requests.  Pseudo-header fields MUST NOT appear in
   trailers.  Endpoints MUST treat a request or response that contains
   undefined or invalid pseudo-header fields as malformed
   (Section 8.1.2.6).

   All pseudo-header fields MUST appear in the header block before
   regular header fields.  Any request or response that contains a
   pseudo-header field that appears in a header block after a regular
   header field MUST be treated as malformed (Section 8.1.2.=
6).

This notably does NOT=
 include the further restrictions in 8.1.2.3:

All HTTP/2 requests MUST include exac=
tly one valid value for the
   ":method", ":scheme", and ":path" pseudo-h=
eader fields, unless it is
   a CONNECT request (Section 8.3).  An HTTP request that om=
its
   mandatory pseudo-header fields is malformed (Section 8.1.=
2.6).

To clar=
ify, this last restriction on exactly one of these pseudoheaders is NOT rel=
evant to HTTP/3? i.e. Clients are free to omit :method, :scheme, and :path =
from their requests?
--000000000000c49c53058ff4094f-- From nobody Mon Aug 12 20:22: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 72F5D12006A for ; Mon, 12 Aug 2019 20:22:20 -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 SKPUk1WLgjgQ for ; Mon, 12 Aug 2019 20:22:18 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 58B6D12004A for ; Mon, 12 Aug 2019 20:22:17 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x7D3MEMv003893; Tue, 13 Aug 2019 05:22:14 +0200 Date: Tue, 13 Aug 2019 05:22:14 +0200 From: Willy Tarreau To: Martin Duke Cc: IETF QUIC WG Subject: Re: HTTP3 Pseudoheaders Message-ID: <20190813032214.GA3880@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 13 Aug 2019 03:22:20 -0000 On Mon, Aug 12, 2019 at 04:39:30PM -0700, Martin Duke wrote: > Obviously it would be weird to omit a :method or have more than one, so > perhaps this is an oversight? Maybe the text should instead say : Pseudo-header generation strictly follow the rules that apply to H2 (see RFC7540 sections X,Y,Z,...). And probably it would be worth mentioning extensions, like RFC8441 which adds ":protocol". Willy From nobody Tue Aug 13 01:06: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 E61DA120074 for ; Tue, 13 Aug 2019 01:06:29 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp_GtEfU5OuX for ; Tue, 13 Aug 2019 01:06:28 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::706]) (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 C7D861200B3 for ; Tue, 13 Aug 2019 01:06:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W0nvVuaGZqWN2ADsTLrKe3jZIizCY935QsvQtQWHxuY3Uja5Xx5O0VJvQ2+snHV1K3nCJVUh+Olu5Hwj0p54ObVeg+TM6GNSjvpr+QcfwM0nTjXGEh1xwvuO6NE8zf+hZBwG48QEFm3IIJIRbnraIMM+0ho9tG4iyhjtMYopxcE8jYqqgXtELPHEuswJjckyataNYgSiEQ/xM1p7Vk1P0zhgP9k0v6/ERLWun1+HGq0zLjqGZ9lc15D6vh0UFJsVTPUoTQGkrirfTgZCtVXbjrLSNn/K5wEu0Pvv2R20netOT7f+JD/BYEqahPPezQ6fWaGMg/2FG4nPcvljobpHIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LARsaZwwGOpP6HzHfRrPUdQ7kIE5QXSzO4u77RtEgHs=; b=GqK2aTf6YcGQkvJlTK1VQ36ymIrfyW9csRqKDGelr85TGxkAa+OGqHHAw+uZ4ZyrbYB57yqRzFfE6uqi4DJQT7EteFOlkr2/T4CT1zN5IqTD5hzWTpAXnE5AcosJY3MxZLwwcE9ZxC1h5Z2a6ojykHFNcIVPLwLhQFA4A+zzMaP3ifi59wLyE4Jumxk+Satf8N/OowtazbI1ZrxJs4+bWrgACCtMOdJ4PIxs3pq+YTf/xWuNkDUVOlDwgrhog8WpXYqnhuNn9UXqMc0H1bVC7Ag3gUi68rpPdIDXb4QH41GQjYs7uZ0QX3WCod8LBfc0jJ5yd5daNGEoz5neZW5DEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LARsaZwwGOpP6HzHfRrPUdQ7kIE5QXSzO4u77RtEgHs=; b=eEZ65bPph0I2wWQQyTgZ0WfiDHbXzAXvOdj9tZdPa4MQECMjpCUFlEchVqs6eEYK381xkR9UuhN1otgYPxK71tDMo9J2zNRCnVXWz2PaXcIqI2BC4YM0LV8VPkFhcSYF5BiTqXi0y4IiwGcgmXMkFKz8gaE4Ml10TSrST3r7Xc0= Received: from HE1PR07MB3306.eurprd07.prod.outlook.com (10.170.246.141) by HE1PR07MB3163.eurprd07.prod.outlook.com (10.170.245.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.11; Tue, 13 Aug 2019 08:06:24 +0000 Received: from HE1PR07MB3306.eurprd07.prod.outlook.com ([fe80::b9bd:a8f4:eb2a:83fd]) by HE1PR07MB3306.eurprd07.prod.outlook.com ([fe80::b9bd:a8f4:eb2a:83fd%3]) with mapi id 15.20.2157.022; Tue, 13 Aug 2019 08:06:24 +0000 From: "Flinck, Hannu (Nokia - FI/Espoo)" To: IETF QUIC WG Subject: Quic wg milestones update? Thread-Topic: Quic wg milestones update? Thread-Index: AdVRrTwb2ZMKPz0xQq+sPbBsdw7zrQ== Date: Tue, 13 Aug 2019 08:06:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hannu.flinck@nokia-bell-labs.com; x-originating-ip: [131.228.2.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b0993f95-cd73-4282-86a1-08d71fc522b7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:HE1PR07MB3163; x-ms-traffictypediagnostic: HE1PR07MB3163: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(136003)(346002)(376002)(39860400002)(396003)(189003)(199004)(66066001)(486006)(71190400001)(2906002)(5660300002)(6116002)(74316002)(14454004)(55016002)(9686003)(33656002)(71200400001)(30864003)(3846002)(476003)(3480700005)(6436002)(305945005)(7736002)(6306002)(66946007)(64756008)(53936002)(66556008)(8936002)(7110500001)(256004)(8676002)(76116006)(81156014)(966005)(186003)(66476007)(81166006)(6916009)(66446008)(25786009)(478600001)(6506007)(86362001)(99286004)(7696005)(2420400007)(316002)(102836004)(52536014)(26005)(15650500001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB3163; H:HE1PR07MB3306.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6IzPWkogRAXfuI26XaXvBNxZUhpbpOMZZ4/xrHzOJF14KjKrS9zQg9qPo9DeDkrVw32DZ057zxMWstX3V7JauEmK6YkxuZnvQI+oxfeRt6cVtkxxaqFL+WF/y35XAw3qZxj2Ys29HqzSCMPg9P8mR43pqEqPvcLgTczA+v3F0OAN1bWJ2KOQOMN2VAW6whvv7bygDyPTbz0LhtSxCJHT4O92bGy17ETofh7P8wJMHaOzRwD2D8Kb5dRZC39oBNgmiApq5j7aw2ZTmvNfcG81Vy2WNz7lxE4us+FrZ19jcoBf0qnf9Kwfo/1UW6r4ewHbYx7bHqC74A7VojZZ/fVYJlwuoj1iTcuH/Vj/7y+/x++86Kpeo7/0uGojEuFR2XdyJiVn22vaUdhkjRnkytFxgxt+hqDViiaNpv6WQdbToAU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB33063D26A8ED45CBB34D857A9BD20HE1PR07MB3306eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0993f95-cd73-4282-86a1-08d71fc522b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 08:06:24.6156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3yQybHImv0TYPgfqPRdNwvWqBmnH1F1w1rj+UUaryhGpFoSFOfRw1IJYjYTu6sm2F8qf6YQY2Q1ELl/V66QdtwcQnwYxXDGFBBpGBUqXsAi/M7tRoxkqq1oUc3l/atjB X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3163 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, 13 Aug 2019 08:06:30 -0000 --_000_HE1PR07MB33063D26A8ED45CBB34D857A9BD20HE1PR07MB3306eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WG page of QUIC states that in Jul 2019 the all of the eight WG documen= ts should have been sent to IESG. What are the latest estimates for milestone dates to complete the first rou= nd of these base documents and to send them to IESG? Probably the WG milestone table should be updated as well to reflect the la= test views. Best regards Hannu --_000_HE1PR07MB33063D26A8ED45CBB34D857A9BD20HE1PR07MB3306eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The WG page of QUIC states that in Jul 2019 the all of the eight WG do= cuments should have been sent to IESG. 
What are the latest estimates for milestone dates to complete the firs= t round of these base documents and to send them to IESG?
 
Probably the WG milestone table should be updated as well to reflect t= he latest views.
 
 
Best regards
Hannu
 
 --_000_HE1PR07MB33063D26A8ED45CBB34D857A9BD20HE1PR07MB3306eurp_-- From nobody Tue Aug 13 08:42: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 A6A271200FA for ; Tue, 13 Aug 2019 08:42:23 -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=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 Z6AMgO1-3xJ5 for ; Tue, 13 Aug 2019 08:42:21 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70042.outbound.protection.outlook.com [40.107.7.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 CF6E112020A for ; Tue, 13 Aug 2019 08:42:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gk4jBVomZSYAM/hAqXtaWBxa+mf2GFSa+2kqvj9rzyzqO27OUcCHHNKPXGcAWGAwuL+PzKVaQTjrdC05fmAsFlOd+8XrUy8BjXHr4JBxdQ33OHfTJIZ2L5402+AGvL6Ri4aAG2OpvQgyeDFbfZwEvnZC5IwKOsgFW/sBPw2njeC6qqSTFM1kXXQTLdZq71f2T6ENcntwTon8Z9N2nTlkeIlK4CcLUZ61z66c9h3c0syjQi7Xhj4voE9h0W1L+FYhlMq+Op1okoYdnnte6mwp0AuMYgo2fddPu85+cYLVsjyNOFSokJ2rj9L3wQy5z6YpzUuyGQlPwD6nXndd7Z71mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MPSab4Rwmnh1tScll136o9A9VUfOT8Oq7GZhNK46p5Y=; b=Edfj3tlzE+IAcFknrjPUjhMd0W35pCwl/jKViv+GpvW3KKO0th0uDvBeIYHu9YgMQGYkTMVl5o4ttPT47AxUuTqEhsL135LR0htfginKB2KM5FB8HWcQBZtGp7jlcTH430/8WfCZ7CIGK6vATcj4ajObyq0W0jKLT7/1IvoS8UtQccXsWhN19PXZf/L++9b8x6jO46Iw1SAUIbd0kTO9oyoQoTF/83M6UYE2ubaMutyYNCJANcUEcNRCiIWh+kjWED0vmOs/xFFZ1Ya99Pld0ElI9tdZy28qXWOlO9ZOTYyTRBwb9qAMveDBOiuTCy3rl88h10Kgrt5MByTwgx1TwQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MPSab4Rwmnh1tScll136o9A9VUfOT8Oq7GZhNK46p5Y=; b=D7XZjee0jm5ilHNkO1UkYq6XfyqpMN1Px3d3seraogfXCor8pTMadS766mLonjn4dspEiuH4zTWlQ/d2zBfboO9mseUItAvHnHkRi9i0yPjuFoCLDm0H+U843Q7vmTVQXw7ZWi2nvjjXaFW5v/Qhb8TH3aKz8y5xH1AuUCZi0DQ= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB5842.eurprd07.prod.outlook.com (20.178.113.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.8; Tue, 13 Aug 2019 15:42:18 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::6175:df24:70a1:a72b]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::6175:df24:70a1:a72b%3]) with mapi id 15.20.2178.013; Tue, 13 Aug 2019 15:42:18 +0000 From: Mirja Kuehlewind To: "quic@ietf.org" Subject: Blocking Quic traffic Thread-Topic: Blocking Quic traffic Thread-Index: AQHVUe2wfsrAib4GYkCEHYQQKVuPIQ== Date: Tue, 13 Aug 2019 15:42:18 +0000 Message-ID: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [129.192.10.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e96940c1-4347-4fd7-20a9-08d72004d293 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR07MB5842; x-ms-traffictypediagnostic: AM0PR07MB5842: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(346002)(39860400002)(366004)(189003)(199004)(53754006)(71200400001)(305945005)(6306002)(6512007)(66946007)(66556008)(66476007)(66446008)(7736002)(66574012)(8936002)(3846002)(3480700005)(64756008)(2906002)(6486002)(25786009)(81156014)(966005)(76116006)(486006)(478600001)(14454004)(71190400001)(256004)(14444005)(8676002)(1730700003)(6916009)(81166006)(476003)(5660300002)(44832011)(2616005)(2351001)(102836004)(6506007)(86362001)(26005)(66066001)(33656002)(2501003)(6436002)(36756003)(5640700003)(6116002)(7116003)(53936002)(316002)(186003)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5842; H:AM0PR07MB4691.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: R6+tM6WYLd5y113zEmFPEFcV7SCHiPkdCidOazh6u4MLXwTyE8HMXOFHCU/hFsokMQM/au4e8YORqbBupixUNJl9vbxoFaWyFMHnfXBO+DFM9UGSSEDnPFHFDH4Bf/qZcmk8/JWxakI1wyXvqGUEoYuiVExJJP9jIYZQjearbKT1mLUk+rKy4NuZ7GOzQEYS5LoohBncN7Doqf0VGO5oA4+zcLJ1yVwz2hQw/h5pmRkP4CLZXD90swwF57XKx1HSdGR3Qxulgp2VKnL8w3Yd+kDXUx0WBwhCG+pyZrhsbTYIH0kqRhdNLm28ZgjhAwmnKYBiY6nZJm1m6A1+KGlKqNA5+FZvxsA5syfoCtH6CZOqC1AOrOeb0CyQqxqHaLa1+3mK40W5fddExzkixpunwUB5wqnwhz9tjEpLJpP2nGc= x-ms-exchange-transport-forked: True 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: e96940c1-4347-4fd7-20a9-08d72004d293 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 15:42:18.0670 (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-CrossTenant-userprincipalname: ZE9S883o4xoHdqWL6V1vZTe8kHcXbHexnc2I8zN4TpueTrSj5MqqDeDoH1SnGX5jvkU9RqUJn3cioZo/My+SgrXOK/TNhhpBPtfL1cZm6t0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5842 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, 13 Aug 2019 15:42:24 -0000 SGkgYWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gcG9pbnQgdGhlIGdyb3VwIHRvIHRoZSBmb2xsb3dp bmcgYmxvZyBwb3N0Og0KDQpodHRwczovL3d3dy5mYXN0dnVlLmNvL2Zhc3R2dWUvYmxvZy9nb29n bGVzLXF1aWMtcHJvdG9jb2xzLXNlY3VyaXR5LWFuZC1yZXBvcnRpbmctaW1wbGljYXRpb25zLyMN Cg0KQW5kIHNwZWNpYWxseSB0aGUgZm9sbG93aW5nIHBhcnQgb2YgaXQ6DQoNCiJSZXNvbHZpbmcg dGhlIFFVSUMgaXNzdWUNCg0KVGhlIGdvb2QgbmV3cyBpcyB0aGF0IGlmIFFVSUMgY29tbXVuaWNh dGlvbiBkb2VzIG5vdCB3b3JrIGJldHdlZW4gYSBjbGllbnQgYW5kIGEgc2VydmVyLCB0aGUgdHJh ZmZpYyB3aWxsIGZhbGwgYmFjayB0byB0cmFkaXRpb25hbCBIVFRQL0hUVFBTIG92ZXIgVENQLCB3 aGVyZSBpdCBjYW4gYmUgaW5zcGVjdGVkLCBjb250cm9sbGVkLCBsb2dnZWQgYW5kIHJlcG9ydGVk IG9uIGFzIHVzdWFsLg0KDQpBdCB0aGUgdGltZSBvZiB3cml0aW5nLCB0aGUgYWR2aWNlIGZyb20g bW9zdCBmaXJld2FsbCB2ZW5kb3JzIGlzIHRvIGJsb2NrIFFVSUMgdW50aWwgc3VwcG9ydCBpcyBv ZmZpY2lhbGx5IGFkZGVkIHRvIHRoZWlyIHByb2R1Y3RzLiBUaGlzIHJlY29tbWVuZGVkIG1ldGhv ZCB3aWxsIHZhcnkgZnJvbSBmaXJld2FsbCB0byBmaXJld2FsbC4gIFNvbWUgZmlyZXdhbGxzIGFs bG93IFFVSUMgYnkgZGVmYXVsdCB3aGlsZSBvdGhlcnMgYmxvY2sgaXQgYnkgZGVmYXVsdCwgYnV0 IGFsbCBmaXJld2FsbHMgYXJlIGFibGUgdG8gYWxsb3cgb3IgYmxvY2sgaXQuDQoNCkNvbW1vbiBt ZXRob2RzIGFyZSB0byBibG9jayBlaXRoZXIgYSBkZWZpbmVkIFFVSUMgcHJvdG9jb2wsIFFVSUMg YXBwbGljYXRpb24gdHlwZSwgb3IgY3JlYXRlIGEgZmlyZXdhbGwgcnVsZSB0byBibG9jayBVRFAg b24gcG9ydCA4MCBhbmQgNDQzLiBXZSBzdWdnZXN0IHlvdSBzZWVrIGd1aWRhbmNlIGZyb20geW91 ciBmaXJld2FsbCBtYW51ZmFjdHVyZXIgZm9yIHJlY29tbWVuZGVkIGFjdGlvbnMuDQoNCkhlcmUg YXJlIHNvbWUgZ3VpZGVzIG9uIGJsb2NraW5nIFFVSUMgd2l0aCBzb21lIHBvcHVsYXIgZmlyZXdh bGxzOg0KDQpIb3cgdG8gQmxvY2sgUVVJQyB3aXRoIFNvbmljV2FsbA0KSG93IHRvIEJsb2NrIFFV SUMgd2l0aCBTb3Bob3MgWEcNCkhvdyB0byBCbG9jayBRVUlDIHdpdGggRm9ydGluZXQgRm9ydGln YXRlDQpIb3cgdG8gQmxvY2sgUVVJQyB3aXRoIFBhbG8gQWx0byBOZXR3b3Jrcw0KSG93IHRvIEJs b2NrIFFVSUMgd2l0aCBXYXRjaEd1YXJkDQoiDQoNCkFuZCBhbHNvIHRoaXMgcGFydDoNCg0KIkFy ZSB0aGVyZSBkb3duc2lkZXMgdG8gZGlzYWJsaW5nIG9yIGJsb2NraW5nIFFVSUM/DQoNCkRlc3Bp dGUgZXZlcnl0aGluZyBhYm92ZSwgUVVJQyBpcyBnZW5lcmFsbHkgYSBnb29kIHRoaW5nIGZvciB0 aGUgd29ybGQgYXMgaXQgbWFrZXMgd2ViIGNvbW11bmljYXRpb25zIG1vcmUgZWZmaWNpZW50IGFu ZCBmYXN0ZXIgYmV0d2VlbiBhIGJyb3dzZXIgYW5kIHRoZSBzZXJ2ZXIsIGFuZCB3aG8gZG9lc27i gJl0IHdhbnQgdGhlaXIgd2ViIHBhZ2VzIHRvIGxvYWQgZmFzdGVyLCBhbmQgdG8gaGF2ZSBsZXNz IGJ1ZmZlcmluZyB3aGVuIHdhdGNoaW5nIGFkb3JhYmxlIHB1cHB5IHZpZGVvcyBvbiBZb3VUdWJl Pw0KDQpIb3dldmVyLCB0aGUgZ2VuZXJhbCBjb25zZW5zdXMgKGF0IGxlYXN0IGZvciBub3cpIGlz IHRoYXQgdGhlcmUgaXMgbm8gbm90aWNlYWJsZSBkaWZmZXJlbmNlIGZvciB0aGUgYXZlcmFnZSB1 c2VyIHdoZW4gUVVJQyBpcyBlbmFibGVkLg0KDQpUaGUgd2Vic2l0ZXMgd2lsbCBzdGlsbCB3b3Jr LCBzbyB5b3UgbWlnaHQgYXMgd2VsbCBjaG9vc2Ugc2VjdXJpdHkgb3ZlciBhIHRpbnkgaW5jcmVh c2UgaW4gcGVyZm9ybWFuY2UuDQoiDQoNCklmIHlvdSBsb29rIGF0IHRoZSBibG9nIGRpcmVjdGx5 LCB5b3Ugd2lsbCBhbHNvIGhhdmUgbGlua3MgdG8gZWFjaCB2ZW5kb3Igc2l0ZSBvbiBob3cgdG8g YmxvY2sgcXVpYy4gTXkgdGFrZS1hd2F5IGlzIHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIGhl cmUgaW4gb3JkZXIgdG8gbm90IGZ1cnRoZXIgc3ByZWFkIHRoZSBuZXdzIHRoYXQgUVVJQyBjYW4g c2ltcGx5IGJlIGJsb2NrZWQgYXMgaXQgY2FuIGZhbGxiYWNrIHRvIFRDUC4uLg0KDQpNaXJqYQ0K DQoNCg== From nobody Tue Aug 13 12:26: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 E2680120168 for ; Tue, 13 Aug 2019 12:26:36 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3hdEpL73CgG for ; Tue, 13 Aug 2019 12:26:35 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DC4120128 for ; Tue, 13 Aug 2019 12:26:34 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id i138so40204611ywg.8 for ; Tue, 13 Aug 2019 12:26: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=Uq2J1iCQssGIigjfhuSIcRng7/7VlK8Fa3UmgkGAvW0=; b=fy9iJXyAgYJLwV+V6mzU2F/JXiw97B65tbUzmb2hWPxntLygZ9v3SYQSzkgHGUflZZ csfF92jw6lnRvJqhGhr7UhW0QQmFObH/oFzfW4ln11o5DV2TZDVVGUIQZMIls9l9ApGX Z+AOVXjxiJgVMdeJqACgs+qQuCYnm74fPOfwrQ6IFBoFTZWeUPmoFOk8VcjMctUIgQP/ 7WYTvSK+gwUHvCAXfVqp2zftlDap9jWgTKagcwV+7ebqDudLurQOOstz8tt7jYANJNGy l87nudArKNokg7OvALPG54J3UrEAuRnvlixl4QuTAxbvGooiTHpvS5rasc6VyGJsvS4Y QPSA== 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=Uq2J1iCQssGIigjfhuSIcRng7/7VlK8Fa3UmgkGAvW0=; b=gA8UI06jPTIhPtu2xuChR1uplvcjMHacucYZoTL+vFdUuYUGb5Y2SUeoa73VZwY1RG 2OJFVBT7YGOsoeAi9gyHgfJqkqfgH7FE0FcXAUf0mQgaO9M90uAqQeBhhimIhTHjlAwP mt0joiwWNAgqvKufPQfhpPnRAi+CDPCPBKBKlxItMmVvV/LdR1AHkScnQhOeZoewmlJF g4I8JCuRveNWvIxbxhAslRAozqjV4a+zg+2PEBjxIn3pEKAtGgKrvalBBoP3mjdJYhE6 JGmXliEZB1Y5Ht2J3c+JDQbwyg/Ic1WFXkOYoqSffeS5Ypo9gHfY5JXh/TwAiEKDoR/M Vytw== X-Gm-Message-State: APjAAAWEUc3/jhDFsoP1wgATVRrENN6Hvo6RWmVyFmOrctaHMwGnwkkZ QNQu+rq98/RjqQdFC5FVT3P7XMe60Xbggo4RiIs= X-Google-Smtp-Source: APXvYqzM76z5hDKPkfmc/JNutF+eEVs8eEiFjPpbY/fymTUXvDPgmEh01G04KwVPh14+mnOrsY1k0sAebA5DKKMgAN0= X-Received: by 2002:a81:2841:: with SMTP id o62mr27259354ywo.238.1565724393719; Tue, 13 Aug 2019 12:26:33 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> In-Reply-To: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Tue, 13 Aug 2019 22:26:20 +0300 Message-ID: Subject: Re: Blocking Quic traffic To: Mirja Kuehlewind Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004dcc230590049ef4" 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, 13 Aug 2019 19:26:37 -0000 --0000000000004dcc230590049ef4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2019, 6:42 PM Mirja Kuehlewind < mirja.kuehlewind@ericsson.com> wrote: > My take-away is that we need to be careful here in order to not further > spread the news that QUIC can simply be blocked as it can fallback to TCP > QUIC isn't being designed as a complete replacement for TCP, especially in heavily resource-constrained access networks. It only handles the most common case. It also relies upon (beg pardon) bold assumptions that QUIC allows only for less powerful DDoS attacks than TCP does because of the initial packet size being larger than in TCP. The underlying assumption is that the packet rate possible to achieve by a malicious packet generator is the limiting figure =E2=80=94 which proves wrong as we follow the DDoS incidents happening in t= he wild. (That was mentioned quite a few times in the mailing list.) As a side note: I've sent my concerns about the manageability draft almost a year ago, and hasn't got anything back ever since. Unless QUIC moves one day to an underlying transport protocol which is less vulnerable to legacy amplification attacks than UDP does, blocking UDP and QUIC altogether with the likes of BGP Flowspec under an attack is the only way for everything less than Google to survive. Thus, the option to downgrade a QUIC connection to a TCP connection must not be underestimated. -- T=C3=B6ma > --0000000000004dcc230590049ef4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 13, 2019, 6:42 PM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>= wrote:
My take-away is that we need to be careful here i= n order to not further spread the news that QUIC can simply be blocked as i= t can fallback to TCP

QUIC isn't being designed as a complete replacemen= t for TCP, especially in heavily resource-constrained access networks.=C2= =A0 It only handles the most common case.

=
It also relies upon (beg pardon) bold assumptions that QU= IC allows only for less powerful DDoS attacks than TCP does because of the = initial packet size being larger than in TCP. The underlying assumption is = that the packet rate possible to achieve by a malicious packet generator is= the limiting figure =E2=80=94 which proves wrong as we follow the DDoS inc= idents happening in the wild. (That was mentioned quite a few times in the = mailing list.)

As a side= note: I've sent my concerns about the manageability draft almost a yea= r ago, and hasn't got anything back ever since.
=
Unless QUIC moves one day to an underlying tran= sport protocol which is less vulnerable to legacy amplification attacks tha= n UDP does, blocking UDP and QUIC altogether with the likes of BGP Flowspec= under an attack is the only way for everything less than Google to survive= .

Thus, the option to do= wngrade a QUIC connection to a TCP connection must not be underestimated.

--
T=C3=B6ma
--0000000000004dcc230590049ef4-- From nobody Tue Aug 13 12:41:15 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 1B6481201B7 for ; Tue, 13 Aug 2019 12:41:14 -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_HELO_NONE=0.001, 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 hdT4E3YE01fO for ; Tue, 13 Aug 2019 12:41:12 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE496120168 for ; Tue, 13 Aug 2019 12:41:11 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id r3so2784823vsr.13 for ; Tue, 13 Aug 2019 12:41:11 -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=CA+Ld+GSWrYEn43raQB4d3HiSG1VPuJiO+u1EIOK81k=; b=DIPrmlo+QlQENsY9ug7kxxgMvBqWJxRNViXDpfZCtCeQESM9orLgYPUPxHEZpmN93s J1glNkQR3ljWIR3srH/szXuFKDYWYPKKU3A+FkYFBkMceH0rSOT1U5BnZp+U7MASXIQH CLDBZPoFBbxIrUif7Qn77O5UzN1I0Yea6prCxIleEn2kp0dKs0P4CxiDLUA8UcHdVuoI H2cccM5H4iVEJtf+bwtkN4GhRJHOQhDIshnAn7pACTOd0wBOCJQzmMmA71VSozwQ2o+C dXYzqeKug0fTrRVR8J5e3JAXfyChcw0Dx+e9Yw16diKbLq5oxrwGb0ftG2aEyXPWhIah r3gg== 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=CA+Ld+GSWrYEn43raQB4d3HiSG1VPuJiO+u1EIOK81k=; b=UFwym8FZNWHCTCUKxt3K/QP2XZGpRfwlyASdU554CMPFUNn0gLvCPuDeKYWZxFrLkL tHR1Lop3OhSvg75NZPBb5WoSiHN2jZOmIt4Nd6Tqk6FxE7AR2Lz6WYbLSO4Hd6Ha2XBn h3aVIxVKhD+kMn+vZontHwxMSe1bvPpXG6dWJ4Ah9h8R8VFB4YaXwKZBNFxXGh6fbEKu 2ESj17tIXCxoRBeb+cbYW3S8F8IdnFe9sXWIMP6VeQbWe8iJGupSh4TcDPjdcEhqRVV9 VniTmY6XtjWpCVxouzEvohoarG1dL290KR7DmcJ6a2cFsYP8daGlMowoCToTBh1jB5Ww JhXQ== X-Gm-Message-State: APjAAAXgSB5sgj2h2CK/oPGMrDsOF7wRFeknlcF+Aga6lc2QoduFf2Sm TTcl5uYp+GWvuWJQXpMjiIuXoTTahOaUl6uSbdDiWg== X-Google-Smtp-Source: APXvYqzwgW4TIah6zw0r5L/+mz+ApevBHH7AIF0zqP86KlXYlig1s1diKQ5AuERRq0pOBQDIByS9jRjFJOaguHyXc4c= X-Received: by 2002:a67:c287:: with SMTP id k7mr12489793vsj.208.1565725269724; Tue, 13 Aug 2019 12:41:09 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> In-Reply-To: From: Ian Swett Date: Tue, 13 Aug 2019 15:40:58 -0400 Message-ID: Subject: Re: Blocking Quic traffic To: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Cc: Mirja Kuehlewind , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000084d08b059004d2e6" 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, 13 Aug 2019 19:41:14 -0000 --00000000000084d08b059004d2e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, the TCP fallback is both a blessing and a curse. One aspect of that article is very misleading. For years Google and YouTube have been served via HTTPS, so the following statement is not specific to QUIC: "From a reporting perspective, this means you cannot log and report on the full URLs of QUIC traffic, such as Google Search or YouTube, meaning search term alerts, or viewing a list of YouTube videos watched is not possible when QUIC is enabled." On Tue, Aug 13, 2019 at 3:26 PM T=C3=B6ma Gavrichenkov = wrote: > On Tue, Aug 13, 2019, 6:42 PM Mirja Kuehlewind < > mirja.kuehlewind@ericsson.com> wrote: > >> My take-away is that we need to be careful here in order to not further >> spread the news that QUIC can simply be blocked as it can fallback to TC= P >> > > QUIC isn't being designed as a complete replacement for TCP, especially i= n > heavily resource-constrained access networks. It only handles the most > common case. > I don't think this is true. I believe TCP will be around for a long time, very possibly until the successor to QUIC arrives, but I do think QUIC is well positioned to be a replacement for most use TCP cases in the not so distant future. > > It also relies upon (beg pardon) bold assumptions that QUIC allows only > for less powerful DDoS attacks than TCP does because of the initial packe= t > size being larger than in TCP. The underlying assumption is that the pack= et > rate possible to achieve by a malicious packet generator is the limiting > figure =E2=80=94 which proves wrong as we follow the DDoS incidents happe= ning in > the wild. (That was mentioned quite a few times in the mailing list.) > > As a side note: I've sent my concerns about the manageability draft almos= t > a year ago, and hasn't got anything back ever since. > > Unless QUIC moves one day to an underlying transport protocol which is > less vulnerable to legacy amplification attacks than UDP does, blocking U= DP > and QUIC altogether with the likes of BGP Flowspec under an attack is the > only way for everything less than Google to survive.. > > Thus, the option to downgrade a QUIC connection to a TCP connection must > not be underestimated. > > -- > T=C3=B6ma > >> --00000000000084d08b059004d2e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, the TCP fallback is both a blessing and a curse.=

One aspect of that article is=C2=A0very misleadin= g.=C2=A0 For years Google and YouTube have been served via HTTPS, so the fo= llowing statement is not specific to QUIC:
"From a reporting= perspective, this means you cannot log and report on the full URLs of QUIC= traffic, such as Google Search or YouTube, meaning search term alerts, or = viewing a list of YouTube videos watched is not possible when QUIC is enabl= ed."

On Tue, Aug 13, 2019 at 3:26 PM T=C3=B6ma Gavrichenkov <ximaera@gmail.com> wrote:
On Tue, Aug 13,= 2019, 6:42 PM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> wrote:
My take-away is that we need to be caref= ul here in order to not further spread the news that QUIC can simply be blo= cked as it can fallback to TCP

QUIC isn't being designed as a complete r= eplacement for TCP, especially in heavily resource-constrained access netwo= rks.=C2=A0 It only handles the most common case.

I don't think this is true.=C2=A0 I believe TCP will = be around for a long time, very possibly until the successor to QUIC arrive= s, but I do think QUIC is well positioned to be a replacement for most use = TCP cases in the not so distant future.
=C2=A0
It also relies upon (beg pardon) bold assumptions= that QUIC allows only for less powerful DDoS attacks than TCP does because= of the initial packet size being larger than in TCP. The underlying assump= tion is that the packet rate possible to achieve by a malicious packet gene= rator is the limiting figure =E2=80=94 which proves wrong as we follow the = DDoS incidents happening in the wild. (That was mentioned quite a few times= in the mailing list.)

A= s a side note: I've sent my concerns about the manageability draft almo= st a year ago, and hasn't got anything back ever since.

Unless QUIC moves one day to an under= lying transport protocol which is less vulnerable to legacy amplification a= ttacks than UDP does, blocking UDP and QUIC altogether with the likes of BG= P Flowspec under an attack is the only way for everything less than Google = to survive..

Thus, the o= ption to downgrade a QUIC connection to a TCP connection must not be undere= stimated.

--
T=C3=B6ma
--00000000000084d08b059004d2e6-- From nobody Tue Aug 13 12:59: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 CF2E9120288 for ; Tue, 13 Aug 2019 12:59:31 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFyiRDpq2vOR for ; Tue, 13 Aug 2019 12:59:30 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DB712018B for ; Tue, 13 Aug 2019 12:59:30 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id h8so1632937ybq.9 for ; Tue, 13 Aug 2019 12:59:30 -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=QrXk1YYN3+Yq6ElSv6W1t3WlSj5qNqswzxeHb4TAd6E=; b=l1bjumzFBkgU1WDCDpcwR3E8iqwvG9iss8shw0cVVgp4kiB66/bnSUyeAS+Ps12nLe 6VHvb2SaCJq+60g2aD0CvOtPDb6npspsM54qGn5aYhz/SnsdFiPwsHAqFZYx70q9WjC6 MHpXVAL6Xevs/TDBBiNaebHSulZ30DHsfsOtImDtrC0TR5vokYXSdwLferiXHuhiI48q m6XBLjO//wdTdQ2CSAu6biOs59bj0Hy17vX0G0e51Ifac277lkJwyujG23aMzMGZt0x3 b7MYR5g5jpdiDI75rp62PIL7WT+i+EMYYa1+VbOFl7mJyUDVyCyT1PkJ8jMjFYKWB+Aq 3weA== 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=QrXk1YYN3+Yq6ElSv6W1t3WlSj5qNqswzxeHb4TAd6E=; b=rjwopgoE0FeyiisSvrzJyGigRycAlB8VjVoxBk/XQXnYlGjXgATnQMrF5qoZiU2L9R qp/VW4WFHTQNFR6SKDgrSpIjbc37X8jH3Jz9FNfcE0Gsub+Qu+2Z/nbMfoMeGNn8xtRc gcX8Jdz/qqSMF/8aBD2Lcx0zRKMOeSjhgOJABRad8JftrmK+G3baLHAknUEfE9n7luCt fWKfeNXAz6BKRga6D6CBOQJtUU7rNob/gIALJaN+KNSk8LBrVL5dX+q6+f2+EDkvQGEU T7nZkSr6GsXooMeE41PtWzLyHZp4EK4IJBYXQbhoS2Q7sE822DLG58dG8w+rB+uNc7xf w6XA== X-Gm-Message-State: APjAAAVgn5i1qJz58oirwcYmpwUWWXJaMueI0QwS1pDInkWIJoaRLlSD x/PFuvsOoOi0Mrh35hlAxD4rXZpk5drx2UBmpWw= X-Google-Smtp-Source: APXvYqwYFKwlT8Mn34Mnu+0LVK2grp/VOpHBsvsvABE0tInkPECL7CiKKiyNG4bQw8DFtAk6R8/TeITi7iNKH5pBQZg= X-Received: by 2002:a25:2a4d:: with SMTP id q74mr17556226ybq.498.1565726369154; Tue, 13 Aug 2019 12:59:29 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Tue, 13 Aug 2019 22:59:16 +0300 Message-ID: Subject: Re: Blocking Quic traffic To: Ian Swett Cc: Mirja Kuehlewind , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000000c8ca205900514fe" 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, 13 Aug 2019 19:59:32 -0000 --0000000000000c8ca205900514fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2019, 10:41 PM Ian Swett wrote: > On Tue, Aug 13, 2019 at 3:26 PM T=C3=B6ma Gavrichenkov > wrote: > >> On Tue, Aug 13, 2019, 6:42 PM Mirja Kuehlewind < >> mirja.kuehlewind@ericsson.com> wrote: >> >>> My take-away is that we need to be careful here in order to not further >>> spread the news that QUIC can simply be blocked as it can fallback to T= CP >>> >> >> QUIC isn't being designed as a complete replacement for TCP, especially >> in heavily resource-constrained access networks. It only handles the mo= st >> common case. >> > > I don't think this is true. I believe TCP will be around for a long time= , > very possibly until the successor to QUIC arrives, but I do think QUIC is > well positioned to be a replacement for most use TCP cases in the not so > distant future. > This is exactly what I've said: QUIC is being designed to handle only the most common use cases TCP is now used for. What we'll be bitten with is the long tail of use cases TCP (and HTTPS) is now also being used within. The not-so-distant future promises us a better v2 protocol, finally with load balancers (may a $DEITY bless that), clientside mitigations (are already being discussed within a different IETF WG), protection against predictable identifiers and other stuff. IMO this would be the time to speak of a transport framework which doesn't require a downgrade option to work. -- T=C3=B6ma > --0000000000000c8ca205900514fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 13, 2019, 10:41 PM Ian Swett <ianswett@google.com> wrote:
On Tue, Aug 13, 2019 at 3:26 PM T=C3=B6m= a Gavrichenkov <ximaera@gmail.com> wrote:
On Tue, Aug 13, 2019, 6:42 = PM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> wr= ote:
My take-away is that we need to b= e careful here in order to not further spread the news that QUIC can simply= be blocked as it can fallback to TCP

QUIC isn't being designed as a co= mplete replacement for TCP, especially in heavily resource-constrained acce= ss networks.=C2=A0 It only handles the most common case.

I don't think this is true.=C2=A0 I believe T= CP will be around for a long time, very possibly until the successor to QUI= C arrives, but I do think QUIC is well positioned to be a replacement for m= ost use TCP cases in the not so distant future.

This is exactly what= I've said: QUIC is being designed to handle only the most common use c= ases TCP is now used for.

What we'll be bitten with is the long tail of use cases TCP (and HTTP= S) is now also being used within.

The not-so-distant future promises us a better v2 protocol, final= ly with load balancers (may a $DEITY bless that), clientside mitigations (a= re already being discussed within a different IETF WG), protection against = predictable identifiers and other stuff.=C2=A0 IMO this would be the time t= o speak of a transport framework which doesn't require a downgrade opti= on to work.

--
T=C3=B6ma
--0000000000000c8ca205900514fe-- From nobody Tue Aug 13 13:55: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 CB1EF1208E3 for ; Tue, 13 Aug 2019 13:55:13 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8zljNjEyEge for ; Tue, 13 Aug 2019 13:55:11 -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 4EDE01208C2 for ; Tue, 13 Aug 2019 13:55:11 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id h15so9144682ljg.10 for ; Tue, 13 Aug 2019 13:55:11 -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=utr9OAK5YrRv61CsSoHbcfvMsVT32cr2SFH7KuH+YuM=; b=V6qtQcm1ChOqYPBketClZvYXbThC//nOjVtAEPjbjcj5CmPmlxJVIVURB6PXPafvz6 OULQ94zX1qaAf03P04ATS6NEFkIPuewRhM0Ib6n246FZh7BwbOSjCtADMkihzhXcJ0dL LuWTGffpLKF/6sQ1XCsNXdcmnWLfcHbzsndjREvzdWjo+Y/ljDVUxpg/ALuSIs7FdWkB tjD70bX/qRTHmoF+AoPhD0xOYvFZdp26ZfRjfqcePb0X7Cjji4R4YxgwyhfnsZ9WLRhR vsdLEbaIXtac3fYC1r4P90TLXLmfq0YL20/MpZ+0q7XpyzIfMwO1tfA+Y7WfKF1Jxy2O iODg== 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=utr9OAK5YrRv61CsSoHbcfvMsVT32cr2SFH7KuH+YuM=; b=aeiSs2fgW7Zsg2FvooF8fjua15KTXPZRtQSeMdykSDfil0BmA0TLCJ7boRQWxFJh2A DCCGETsdpqcA21RjGTQ43kajAqy0RHZACQxRn4U0jyiyYAn16vJW4IhIijxOyZro4Rh0 mCj56x++fjLLd/CKYbrgjqT4HGg0EMcHDA1SVlDd2R6qyDa3U1OKOEaiPF7TQq+bF2br X7F9qRp5pMkqfa4fIv7yz/GOdyz2hFdCv/t8jk6/edBDrXtfVpMcuRUefGsMr2y0hrlV LACUaKt6h7jttMcHKGmW70F3kV8hKNsFtMGpEINFMQQ3Jsl1gVCkg2tjDR0qvqxZAs3X NheA== X-Gm-Message-State: APjAAAUoRjab0ZNtZnwqXH397UKnKmzB40Axrw/edO8h+lwCVJeAIOlv I+qemK0RJTIbJAMyTdabyhnnJM19F4imG8ItX7I= X-Google-Smtp-Source: APXvYqyoCerN+GjQga+BU73bEUtz8LKo2C6SxjSmgA7TZHbTx5CFs+lI17OnIhrw7bXYVQh7V1/+5vr+nETZWqaU250= X-Received: by 2002:a2e:8744:: with SMTP id q4mr22704493ljj.77.1565729709434; Tue, 13 Aug 2019 13:55:09 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> In-Reply-To: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> From: Jana Iyengar Date: Tue, 13 Aug 2019 13:54:58 -0700 Message-ID: Subject: Re: Blocking Quic traffic To: Mirja Kuehlewind Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000252a6a059005dbf6" 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, 13 Aug 2019 20:55:14 -0000 --000000000000252a6a059005dbf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mirja, I did a short presentation on this at the interim in London earliier this year: https://github.com/quicwg/wg-materials/blob/master/interim-19-05/quic-firew= alls.pdf I don't think we can do very much at the moment. TCP will be used as a fallback because there is a non-trivial blackhole rate for UDP and QUIC, and firewalls will block QUIC where they are configured to. I don't expect these to change... but my expectation remains that the amount of blocking won't be high enough to matter. We should still keep an eye on these firewalls to ensure that when they do want to block QUIC, that they do it well, and not break any fallback mechanisms. - jana On Tue, Aug 13, 2019 at 8:42 AM Mirja Kuehlewind < mirja.kuehlewind@ericsson.com> wrote: > Hi all, > > I would like to point the group to the following blog post: > > > https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-r= eporting-implications/# > > And specially the following part of it: > > "Resolving the QUIC issue > > The good news is that if QUIC communication does not work between a clien= t > and a server, the traffic will fall back to traditional HTTP/HTTPS over > TCP, where it can be inspected, controlled, logged and reported on as usu= al. > > At the time of writing, the advice from most firewall vendors is to block > QUIC until support is officially added to their products. This recommende= d > method will vary from firewall to firewall. Some firewalls allow QUIC by > default while others block it by default, but all firewalls are able to > allow or block it. > > Common methods are to block either a defined QUIC protocol, QUIC > application type, or create a firewall rule to block UDP on port 80 and > 443. We suggest you seek guidance from your firewall manufacturer for > recommended actions. > > Here are some guides on blocking QUIC with some popular firewalls: > > How to Block QUIC with SonicWall > How to Block QUIC with Sophos XG > How to Block QUIC with Fortinet Fortigate > How to Block QUIC with Palo Alto Networks > How to Block QUIC with WatchGuard > " > > And also this part: > > "Are there downsides to disabling or blocking QUIC? > > Despite everything above, QUIC is generally a good thing for the world as > it makes web communications more efficient and faster between a browser a= nd > the server, and who doesn=E2=80=99t want their web pages to load faster, = and to > have less buffering when watching adorable puppy videos on YouTube? > > However, the general consensus (at least for now) is that there is no > noticeable difference for the average user when QUIC is enabled. > > The websites will still work, so you might as well choose security over a > tiny increase in performance. > " > > If you look at the blog directly, you will also have links to each vendor > site on how to block quic. My take-away is that we need to be careful her= e > in order to not further spread the news that QUIC can simply be blocked a= s > it can fallback to TCP... > > Mirja > > > --000000000000252a6a059005dbf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mirja,

I did a short presentation on th= is at the interim in London earliier this year:=C2=A0h= ttps://github.com/quicwg/wg-materials/blob/master/interim-19-05/quic-firewa= lls.pdf

I don't think we can do very much = at the moment. TCP will be used as a fallback because there is a non-trivia= l blackhole rate for UDP and QUIC, and firewalls will block QUIC where they= are configured to. I don't expect these to change... but my expectatio= n remains that the amount of blocking won't be high enough to matter.= =C2=A0

We should still keep an eye on these firewa= lls to ensure that when they do want to block QUIC, that they do it well, a= nd not break any fallback mechanisms.

- jana
=

= On Tue, Aug 13, 2019 at 8:42 AM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> wrote:
=
Hi all,

I would like to point the group to the following blog post:

http= s://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporti= ng-implications/#

And specially the following part of it:

"Resolving the QUIC issue

The good news is that if QUIC communication does not work between a client = and a server, the traffic will fall back to traditional HTTP/HTTPS over TCP= , where it can be inspected, controlled, logged and reported on as usual.
At the time of writing, the advice from most firewall vendors is to block Q= UIC until support is officially added to their products. This recommended m= ethod will vary from firewall to firewall.=C2=A0 Some firewalls allow QUIC = by default while others block it by default, but all firewalls are able to = allow or block it.

Common methods are to block either a defined QUIC protocol, QUIC applicatio= n type, or create a firewall rule to block UDP on port 80 and 443. We sugge= st you seek guidance from your firewall manufacturer for recommended action= s.

Here are some guides on blocking QUIC with some popular firewalls:

How to Block QUIC with SonicWall
How to Block QUIC with Sophos XG
How to Block QUIC with Fortinet Fortigate
How to Block QUIC with Palo Alto Networks
How to Block QUIC with WatchGuard
"

And also this part:

"Are there downsides to disabling or blocking QUIC?

Despite everything above, QUIC is generally a good thing for the world as i= t makes web communications more efficient and faster between a browser and = the server, and who doesn=E2=80=99t want their web pages to load faster, an= d to have less buffering when watching adorable puppy videos on YouTube?
However, the general consensus (at least for now) is that there is no notic= eable difference for the average user when QUIC is enabled.

The websites will still work, so you might as well choose security over a t= iny increase in performance.
"

If you look at the blog directly, you will also have links to each vendor s= ite on how to block quic. My take-away is that we need to be careful here i= n order to not further spread the news that QUIC can simply be blocked as i= t can fallback to TCP...

Mirja


--000000000000252a6a059005dbf6-- From nobody Wed Aug 14 04:13: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 3DE2B1200F8 for ; Wed, 14 Aug 2019 04:13: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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T8t4KGMGwyQ for ; Wed, 14 Aug 2019 04:13:07 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EB71200EF for ; Wed, 14 Aug 2019 04:13:07 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id o82so9114736ybg.10 for ; Wed, 14 Aug 2019 04:13: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=XrwwbPbkBZ9eyd4dS+8cAOJbc82Sscd24saD0Mo0pOY=; b=DlnyGDndGEk4YxZMBZcPv6VlrSr6tL9BvsM7Zy/w6VGgNkR0p2M+0WNC7+pif+Kyma rvRGd+kY2qy0pN/lhfmnP/Bp5F9f9rUmmTwgU8znoADytl6oHxz5iVxFm54MNRkiXR98 +YfCjX6sq9gdRjIdW6IG0FaFt6l7g4PieSxCc+Tgy+PI3YDqp7tESPWkEvCZn6uGhUqf qcdG8+rEXSvZENGgqb9MmR/uOYklFX5cpN22Nq6qXTSquqfFpP3dGw4TF2rJcBZoD3Zt kUnuIdTtjOjKNArpngp7U/qtZJVZ8BC1PBNKlMNzqj0SC6G3+b9mJvUdrrUDlwdu3hj+ 2TOQ== 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=XrwwbPbkBZ9eyd4dS+8cAOJbc82Sscd24saD0Mo0pOY=; b=G1mF43/6RpvgyFSpvE5jW2yTDAsxVS/WaR3lpWr3TLTPXszc3fJoV54Ul4L6QH6LBr wdY4+QIEQ6krX9hcoQOqEmNWk74xAjtKP5hlik/ZNu7B9TYMb0mWPUd5pa8NfvaUI9dF ACXunraabn265Gts4uubZGS7Ok6p+MY4Hmn3tBUT7LucsaIaViCUSra40km93vxqi7Jo 1XmMFAqRWZMJLsM1J7KU0pCigMAGu2itafCAdoPyqKiCYwI6SThLps+K9VGeaEW2wf9a DtkWQeh9rUyzz9Dp8ettvQP29a0/jzBxATyVAjTsvavbh1/ynDnP8Na5ogRRqTvytPyr PJ9A== X-Gm-Message-State: APjAAAU8Bu1IiQNm5D4dhnVs0cWOBfzKNgBMY09TKUQQLIaovVDBxgHt 1pBRvs8s7Hvj1ejrw7xW59wZyy9SQajtPQwYoDU= X-Google-Smtp-Source: APXvYqzv6IGazCLI34fPifIiPhYHwVYhAtMYxV8gI3mPs/h48Boyc/kVMzn4fEPVPpiEmxHJmkyHKN8AycE3Cv6B+No= X-Received: by 2002:a25:84c7:: with SMTP id x7mr8438162ybm.183.1565781186419; Wed, 14 Aug 2019 04:13:06 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Wed, 14 Aug 2019 14:12:51 +0300 Message-ID: Subject: Re: Blocking Quic traffic To: Mirja Kuehlewind 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, 14 Aug 2019 11:13:09 -0000 Peace, On Tue, Aug 13, 2019 at 10:26 PM T=C3=B6ma Gavrichenkov = wrote: > The underlying assumption is that the packet rate > possible to achieve by a malicious packet generator > is the limiting figure =E2=80=94 which proves wrong Err... s/is the/isn't the/ (that's an interesting way autocorrection works in Android, I must say!) -- T=C3=B6ma From nobody Wed Aug 14 04:13: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 70BCC120812 for ; Wed, 14 Aug 2019 04:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp2qhP-B8qo1 for ; Wed, 14 Aug 2019 04:13:38 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450: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 27B9D120104 for ; Wed, 14 Aug 2019 04:13:36 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id p197so78992891lfa.2 for ; Wed, 14 Aug 2019 04:13:36 -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=hSwpr3GZueMRorptTd8XOsAQgdkzzbPrmojpL5s2+Qc=; b=LZWmbqVyuC5WggkzieaQiu/wSZ2Y56RAVC9LQUJCeBWgzmVwPkvYHpsMjFEwG0w2Ie A29wS2nfb0g8OYBbl1j8NycZlsL6DErEk73Wonni8O6SQapxURZO3M9wSwUo95lhEL12 FjrT/V/Yh55znqFnScRfwKFEwZqwuqc8OMnS5TlW28lm37jGXjTXdO6LHNmXWy43iAnm nL+LYt9Qm+ewMVtycsx/5W+hkd9ferREHV50iquhANYCskcPPJm986gMShlbuwEC9J3K q9zvwAwXw1jiJlmEccz5yzh+YrTXvAJHraOAdS9xhzKExJXjOeBh+koWqfBONlBjTI67 gA1A== 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=hSwpr3GZueMRorptTd8XOsAQgdkzzbPrmojpL5s2+Qc=; b=UCdfs/xlqDR4Gnf9rMYu8pe2oVXSIH4qx6HqELB+cXt5aXhuLgM/E6ostrdYpFd1sS MSJmKiQvDI0P02r66MYdjWyprS6zxpqI2iuF65FoqjawQ2lcH3aVSnExOyj8dODuQ/Hf PwPEFyLbtwHbhIudzvQR7GX8IdbO/G5y98cJDoDnKXjxZFz9K0icyfdUZasy3GVN0RKU w/S3IA93tsJhtvV7lmdpMOHqQkYr0ieAjhe3SFzAn8NOPGpJftPdnq06xVltKGK8Y39w hdYVM7pJEF6Hymp6HZNRWU84KmzHTbg0JAvx0bUjkQ0KoILjp4p+5w3ArM5rPl9JgJfP cwSw== X-Gm-Message-State: APjAAAXdQ9af7KejiwD6wowO9MWdVxmV1D6+LVyNY+m4bfRx5NktXQBM uxdVoV4ya0+UfT+em3QaW2XG74RlIfsf2pxXkkYqQQ== X-Google-Smtp-Source: APXvYqzcM7gECWAx9GaI0RyieHN2XgqUGYPaWteoIWWXZXZSCfbKfGl3Laua/J5lX02FRuToRwgVn0WAvJ2Jqp8d8ew= X-Received: by 2002:ac2:545b:: with SMTP id d27mr25803716lfn.36.1565781212296; Wed, 14 Aug 2019 04:13:32 -0700 (PDT) MIME-Version: 1.0 References: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> In-Reply-To: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> From: Victor Vasiliev Date: Wed, 14 Aug 2019 07:13:20 -0400 Message-ID: Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20) To: Andy Green Cc: dispatch@ietf.org, David Schinazi , hybi@ietf.org, IETF QUIC WG , HTTP Working Group , webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000f4dd45059011d867" 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, 14 Aug 2019 11:13:41 -0000 --000000000000f4dd45059011d867 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2019 at 5:00 PM Andy Green wrote: > > > On 7/22/19 1:36 PM, Victor Vasiliev wrote: > > Hello everyone, > > > > Today, at the dispatch working group meeting (18:10), I am going to > > present WebTransport. WebTransport is a protocol framework that allows > > multiplexed and datagram-oriented transport protocols to be used by the > > web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D). > > "Historically, web applications that needed bidirectional data stream > between a client and a server could rely on WebSockets [RFC6455], a > message-based protocol compatible with Web security model. However, > since the abstraction it provides is a single ordered stream of > messages, it suffers from head-of-line blocking (HOLB), meaning that > all messages must be sent and received in order even if they are > independent and some of them are no longer needed. This makes it a > poor fit for latency sensitive applications which rely on partial > reliability and stream independence for performance." > > The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary > fragmentation of messages allowing interleaving with control frames. > It allows them to be fragmented, but the fragments have to be in order. The multiplexing extension is mentioned as potential future work in RFC 6455, but I don't believe it ever actually materialized. > ws-over-h2 allows you to can the h2 stream when you want as well. > True, though you can't use them in the same way as pure QUIC streams because QUIC streams are created immediately, whereas a new WS requires a handshake. > > " Each new stream would require a WebSocket handshake to agree on > application protocol used, meaning that it would take at least one > RTT for each new stream before the client can write to it." > > Yes it was knowingly done as a hack to try to encourage uptake from > browser vendors... it's not really integrated into the encapsulating > protocol. > It =3D ws-over-http2 being a thin overlay over existing WSP? > > * WebTransport overview: > > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > > * QuicTransport: > > https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > > * Http3Transport: > > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 > > There's no h2 transport implementation? > > Not everything that might want to use this will get h3 capability in a > reasonable timeframe. If there's more momentum behind it than RFC8441 > there's probably room for a generic long-lived bidirectional extension > to h2 either reusing DATA or a new frame type. > I think we might adapt an HTTP/2 transport as well (via draft-kinnear-httpbis-http2-transport). > It's a good idea to have it ride on other protocols. Not doing this > really hurt RFC6455 ws since deploying it usually needed extra, > different servers with the attendant difficulties interoperating with > other protocols. > One idea I had is an object called FallbackTransport, that can simulate QUIC semantics on top of WebSocket and be fully polyfillable in browsers. > I really suggest thinking through the effects of not having an RFC6455 > type subprotocol (unless I failed to spot it). It really makes an > implicit assumption about what the stream will carry that doesn't scale > beyond one server carrying one thing. That's not how things tend to pan > out if the protocol is useful. The url path could be hacked to imply > the subprotocol but if that's not standardized it's still a mess. And > the subprotocol binding may be orthogonal to the url layout complicating > things needlessly. > That's definitely an open issue with current proposal (some discussion here ). The current problem is that we basically have to choose between either transmitting the requested protocol in the open, or paying one extra RTT for the protocol selection mechanism. --000000000000f4dd45059011d867 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 22, 2019 at 5:00 PM Andy Gree= n <andy@warmcat.com> wrote:


On 7/22/19 1:36 PM, Victor Vasiliev wrote:
> Hello everyone,
>
> Today, at the dispatch working group meeting (18:10), I am going to > present WebTransport. WebTransport is a protocol framework that allows=
> multiplexed and datagram-oriented transport protocols to be used by th= e
> web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D).

"Historically, web applications that needed bidirectional data stream<= br> =C2=A0 =C2=A0 between a client and a server could rely on WebSockets [RFC64= 55], a
=C2=A0 =C2=A0 message-based protocol compatible with Web security model.=C2= =A0 However,
=C2=A0 =C2=A0 since the abstraction it provides is a single ordered stream = of
=C2=A0 =C2=A0 messages, it suffers from head-of-line blocking (HOLB), meani= ng that
=C2=A0 =C2=A0 all messages must be sent and received in order even if they = are
=C2=A0 =C2=A0 independent and some of them are no longer needed.=C2=A0 This= makes it a
=C2=A0 =C2=A0 poor fit for latency sensitive applications which rely on par= tial
=C2=A0 =C2=A0 reliability and stream independence for performance."
The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary =
fragmentation of messages allowing interleaving with control frames.

It allows them to be fragmented, but the frag= ments have to be in order.=C2=A0 The multiplexing extension is mentioned as= potential future work in RFC 6455, but I don't believe it ever actuall= y materialized.
=C2=A0
ws-over-h2 allows you to can the h2 stream when you want as well.

True, though you can't use them in the same = way as pure QUIC streams because QUIC streams are created immediately, wher= eas a new WS requires a handshake.
=C2=A0

" Each new stream would require a WebSocket handshake to agree on
=C2=A0 =C2=A0 =C2=A0 =C2=A0application protocol used, meaning that it would= take at least one
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTT for each new stream before the client can wr= ite to it."

Yes it was knowingly done as a hack to try to encourage uptake from
browser vendors... it's not really integrated into the encapsulating protocol.

It =3D ws-over-http2=C2=A0bei= ng a thin overlay over existing WSP?
=C2=A0
>=C2=A0 =C2=A0* WebTransport overview:
>=C2=A0 =C2=A0 =C2=A0https://tools.= ietf.org/html/draft-vvv-webtransport-overview-00
>=C2=A0 =C2=A0* QuicTransport:
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf= .org/html/draft-vvv-webtransport-quic-00
>=C2=A0 =C2=A0* Http3Transport:
>=C2=A0 =C2=A0 =C2=A0https://tools.iet= f.org/html/draft-vvv-webtransport-http3-00

There's no h2 transport implementation?

Not everything that might want to use this will get h3 capability in a
reasonable timeframe.=C2=A0 If there's more momentum behind it than RFC= 8441
there's probably room for a generic long-lived bidirectional extension =
to h2 either reusing DATA or a new frame type.

I think we might adapt an HTTP/2 transport as well (via=C2=A0draft-= kinnear-httpbis-http2-transport).
=C2=A0
It's a good idea to have it ride on other protocols.=C2=A0 Not doing th= is
really hurt RFC6455 ws since deploying it usually needed extra,
different servers with the attendant difficulties interoperating with
other protocols.

One idea I had is an o= bject called FallbackTransport, that can simulate QUIC semantics on top of = WebSocket and be fully polyfillable in browsers.
=C2=A0
I really suggest thinking through the effects of not having an RFC6455
type subprotocol (unless I failed to spot it).=C2=A0 It really makes an implicit assumption about what the stream will carry that doesn't scale=
beyond one server carrying one thing.=C2=A0 That's not how things tend = to pan
out if the protocol is useful.=C2=A0 The url path could be hacked to imply =
the subprotocol but if that's not standardized it's still a mess.= =C2=A0 And
the subprotocol binding may be orthogonal to the url layout complicating things needlessly.

That's definitel= y an open issue with current proposal (some discussion here).=C2=A0 =C2=A0The current = problem is that we basically have to choose between either transmitting the= requested protocol in the open, or paying one extra RTT for the protocol s= election mechanism.
--000000000000f4dd45059011d867-- From nobody Wed Aug 14 05:01: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 2DD9B12006F; Wed, 14 Aug 2019 05:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rPEzxms_9fHc; Wed, 14 Aug 2019 05:01:29 -0700 (PDT) Received: from warmcat.com (warmcat.com [46.105.127.147]) (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 0088812010F; Wed, 14 Aug 2019 05:01:28 -0700 (PDT) Date: Wed, 14 Aug 2019 13:01:14 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20) To: Victor Vasiliev CC: dispatch@ietf.org, David Schinazi , hybi@ietf.org, IETF QUIC WG , HTTP Working Group , webtransport@ietf.org From: Andy Green Message-ID: <9BF912A7-07AF-4174-99F0-7A8F9ED2A44C@warmcat.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: Wed, 14 Aug 2019 12:01:31 -0000 On August 14, 2019 12:13:20 PM GMT+01:00, Victor Vasiliev wrote: >On Mon, Jul 22, 2019 at 5:00 PM Andy Green wrote: > >> >> >> On 7/22/19 1:36 PM, Victor Vasiliev wrote: >> > Hello everyone, >> > >> > Today, at the dispatch working group meeting (18:10), I am going to >> > present WebTransport=2E WebTransport is a protocol framework that >allows >> > multiplexed and datagram-oriented transport protocols to be used by >the >> > web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D)=2E >> >> "Historically, web applications that needed bidirectional data stream >> between a client and a server could rely on WebSockets [RFC6455], >a >> message-based protocol compatible with Web security model=2E=20 >However, >> since the abstraction it provides is a single ordered stream of >> messages, it suffers from head-of-line blocking (HOLB), meaning >that >> all messages must be sent and received in order even if they are >> independent and some of them are no longer needed=2E This makes it >a >> poor fit for latency sensitive applications which rely on partial >> reliability and stream independence for performance=2E" >> >> The HOLB isn't really entirely the case=2E=2E=2E RFC6455 ws allows >arbitrary >> fragmentation of messages allowing interleaving with control frames=2E >> > >It allows them to be fragmented, but the fragments have to be in order=2E >The multiplexing extension is mentioned as potential future work in RFC >6455, but I don't believe it ever actually materialized=2E Yes, you can only have one message on the go at a time; in that sense larg= e messages block it=2E But it does not block the stream completely because= you can issue control frames inbetween fragments=2E And although you may = not have control over fragment size since intermediaries can mess with it, = as the sender you do have control over message size which puts a ceiling on= both how long other messages are blocked, and the max fragment size=2E Yo= u may choose to split a large logical message into smaller ones so other me= ssage content can get a look-in=2E The mux extension stuff was a thing on hybi for a while and then the main = proponent seemed to lose interest with muxed ws vs h2=2E=2E=2E h2 was clear= ly a better result than he could have gotten from ws=2E >> ws-over-h2 allows you to can the h2 stream when you want as well=2E >> > >True, though you can't use them in the same way as pure QUIC streams >because QUIC streams are created immediately, whereas a new WS requires >a >handshake=2E Sure=2E=2E=2E for clarity I also think h1 ws if not competitive itself wit= h h2 or quic=2E But it is widely implemented and deployed, and h2 doesn't = have a native equivalent=2E So it's still kind of keeping its hand in=2E > >> >> " Each new stream would require a WebSocket handshake to agree on >> application protocol used, meaning that it would take at least >one >> RTT for each new stream before the client can write to it=2E" >> >> Yes it was knowingly done as a hack to try to encourage uptake from >> browser vendors=2E=2E=2E it's not really integrated into the encapsulat= ing >> protocol=2E >> > >It =3D ws-over-http2 being a thin overlay over existing WSP? Yeah=2E It's implemented in ffox and chrome but not turned on by default = last time I looked=2E There are few server implementations which makes it = chicken-and-egg=2E > >> > * WebTransport overview: >> > https://tools=2Eietf=2Eorg/html/draft-vvv-webtransport-overview-0= 0 >> > * QuicTransport: >> > https://tools=2Eietf=2Eorg/html/draft-vvv-webtransport-quic-00 >> > * Http3Transport: >> > https://tools=2Eietf=2Eorg/html/draft-vvv-webtransport-http3-00 >> >> There's no h2 transport implementation? >> >> Not everything that might want to use this will get h3 capability in >a >> reasonable timeframe=2E If there's more momentum behind it than >RFC8441 >> there's probably room for a generic long-lived bidirectional >extension >> to h2 either reusing DATA or a new frame type=2E >> > >I think we might adapt an HTTP/2 transport as well >(via draft-kinnear-httpbis-http2-transport)=2E Sounds good=2E >> It's a good idea to have it ride on other protocols=2E Not doing this >> really hurt RFC6455 ws since deploying it usually needed extra, >> different servers with the attendant difficulties interoperating with >> other protocols=2E >> > >One idea I had is an object called FallbackTransport, that can simulate >QUIC semantics on top of WebSocket and be fully polyfillable in >browsers=2E In this space the problem isn't really ideas but implementation buy-in=2E = RFC8441 is educational because it was well positioned politically, the rfc= certainly was exemplary for just saying what it needed to say, it solved a= real problem, got some key implementations yet has still not been able to = reach escape velocity=2E There's some psychological and architectural gap = between ws and http that is much wider than you would expect for many peopl= e (cf h2 addressed every single h1 + html 5 technology except ws -- and it = was not an accidental oversight)=2E RFC8441 went in Chrome=2E=2E=2E it hasn't been enough by itself=2E Maybe = the crossover with quic will help your thing over the hump=2E >> I really suggest thinking through the effects of not having an >RFC6455 >> type subprotocol (unless I failed to spot it)=2E It really makes an >> implicit assumption about what the stream will carry that doesn't >scale >> beyond one server carrying one thing=2E That's not how things tend to >pan >> out if the protocol is useful=2E The url path could be hacked to imply >> the subprotocol but if that's not standardized it's still a mess=2E=20 >And >> the subprotocol binding may be orthogonal to the url layout >complicating >> things needlessly=2E >> > >That's definitely an open issue with current proposal (some discussion >here >)=2E The current >problem >is that we basically have to choose between either transmitting the >requested protocol in the open, or paying one extra RTT for the >protocol >selection mechanism=2E Usually the guy who directed the client to that server does it knowing tha= t the server has the subprotocol he wants, unless something has gone wrong= =2E And it's only client -> server direction pipelining in question; the s= erver can't send anything until he's had the request and he definitively de= cided the negotiated subprotocol by then, or killed the stream=2E A client that had hot data to send could mark his preferred subprotocol as= being non-neogitiable and start issuing data immediately after the stream = open request=2E=2E=2E all being well the server allowed the stream's subpro= tocol, it lives on and takes the data, in the case it rejected the subproto= col it closes the stream and discards the data=2E The client would have to= either fail or retry without the non-neotiable part to recover if so=2E B= ut typically, he's only talking to the server because he's pretty sure it'l= l talk his subprotocol and it'll work the first time=2E -Andy From nobody Wed Aug 14 10:33: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 E67FE120C12 for ; Wed, 14 Aug 2019 10:33:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 YYY3f0Z7e-WB for ; Wed, 14 Aug 2019 10:33:20 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC90120C1A for ; Wed, 14 Aug 2019 10:33:19 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id D7D81B0039; Wed, 14 Aug 2019 20:33:16 +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 C1DFB694085; Wed, 14 Aug 2019 20:33:09 +0300 (EEST) From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_345EF9F1-BEFF-43FB-81EB-2602749C6F26"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Quic wg milestones update? Date: Wed, 14 Aug 2019 20:33:09 +0300 In-Reply-To: Cc: IETF QUIC WG To: "Flinck, Hannu (Nokia - FI/Espoo)" References: X-MailScanner-ID: C1DFB694085.A5B02 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: Wed, 14 Aug 2019 17:33:22 -0000 --Apple-Mail=_345EF9F1-BEFF-43FB-81EB-2602749C6F26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2019-8-13, at 11:06, Flinck, Hannu (Nokia - FI/Espoo) = wrote: > Probably the WG milestone table should be updated as well to reflect = the latest views. I recently heard that the IESG is debating to eliminate WG milestones = across the board. We're waiting for this discussion to terminate before = making any adjustments. Lars --Apple-Mail=_345EF9F1-BEFF-43FB-81EB-2602749C6F26 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAl1URdUACgkQHbmKvSnu NPix4Q//Tu7bkkuFKDzBbHHNpJPROs/HUS52FWwAqjCBXfxLdou0h+1KUYtBhVuF WJCiBHPeiTxdJPbgBn68XIlDwXoow2z1jyS+6vUMwkAvTYhZGnB8CeuJorGJhwrI WyVq6MdT3MKaOeHcUXTv219U4w/xiHHKKpFv9pbaTJWY87YRjs5Qd90p+sBMrYrJ +1XfObHJXPxS5hRu6Aevi9eVdAmHtydM+DrHfzEJBPNclpjGCIA3FOcfsaZePO/P guZ+TEmtSVx5XhWGYPHlLcX9FvDTwELfPARuY9frLUkSGqvADY2O5S31eg5NVwap c7LSWbZM85wHmXkhIKgKhUjbN2yy3cXuvGFXBJ9nwpULQrYEkrSMMQh6QgmPXkHB TZo7vDEIcQXGWtqiTMCd1zTVQkb1IZ+S4AMTy3mo9gXgSJGxxOGQq+Rk4cE+wy4d ARZEMWQXNTaDRY/IAzZ5jsP6qDXr/6j9NLNQWYO/VTWMWN6MiBlphSW2BBjIhw6x ttisP5jyVUkWa18co2W/FO+x6IykT1rZxS6HqnsJZrX93lQ6MqzVxVmFJTrqTtxs k6tpfNrwSu0d8XvjmEEeBh7GSFhoHMEmBoeRcd3jbO9rEZc806+/qQL0720dVxhN xunjYubgYSFzt6d4Xbm9KwbSOcx/e5rpANQGZqZRhrb2xM36be0= =gB+F -----END PGP SIGNATURE----- --Apple-Mail=_345EF9F1-BEFF-43FB-81EB-2602749C6F26-- From nobody Wed Aug 14 20:46: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 6BB99120025; Wed, 14 Aug 2019 20:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ce4UJBwL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MabGcpPC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myDKwOvRcH9c; Wed, 14 Aug 2019 20:46:25 -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 D89A512001A; Wed, 14 Aug 2019 20:46:25 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9A29957C; Wed, 14 Aug 2019 23:46:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 14 Aug 2019 23:46: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 :reply-to:content-transfer-encoding:message-id:references:to; s= fm3; bh=gK1yYyLOi8yvbQB50u7zTCrPk5vpwFH+dtsmAE+4gic=; b=ce4UJBwL lsAogFylkHpqwlTyMyBiFtdxx/zBT9p4FAq412XAUG4I1cFHZGh1Xv7qOKPidTuc 6IL8SZq2u7kP+KtPgIysa4is8jZdAjrKXrwJq07od/z+TBs0MwU24oBE4Si+7lrg l3SRFegWO0goUIhVkrTdYEWH5Fmsj/9ldsPh/j3/POfQ+kvPPrPEf48hb4CHoLxW 46JxHWHCY5euF+A8XdClipVjl91VeVXbauTlzI5mrO41hpLjqS6ZLciqyKFTdFKY 2d1qVviSuhBuWnRAyXBU5dxBc+OhF3kLytNlUKS8DXpNiIag7jha7Nxw3XzaEGeO b6tBqxxC/3nM+w== 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=gK1yYyLOi8yvbQB50u7zTCrPk5vpw FH+dtsmAE+4gic=; b=MabGcpPCeEotv4QuMIEypU9BVBizMTIm3wcU7BB6v/zi9 CZYJ4Jw/SMUWM13aY5/gsVcTu7whdX7Ir7XttQHI7JzSaiPLYerkdR3T/SOcmBjK DJ6WBqGkWUlu8qSPQ1uYT4ZizrwjUEGjUH2yMHLX8cu4r3QmwMQEt9bxJtn48ioO sXKI+0BxxAD1Fj1VGpJeH4Wh0vrHQvvZT1zRddiQxCMmWftAqrT3OMvnfLLVolzk h8MU95/JN8l7XdOOXgy0Qfiaqf4FSTrJZkrX8LbqeYubvldjnKWQ+VL5cg83IjLd kJfjKaIelnE5mYhdv6SH3T/NY+GkA7EftB6y7/rfA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeftddggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffrhfgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrih hnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucfkphep udeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhoth esmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 12D6A380076; Wed, 14 Aug 2019 23:46:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20) From: Mark Nottingham In-Reply-To: <9BF912A7-07AF-4174-99F0-7A8F9ED2A44C@warmcat.com> Date: Thu, 15 Aug 2019 13:46:13 +1000 Cc: Victor Vasiliev , hybi@ietf.org, webtransport@ietf.org, David Schinazi , DISPATCH , HTTP Working Group , IETF QUIC WG Reply-To: webtransport@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7CC9DF9E-6A1C-4DD6-9CA3-92EB04AFAE2D@mnot.net> References: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> <9BF912A7-07AF-4174-99F0-7A8F9ED2A44C@warmcat.com> To: Andy Green X-Mailer: Apple Mail (2.3445.104.11) 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, 15 Aug 2019 03:46:30 -0000 Folks, Now that webtransport@ has been created, let's continue the discussion = over there, rather than cross-posting to five lists. Cheers, > On 14 Aug 2019, at 10:01 pm, Andy Green wrote: >=20 >=20 >=20 > On August 14, 2019 12:13:20 PM GMT+01:00, Victor Vasiliev = wrote: >> On Mon, Jul 22, 2019 at 5:00 PM Andy Green wrote: >>=20 >>>=20 >>>=20 >>> On 7/22/19 1:36 PM, Victor Vasiliev wrote: >>>> Hello everyone, >>>>=20 >>>> Today, at the dispatch working group meeting (18:10), I am going to >>>> present WebTransport. WebTransport is a protocol framework that >> allows >>>> multiplexed and datagram-oriented transport protocols to be used by >> the >>>> web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D). >>>=20 >>> "Historically, web applications that needed bidirectional data = stream >>> between a client and a server could rely on WebSockets [RFC6455], >> a >>> message-based protocol compatible with Web security model.=20 >> However, >>> since the abstraction it provides is a single ordered stream of >>> messages, it suffers from head-of-line blocking (HOLB), meaning >> that >>> all messages must be sent and received in order even if they are >>> independent and some of them are no longer needed. This makes it >> a >>> poor fit for latency sensitive applications which rely on partial >>> reliability and stream independence for performance." >>>=20 >>> The HOLB isn't really entirely the case... RFC6455 ws allows >> arbitrary >>> fragmentation of messages allowing interleaving with control frames. >>>=20 >>=20 >> It allows them to be fragmented, but the fragments have to be in = order. >> The multiplexing extension is mentioned as potential future work in = RFC >> 6455, but I don't believe it ever actually materialized. >=20 > Yes, you can only have one message on the go at a time; in that sense = large messages block it. But it does not block the stream completely = because you can issue control frames inbetween fragments. And although = you may not have control over fragment size since intermediaries can = mess with it, as the sender you do have control over message size which = puts a ceiling on both how long other messages are blocked, and the max = fragment size. You may choose to split a large logical message into = smaller ones so other message content can get a look-in. >=20 > The mux extension stuff was a thing on hybi for a while and then the = main proponent seemed to lose interest with muxed ws vs h2... h2 was = clearly a better result than he could have gotten from ws. >=20 >>> ws-over-h2 allows you to can the h2 stream when you want as well. >>>=20 >>=20 >> True, though you can't use them in the same way as pure QUIC streams >> because QUIC streams are created immediately, whereas a new WS = requires >> a >> handshake. >=20 > Sure... for clarity I also think h1 ws if not competitive itself with = h2 or quic. But it is widely implemented and deployed, and h2 doesn't = have a native equivalent. So it's still kind of keeping its hand in. >=20 >>=20 >>>=20 >>> " Each new stream would require a WebSocket handshake to agree on >>> application protocol used, meaning that it would take at least >> one >>> RTT for each new stream before the client can write to it." >>>=20 >>> Yes it was knowingly done as a hack to try to encourage uptake from >>> browser vendors... it's not really integrated into the encapsulating >>> protocol. >>>=20 >>=20 >> It =3D ws-over-http2 being a thin overlay over existing WSP? >=20 > Yeah. It's implemented in ffox and chrome but not turned on by = default last time I looked. There are few server implementations which = makes it chicken-and-egg. >=20 >>=20 >>>> * WebTransport overview: >>>> https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 >>>> * QuicTransport: >>>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 >>>> * Http3Transport: >>>> https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 >>>=20 >>> There's no h2 transport implementation? >>>=20 >>> Not everything that might want to use this will get h3 capability in >> a >>> reasonable timeframe. If there's more momentum behind it than >> RFC8441 >>> there's probably room for a generic long-lived bidirectional >> extension >>> to h2 either reusing DATA or a new frame type. >>>=20 >>=20 >> I think we might adapt an HTTP/2 transport as well >> (via draft-kinnear-httpbis-http2-transport). >=20 > Sounds good. >=20 >>> It's a good idea to have it ride on other protocols. Not doing this >>> really hurt RFC6455 ws since deploying it usually needed extra, >>> different servers with the attendant difficulties interoperating = with >>> other protocols. >>>=20 >>=20 >> One idea I had is an object called FallbackTransport, that can = simulate >> QUIC semantics on top of WebSocket and be fully polyfillable in >> browsers. >=20 > In this space the problem isn't really ideas but implementation = buy-in. RFC8441 is educational because it was well positioned = politically, the rfc certainly was exemplary for just saying what it = needed to say, it solved a real problem, got some key implementations = yet has still not been able to reach escape velocity. There's some = psychological and architectural gap between ws and http that is much = wider than you would expect for many people (cf h2 addressed every = single h1 + html 5 technology except ws -- and it was not an accidental = oversight). >=20 > RFC8441 went in Chrome... it hasn't been enough by itself. Maybe the = crossover with quic will help your thing over the hump. >=20 >>> I really suggest thinking through the effects of not having an >> RFC6455 >>> type subprotocol (unless I failed to spot it). It really makes an >>> implicit assumption about what the stream will carry that doesn't >> scale >>> beyond one server carrying one thing. That's not how things tend to >> pan >>> out if the protocol is useful. The url path could be hacked to = imply >>> the subprotocol but if that's not standardized it's still a mess.=20 >> And >>> the subprotocol binding may be orthogonal to the url layout >> complicating >>> things needlessly. >>>=20 >>=20 >> That's definitely an open issue with current proposal (some = discussion >> here >> ). The current >> problem >> is that we basically have to choose between either transmitting the >> requested protocol in the open, or paying one extra RTT for the >> protocol >> selection mechanism. >=20 > Usually the guy who directed the client to that server does it knowing = that the server has the subprotocol he wants, unless something has gone = wrong. And it's only client -> server direction pipelining in question; = the server can't send anything until he's had the request and he = definitively decided the negotiated subprotocol by then, or killed the = stream. >=20 > A client that had hot data to send could mark his preferred = subprotocol as being non-neogitiable and start issuing data immediately = after the stream open request... all being well the server allowed the = stream's subprotocol, it lives on and takes the data, in the case it = rejected the subprotocol it closes the stream and discards the data. = The client would have to either fail or retry without the non-neotiable = part to recover if so. But typically, he's only talking to the server = because he's pretty sure it'll talk his subprotocol and it'll work the = first time. >=20 > -Andy -- Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 15 18:04: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 2AC75120106 for ; Thu, 15 Aug 2019 18:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lgDQORHA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WdLaySX3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZL1g6PfPTbj for ; Thu, 15 Aug 2019 18:04:12 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAD41200F3 for ; Thu, 15 Aug 2019 18:04:12 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 7B4445E8; Thu, 15 Aug 2019 21:04:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 15 Aug 2019 21:04:11 -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=fm3; bh=t CsqqWkVdZgyZNBZA/2DUEctLMoLyxW8SZYxc5+tjCY=; b=lgDQORHAoGT6WRJI0 T7Hl5kUlF6SopG+AoMhGxlzrfwc5Irf/RzKNFEFgsdUSSdTnHTUaKfJbQxH0j1R5 uDFBlP54W6U0HlWUK2/N7AQqy9/H3yST40OvaoWu085Bq0Y5Ed/t9PjCAswIasj6 6yi7cgBwgztSIHMoXJHuO1i91so81qGbuAYUMvcI1Y45RIjjyTUPWpauXPfQYx5x F0+2vjj+gEFv5Gtl28spMr+rLiWjXKqJ0oA/Yb0gxMob7sB1iAXrPbhYwXXdtieo KWffMbOIjPrVf6kCRn+nGb2M2hWMGsyGObyJvlnv+80z2kLAdKZgb8r3FEcYluEO FNHPQ== 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=fm3; bh=tCsqqWkVdZgyZNBZA/2DUEctLMoLyxW8SZYxc5+tj CY=; b=WdLaySX3ctKFyfoknUd4Kjma7LfG3D5tj6S0cmZE6o5i/pGrvnaljag/W XZ5MrG5sBWJYJLv4mw3afr5+1eOjw6ZuWrj11CU0gair+OPkd4WiF8BbhAE5xuYQ 5yGK+Qcj8BE82bIdpEWRZelZleNxT94Bq4GwH2iQac2RcwX/ZbUDxSf6TN8FqT+i dHuJa7z07nEN10N5Q05QoFqYV/2Sf3BaB1SWdm0F1KWvXMakcZ3RjETILkYJtrBI AiSRr+VlpPwtJPhKi0n89GovaCSMuoH9gIJBKlRmlYhni2PEzAk5us35w8VDYDCp bHysrkKOhtzWtij/+fdr3GtlpWxKQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefvddggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id BCBD180059; Thu, 15 Aug 2019 21:04:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Consensus Calls on Recent Transport/TLS Issues From: Mark Nottingham In-Reply-To: Date: Fri, 16 Aug 2019 11:04:04 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <72B11C06-AC66-4D24-904B-C94C736D9D97@mnot.net> References: To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.104.11) 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, 16 Aug 2019 01:04:15 -0000 Hearing no pushback, consensus declared. > On 7 Aug 2019, at 8:48 am, Mark Nottingham wrote: >=20 > The following issues have proposals for resolution, and discussion so = far seems to support consensus to accept them. If you object, please do = so on the issue or in response to this message (changing the Subject = appropriately!). Absent any pushback, we'll direct the editors to = incorporate them next week. >=20 > See for the current = state of issues in the Late Stage process, itself defined at = . >=20 > * #2170: Embed QUIC version in expansion > The proposal is to close with no action. >=20 > * #2920: Should server TP encryption be a requirement for the = cryptographic handshake? > The proposal is: >=20 > * #2842: Does it make sense to try 0-RTT after Retry? > The proposal is: >=20 > * #2840: Does rejecting 0-RTT data prohibit ACKing 0-RTT data? > The proposal is: >=20 > * #2825: Exceeding Max STREAM ID should be a connection error > The proposal is: >=20 > * #2805: Rationalize terminology around transport/application = interactions > The proposal is: >=20 > * #2763: Coordinating spin > The proposal is: >=20 > * #2760: NEW_TOKEN should be symmetric > The proposal is to close with no action (although it may be taken up = in post-QUICv1 work) >=20 > * #2685: CC state after a change of path? > The proposal is: >=20 > * #2670: Remove ack_delay_exponent TP > The proposal is to close with no action. >=20 > * #2550: Apply GREASE to transport parameters > The proposal is: >=20 > * #2389: Be clearer about the purpose of disable_migration > The proposal is: >=20 > * #2388: Articulate principles for definition of error codes > The proposal is: >=20 > * #2342: Spoofed connection migration as a DoS vector > The proposal is: >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 15 18:27: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 845AF120106 for ; Thu, 15 Aug 2019 18:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=Pmta2zYB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=puTaqH7t Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAPHCvJlMeeF for ; Thu, 15 Aug 2019 18:27: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 A5458120103 for ; Thu, 15 Aug 2019 18:27:32 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 99E7E201E3 for ; Thu, 15 Aug 2019 21:27:31 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 15 Aug 2019 21:27:31 -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=fm3; bh=xhdVbttA7ULOWnhsXtWy3EfbIJehGz2 FqVGFB6aljN8=; b=Pmta2zYBSc97ZFea8FxaXKY35LEHhxNjDSyxP4ivbGvuq6Z uaE60GjoQtPAS/raeE1uD/qjBO4pwCkzRu7f8z+QNEmRqi9uAUvhJ4loLoQC6id3 ERkwceiL4tjgQEOsCGcBi2qDtD06TZHjJ0ANBKBIVb9xHRF4n6hxinpexmonWfby 5hIDcY4P/RhfZI/pXOqgpDdgqMzXz4asmlwzf6nTQfwBumFm+b6PWbiJzPNpp5ps H2fbsbdd3gfy+FrreM5Gz5LcBcDSUTSueC7rYqDydot/puN0Stt+EU8PL0O2Jl4n XAvLOuZYS72IDZU0eFuviLwHPpuojY9cFFUVajg== 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=fm3; bh=xhdVbt tA7ULOWnhsXtWy3EfbIJehGz2FqVGFB6aljN8=; b=puTaqH7ttwJb13YfQPZ+Yv 6MyHD9BLehhboT1qZ1WQcWiYTVSaHgMTlqRynX7nYpPpUPZ2FF14+NPOow7uT6Qu jWHFcE0Kb9E0OmGUdkWOcwhlVB5XoZROB56CyPEHZNCcVtdGnUrnxR4slY3JcMsF 327xv2vy2baYnPcuDtGRVVWzt2epsO1Y6DLhni72/6448U0echePoykvgqT5Tqpp 4rCzGeO2rBQVScOBC/L0nok+4tXsAkn7buN9EkXIOarFirq351mdmvw+SpWxBG5U u9XaXJ5r9D7f3gfOUpG0CTsRytwi/Ptn929/9G9qJ1qHau3G04r+BXEhkqg4pipg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefvddggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhmnh hothdrnhgvthenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5104FE00A3; Thu, 15 Aug 2019 21:27:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-869-g2d94aad-fmstable-20190814v1 Mime-Version: 1.0 Message-Id: <2c3efcdb-f644-4546-8e0c-3f7339c70d7b@www.fastmail.com> In-Reply-To: <72B11C06-AC66-4D24-904B-C94C736D9D97@mnot.net> References: <72B11C06-AC66-4D24-904B-C94C736D9D97@mnot.net> Date: Fri, 16 Aug 2019 11:27:33 +1000 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Calls on Recent Transport/TLS Issues 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: Fri, 16 Aug 2019 01:27:34 -0000 Thanks Mark. I have merged all the PRs and closed all the issues. On Fri, Aug 16, 2019, at 11:04, Mark Nottingham wrote: > Hearing no pushback, consensus declared. > > > > On 7 Aug 2019, at 8:48 am, Mark Nottingham wrote: > > > > The following issues have proposals for resolution, and discussion so far seems to support consensus to accept them. If you object, please do so on the issue or in response to this message (changing the Subject appropriately!). Absent any pushback, we'll direct the editors to incorporate them next week. > > > > See for the current state of issues in the Late Stage process, itself defined at . > > > > * #2170: Embed QUIC version in expansion > > The proposal is to close with no action. > > > > * #2920: Should server TP encryption be a requirement for the cryptographic handshake? > > The proposal is: > > > > * #2842: Does it make sense to try 0-RTT after Retry? > > The proposal is: > > > > * #2840: Does rejecting 0-RTT data prohibit ACKing 0-RTT data? > > The proposal is: > > > > * #2825: Exceeding Max STREAM ID should be a connection error > > The proposal is: > > > > * #2805: Rationalize terminology around transport/application interactions > > The proposal is: > > > > * #2763: Coordinating spin > > The proposal is: > > > > * #2760: NEW_TOKEN should be symmetric > > The proposal is to close with no action (although it may be taken up in post-QUICv1 work) > > > > * #2685: CC state after a change of path? > > The proposal is: > > > > * #2670: Remove ack_delay_exponent TP > > The proposal is to close with no action. > > > > * #2550: Apply GREASE to transport parameters > > The proposal is: > > > > * #2389: Be clearer about the purpose of disable_migration > > The proposal is: > > > > * #2388: Articulate principles for definition of error codes > > The proposal is: > > > > * #2342: Spoofed connection migration as a DoS vector > > The proposal is: > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > -- > Mark Nottingham https://www.mnot.net/ > > From nobody Thu Aug 15 20:49: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 4AC24120024 for ; Thu, 15 Aug 2019 20:49: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=e9wqrB+Z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dT5nxrAm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LNLL1QHwMje for ; Thu, 15 Aug 2019 20:49:30 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B043120013 for ; Thu, 15 Aug 2019 20:49:30 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 8226A6C0; Thu, 15 Aug 2019 23:49:29 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 15 Aug 2019 23:49: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=fm3; bh=BiZ73RLJpsTTzTF6RHfAKuUlygZ9jg FUvXzIX4TtfHk=; b=e9wqrB+ZVmjyouA1gZPFacLnUeog3EfokcRH7QL9y2Wx3t vXcdF1Wk0P9qufK3LBQDnREaoNalAc/XqOEjwdI1QMvo55OgZ6IboDAoJAWQeHqf BS/Jfj1VVJPZbGK8n14XxjScHEDqfxPp2OXPLzHcvgqIlAG5b1XkvOZBzXLgHvTO 0BJ5rVDXXs0/VdaJ4SylSjMApzfRtRCeHEz8RtKwraxriEZEciT8oPDsdJY6IjcP rrB45hHTEsmeH4qOAXmvxcYcsT2NRLNUe3yPK4HVpx7vCLCfjHcSWpW8XtHwLJQ1 WrTA0jKiTGtQWNQ5/xQBHoq+lahrQCVAoMXpy9ow== 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=fm3; bh=BiZ73R LJpsTTzTF6RHfAKuUlygZ9jgFUvXzIX4TtfHk=; b=dT5nxrAmJjOGPtX0Ww9e4o v/mNHrtd306NrtTG5FxWCHg91MoNU1E88Q4OT8iaEURTGGdKXirqJ5RN7m+v+UrT vuibrpSPSWjD12SJsL7J0B2wI+Nk2sZ6g6hD0z+clFCOo0UZx0kMBiOQKVTIotm0 6NDe31YsvgV4Z3T4CDml9cRDDItrZwNeKVaz+NslgPsyVPbBF5UfIoqeJeHDN7cd IkyATGreNWnAix+Tzhd3bC/qAP57KqzrKDSBNCnO0dgDziYRnuzfCTpejqNiOveQ GOPxGwUzaZ/okIySg5/jPiuQkiOvj+k9NGekC5AtNExoZ1h/y8DFmNNp1KAk2Xlw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefvddgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepfi efrdhorhhgpdhgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtpdhhthhtphefrdhithen ucfkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id B92BD380075; Thu, 15 Aug 2019 23:49:26 -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.11\)) Subject: Call for consensus: HTTP/2 Priorities Message-Id: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> Date: Fri, 16 Aug 2019 13:49:22 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.104.11) 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, 16 Aug 2019 03:49:33 -0000 In Montreal, we had a discussion about priorities, where the outcome was = that people in the room agreed to defer to the HTTP Working Group = regarding whether HTTP/3 should ship with something compatible with = HTTP/2 priorities in it: = https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-p= riorities Since then, the HTTP Working Group has come to consensus that it does = not believe we should do so: https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net This consensus call is to confirm this approach in this WG. In practical = terms, it means we will remove the current HTTP/2-aligned priorities = machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will = ship without any form of priorities; just not this one. Doing so will = resolve a number of outstanding issues, and make way for a replacement = scheme, currently under discussion in a design team in the HTTP Working = Group. Please respond by the middle of next week; we'd like to move forward = with this resolution. Kind regards, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 15 21:18: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 AC293120020 for ; Thu, 15 Aug 2019 21:18:38 -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=eU7QrWFK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nRlA8Ic9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLN2xdDS6s1W for ; Thu, 15 Aug 2019 21:18:36 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C15120013 for ; Thu, 15 Aug 2019 21:18:36 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 769B320222; Fri, 16 Aug 2019 00:18:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 16 Aug 2019 00:18:35 -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=fm3; bh=+N33hJ1dPVALTTtvOsV1nWKl4EVwmS Zb366LshR7vCM=; b=eU7QrWFKN03NsAOH7NXMwblS5TEtxgrMpbwVkMH/v/xTkB iCKW0ie1WMpnPJmsJQzoUPJOjBiUooeDZHTBJj2wzL4hj4a9SJYH4TLJfQ6MF5H+ aF07P+U3KSkmdJWICsrCW/c2dF+2au8HMNysYflu9c+/YJyJgIPM1EfaNojh3OJY jxu7IhNOunoKeTk6kPzCBxEsvqYemuB2SM7N4btnYfJUtdoOHG+pvA/2PQojzGJD qcwu5VrzFOHyxY3TLJ/otPAy5zjq/eysWItKoDDLTVz55KFbrU1YAI6FCeqy07uq oa0aE2pRK07R8J/rU8ImW0QU0OzIASw3xHGA6DIQ== 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=fm3; bh=+N33hJ 1dPVALTTtvOsV1nWKl4EVwmSZb366LshR7vCM=; b=nRlA8Ic9cYXPAqkBET7vF/ axSF1hgtRvhrJfj1qPH/1u35gKbPZaFdjFklXv0sbh+yxZX2fky/R9cy4jssOUk3 gKVXozwwncBx0QdN6I7b1pZU1swhjFQY6Dv03J32Mgntkd0Y2EZg4mWzuty5u8gF VB2JJl5xyqiyNeEzuiIWeGRHEEd+DGFjWezUW0KXfVqNgkfOMeSohCTZsaUTC7hc rsaOX3KsFxT93yqtaRmJ+6xbFf913sLRV0jjNoLGBxRqC7kXigq1KbFleN65kHyF Zr4P18P3hTz1HdC7fhU05byzO19YykVqSrNI2mewWFUQJ9OEyHbCSVb/AZAnzs7w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefvddgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudejhedr vdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id F2A0D8005A; Fri, 16 Aug 2019 00:18:32 -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.11\)) Subject: Consensus Calls on Recent Transport/TLS Issues (again) Message-Id: <8EDCB64E-68BC-4D3C-83CD-7455B3155E88@mnot.net> Date: Fri, 16 Aug 2019 14:18:28 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.104.11) 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, 16 Aug 2019 04:18:39 -0000 The following issues have proposals for resolution, and discussion so = far seems to support consensus to accept them. If you object, please do = so on the issue or in response to this message (changing the Subject = appropriately!). Absent any pushback, we'll direct the editors to = incorporate them next week. See for the current = state of issues in the Late Stage process, itself defined at = . * #2869: Stateless Reset packet sizes should not depend on the maximum = connection ID length The proposal is: * #2834: Long Header Packets and Routing Connection IDs The proposal is to close with no action. * #2770: If you want a Stateless Reset you need to send a larger packet = than before The proposal is: * #2656: Discarding connection state at server on unvalidated client The proposal is to make this an editorial issue. * #2541: Clients cannot abandon Initial packets while server can still = send initial close The proposal is: * #2534: ECN text disables ECN too aggressively The proposal is: * #2205: Largest acked in ACK frame MUST NOT decrease The proposal is: * #2151: Where can you send CONNECTION_CLOSE The proposal is: * #2084: Discuss requirement that connection IDs not be correlatable The proposal is: -- Mark Nottingham https://www.mnot.net/ From nobody Fri Aug 16 00:05: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 DB540120112 for ; Fri, 16 Aug 2019 00:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 vEzbYYdiYpTS for ; Fri, 16 Aug 2019 00:05:40 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 B607A1200FD for ; Fri, 16 Aug 2019 00:05:40 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hyWIs-0005sS-4B; Fri, 16 Aug 2019 09:05:38 +0200 Received: from ti0182q160-2022.bb.online.no ([212.251.170.252] helo=[10.0.0.10]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hyWIq-0007WN-Vv; Fri, 16 Aug 2019 09:05:38 +0200 From: Michael Welzl Message-Id: <92E0FB57-5EAC-4E9B-BC78-7AC0278D1717@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_D56781D9-6EA1-4003-B8BD-0ECDA1E6379F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Blocking Quic traffic Date: Fri, 16 Aug 2019 09:05:36 +0200 In-Reply-To: Cc: Mirja Kuehlewind , "quic@ietf.org" To: Jana Iyengar References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 212.251.170.252 is neither permitted nor denied by domain of ifi.uio.no) client-ip=212.251.170.252; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.10]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: CC98BBA4E5E77A21F44837D76A404AAB5798E3E0 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, 16 Aug 2019 07:05:44 -0000 --Apple-Mail=_D56781D9-6EA1-4003-B8BD-0ECDA1E6379F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So, I wonder - are there any (citable) statistics available on QUIC connection attempt = failures? Cheers, Michael > On Aug 13, 2019, at 10:54 PM, Jana Iyengar wrote: >=20 > Mirja, >=20 > I did a short presentation on this at the interim in London earliier = this year: = https://github.com/quicwg/wg-materials/blob/master/interim-19-05/quic-fire= walls.pdf = >=20 > I don't think we can do very much at the moment. TCP will be used as a = fallback because there is a non-trivial blackhole rate for UDP and QUIC, = and firewalls will block QUIC where they are configured to. I don't = expect these to change... but my expectation remains that the amount of = blocking won't be high enough to matter.=20 >=20 > We should still keep an eye on these firewalls to ensure that when = they do want to block QUIC, that they do it well, and not break any = fallback mechanisms. >=20 > - jana >=20 > On Tue, Aug 13, 2019 at 8:42 AM Mirja Kuehlewind = > = wrote: > Hi all, >=20 > I would like to point the group to the following blog post: >=20 > = https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-re= porting-implications/# = >=20 > And specially the following part of it: >=20 > "Resolving the QUIC issue >=20 > The good news is that if QUIC communication does not work between a = client and a server, the traffic will fall back to traditional = HTTP/HTTPS over TCP, where it can be inspected, controlled, logged and = reported on as usual. >=20 > At the time of writing, the advice from most firewall vendors is to = block QUIC until support is officially added to their products. This = recommended method will vary from firewall to firewall. Some firewalls = allow QUIC by default while others block it by default, but all = firewalls are able to allow or block it. >=20 > Common methods are to block either a defined QUIC protocol, QUIC = application type, or create a firewall rule to block UDP on port 80 and = 443. We suggest you seek guidance from your firewall manufacturer for = recommended actions. >=20 > Here are some guides on blocking QUIC with some popular firewalls: >=20 > How to Block QUIC with SonicWall > How to Block QUIC with Sophos XG > How to Block QUIC with Fortinet Fortigate > How to Block QUIC with Palo Alto Networks > How to Block QUIC with WatchGuard > " >=20 > And also this part: >=20 > "Are there downsides to disabling or blocking QUIC? >=20 > Despite everything above, QUIC is generally a good thing for the world = as it makes web communications more efficient and faster between a = browser and the server, and who doesn=E2=80=99t want their web pages to = load faster, and to have less buffering when watching adorable puppy = videos on YouTube? >=20 > However, the general consensus (at least for now) is that there is no = noticeable difference for the average user when QUIC is enabled. >=20 > The websites will still work, so you might as well choose security = over a tiny increase in performance. > " >=20 > If you look at the blog directly, you will also have links to each = vendor site on how to block quic. My take-away is that we need to be = careful here in order to not further spread the news that QUIC can = simply be blocked as it can fallback to TCP... >=20 > Mirja >=20 >=20 --Apple-Mail=_D56781D9-6EA1-4003-B8BD-0ECDA1E6379F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 So, = I wonder -

are there = any (citable) statistics available on QUIC connection attempt = failures?

Cheers,
Michael


On Aug 13, 2019, at 10:54 PM, = Jana Iyengar <jri.ietf@gmail.com> wrote:

Mirja,

I = did a short presentation on this at the interim in London earliier this = year: https://github.com/quicwg/wg-materials/blob/master/interim-19-0= 5/quic-firewalls.pdf

I don't think we can do very much at the moment. TCP will be = used as a fallback because there is a non-trivial blackhole rate for UDP = and QUIC, and firewalls will block QUIC where they are configured to. I = don't expect these to change... but my expectation remains that the = amount of blocking won't be high enough to matter. 

We should still keep an = eye on these firewalls to ensure that when they do want to block QUIC, = that they do it well, and not break any fallback mechanisms.

- jana

On Tue, Aug 13, 2019 at 8:42 AM Mirja Kuehlewind = <mirja.kuehlewind@ericsson.com> wrote:
Hi all,

I would like to point the group to the following blog post:
=
https://www.fastvue.co/fastvue/blog/googles-quic-protocols-secu= rity-and-reporting-implications/#

And specially the following part of it:

"Resolving the QUIC issue

The good news is that if QUIC communication does not work between a = client and a server, the traffic will fall back to traditional = HTTP/HTTPS over TCP, where it can be inspected, controlled, logged and = reported on as usual.

At the time of writing, the advice from most firewall vendors is to = block QUIC until support is officially added to their products. This = recommended method will vary from firewall to firewall.  Some = firewalls allow QUIC by default while others block it by default, but = all firewalls are able to allow or block it.

Common methods are to block either a defined QUIC protocol, QUIC = application type, or create a firewall rule to block UDP on port 80 and = 443. We suggest you seek guidance from your firewall manufacturer for = recommended actions.

Here are some guides on blocking QUIC with some popular firewalls:

How to Block QUIC with SonicWall
How to Block QUIC with Sophos XG
How to Block QUIC with Fortinet Fortigate
How to Block QUIC with Palo Alto Networks
How to Block QUIC with WatchGuard
"

And also this part:

"Are there downsides to disabling or blocking QUIC?

Despite everything above, QUIC is generally a good thing for the world = as it makes web communications more efficient and faster between a = browser and the server, and who doesn=E2=80=99t want their web pages to = load faster, and to have less buffering when watching adorable puppy = videos on YouTube?

However, the general consensus (at least for now) is that there is no = noticeable difference for the average user when QUIC is enabled.

The websites will still work, so you might as well choose security over = a tiny increase in performance.
"

If you look at the blog directly, you will also have links to each = vendor site on how to block quic. My take-away is that we need to be = careful here in order to not further spread the news that QUIC can = simply be blocked as it can fallback to TCP...

Mirja



= --Apple-Mail=_D56781D9-6EA1-4003-B8BD-0ECDA1E6379F-- From nobody Fri Aug 16 06:52: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 8BDC2120048 for ; Fri, 16 Aug 2019 06:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, 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 WgAcA01U35XP for ; Fri, 16 Aug 2019 06:52:36 -0700 (PDT) Received: from mail-vk1-xa43.google.com (mail-vk1-xa43.google.com [IPv6:2607:f8b0:4864:20::a43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB121201E4 for ; Fri, 16 Aug 2019 06:52:36 -0700 (PDT) Received: by mail-vk1-xa43.google.com with SMTP id b64so1076022vke.13 for ; Fri, 16 Aug 2019 06:52:36 -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=ywZya5M/cnNHZJcjGGeL1I7Jw9/GRZywx1E2vlMGTno=; b=Mz1B6PapWVQOC1VlnzCicqmO2Q24L/gNVs/YEv/6m4NHY7oJkBBVu2FKYRn6Ts+aXi 8Ko0BSLPbCT+G1dvy8BiyFyHWmdy8pJXykpKAHcNwE7l6rr7433QITeTLnIqtVQ/OMR8 XLh8fX4pqJl5s1yqj6jm24uY1aURcv/O8ChpRvjXJlq7LQNvFTzr26NWXh4EiMTWCMsZ j4J2JVB1U592dU9a9TvRC9xW4hBEVFIZElsH9YqMK630qvmVPuJMH5DALMeSntj6QOz5 KaHmxIqWnOZPS+FYetL6Zus/rJ095zbO9mbUD2Fid5qeYhrI9ogODsf3vzR82taWdofv 3KtQ== 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=ywZya5M/cnNHZJcjGGeL1I7Jw9/GRZywx1E2vlMGTno=; b=CPhCGJzOP2Jyc8lySm0kRjdiMhQwbK7RmB24ZRFNqvtOh6N+tlrFVesm5HNnl84lTY +AUJ6rnPpP6E2z8i77hwXgkt4PQfXYGjubxGi/nqt0r7nuPWMWVrawvlTj/Y3W6WZXmZ NVAzwqZgIdcMZ7D+t0rIEpB39iwGkCvhjS2MnfG0KWvusByZz0/IMYYfCiH0HaObaMH2 1VC4TE1fdDmqvx8hqjd+QhQd/IcBSiaTCCrrgtRUe95Dd2oS4C5EjZqhelH6m7Mr4o2J oK1eA4yDZH02r6H6nki96kfG98xBxrzh3EL9zIzLFKPf4pfQ88Xb2Gec+ZVWRf11yvkb P2Ww== X-Gm-Message-State: APjAAAXpg0evm6WX9Y60eqbs93YeKl/1g9FxoFfH1ONq1SWHKqRlmVWq 7Lc78h522BLNOuWOMTZRUo3n72imuleaK9KgugSKZQ== X-Google-Smtp-Source: APXvYqwEQad01q/6nU4Y+60YP2jb7weG1eDkHOdJHFGniYwjbJftaWZEfiOU4GmEcwPo1cAhiqoKJ1MopxboOiP3v9c= X-Received: by 2002:a1f:a194:: with SMTP id k142mr4006235vke.16.1565963555245; Fri, 16 Aug 2019 06:52:35 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <92E0FB57-5EAC-4E9B-BC78-7AC0278D1717@ifi.uio.no> In-Reply-To: <92E0FB57-5EAC-4E9B-BC78-7AC0278D1717@ifi.uio.no> From: Ian Swett Date: Fri, 16 Aug 2019 09:52:24 -0400 Message-ID: Subject: Re: Blocking Quic traffic To: Michael Welzl Cc: Jana Iyengar , "quic@ietf.org" , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="000000000000718e1405903c4d3a" 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, 16 Aug 2019 13:52:40 -0000 --000000000000718e1405903c4d3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See the "QUIC: Does it work?" slide from the QUIC BoF: https://datatracker.ietf.org/meeting/96/materials/slides-96-quic-3 which indicated QUIC worked 93% of the time. These are in line with numbers I've heard from the WebRTC community as well= . On Fri, Aug 16, 2019 at 3:05 AM Michael Welzl wrote: > So, I wonder - > > are there any (citable) statistics available on QUIC connection attempt > failures? > > Cheers, > Michael > > > On Aug 13, 2019, at 10:54 PM, Jana Iyengar wrote: > > Mirja, > > I did a short presentation on this at the interim in London earliier this > year: > https://github.com/quicwg/wg-materials/blob/master/interim-19-05/quic-fir= ewalls.pdf > > I don't think we can do very much at the moment. TCP will be used as a > fallback because there is a non-trivial blackhole rate for UDP and QUIC, > and firewalls will block QUIC where they are configured to. I don't expec= t > these to change... but my expectation remains that the amount of blocking > won't be high enough to matter. > > We should still keep an eye on these firewalls to ensure that when they d= o > want to block QUIC, that they do it well, and not break any fallback > mechanisms. > > - jana > > On Tue, Aug 13, 2019 at 8:42 AM Mirja Kuehlewind < > mirja.kuehlewind@ericsson.com> wrote: > >> Hi all, >> >> I would like to point the group to the following blog post: >> >> >> https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-= reporting-implications/# >> >> And specially the following part of it: >> >> "Resolving the QUIC issue >> >> The good news is that if QUIC communication does not work between a >> client and a server, the traffic will fall back to traditional HTTP/HTTP= S >> over TCP, where it can be inspected, controlled, logged and reported on = as >> usual. >> >> At the time of writing, the advice from most firewall vendors is to bloc= k >> QUIC until support is officially added to their products. This recommend= ed >> method will vary from firewall to firewall. Some firewalls allow QUIC b= y >> default while others block it by default, but all firewalls are able to >> allow or block it. >> >> Common methods are to block either a defined QUIC protocol, QUIC >> application type, or create a firewall rule to block UDP on port 80 and >> 443. We suggest you seek guidance from your firewall manufacturer for >> recommended actions. >> >> Here are some guides on blocking QUIC with some popular firewalls: >> >> How to Block QUIC with SonicWall >> How to Block QUIC with Sophos XG >> How to Block QUIC with Fortinet Fortigate >> How to Block QUIC with Palo Alto Networks >> How to Block QUIC with WatchGuard >> " >> >> And also this part: >> >> "Are there downsides to disabling or blocking QUIC? >> >> Despite everything above, QUIC is generally a good thing for the world a= s >> it makes web communications more efficient and faster between a browser = and >> the server, and who doesn=E2=80=99t want their web pages to load faster,= and to >> have less buffering when watching adorable puppy videos on YouTube? >> >> However, the general consensus (at least for now) is that there is no >> noticeable difference for the average user when QUIC is enabled. >> >> The websites will still work, so you might as well choose security over = a >> tiny increase in performance. >> " >> >> If you look at the blog directly, you will also have links to each vendo= r >> site on how to block quic. My take-away is that we need to be careful he= re >> in order to not further spread the news that QUIC can simply be blocked = as >> it can fallback to TCP... >> >> Mirja >> >> >> > --000000000000718e1405903c4d3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
See the "QUIC: Does it work?" slide from the QUI= C BoF:=C2=A0https://datatracker.ietf.org/meeting/96/materials/slides-96= -quic-3=C2=A0which indicated QUIC worked 93% of the time.

These are in line with numbers I've heard from the WebRTC communi= ty as well.

On Fri, Aug 16, 2019 at 3:05 AM Michael Welzl <michawe@ifi.uio.no> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
So, I wonder -

are there any (citable) s= tatistics available on QUIC connection attempt failures?

Cheers,
Michael


On Aug 13, 2019, at 10:54 PM, Jana Iyengar <jri.ietf@gmail.com&g= t; wrote:

Mirja,

I did a = short presentation on this at the interim in London earliier this year:=C2= =A0https://github.com/quicwg/wg-mate= rials/blob/master/interim-19-05/quic-firewalls.pdf

=
I don't think we can do very much at the moment. TCP will be used = as a fallback because there is a non-trivial blackhole rate for UDP and QUI= C, and firewalls will block QUIC where they are configured to. I don't = expect these to change... but my expectation remains that the amount of blo= cking won't be high enough to matter.=C2=A0

We= should still keep an eye on these firewalls to ensure that when they do wa= nt to block QUIC, that they do it well, and not break any fallback mechanis= ms.

- jana

On Tue, Aug 13, 2019 at 8:42 AM Mi= rja Kuehlewind <mirja.kuehlewind@ericsson.com> wrote:
Hi all,

I would like to point the group to the following blog post:

http= s://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporti= ng-implications/#

And specially the following part of it:

"Resolving the QUIC issue

The good news is that if QUIC communication does not work between a client = and a server, the traffic will fall back to traditional HTTP/HTTPS over TCP= , where it can be inspected, controlled, logged and reported on as usual.
At the time of writing, the advice from most firewall vendors is to block Q= UIC until support is officially added to their products. This recommended m= ethod will vary from firewall to firewall.=C2=A0 Some firewalls allow QUIC = by default while others block it by default, but all firewalls are able to = allow or block it.

Common methods are to block either a defined QUIC protocol, QUIC applicatio= n type, or create a firewall rule to block UDP on port 80 and 443. We sugge= st you seek guidance from your firewall manufacturer for recommended action= s.

Here are some guides on blocking QUIC with some popular firewalls:

How to Block QUIC with SonicWall
How to Block QUIC with Sophos XG
How to Block QUIC with Fortinet Fortigate
How to Block QUIC with Palo Alto Networks
How to Block QUIC with WatchGuard
"

And also this part:

"Are there downsides to disabling or blocking QUIC?

Despite everything above, QUIC is generally a good thing for the world as i= t makes web communications more efficient and faster between a browser and = the server, and who doesn=E2=80=99t want their web pages to load faster, an= d to have less buffering when watching adorable puppy videos on YouTube?
However, the general consensus (at least for now) is that there is no notic= eable difference for the average user when QUIC is enabled.

The websites will still work, so you might as well choose security over a t= iny increase in performance.
"

If you look at the blog directly, you will also have links to each vendor s= ite on how to block quic. My take-away is that we need to be careful here i= n order to not further spread the news that QUIC can simply be blocked as i= t can fallback to TCP...

Mirja



--000000000000718e1405903c4d3a-- From nobody Fri Aug 16 15:07: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 197A712008B for ; Fri, 16 Aug 2019 15:07: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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyWErHJdaF7D for ; Fri, 16 Aug 2019 15:07:50 -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 D86CE120018 for ; Fri, 16 Aug 2019 15:07:49 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id u15so6586438ljl.3 for ; Fri, 16 Aug 2019 15:07:49 -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=0KvDtQNTNpV4ZeWmB8N5RtiVFfi9c16pgTIDijf3V78=; b=dnxw8bV65KyV4e1ZMsKPCd30qGQFUsUlHWgJFbqOcc0RTU2Grljylcc7Ct7gOW4XsE JI9Ch30yuHVSZPB46dYeUYIGwBqBDrzTfCvyfUBdzqlDuXLAkPk6nL/GKMKijQP4Yaci D6MLGLIyX8yZPHdRSaGW9rkwHESHZCH7yAF1lAYKFqt6XWBWX8Bm9EA6Q0VFhMZ3dMRh I3Aphs0dVoRIwYf/zYMGHKoPWeV4DuFHECjhG/jbNdowPoZBCHg576CG/Rfs//JH5L6T djmoYtIG5tcwZwXkzGvcqS1PGeZBTNKpSSvDea5hZzR2Qm4lmfyozqotL/n9mttLtrd2 flBg== 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=0KvDtQNTNpV4ZeWmB8N5RtiVFfi9c16pgTIDijf3V78=; b=ttUU3CIxPdrrPbfkwMZqIPpoAg9FYNDuJPAsRHFnOD5O7ENRZu4c5UxviQgyFjvEw/ vo2BnX5NDXijgT8075o/5qLzxYWnsWt6L91iJDyOqCMK9syEnIs8H+wRW9fe1OmGR9PB hb4k0jL2xTgFEk0EGZfLZfbAUnCmH1/9c4HvGIceyHLbDGzA+vsonNaITlfCVkzhxok+ WMZlfeAYF8XXnxVSa3QfgzZx27+gH6DwSnaWTQAlshj7RBbI48+mTuQcY0pswr4cK5DS rXW3SDuoBT34F04ZLatydh7aRxr194CTaOiCafL/JTIiAATX6XvNcuwcCm/d3DPkYuMz H3sg== X-Gm-Message-State: APjAAAV5nFrGN9LNVznp+kkmgEzRA+4JPnRu0BvuGMk1wWa8JDJCnslF KhePS5Egv8pODThiUWtLmiZ2EiEGymM924qSWys= X-Google-Smtp-Source: APXvYqzabRV9L+Tfhh8ngk63H8WPjvg6GiqvQ4lN4j27hcB2d0LDPeV+L/IeYqZ9ZavSFrjZZxL7lOI7GbA5SdaqlZ8= X-Received: by 2002:a2e:8744:: with SMTP id q4mr6590373ljj.77.1565993267928; Fri, 16 Aug 2019 15:07:47 -0700 (PDT) MIME-Version: 1.0 References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> In-Reply-To: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> From: Jana Iyengar Date: Fri, 16 Aug 2019 15:07:37 -0700 Message-ID: Subject: Re: Call for consensus: HTTP/2 Priorities To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="00000000000074a27105904338e1" 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, 16 Aug 2019 22:07:52 -0000 --00000000000074a27105904338e1 Content-Type: text/plain; charset="UTF-8" +1 to removing the current priorities from HTTP/3. On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham wrote: > In Montreal, we had a discussion about priorities, where the outcome was > that people in the room agreed to defer to the HTTP Working Group regarding > whether HTTP/3 should ship with something compatible with HTTP/2 priorities > in it: > > https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-priorities > > Since then, the HTTP Working Group has come to consensus that it does not > believe we should do so: > https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net > > This consensus call is to confirm this approach in this WG. In practical > terms, it means we will remove the current HTTP/2-aligned priorities > machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will ship > without any form of priorities; just not this one. Doing so will resolve a > number of outstanding issues, and make way for a replacement scheme, > currently under discussion in a design team in the HTTP Working Group. > > Please respond by the middle of next week; we'd like to move forward with > this resolution. > > Kind regards, > > -- > Mark Nottingham https://www.mnot.net/ > > --00000000000074a27105904338e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to removing the current priorities from HTTP/3.

On T= hu, Aug 15, 2019 at 8:49 PM Mark Nottingham <mnot@mnot.net> wrote:
In Montreal, we had a discussion about priorities, where= the outcome was that people in the room agreed to defer to the HTTP Workin= g Group regarding whether HTTP/3 should ship with something compatible with= HTTP/2 priorities in it:
=C2=A0 https://gi= thub.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-priorities

Since then, the HTTP Working Group has come to consensus that it does not b= elieve we should do so:
=C2=A0 https://www.w3.org/mid/00= CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net

This consensus call is to confirm this approach in this WG. In practical te= rms, it means we will remove the current HTTP/2-aligned priorities machiner= y from HTTP/3. It does NOT necessarily mean that HTTP/3 will ship without a= ny form of priorities; just not this one. Doing so will resolve a number of= outstanding issues, and make way for a replacement scheme, currently under= discussion in a design team in the HTTP Working Group.

Please respond by the middle of next week; we'd like to move forward wi= th this resolution.

Kind regards,

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

--00000000000074a27105904338e1-- From nobody Sat Aug 17 05:09: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 3A927120106 for ; Sat, 17 Aug 2019 05:09:30 -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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvNX4vBNpnyf for ; Sat, 17 Aug 2019 05:09:29 -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 A18FA12010E for ; Sat, 17 Aug 2019 05:09:28 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id r12so7343153edo.5 for ; Sat, 17 Aug 2019 05:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=anwPj4PltZ+abKm3TVXIdp2TirBlN9bpoVSz0cwByxI=; b=eDRLxOHx3Tj2sUup8ZvNyga0ZlF5TDCyY7d4wQCl5YeZFjDuW43QNNpUUZf4eLneRL +yGNKEsafeE3lll/gDk2UZJbwGX5zHeiLkZLSbaXEL8r/j6+NUoy3+aX2K+SgDDC74Zp StaSBpbELX4NJdyJ9C7S9gUwiQCikf6Zbpoq+nUxGQxRgHJPuJLlKjVcfiLxszzUohs9 pdJ0ED8GQHiCtR1KL4Y+ox50xAvN/YMoamjC696ynYtOJQLVjC9UuYOf1T5vLXgcEzeP /eHyxfVK1dcXu9jfZJ4vsCsH2m9Vqpa0Cmz+YGAYyYvAxLVxly6fdnK9+eGlKVs8fzKU DSGQ== 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=anwPj4PltZ+abKm3TVXIdp2TirBlN9bpoVSz0cwByxI=; b=Xm9/C02FuEOR38a9GhPtMa9DQF83yYYJVnCO4XHC2TtGARwOoKTkRLhrJnB737zSx8 buwjhyRxi5vHhfOkvG5MwwpHUFLTQ++moFCoaRIB2tZEcMxZDw05F6syLaUcvDfWAOsa 0xvHTBW0kckIxR9GU394o9EwUTe6yHzBMxSIXYPYsPs8ZgZzImM5YkYDmoUxA1WXE8e2 ttcw4mgGkbFZgpO8lmhG8MzzWIT6plAQD0wUU/JinkKpbPyWSo70/6ba9x/F6SX0Fqjr yjQ0Z93Zl4Nnf4irpj4hPfTeobu8Lob3EbwTBE7Qh9Gx15ifYxKJdCG58DgW2eMmgjnF +NyQ== X-Gm-Message-State: APjAAAUAXT/R3h2aoSB/ubI7n+CB6NnHCDHa1kS037EYl+jtIRBzq+4N IuwFEserWTpmKLDh0wUIMdcc8iKwmd/Hgf8wlIU= X-Google-Smtp-Source: APXvYqwidyFcudDk42PSo0gkps9OiaAlvr13JRt6UDsCkgTpHEgaviJ7M2gYgmZB59tluBpdQqVh+/oE4Q6oJlfsbxA= X-Received: by 2002:a50:b635:: with SMTP id b50mr15654624ede.293.1566043767292; Sat, 17 Aug 2019 05:09:27 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 17 Aug 2019 08:09:26 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 17 Aug 2019 08:09:26 -0400 Message-ID: Subject: Re: Call for consensus: HTTP/2 Priorities To: Jana Iyengar , Mark Nottingham Cc: Lars Eggert , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000073c8f305904efa62" 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, 17 Aug 2019 12:09:30 -0000 --00000000000073c8f305904efa62 Content-Type: text/plain; charset="UTF-8" +1 On 17 August 2019 at 00.08.06, Jana Iyengar (jri.ietf@gmail.com) wrote: +1 to removing the current priorities from HTTP/3. On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham > wrote: > In Montreal, we had a discussion about priorities, where the outcome was > that people in the room agreed to defer to the HTTP Working Group regarding > whether HTTP/3 should ship with something compatible with HTTP/2 priorities > in it: > > https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-priorities > > Since then, the HTTP Working Group has come to consensus that it does not > believe we should do so: > https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net > > This consensus call is to confirm this approach in this WG. In practical > terms, it means we will remove the current HTTP/2-aligned priorities > machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will ship > without any form of priorities; just not this one. Doing so will resolve a > number of outstanding issues, and make way for a replacement scheme, > currently under discussion in a design team in the HTTP Working Group. > > Please respond by the middle of next week; we'd like to move forward with > this resolution. > > Kind regards, > > -- > Mark Nottingham https://www.mnot.net/ > > --00000000000073c8f305904efa62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = +1


On 17 August 2019 at 00.08.06, Jana Iyengar (jri.ietf@gmail.com) wrote:

+1 to removing the current priorities from HTTP/3.

On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham <mnot@mnot.net>= wrote:
In Montreal, we had a discussion about priorities, where the outcome was that people in the room agreed to defer to the HTTP Working Group regarding whether HTTP/3 should ship with something compatible with HTTP/2 priorities in it:
=C2=A0 https://gi= thub.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-priorities

Since then, the HTTP Working Group has come to consensus that it does not believe we should do so:
=C2=A0 https://www.w3.org/mid/00= CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net

This consensus call is to confirm this approach in this WG. In practical terms, it means we will remove the current HTTP/2-aligned priorities machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will ship without any form of priorities; just not this one. Doing so will resolve a number of outstanding issues, and make way for a replacement scheme, currently under discussion in a design team in the HTTP Working Group.

Please respond by the middle of next week; we'd like to move forward with this resolution.

Kind regards,

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

--00000000000073c8f305904efa62-- From jesk78@errxtx.net Sat Aug 17 06:25: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 958D6120072 for ; Sat, 17 Aug 2019 06:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=errxtx-net.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 Wf5lzR-hkfen for ; Sat, 17 Aug 2019 06:25:36 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90381120111 for ; Sat, 17 Aug 2019 06:25:36 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id w20so7432763edd.2 for ; Sat, 17 Aug 2019 06:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=errxtx-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BEqPTQ7r/4uES1qxAyGnL2RkDrqSQQydINg3TgpQb/o=; b=oFiFe8Od6MOfKqFdypzWAomt6L+9kUqtjO4BPYXiG9BNLlAmnPUkOMCK4ZePlB8KhH a5+P7OzugpYCgSakLSG9c0370J4QlZRtMFnH5rItQHIbXlNaBnmDZSs6nFG4YJtLMn2n J4S9zFJEABsAfDbKuMf8URtdMzcSlQE11KbR0pskAN+PaID5U+Vao2yJJ5UALkrvtD2M YYgO5LH9sqN/GhSvC9I313hbCx5dFOK3W3UeoR/BsKi97205aahZN15Mf/IcKLmXUcKF AODrvrxLEUPGgpPdyQZv8CcOMNrbpWJQuG4QjHVk0ys0hVt4CBnxtpKVn+Qi2SXb3Nx7 PGzQ== 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=BEqPTQ7r/4uES1qxAyGnL2RkDrqSQQydINg3TgpQb/o=; b=KTPPCaPfqXi6dV2s4MXcDjvNr3eeprPsSClue1RsaCoRqXKaWzFn7dKZFzdDcBasOs Px/MS9KEH37ApG91JzClR6EwrQC7lFwE9iojXZg5fGkzhWoBikDW0vRf8FXwJNaLEAVm wuT19lRnmoeY3XXzRmdvo4Q1FZuApZK3xsWPlQ4yd8RFyU2UYHxXb0iF3paLRHrBzWSv TC7xeGUb/kV0giKcMXX+Vxq9rVFnURKMLGgaGob813JuCC4tnpxdtuMBbQQM5leToLuq fZarkl/qmWQlMPTQQTcaYz70J4YKETc+Dxdgzvd/Nh1poxCGFEF3pZeiZncax1cywF0k f2Zw== X-Gm-Message-State: APjAAAWxsd11PBoICQEVutNDzTzTlIgkn6SUlRq+c+HhAy8n9TeZpfFn AprrIAqfMYlMulN42e/5rr3cGE8mcpl5vDTElXvv1Mtm X-Google-Smtp-Source: APXvYqzmS6iyK0OkSgGryLF3HLv43okSBRLXPRVkkDAzrWNCJ2W2mcQOm0mdD1h340au2MTyeaRyT04ooNwOiy9Pm9c= X-Received: by 2002:a17:906:e0cd:: with SMTP id gl13mr13381210ejb.52.1566048334762; Sat, 17 Aug 2019 06:25:34 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> In-Reply-To: From: Christian Meutes Date: Sat, 17 Aug 2019 15:25:23 +0200 Message-ID: Subject: Re: Blocking Quic traffic To: Ian Swett Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b1ebd50590500a41" 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, 17 Aug 2019 13:27:00 -0000 --000000000000b1ebd50590500a41 Content-Type: text/plain; charset="UTF-8" Hi, On Tue 13. Aug 2019 at 21:41, Ian Swett wrote: > One aspect of that article is very misleading. For years Google and > YouTube have been served via HTTPS, so the following statement is not > specific to QUIC: > "From a reporting perspective, this means you cannot log and report on the > full URLs of QUIC traffic, such as Google Search or YouTube, meaning search > term alerts, or viewing a list of YouTube videos watched is not possible > when QUIC is enabled." > my guess is that the authors statement contextually relates to fully controlled corporate environments where MITM via HTTPS spoofing middleboxes is an unfortunate but widely lived reality. --000000000000b1ebd50590500a41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue 13. Aug 2019 at 21:41, Ian Swet= t <ianswett=3D40google.co= m@dmarc.ietf.org> wrote:
One aspect of that article is=C2=A0very misleading.=C2=A0 Fo= r years Google and YouTube have been served via HTTPS, so the following sta= tement is not specific to QUIC:
"From a reporting perspectiv= e, this means you cannot log and report on the full URLs of QUIC traffic, s= uch as Google Search or YouTube, meaning search term alerts, or viewing a l= ist of YouTube videos watched is not possible when QUIC is enabled."

my gue= ss is that the authors statement contextually relates to fully controlled c= orporate environments where MITM via HTTPS spoofing middleboxes is an unfor= tunate but widely lived reality.

=
--000000000000b1ebd50590500a41-- From nobody Sat Aug 17 06:54: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 9118C120072 for ; Sat, 17 Aug 2019 06:54: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 YqFXzNjclDhT for ; Sat, 17 Aug 2019 06:54:16 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5812D12002E for ; Sat, 17 Aug 2019 06:54:16 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id u15so7746297ljl.3 for ; Sat, 17 Aug 2019 06:54:16 -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; bh=qWkuSEu/1gVbJm9GAC9uwDxHXZn7w+JlI+cat0k4AZs=; b=pCdzzr5CD1xuzMFkmXidYB9OWP+kYCqYDvBZQi6ytvDbAVaxtFN6idq167pK1mD+2O TgSDcbUIXhIkdofnueDqswElPMJebshAoXRMUvuFSIe1eGeV4/7tq+bsYC+LQGUz2aQo P+glNkKc8Giu5qyZic8pfZBm5sLgSUhTtMXk8= 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=qWkuSEu/1gVbJm9GAC9uwDxHXZn7w+JlI+cat0k4AZs=; b=Vk+06Wd3mISYFIwISjb4LzmY1epA9wWeoCZS9xNQbcM7F2y4TUqlfGVhMPFGooDERj zulE/fqARzazgD8PmRysFpboaipXmO6HZdAJ7Pwxon53STHmHhr35rwnu5h4dhdimQO3 i75LY7ftlsToE4D2J8GNW/zjZ071/jo23oA/3NDbSVDY6n0xpl/Ym9aa6KXH4cPjo12o uy0SxaGTw1gDC4Xcsn8pDiRWflVZYKJeWNRX189RvEB23CFZ/2wOnNTNeVKHEx2Jd0PR uV9kAPfCpL0AmfnFS94Sk6Rxd98M22Ykyh2n+Cgap8zufTGXLE3dsknuX9dbdMY5Zpx5 bVnw== X-Gm-Message-State: APjAAAUhr8aGW/nXACS3lr6V/3MQM/ikA0tpGMXh5v3Cg7hF8tHnep4O 5hjpPD0ESsDRaUxVQgWnwqsCrhtPt7S73X8Tla7mzVrtjmc= X-Google-Smtp-Source: APXvYqzfGIU9VoCnpAtNSvEcyUqUC5+xIyA6NYd2AJnAmKw3mUyUpQweS7ZQRY/PJ4RV5lZuD/pxBK862Nig7NQ1Hq8= X-Received: by 2002:a2e:81cb:: with SMTP id s11mr7954925ljg.179.1566050053338; Sat, 17 Aug 2019 06:54:13 -0700 (PDT) MIME-Version: 1.0 References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> In-Reply-To: From: Robin MARX Date: Sat, 17 Aug 2019 15:54:03 +0200 Message-ID: Subject: Re: Call for consensus: HTTP/2 Priorities To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000002151e505905071b2" 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, 17 Aug 2019 13:54:21 -0000 --0000000000002151e505905071b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At the risk of repeatedly screaming into the void: I do not have a problem with the removal of HTTP/2-style priorities per se. The setup is certainly quite complex and can be simplified in terms of implementation. However, the dependency tree is also very flexible and able to represent a wide variety of different prioritization schemes. That this flexibility has been severely under-utilized to this day, does not necessarily mean it's not needed in my opinion. And sure, we can drop it now, ship with something simple, and move to a more complex/flexible setup again down the road once we have more insights. However, that latter point is still not what seems to be on the table here. I still feel like we're proposing dropping priorities completely right now and -maybe-, just maybe (NOT *necessarily *as Mark says*)* shipping H3 with some form of priorities on-board (i.e., "priorities should not block H3"). The way I see this going forward is that many people just won't bother implementing any prioritization concept until it's clear what will end up chosen (and it's in the spec). Consequently, people will keep testing QUIC stack performance without caring about multiplexing (much): downloading a single file over a single stream, which imo is only part of the equation. I see us ending up with shipped implementations that don't have decent prioritization support, this time not because they can't be bothered to implement a dependency tree, but simply because nobody told them they should. Thus we run the risk of H3 performing worse than H2. As such, I am not really in favor of removing priorities from the spec until we have a replacement. Or if we do, I feel priorities should block H3 (even if it's just for a simplified setup). I really feel we're sticking our heads in the sand on this. We've been ignoring HTTP priorities for too long (otherwise we wouldn't be in this current mess). Next to that, we've also been ignoring QUIC-level priorities (with the very vague https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-2.3 as only indication). I've asked this of multiple implementers on multiple occasions and no one had a concrete idea of how they will/should be mapping application-layer priorities to QUIC stream priorities yet. People seem to expect this to somehow resolve itself or that it can be bolted on as an afterthought, and maybe it will/can, but I doubt it. The only other conclusion I can draw from all this, is that priorities don't really matter in the big picture. I certainly see enough indicators to that end. For example Microsoft Edge not bothering to use them in the first place. For example browsers not seeming to a/b test optimal approaches for over 4 years. For example, some people advocating that "passive" resource request order + content-type is enough of a signal in itself to provide good page loading performance. For example, people proposing not letting them block H3. This viewpoint is 100% contradictory to my own prioritization research and my understanding of current web page building techniques. Maybe I'm missing things others take for granted. Maybe I'm making mistakes. Maybe priorities are not the cornerstone of a multiplexed protocol that I view them to be. In that case, by all means go ahead and continue down this proposed route, as it indeed seems the best way forward. If not: please give them the attention they deserve. With best regards, Robin On Sat, 17 Aug 2019 at 14:10, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > +1 > > > On 17 August 2019 at 00.08.06, Jana Iyengar (jri.ietf@gmail.com) wrote: > > +1 to removing the current priorities from HTTP/3. > > On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham > wrote: > >> In Montreal, we had a discussion about priorities, where the outcome was >> that people in the room agreed to defer to the HTTP Working Group regard= ing >> whether HTTP/3 should ship with something compatible with HTTP/2 priorit= ies >> in it: >> >> https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3= -priorities >> >> Since then, the HTTP Working Group has come to consensus that it does no= t >> believe we should do so: >> https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net >> >> This consensus call is to confirm this approach in this WG. In practical >> terms, it means we will remove the current HTTP/2-aligned priorities >> machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will shi= p >> without any form of priorities; just not this one. Doing so will resolve= a >> number of outstanding issues, and make way for a replacement scheme, >> currently under discussion in a design team in the HTTP Working Group. >> >> Please respond by the middle of next week; we'd like to move forward wit= h >> this resolution. >> >> Kind regards, >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> --=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 --0000000000002151e505905071b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the risk of repeatedly screaming into the void:
I do not have a problem with the removal of HTTP/2-style priori= ties per se. The setup is certainly quite complex and can be simplified in = terms of implementation.
However, the dependency tree is also ver= y flexible and able to represent a wide variety of different prioritization= schemes.
That this flexibility has been severely under-utilized = to this day, does not necessarily mean it's not needed in my opinion.= =C2=A0
And sure, we can drop it now, ship with something simple, = and move to a more complex/flexible setup again down the road once we have = more insights.=C2=A0

However, that latt= er point is still not what seems to be on the table here. I still feel like= we're proposing dropping priorities completely right now and -maybe-,= =C2=A0
just maybe (NOT=C2=A0necessarily as Mark says) shipping H3 with some form of priorities on-board (i.e., "prioritie= s should not block H3"). The way I see this going forward=C2=A0
<= div>is that many people just won't bother implementing any prioritizati= on concept until it's clear what will end up chosen (and it's in th= e spec).=C2=A0
Consequently, people will keep testing QUIC stack = performance without caring about multiplexing (much): downloading a single = file over a single stream,=C2=A0
which imo is only part of the eq= uation. I see us ending up with shipped implementations that don't have= decent prioritization support, this time not because they can't=C2=A0<= /div>
be bothered to implement a dependency tree, but simply because no= body told them they should. Thus we run the risk of H3 performing worse tha= n H2.=C2=A0

As such, I am not really in favor of r= emoving priorities from the spec until we have a replacement. Or if we do, = I feel priorities should block H3 (even if it's just for a simplified s= etup).


I really feel we're stic= king our heads in the sand on this. We've been ignoring HTTP priorities= for too long (otherwise we wouldn't be in this current mess). Next to = that,
we've also been ignoring QUIC-level priorities (with th= e very vague=C2=A0https://tools.ietf.org/html/draft-ietf-quic-transpo= rt-22#section-2.3=C2=A0as only indication). I've asked this
of multiple implementers on multiple occasions and no one had a concrete= idea of how they will/should be mapping application-layer priorities to QU= IC stream priorities yet.=C2=A0
People seem to expect this to som= ehow resolve itself or that it can be bolted on as an afterthought, and may= be it will/can, but I doubt it.=C2=A0

The only oth= er conclusion I can draw from all this, is that priorities don't really= matter in the big picture. I certainly see enough indicators to that end. = For example Microsoft Edge
not bothering to use them in the first= place. For example browsers not seeming to a/b test optimal approaches for= over 4 years. For example, some people advocating that "passive"=
resource request order=C2=A0+ content-type is enough of a signal= in itself to provide good page loading performance. For example, people pr= oposing not letting them block H3.=C2=A0
This viewpoint is 100% c= ontradictory to my own prioritization research and my understanding of curr= ent web page building techniques. Maybe I'm missing things others take = for=C2=A0
granted. Maybe I'm making mistakes. Maybe prioritie= s are not the cornerstone of a multiplexed protocol that I view them to be.= In that case, by all means go ahead and continue=C2=A0
down this= proposed route, as it indeed seems the best way forward. If not: please gi= ve them the attention they deserve.

With best rega= rds,
Robin=C2=A0


On Sat, 17 Aug 2019 at 14:10= , Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
+1


On 17 August 2019 at 00.08.06, Jana Iyengar (jri.ietf@gmail.com) wrote:

+1 to removing the current priorities from HTTP/3.

On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham <mno= t@mnot.net> wrote:
In Montreal, we had a discussion about priorities, where the outcome was that people in the room agreed to defer to the HTTP Working Group regarding whether HTTP/3 should ship with something compatible with HTTP/2 priorities in it:
=C2=A0 https://gi= thub.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-priorities

Since then, the HTTP Working Group has come to consensus that it does not believe we should do so:
=C2=A0 https://www.w3.org/mid/00= CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net

This consensus call is to confirm this approach in this WG. In practical terms, it means we will remove the current HTTP/2-aligned priorities machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will ship without any form of priorities; just not this one. Doing so will resolve a number of outstanding issues, and make way for a replacement scheme, currently under discussion in a design team in the HTTP Working Group.

Please respond by the middle of next week; we'd like to move forward with this resolution.

Kind regards,

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



--

<= td style=3D"font-family:Verdana,Geneva,sans-serif">Agoralaan Gebouw D - = B-3590 Diepenbeek --0000000000002151e505905071b2-- From nobody Sat Aug 17 07:10: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 4290C12004A for ; Sat, 17 Aug 2019 07:10:41 -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_HELO_NONE=0.001, 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 SKxWR3lZUPTO for ; Sat, 17 Aug 2019 07:10:38 -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 E032912002E for ; Sat, 17 Aug 2019 07:10:37 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id z11so4260046wrt.4 for ; Sat, 17 Aug 2019 07:10:37 -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=itlyVit/83ShGA9UlMZCc+bkIXSGJ83XTNb9MLAYM8Q=; b=DEw6f5pXHC81kVDT63go/vDAVKCUpAcUlLzEbSz/tPBq/4kAU7sDeR0fXhE9YztxBx SnVpAObLbYH5K8iFeH41FypzEuI4zWlKPZLpiCmXYilrjK9tSf2FBVYHxGs1+riRYDOj uBtbtiKq+7Yn6i4RHLcJ+RJi1IVguJSW+zNWCDeeCLrIqjkk8IqlgDdcK6aW+AP31/1y ZsN1STf3VYJeK/j7eEbjnKJIEVIRrr/AlgJfMwZhsiH56/pi1cAhoOBT87Mtn3BBMixg 01ajdNpWW7lDP0cAtZmOikJZ7T160blLgq7nPoXsA3ss5nHPn4lWbyZrQUU+xr0XEpwM z1lg== 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=itlyVit/83ShGA9UlMZCc+bkIXSGJ83XTNb9MLAYM8Q=; b=LNH5/dooLpZ+19wgkUVfXt0aH34/2KvVd0CQyqrR3MTk1f/yP6BOofCLbR35pKFQ7e x1G2LqIMMD6522k+i5yWQND9cHVkgXolTkD5H1e3vSDbRTqdfuiHWzR7L1c7W1hm+29p sLgdLZ7D36MmnMscfKffG2I68ewt7EPz4ho+JFPa59I6ObATNstHbzKLzoQqmoJ8S1G6 Kj7SAuSdiFrWfqv50Z0hm8DSsJUdChChg4LYZgmHndFb/ZT1OORSUWiRK6XQuI4ikbtD lQZGDmm+/uM/U8TedjMaFIzzHoMkL/pn/kpi92rWFfKRSFHmsLgW18ug0fk446vKFRe+ 0EAg== X-Gm-Message-State: APjAAAX98EFW67GEHn8jGb91lxcUh3xXGNkWEG4SQ4DlBySliW+GCjXQ N/mmb0oW9vu4UwgXWeypcIrBz96if/BRE2A5rZm9hw== X-Google-Smtp-Source: APXvYqxJq8phfl/vGmw7voOgyb4oDZ8I+kRi0Kded2Ug9Ukcv+Nlr6jNWdKZOolaRqEruk+p+MB7ywGyELQcDBge+FQ= X-Received: by 2002:adf:afe7:: with SMTP id y39mr16110935wrd.350.1566051035953; Sat, 17 Aug 2019 07:10:35 -0700 (PDT) MIME-Version: 1.0 References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> In-Reply-To: From: Ryan Hamilton Date: Sat, 17 Aug 2019 07:10:23 -0700 Message-ID: Subject: Re: Call for consensus: HTTP/2 Priorities To: Robin MARX Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b33b01059050ab69" 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, 17 Aug 2019 14:10:41 -0000 --000000000000b33b01059050ab69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with the proposal of removing HTTP/2 priorities from HTTP/3. HTTP/2 Priorities are overly complicated for the task at hand (as the implementation experience with HTTP/2 suggests). I look forward to the priority design team's output. On Sat, Aug 17, 2019 at 6:54 AM Robin MARX wrote: > At the risk of repeatedly screaming into the void: > > I do not have a problem with the removal of HTTP/2-style priorities per > se. The setup is certainly quite complex and can be simplified in terms o= f > implementation. > However, the dependency tree is also very flexible and able to represent = a > wide variety of different prioritization schemes. > That this flexibility has been severely under-utilized to this day, does > not necessarily mean it's not needed in my opinion. > And sure, we can drop it now, ship with something simple, and move to a > more complex/flexible setup again down the road once we have more insight= s. > > However, that latter point is still not what seems to be on the table > here. I still feel like we're proposing dropping priorities completely > right now and -maybe-, > just maybe (NOT *necessarily *as Mark says*)* shipping H3 with some form > of priorities on-board (i.e., "priorities should not block H3"). The way = I > see this going forward > is that many people just won't bother implementing any prioritization > concept until it's clear what will end up chosen (and it's in the spec). > Consequently, people will keep testing QUIC stack performance without > caring about multiplexing (much): downloading a single file over a single > stream, > which imo is only part of the equation. I see us ending up with shipped > implementations that don't have decent prioritization support, this time > not because they can't > be bothered to implement a dependency tree, but simply because nobody tol= d > them they should. Thus we run the risk of H3 performing worse than H2. > > As such, I am not really in favor of removing priorities from the spec > until we have a replacement. Or if we do, I feel priorities should block = H3 > (even if it's just for a simplified setup). > > > I really feel we're sticking our heads in the sand on this. We've been > ignoring HTTP priorities for too long (otherwise we wouldn't be in this > current mess). Next to that, > we've also been ignoring QUIC-level priorities (with the very vague > https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-2.3 as > only indication). I've asked this > of multiple implementers on multiple occasions and no one had a concrete > idea of how they will/should be mapping application-layer priorities to > QUIC stream priorities yet. > People seem to expect this to somehow resolve itself or that it can be > bolted on as an afterthought, and maybe it will/can, but I doubt it. > > The only other conclusion I can draw from all this, is that priorities > don't really matter in the big picture. I certainly see enough indicators > to that end. For example Microsoft Edge > not bothering to use them in the first place. For example browsers not > seeming to a/b test optimal approaches for over 4 years. For example, som= e > people advocating that "passive" > resource request order + content-type is enough of a signal in itself to > provide good page loading performance. For example, people proposing not > letting them block H3. > This viewpoint is 100% contradictory to my own prioritization research an= d > my understanding of current web page building techniques. Maybe I'm missi= ng > things others take for > granted. Maybe I'm making mistakes. Maybe priorities are not the > cornerstone of a multiplexed protocol that I view them to be. In that cas= e, > by all means go ahead and continue > down this proposed route, as it indeed seems the best way forward. If not= : > please give them the attention they deserve. > > With best regards, > Robin > > > On Sat, 17 Aug 2019 at 14:10, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > >> +1 >> >> >> On 17 August 2019 at 00.08.06, Jana Iyengar (jri.ietf@gmail.com) wrote: >> >> +1 to removing the current priorities from HTTP/3. >> >> On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham > > wrote: >> >>> In Montreal, we had a discussion about priorities, where the outcome wa= s >>> that people in the room agreed to defer to the HTTP Working Group regar= ding >>> whether HTTP/3 should ship with something compatible with HTTP/2 priori= ties >>> in it: >>> >>> https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h= 3-priorities >>> >>> Since then, the HTTP Working Group has come to consensus that it does >>> not believe we should do so: >>> https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net >>> >>> This consensus call is to confirm this approach in this WG. In practica= l >>> terms, it means we will remove the current HTTP/2-aligned priorities >>> machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will sh= ip >>> without any form of priorities; just not this one. Doing so will resolv= e a >>> number of outstanding issues, and make way for a replacement scheme, >>> currently under discussion in a design team in the HTTP Working Group. >>> >>> Please respond by the middle of next week; we'd like to move forward >>> with this resolution. >>> >>> Kind regards, >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> > > -- > > 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 > > > --000000000000b33b01059050ab69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with the proposal of removing HTTP/2 priorities=C2= =A0from HTTP/3. HTTP/2 Priorities are overly complicated for the task at ha= nd (as the implementation experience with HTTP/2 suggests). I look forward = to the priority design team's output.

On Sat, Aug 17, 2019 at 6:54= AM Robin MARX <robin.marx@uha= sselt.be> wrote:
At the risk of repeatedly screaming into the void:=

I do not have a problem with the removal of HTTP/2-styl= e priorities per se. The setup is certainly quite complex and can be simpli= fied in terms of implementation.
However, the dependency tree is = also very flexible and able to represent a wide variety of different priori= tization schemes.
That this flexibility has been severely under-u= tilized to this day, does not necessarily mean it's not needed in my op= inion.=C2=A0
And sure, we can drop it now, ship with something si= mple, and move to a more complex/flexible setup again down the road once we= have more insights.=C2=A0

However, tha= t latter point is still not what seems to be on the table here. I still fee= l like we're proposing dropping priorities completely right now and -ma= ybe-,=C2=A0
just maybe (NOT=C2=A0necessarily as Mark says<= i>) shipping H3 with some form of priorities on-board (i.e., "prio= rities should not block H3"). The way I see this going forward=C2=A0
is that many people just won't bother implementing any priorit= ization concept until it's clear what will end up chosen (and it's = in the spec).=C2=A0
Consequently, people will keep testing QUIC s= tack performance without caring about multiplexing (much): downloading a si= ngle file over a single stream,=C2=A0
which imo is only part of t= he equation. I see us ending up with shipped implementations that don't= have decent prioritization support, this time not because they can't= =C2=A0
be bothered to implement a dependency tree, but simply bec= ause nobody told them they should. Thus we run the risk of H3 performing wo= rse than H2.=C2=A0

As such, I am not really in fav= or of removing priorities from the spec until we have a replacement. Or if = we do, I feel priorities should block H3 (even if it's just for a simpl= ified setup).


I really feel we'= re sticking our heads in the sand on this. We've been ignoring HTTP pri= orities for too long (otherwise we wouldn't be in this current mess). N= ext to that,
we've also been ignoring QUIC-level priorities (= with the very vague=C2=A0https://tools.ietf.org/htm= l/draft-ietf-quic-transport-22#section-2.3=C2=A0as only indication). I&= #39;ve asked this
of multiple implementers on multiple occasions = and no one had a concrete idea of how they will/should be mapping applicati= on-layer priorities to QUIC stream priorities yet.=C2=A0
People s= eem to expect this to somehow resolve itself or that it can be bolted on as= an afterthought, and maybe it will/can, but I doubt it.=C2=A0
The only other conclusion I can draw from all this, is that pr= iorities don't really matter in the big picture. I certainly see enough= indicators to that end. For example Microsoft Edge
not bothering= to use them in the first place. For example browsers not seeming to a/b te= st optimal approaches for over 4 years. For example, some people advocating= that "passive"
resource request order=C2=A0+ content-t= ype is enough of a signal in itself to provide good page loading performanc= e. For example, people proposing not letting them block H3.=C2=A0
This viewpoint is 100% contradictory to my own prioritization research and= my understanding of current web page building techniques. Maybe I'm mi= ssing things others take for=C2=A0
granted. Maybe I'm making = mistakes. Maybe priorities are not the cornerstone of a multiplexed protoco= l that I view them to be. In that case, by all means go ahead and continue= =C2=A0
down this proposed route, as it indeed seems the best way = forward. If not: please give them the attention they deserve.
With best regards,
Robin=C2=A0


On= Sat, 17 Aug 2019 at 14:10, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= wrote:
+1


On 17 August 2019 at 00.08= .06, Jana Iyengar (= jri.ietf@gmail.com) wrote:

+1 to removing the current priorities from HTTP/3.

On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham <mno= t@mnot.net> wrote:
In Montreal, we had a discussion about priorities, where the outcome was that people in the room agreed to defer to the HTTP Working Group regarding whether HTTP/3 should ship with something compatible with HTTP/2 priorities in it:
=C2=A0 https://gi= thub.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-priorities

Since then, the HTTP Working Group has come to consensus that it does not believe we should do so:
=C2=A0 https://www.w3.org/mid/00= CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net

This consensus call is to confirm this approach in this WG. In practical terms, it means we will remove the current HTTP/2-aligned priorities machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will ship without any form of priorities; just not this one. Doing so will resolve a number of outstanding issues, and make way for a replacement scheme, currently under discussion in a design team in the HTTP Working Group.

Please respond by the middle of next week; we'd like to move forward with this resolution.

Kind regards,

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



--

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""
=C2=A0<= /tr>
Robin= =C2=A0Marx
PhD researcher - web performance
Expertise centre for Digital Media
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2= =A0
www.uhasselt.be=
Unive= rsiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0ED= M-2.05
=C2=A0
3D""
--000000000000b33b01059050ab69-- From nobody Sat Aug 17 10:31: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 C196A12011D for ; Sat, 17 Aug 2019 10:31:00 -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 (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHAzY7-Uxef2 for ; Sat, 17 Aug 2019 10:30:57 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 4F6D11200D7 for ; Sat, 17 Aug 2019 10:30:57 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x7HHQdaW035642; Sat, 17 Aug 2019 10:30:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=i6q9EZk3gWPgb+22iW8Ky6lobP6ct7kVo3qVS2GV1OU=; b=VrWEyI7FAH/LUCbvNcjahdaPlTJ5ayigPrCNMMkzLkRSC/NznTYLFcjeiFhFCtWkdkr1 TCHUvm/yyUKtkcvyDope+OB2n/t5Q3i6ZEpMQJljT2TCDdzaYyVPEC5kCgkCYmGTI+LG /COCn6BO6ZPj4a/NFBWC4xLNLZk+6+bHbEUiKt6mm7TQowtTniN08SiI+klqSrahA5rP 9mU9YuWh4A98JhAfiEXneqZC9r3zMUU8N2/8FN1bRPxGzXNuAMlC104fpTqdILLZieeZ Ns9LhxiYqULyXn94j10VVRkr2FHuSXnloPK4v5Ugfw9qLWAPxf8Dor9TPtwcNVMvl0CX tQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2uegjtmm85-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 17 Aug 2019 10:30:52 -0700 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PWE009XG5ZFVU30@ma1-mtap-s03.corp.apple.com>; Sat, 17 Aug 2019 10:30:52 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PWE00E005GHCO00@nwk-mmpp-sz11.apple.com>; Sat, 17 Aug 2019 10:30:51 -0700 (PDT) X-Va-A: X-Va-T-CD: dbc32019e2ab4830dcf570ce64b11590 X-Va-E-CD: 3e13af08c699ce638d90a3b158b6311f X-Va-R-CD: 84a55814ff6a3404092e18cf8161aa64 X-Va-CD: 0 X-Va-ID: 1567e180-f3ab-49dd-ab5a-2f19b9a015e7 X-V-A: X-V-T-CD: dbc32019e2ab4830dcf570ce64b11590 X-V-E-CD: 3e13af08c699ce638d90a3b158b6311f X-V-R-CD: 84a55814ff6a3404092e18cf8161aa64 X-V-CD: 0 X-V-ID: ac612cb6-cf10-44ef-abd0-db34143fe8db X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-17_08:,, signatures=0 Received: from [17.234.18.126] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PWE0000C5YW4L30@nwk-mmpp-sz11.apple.com>; Sat, 17 Aug 2019 10:30:50 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_7D855476-AFEC-475F-B5AC-B99A56452B50" MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Subject: Re: Call for consensus: HTTP/2 Priorities Date: Sat, 17 Aug 2019 10:30:26 -0700 In-reply-to: Cc: IETF QUIC WG To: Robin MARX , Ian Swett References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-17_08:, , signatures=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: Sat, 17 Aug 2019 17:31:01 -0000 --Apple-Mail=_7D855476-AFEC-475F-B5AC-B99A56452B50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 17, 2019, at 6:54 AM, Robin MARX = wrote: >=20 > At the risk of repeatedly screaming into the void: >=20 > I do not have a problem with the removal of HTTP/2-style priorities = per se. The setup is certainly quite complex and can be simplified in = terms of implementation. > However, the dependency tree is also very flexible and able to = represent a wide variety of different prioritization schemes. > That this flexibility has been severely under-utilized to this day, = does not necessarily mean it's not needed in my opinion.=20 > And sure, we can drop it now, ship with something simple, and move to = a more complex/flexible setup again down the road once we have more = insights.=20 >=20 > However, that latter point is still not what seems to be on the table = here. I still feel like we're proposing dropping priorities completely = right now and -maybe-,=20 > just maybe (NOT necessarily as Mark says) shipping H3 with some form = of priorities on-board (i.e., "priorities should not block H3"). The way = I see this going forward=20 > is that many people just won't bother implementing any prioritization = concept until it's clear what will end up chosen (and it's in the spec).=20= > Consequently, people will keep testing QUIC stack performance without = caring about multiplexing (much): downloading a single file over a = single stream,=20 > which imo is only part of the equation. I see us ending up with = shipped implementations that don't have decent prioritization support, = this time not because they can't=20 > be bothered to implement a dependency tree, but simply because nobody = told them they should. Thus we run the risk of H3 performing worse than = H2.=20 >=20 > As such, I am not really in favor of removing priorities from the spec = until we have a replacement. Or if we do, I feel priorities should block = H3 (even if it's just for a simplified setup). I think that many people, if not most, agree that we would like some = form of priority hinting in H3. The best-case scenario is that we have a = new priority mechanism for H3 (that's potentially minimal); followed by = no priority mechanism (but letting one be specified soon); and the = least-preferred option is to just maintain H2 priorities. We do have a design team that's tasked with coming up with a solution = for H3, that Ian Swett is leading. I would encourage you to provide = input or suggestions to that process. Best, Tommy >=20 >=20 > I really feel we're sticking our heads in the sand on this. We've been = ignoring HTTP priorities for too long (otherwise we wouldn't be in this = current mess). Next to that, > we've also been ignoring QUIC-level priorities (with the very vague = https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-2.3 = = as only indication). I've asked this > of multiple implementers on multiple occasions and no one had a = concrete idea of how they will/should be mapping application-layer = priorities to QUIC stream priorities yet.=20 > People seem to expect this to somehow resolve itself or that it can be = bolted on as an afterthought, and maybe it will/can, but I doubt it.=20 >=20 > The only other conclusion I can draw from all this, is that priorities = don't really matter in the big picture. I certainly see enough = indicators to that end. For example Microsoft Edge > not bothering to use them in the first place. For example browsers not = seeming to a/b test optimal approaches for over 4 years. For example, = some people advocating that "passive" > resource request order + content-type is enough of a signal in itself = to provide good page loading performance. For example, people proposing = not letting them block H3.=20 > This viewpoint is 100% contradictory to my own prioritization research = and my understanding of current web page building techniques. Maybe I'm = missing things others take for=20 > granted. Maybe I'm making mistakes. Maybe priorities are not the = cornerstone of a multiplexed protocol that I view them to be. In that = case, by all means go ahead and continue=20 > down this proposed route, as it indeed seems the best way forward. If = not: please give them the attention they deserve. >=20 > With best regards, > Robin=20 >=20 >=20 > On Sat, 17 Aug 2019 at 14:10, Mikkel Fahn=C3=B8e J=C3=B8rgensen = > wrote: > +1 >=20 >=20 > On 17 August 2019 at 00.08.06, Jana Iyengar (jri.ietf@gmail.com = ) wrote: >=20 >> +1 to removing the current priorities from HTTP/3. >>=20 >> On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham > wrote: >> In Montreal, we had a discussion about priorities, where the outcome = was that people in the room agreed to defer to the HTTP Working Group = regarding whether HTTP/3 should ship with something compatible with = HTTP/2 priorities in it: >> = https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-p= riorities = >>=20 >> Since then, the HTTP Working Group has come to consensus that it does = not believe we should do so: >> = https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net = >>=20 >> This consensus call is to confirm this approach in this WG. In = practical terms, it means we will remove the current HTTP/2-aligned = priorities machinery from HTTP/3. It does NOT necessarily mean that = HTTP/3 will ship without any form of priorities; just not this one. = Doing so will resolve a number of outstanding issues, and make way for a = replacement scheme, currently under discussion in a design team in the = HTTP Working Group. >>=20 >> Please respond by the middle of next week; we'd like to move forward = with this resolution. >>=20 >> Kind regards, >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >=20 >=20 > --=20 >=20 > Robin Marx > PhD researcher - web performance > Expertise centre for Digital Media > =20 > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > =20 > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > =20 >=20 --Apple-Mail=_7D855476-AFEC-475F-B5AC-B99A56452B50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 17, 2019, at 6:54 AM, Robin MARX <robin.marx@uhasselt.be> wrote:

At the risk of repeatedly screaming into the void:

I do not have a problem = with the removal of HTTP/2-style priorities per se. The setup is = certainly quite complex and can be simplified in terms of = implementation.
However, the dependency tree is = also very flexible and able to represent a wide variety of different = prioritization schemes.
That this flexibility has = been severely under-utilized to this day, does not necessarily mean it's = not needed in my opinion. 
And sure, we can = drop it now, ship with something simple, and move to a more = complex/flexible setup again down the road once we have more = insights. 

However, that latter point is still not = what seems to be on the table here. I still feel like we're proposing = dropping priorities completely right now and -maybe-, 
just maybe (NOT necessarily as Mark = says) shipping H3 with some form of priorities = on-board (i.e., "priorities should not block H3"). The way I see this = going forward 
is that many people just won't = bother implementing any prioritization concept until it's clear what = will end up chosen (and it's in the spec). 
Consequently, people will keep testing QUIC stack performance = without caring about multiplexing (much): downloading a single file over = a single stream, 
which imo is only part of = the equation. I see us ending up with shipped implementations that don't = have decent prioritization support, this time not because they = can't 
be bothered to implement a dependency = tree, but simply because nobody told them they should. Thus we run the = risk of H3 performing worse than H2. 

As such, I am not really in favor of = removing priorities from the spec until we have a replacement. Or if we = do, I feel priorities should block H3 (even if it's just for a = simplified setup).

I think that many people, if not most, agree that = we would like some form of priority hinting in H3. The best-case = scenario is that we have a new priority mechanism for H3 (that's = potentially minimal); followed by no priority mechanism (but letting one = be specified soon); and the least-preferred option is to just maintain = H2 priorities.

We do have a design = team that's tasked with coming up with a solution for H3, that Ian Swett = is leading. I would encourage you to provide input or suggestions to = that process.

Best,
Tommy



I really feel we're = sticking our heads in the sand on this. We've been ignoring HTTP = priorities for too long (otherwise we wouldn't be in this current mess). = Next to that,
we've also been ignoring QUIC-level = priorities (with the very vague https://tools.ietf.org/html/draft-ietf-quic-transport-22#sectio= n-2.3 as only indication). I've asked this
of multiple implementers on multiple occasions and no one had = a concrete idea of how they will/should be mapping application-layer = priorities to QUIC stream priorities yet. 
People seem to expect this to somehow resolve itself or that = it can be bolted on as an afterthought, and maybe it will/can, but I = doubt it. 

The only other conclusion I can draw from all this, is that = priorities don't really matter in the big picture. I certainly see = enough indicators to that end. For example Microsoft Edge
not bothering to use them in the first place. For example = browsers not seeming to a/b test optimal approaches for over 4 years. = For example, some people advocating that "passive"
resource request order + content-type is enough of a = signal in itself to provide good page loading performance. For example, = people proposing not letting them block H3. 
This viewpoint is 100% contradictory to my own prioritization = research and my understanding of current web page building techniques. = Maybe I'm missing things others take for 
granted. Maybe I'm making mistakes. Maybe priorities are not = the cornerstone of a multiplexed protocol that I view them to be. In = that case, by all means go ahead and continue 
down this proposed route, as it indeed seems the best way = forward. If not: please give them the attention they deserve.

With best = regards,
Robin 


On Sat, 17 Aug 2019 at 14:10, Mikkel = Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
+1
=


On 17 August 2019 at = 00.08.06, Jana Iyengar (jri.ietf@gmail.com) wrote:

=
+1 to removing the current priorities from HTTP/3.

On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham <mnot@mnot.net> wrote:
In Montreal, we had a discussion about priorities, where the outcome was that people in the room agreed to defer to the HTTP Working Group regarding whether HTTP/3 should ship with something compatible with HTTP/2 priorities in it:
  https://github.com/quicwg/wg-materials/blob/master/ietf105/minu= tes.md#h3-priorities

Since then, the HTTP Working Group has come to consensus that it does not believe we should do so:
  https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mno= t.net

This consensus call is to confirm this approach in this WG. In practical terms, it means we will remove the current HTTP/2-aligned priorities machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will ship without any form of priorities; just not this one. Doing so will resolve a number of outstanding issues, and make way for a replacement scheme, currently under discussion in a design team in the HTTP Working Group.

Please respond by the middle of next week; we'd like to move forward with this resolution.

Kind regards,

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



--

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
 
3D""

= --Apple-Mail=_7D855476-AFEC-475F-B5AC-B99A56452B50-- From nobody Sat Aug 17 13:45: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 A12C4120170 for ; Sat, 17 Aug 2019 13:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NtKU3zwm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kbjLP8co Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbJQCocKtI-E for ; Sat, 17 Aug 2019 13:45:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4999D1200FF for ; Sat, 17 Aug 2019 13:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2333; q=dns/txt; s=iport; t=1566074708; x=1567284308; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/XWiGJ/Hcyt15wFu3/kbWO0muxlwnt71aUZV51onjoo=; b=NtKU3zwm7iHpwhJzObVSvlWqfJxiHZvgZZxBDgf95xpF/8T27hHyGETv Gbg7gofVnyg707axYusyotFlttAKFtomRPHmwjTum4squcD+ZnHWgCRaK 0gWz2QPfV67SlXHj6YvLfefgLqA73JE8X9dujwGxOGdQODFj0jezWiD2g s=; IronPort-PHdr: =?us-ascii?q?9a23=3AcaH8hRGPr03e+Yt1GgZs5J1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efPuYiUgNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AABFZlhd/4QNJK1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVQQBAQELAYFEUANtVSAECyqEH4NHA4p6gjeTMIRagS6BJANUCQE?= =?us-ascii?q?BAQwBAS0CAQGEPwIXgwMjNgcOAgUBAQQBAQECAQYEbYUnDIVBCgIEEhEdAQE?= =?us-ascii?q?3AQ8CAQgDATsDAgICMBQRAgQOBSKDAAGBHU0DHQECnjsCgTiIYXOBMoJ6AQE?= =?us-ascii?q?FgkeCRhiCFAmBNAGLaBeBQD+BEScME4JMPodPMoImjBuCeoUPlzEJAoIdlDk?= =?us-ascii?q?bmESlZQIEAgQFAg4BAQWBVwIvgVhwFWUBgkGCQoNyilNygSmMCAEB?= X-IronPort-AV: E=Sophos;i="5.64,398,1559520000"; d="scan'208,217";a="397427530" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Aug 2019 20:45:07 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x7HKj7VL024227 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 17 Aug 2019 20:45:07 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 17 Aug 2019 15:45:06 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 17 Aug 2019 15:45:05 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 17 Aug 2019 15:45:05 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VfpAzwnbqQ37y5tOVUgT/McFlgBLDKv2aoAYKvtt/dPqhGuVh1ayncXNI96Fz/tlImBzsopefSkP2aRUyO6PgYjjtYEZv6u4VE+pDi9F/OYPbrL/0AjY7GbNzFW3vPOD7tcbr+wl++8x79RJKjAX0RzGSTaIqtYm8ZacnzBjK7/XgJmUoXSVuQxJkQEfyaOMdhwWwKn16MiceQqgqf5+D5gFHzkAYyIYngiLInbsnuNwlqyy4nPAjYsrJDFNlvQrrBHBCE/ILQQqyq+u31BV2SLeFfhEVoTSmmJyKoqWGIfpsRLVvKAbbBVKYODLNmSz0pkJFoi9UJndenA3tqsckg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/XWiGJ/Hcyt15wFu3/kbWO0muxlwnt71aUZV51onjoo=; b=kh0Kt+g5vweVKjqmaNPYQV9xfGXL+ry88LBbGi6Tz9iKod/DtUcjF5QPM5Yzvq11wmHhsZKSpbAXOwlwphZseCL4wE6NiDL+b3Yewr/IT/CG43d0a7RFm6dz7f9gi/mEWBdf9J+BgXd6pMwXQk9StV4z99wH+hXPIcLL6B8uY88R4+uFK+PFuSw1BLUuw6C+0i5T9Ava2WFlzV3E+v2lAnLjnfQA2nBaSxLRf36QmvQYQhDfkjgqb3ckKRDbvhWP3yA98zblTdlDdS7BNsnEEHWFwRm5XSl+wSdEjJQUL0qdyO0XVYfjTxf4sQht0KFUVj4VUHzht3umgTvILA+Vlw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/XWiGJ/Hcyt15wFu3/kbWO0muxlwnt71aUZV51onjoo=; b=kbjLP8cob5Px2eaVKafAh4g8/p7eYEpXQXbhY6pbbxZXCtmgcgOmPdQz7xcrWAA/tWeazzZDCSBNa7Get+c7oDF5mWpnesnkS2rXWcXQUeK+yEzY5uS+J33D0/VwwQjxKga7Kjj/TRHy4pZvx3dWurvp0/G3jiLAY1mq3UH8JEw= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB3320.namprd11.prod.outlook.com (20.177.185.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Sat, 17 Aug 2019 20:45:04 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::c5e6:22b8:9d47:2fbb]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::c5e6:22b8:9d47:2fbb%5]) with mapi id 15.20.2157.022; Sat, 17 Aug 2019 20:45:04 +0000 From: "Eliot Lear (elear)" To: Christian Meutes CC: Ian Swett , IETF QUIC WG Subject: Re: Blocking Quic traffic Thread-Topic: Blocking Quic traffic Thread-Index: AQHVUe2wfsrAib4GYkCEHYQQKVuPIab5dhwAgAAEFwCABeBjgIAAetnU Date: Sat, 17 Aug 2019 20:45:04 +0000 Message-ID: <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> References: <95198D4B-63F4-4363-B49C-AB254CF24030@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=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:38fa:312a:9f30:b93d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2f7362b-58e9-4505-4061-08d72353c83d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3320; x-ms-traffictypediagnostic: BYAPR11MB3320: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 0132C558ED x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(366004)(39860400002)(396003)(199004)(189003)(86362001)(81156014)(5660300002)(6246003)(4744005)(229853002)(8676002)(14454004)(3480700005)(76176011)(6506007)(54906003)(99286004)(46003)(486006)(186003)(81166006)(478600001)(33656002)(8936002)(476003)(53546011)(11346002)(2616005)(446003)(316002)(54896002)(6916009)(102836004)(6116002)(256004)(6436002)(7736002)(236005)(6512007)(66556008)(76116006)(91956017)(66446008)(4326008)(53936002)(66946007)(7116003)(6486002)(64756008)(66476007)(71200400001)(36756003)(25786009)(2906002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3320; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: UDuc45tXKHGwjsGENbbahrXBzp0kBc1H2Uq0Cdq3Ay6Mf34fvvQY3U5O1ep6kg+wWBjNSOnMp5oGUr9WSgdmtOhRi9Yl0LYLnZtjO8MD5sNcuSN5sHW3qVPzs2twfDl0ssQjDe7IQhB+g7GIfJvlMIAvGGqbRJrqU5CeQ+IEDQ4cTokcVSweVxmMLCDGomzVgYLzNnxPge+iUo2AQ78+6NO+NmdBkRdhpR72mSsoWQopOoQs2eo9oCSgRmcxz29Iz6gZpsm08EkDSXDf3df8ngZBh365jqR52tPpbUcvLVo8+QA2zyDfwtnvfAjkl0vIGbqUr28Y34wegnm6TjdlUqnEPXV2ymOF7VCuJeY4eliWTa/kLzOqMVywtsmCiildac8SWR0S0Bgo40x36OIuFF7EwMDjPdDRjUjCxVic4WU= Content-Type: multipart/alternative; boundary="_000_9CBEED9614194CB0A8B4D2A548FD06F1ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f2f7362b-58e9-4505-4061-08d72353c83d X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2019 20:45:04.3660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: avLqt7QN8W6L7IjAdXfxEo7xbcJkxZbdgsmjqCm6UETIor9VxVoNGk7G+urPeXMA X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3320 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-10.cisco.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: Sat, 17 Aug 2019 20:45:11 -0000 --_000_9CBEED9614194CB0A8B4D2A548FD06F1ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEF1ZyAxNywgMjAxOSwgYXQgMTU6MjcsIENocmlzdGlhbiBNZXV0ZXMgPGNocmlzdGlh bkBlcnJ4dHgubmV0PG1haWx0bzpjaHJpc3RpYW5AZXJyeHR4Lm5ldD4+IHdyb3RlOg0KDQpteSBn dWVzcyBpcyB0aGF0IHRoZSBhdXRob3JzIHN0YXRlbWVudCBjb250ZXh0dWFsbHkgcmVsYXRlcyB0 byBmdWxseSBjb250cm9sbGVkIGNvcnBvcmF0ZSBlbnZpcm9ubWVudHMgd2hlcmUgTUlUTSB2aWEg SFRUUFMgc3Bvb2ZpbmcgbWlkZGxlYm94ZXMgaXMgYW4gdW5mb3J0dW5hdGUgYnV0IHdpZGVseSBs aXZlZCByZWFsaXR5Lg0KDQoNCkl04oCZcyDigJx1bmZvcnR1bmF0ZeKAnSB1bnRpbCBpdCBzdG9w cyBzb21lb25lIGZyb20gYWJzY29uZGluZyB3aXRoIG9yIGxlYWtpbmcgeW91ciBwZXJzb25hbCBp bmZvcm1hdGlvbi4NCg0KTGV04oCZcyBhdm9pZCB1c2luZyBzdWNoIGxvYWRlZCBsYW5ndWFnZS4N Cg== --_000_9CBEED9614194CB0A8B4D2A548FD06F1ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 YnI+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQpPbiBBdWcgMTcsIDIwMTksIGF0IDE1OjI3LCBDaHJp c3RpYW4gTWV1dGVzICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0aWFuQGVycnh0eC5uZXQiPmNo cmlzdGlhbkBlcnJ4dHgubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJhdXRvIj5teSBndWVzcyBpcyB0aGF0IHRoZSBhdXRo b3JzIHN0YXRlbWVudCBjb250ZXh0dWFsbHkgcmVsYXRlcyB0byBmdWxseSBjb250cm9sbGVkIGNv cnBvcmF0ZSBlbnZpcm9ubWVudHMgd2hlcmUgTUlUTSB2aWEgSFRUUFMgc3Bvb2ZpbmcgbWlkZGxl Ym94ZXMgaXMgYW4gdW5mb3J0dW5hdGUgYnV0IHdpZGVseSBsaXZlZCByZWFsaXR5LjwvZGl2Pg0K PGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+PC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi cj4NCjxkaXY+SXTigJlzIOKAnHVuZm9ydHVuYXRl4oCdIHVudGlsIGl0IHN0b3BzIHNvbWVvbmUg ZnJvbSBhYnNjb25kaW5nIHdpdGggb3IgbGVha2luZyB5b3VyIHBlcnNvbmFsIGluZm9ybWF0aW9u LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TGV04oCZcyBhdm9pZCB1c2luZyBzdWNo IGxvYWRlZCBsYW5ndWFnZS48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9CBEED9614194CB0A8B4D2A548FD06F1ciscocom_-- From nobody Sat Aug 17 17:02: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 2300812007C for ; Sat, 17 Aug 2019 17:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAWh74MfAFaV for ; Sat, 17 Aug 2019 17:02:48 -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 9A20812006D for ; Sat, 17 Aug 2019 17:02:48 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id x4so13578890iog.13 for ; Sat, 17 Aug 2019 17:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=niQz5LNnGccmLROgrdF3bIq5ogF6gsrvApa3x0qAmSs=; b=RadBqdnenpnCHuiqNJRmClETAOsGZhuejs74/oyLP8eULetyHYiA6vkyjIQrzb/w7N a9BllV+IesJ8oSTizY4kPBYGh1oyqS8ZJA4fMaVQx1LNhwYj8tXX0UDW/11xtTDnIRpB BhXrEPgBhNHFt1u4qxPeAsoQbdktIq2M8XdE5PYcZtAd4q41NQyE6FM8R5VSY4eGgMjq KitqCPFhIIizHXG8qwA0noMhZ+5FF5KJf6oaGFAXTT51Uv96Q574Y1Gxmq+y8Vk8QFvZ 9CfAJ8VXTOi1LFMnoneqRX4F89oYt8MXCJ8zQ1x/yF0eN/jovTrZGUmdqjrBa7RAzasp xTWQ== 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=niQz5LNnGccmLROgrdF3bIq5ogF6gsrvApa3x0qAmSs=; b=R43ic/sc6KafEjORaQTWis/x1g7OXZqRgZVtBE50VbXdRq9+gEH/QOsVsNzOGPmj3Q A2fBB9hhZoqdWaCl5EPo9kh3BaSl4TMwibIuEgLFbhasITfEDee+WDnQmJCrghy3n4ds WEAAMVUkz738/3FQhWupwAvhpPz4K6Ved4vlF41pQkYNZqt8hq955DpQYxodfOsBbP/u /rr2JkM8Ga9rC5FdimvrslqswRuiJbAHtr3+EhX+ycwljD3HV5qMXxggi4/2wSE7hXnl tGjIdZgRl+dR2cQGu4BgbCsx01v85SOOPu5IkTzz2KHZyQdoA2VZiZ1SQjBZfMYmioaa 1DpQ== X-Gm-Message-State: APjAAAWEk48sNq/kYTuNfNteLIrEK9WcsNyyegg02ZjQ/ZcUiRW2EiMw orxnYGRt6FnALzsXwcD+hs72rKqP5WOiuLS27NTTYpJ8 X-Google-Smtp-Source: APXvYqx2NEMCQfx/jyJkhKbkHPS32pnIh+CG6Ur2aaiAIqa47IqUlNBhERbKfdEq/m0C0iMctvPUa+PBNtXw9U53oNU= X-Received: by 2002:a5e:c247:: with SMTP id w7mr15992509iop.72.1566086567815; Sat, 17 Aug 2019 17:02:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:a3c1:0:0:0:0:0 with HTTP; Sat, 17 Aug 2019 17:02:47 -0700 (PDT) From: JH Date: Sun, 18 Aug 2019 10:02:47 +1000 Message-ID: Subject: QUIC for IoT embeddeds system To: IETF QUIC WG Content-Type: text/plain; charset="UTF-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: Sun, 18 Aug 2019 00:02:50 -0000 Hi, I am new to QUIC and just joined the mailing list, it seems to me that QUIC working groups focus on HTTP and Web applications. Are there any WG working for small socket level QUIC client server for embedded system? The requirements for embedded system QUIC is very much different to large size of QUIC for HTTP, using small size socket level QUIC in embedded system is long overdue, I will be very interested in involving the embedded system QUIC development, appreciate more information about IETF WG agenda and clarification. Thank you. Kind regards, - Jupiter From nobody Sat Aug 17 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 DC3621200DB for ; Sat, 17 Aug 2019 17:45: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, 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=hNpgkvF4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UqlMw5/r Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biEhP6wgZThh for ; Sat, 17 Aug 2019 17:45:20 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D71E1200CC for ; Sat, 17 Aug 2019 17:45:20 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id BCBB4635 for ; Sat, 17 Aug 2019 20:45:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 17 Aug 2019 20:45:19 -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= fm3; bh=2GEcXNgT0RTbd4Gfvv8thMkpBsXiND0wOtDtr2ssRFE=; b=hNpgkvF4 LW++gef2dd0UaX6l0P5jgrfXzqhgZkECc46RF4pO57sr9Q6Kbs1HnvCx39OLnkP5 wrA1HFGib++pRQdS+3uk9KnoD7lTqF5WJIdmYgb2dlAox01OhtIvr6J9s1fpyyGz VuMxQHNtYXWIbA6Q90vjIoOhWyZjiNKdEViqiTnXG9sY88lrdvgfK2GYtV0NK7mT 8tYpMsPLNSNxMMK2KCEx9Yjy1ry91BDovgDRpC3Dqd2YJCv32S9npmHzmNfdrJTt uGduW6TWOXKYLNFLQfn/iVQgKKiDZEnLKOarjkF42QPFaUqpta+SIljCmf77/5AN oTjmbjKJ1oxI3g== 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=fm3; bh=2GEcXNgT0RTbd4Gfvv8thMkpBsXiN D0wOtDtr2ssRFE=; b=UqlMw5/r2KF+OinHQPD1cNHbCR5/gAugaTBYddkB08ZAL BvY+iQ7HFdIwmqBPUHurCSfltBy6zUD/SVUiGrvLpaR0694QVtnLhtu7SNy8OSor VYSdE5qCIWzYP0gnuu0Fa8IR8qPYv/+6Kuh7Ly1N6AjOnQdx+Lmn73FNm3VVV7n+ wYboJ73awviFKUnl+eJxH8OxbqcrvPsupPZZTuxsbLgB5kiQeohGyKteg8HNZy0e o1YsyADQ4hblHh+O9zZA7pBpekLWQypKfmTJUd/MDG3bMu4XELZQ57WG7EFx4WW6 obKkCgDkV9suzBXQqtHl4Wq+jYL/n6ihtBmsrDMOA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefiedgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusggppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeduudelrdelrdegfedrvdegudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id A57F1380076 for ; Sat, 17 Aug 2019 20:45:17 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 9AB2BC1500 for ; Sun, 18 Aug 2019 00:45:14 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============2875058829653281131==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190818004514.9AB2BC1500@cloud.mnot.net> Date: Sun, 18 Aug 2019 00:45:14 +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, 18 Aug 2019 00:45:26 -0000 --===============2875058829653281131== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+2/-21/=F0=9F=92=AC24) 2 issues created: - What's the difference of closing and resetting a stream? (by tandf) https://github.com/quicwg/base-drafts/issues/2971 = - HTTP/3 Pseudoheader constraints are incorrect? (by martinduke) https://github.com/quicwg/base-drafts/issues/2966 = 16 issues received 24 new comments: - #2778 CID change still required in response to migration? (5 by erickin= near, kazuho, martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/issues/2778 [-transport] = - #2944 Layout of PreferredAddress (2 by MikeBishop, mikkelfj) https://github.com/quicwg/base-drafts/issues/2944 [-transport] = - #2945 When to send the SETTINGS frame (2 by davidben, MikeBishop) https://github.com/quicwg/base-drafts/issues/2945 [-http] [design] = - #2966 HTTP/3 Pseudoheader constraints are incorrect? (2 by LPardue, Mik= eBishop) https://github.com/quicwg/base-drafts/issues/2966 [-http] = - #2971 What's the difference of closing and resetting a stream? (2 by LP= ardue, tandf) https://github.com/quicwg/base-drafts/issues/2971 = - #2819 CANCEL_PUSH edge cases (1 by martinduke) https://github.com/quicwg/base-drafts/issues/2819 [-http] = - #2957 Are ECN counts per pn_space or unified across pn_spaces? (1 by ja= naiyengar) https://github.com/quicwg/base-drafts/issues/2957 [-recovery] [-transpo= rt] [editorial] = - #2669 Only received Stateless reset token should be checked (1 by marti= nthomson) https://github.com/quicwg/base-drafts/issues/2669 [-transport] [editori= al] = - #2963 What if server does not send HTTP_EARLY_RESPONSE but starts sendi= ng response (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2963 [-http] = - #2837 Does a Retry really need to change the CID? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2837 [-transport] [editori= al] = - #2205 Largest acked in ACK frame MUST NOT decrease (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2205 [-transport] [design] = - #2227 It's annoying that one can't send push in 0.5RTT (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2227 [-http] [design] [qui= cv2] = - #2892 QPACK Required Insert Count decoding pseudocode does not enforce = that encoding is valid (1 by bencebeky) https://github.com/quicwg/base-drafts/issues/2892 [-qpack] = - #2924 Remove PRIORITY (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2924 [-http] [design] = - #2541 Clients cannot abandon Initial packets while server can still sen= d initial close (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2541 [-transport] [design]= [proposal-ready] = - #2926 ICID or OCID? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2926 [-transport] [editori= al] = 21 issues closed: - Byte order of IP addresses in PreferredAddress https://github.com/quicw= g/base-drafts/issues/2951 [-transport] [editorial] = - It's annoying that one can't send push in 0.5RTT https://github.com/qui= cwg/base-drafts/issues/2227 [-http] [design] [quicv2] = - What's the difference of closing and resetting a stream? https://github= .com/quicwg/base-drafts/issues/2971 = - Exceeding Max STREAM ID should be a connection error https://github.com= /quicwg/base-drafts/issues/2825 [-transport] [design] [has-consensus] = - Coordinating spin https://github.com/quicwg/base-drafts/issues/2763 [-t= ransport] [design] [has-consensus] = - NEW_TOKEN should be symmetric https://github.com/quicwg/base-drafts/iss= ues/2760 [-transport] [design] [has-consensus] [quicv2] = - Remove ack_delay_exponent TP https://github.com/quicwg/base-drafts/issu= es/2670 [-transport] [design] [has-consensus] = - Articulate principles for definition of error codes https://github.com/= quicwg/base-drafts/issues/2388 [-transport] [design] [has-consensus] = - Embed QUIC version in expansion https://github.com/quicwg/base-drafts/i= ssues/2170 [-tls] [design] [has-consensus] = - Apply GREASE to transport parameters https://github.com/quicwg/base-dra= fts/issues/2550 [-transport] [design] [has-consensus] = - Spoofed connection migration as a DoS vector https://github.com/quicwg/= base-drafts/issues/2342 [-transport] [design] [has-consensus] = - Be clearer about the purpose of disable_migration https://github.com/qu= icwg/base-drafts/issues/2389 [-transport] [design] [has-consensus] = - CC state after a change of path? https://github.com/quicwg/base-drafts/= issues/2685 [-transport] [design] [has-consensus] = - Rationalize terminology around transport/application interactions https= ://github.com/quicwg/base-drafts/issues/2805 [-http] [-transport] [design] = [has-consensus] = - Does rejecting 0-RTT data prohibit ACKing 0-RTT data? https://github.co= m/quicwg/base-drafts/issues/2840 [-transport] [design] [has-consensus] = - text about rejecting 0-RTT is unclear https://github.com/quicwg/base-dr= afts/issues/2829 [-tls] [editorial] = - Does it make sense to try 0-RTT after Retry? https://github.com/quicwg/= base-drafts/issues/2842 [-transport] [design] [has-consensus] = - Should server TP encryption be a requirement for the cryptographic hand= shake? https://github.com/quicwg/base-drafts/issues/2920 [-transport] [desi= gn] [has-consensus] = - QPACK Required Insert Count decoding pseudocode does not enforce that e= ncoding is valid https://github.com/quicwg/base-drafts/issues/2892 [-qpack] = - Are ECN counts per pn_space or unified across pn_spaces? https://github= .com/quicwg/base-drafts/issues/2957 [-recovery] [-transport] [editorial] = - Possible HoL blocking due to co-mingling payload and metadata (header) = address space. https://github.com/quicwg/base-drafts/issues/1606 [-http] [d= esign] [quicv2] = Pull requests ------------- * quicwg/base-drafts (+11/-16/=F0=9F=92=AC16) 11 pull requests submitted: - forbid empty NEW_TOKEN frames (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2977 = - State network byte order in PreferredAddress (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2976 [-transport] [editorial= ] = - Add headings to Security Considerations (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2975 [-http] [editorial] = - Default values in IANA (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2974 [-http] [editorial] = - Require 8164 validation for non-https origins (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2973 [-http] [design] = - Http/complete settings (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2972 [-http] [design] = - Update QPACK stream creation error (by RenjieTang) https://github.com/quicwg/base-drafts/pull/2970 = - Prevent linkability from responding to migration (by martinthomson) https://github.com/quicwg/base-drafts/pull/2969 [-transport] [design] = - Stateless reset too (by martinthomson) https://github.com/quicwg/base-drafts/pull/2968 [-transport] [design] = - Preface QUIC frames with "QUIC" (by tandf) https://github.com/quicwg/base-drafts/pull/2967 = - Update Stream Commitment Attack example (by tandf) https://github.com/quicwg/base-drafts/pull/2965 = 11 pull requests received 16 new comments: - #2851 Allow connections to share a port by adding restrictions on zero-= length connection IDs (3 by erickinnear, DavidSchinazi, martinthomson) https://github.com/quicwg/base-drafts/pull/2851 [-transport] [design] = - #2967 Preface QUIC frames with "QUIC" (2 by martinthomson, ianswett) https://github.com/quicwg/base-drafts/pull/2967 [-http] [editorial] = - #2752 ECN verification text (2 by martinthomson, janaiyengar) https://github.com/quicwg/base-drafts/pull/2752 [-transport] = - #2935 QPACK [editorial] update RIC and Base on figures (2 by bencebeky,= afrind) https://github.com/quicwg/base-drafts/pull/2935 [-qpack] = - #2961 Repair rules for NEW_TOKEN (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2961 [-transport] [editorial= ] = - #2964 ECN counts in the ACK frame should be in the same pn_space of the= ACK frame (1 by ianswett) https://github.com/quicwg/base-drafts/pull/2964 [-recovery] [-transport= ] = - #2972 Send complete SETTINGS (1 by nharper) https://github.com/quicwg/base-drafts/pull/2972 [-http] [design] = - #2878 Initial secrets do not change after Retry (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2878 [-tls] [-transport] [de= sign] = - #2879 Add note about stale ACK frames breaking ECN (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2879 [-transport] [design] = - #2939 QPACK [design] Decoder MUST emit Header Acknowledgement. (1 by af= rind) https://github.com/quicwg/base-drafts/pull/2939 [-qpack] = - #2965 Update Stream Commitment Attack example (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2965 [-transport] [editorial= ] = 16 pull requests merged: - State network byte order in PreferredAddress https://github.com/quicwg/base-drafts/pull/2976 [-transport] [editorial= ] = - Remove spin coordination requirement https://github.com/quicwg/base-drafts/pull/2882 [-transport] [design] = - Articulate error code principles https://github.com/quicwg/base-drafts/pull/2880 [-transport] [design] = - grease transport parameters https://github.com/quicwg/base-drafts/pull/2873 [-transport] [design] = - Remove DoS vector for spoofed connection migration https://github.com/quicwg/base-drafts/pull/2893 [-transport] = - Fix language around CC on migration https://github.com/quicwg/base-drafts/pull/2918 [-transport] [design] = - Define terms for application actions https://github.com/quicwg/base-drafts/pull/2857 [-http] [-transport] [d= esign] = - describe how 0-RTT is accepted and rejected https://github.com/quicwg/base-drafts/pull/2841 [-tls] [-transport] [de= sign] = - recommend resending of 0-RTT data after a Retry https://github.com/quicwg/base-drafts/pull/2852 [-transport] [design] = - Confidentiality for server transport parameters https://github.com/quicwg/base-drafts/pull/2921 [-transport] [design] = - ECN counts in the ACK frame should be in the same pn_space of the ACK f= rame https://github.com/quicwg/base-drafts/pull/2964 [-recovery] [-transport= ] = - QPACK [editorial] Post-base index is not relative index. https://github.com/quicwg/base-drafts/pull/2940 [-qpack] = - QPACK [design] Decoder MUST emit Header Acknowledgement. https://github.com/quicwg/base-drafts/pull/2939 [-qpack] = - QPACK [editorial] Reword paragraph on blocked stream limit. https://github.com/quicwg/base-drafts/pull/2936 [-qpack] = - Modify pseudo-code to enforce that zero must be encoded as zero. https://github.com/quicwg/base-drafts/pull/2933 [-qpack] = - Update Stream Commitment Attack example https://github.com/quicwg/base-drafts/pull/2965 [-transport] [editorial= ] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============2875058829653281131== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday August 18, 2019

Issues

quicwg/base-drafts (+2/-21/=F0=9F=92=AC24)

2 issues created:

16 issues received 24 new comments:

21 issues closed:

Pull requests

quicwg/base-drafts (+11/-16/=F0=9F=92=AC16)

11 pull requests submitted:

11 pull requests received 16 new comments:

16 pull requests merged:

Repositories tracked by this digest:

--===============2875058829653281131==-- From nobody Sat Aug 17 22: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 A0248120041 for ; Sat, 17 Aug 2019 22:57:42 -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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0rPV3NjF6Jj for ; Sat, 17 Aug 2019 22:57:41 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA0412001A for ; Sat, 17 Aug 2019 22:57:41 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id s15so8485152edx.0 for ; Sat, 17 Aug 2019 22:57:41 -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=C8O2eV2ecuMzhqBG2WXMvxmPcz/J+dYepCS4lGu7+zs=; b=pbF3M3XOVWgum0V+2d6av0qmjixsSzb7bspZQwEdWMjKI5Qm+AbIDC4aGhqprolfZZ 3iBmN2LgXUV5xb73Wa2qAdFWb7zAoFqi8oEYeLvGrOfKJeAksncnSn7O1qxSVbfuCzOz zNdAgVm3fJm+hsH29IuRo5KJsgrruCYeJvXKoPGj4O8VmaaWNyYFSP8BTOK0JTfLJSRd L+U8JWslRWZBsWHGm1y2miWsQJiaaSP7RKBhE2YVetciM+hOmrGzMqaGPFweK/7SR9HS 28jyP7qyNPAkL8EA7eLPjTBEuTbhh/l54dNJLquS/ixGcdOxdLCdzKJAnZTz2X2rwCf9 sRTg== 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=C8O2eV2ecuMzhqBG2WXMvxmPcz/J+dYepCS4lGu7+zs=; b=qLqojR0fPP+6uqNGTQm3Aiq5T1FiGyvvqfAfYXUZoO/EDZyxXVsfEOJI7xWhdtZxjp JnLbBSKKDf98snKMjziinyljW6m1Sfk0tlPaplBMolQANtvSOOdAvMjcXp4WmInz/35s eaJNsxzGmnRpbNTbEYBWKx8XjdsvqQpqczqd0/bWLIdtg6qo9MSAkvh9BOiEP6q9fl7y yhv2jlCZrnK3mUYhfB0PG3YZNR2Br1rltzHOTu+Xbkw5kYI5+VdG/nfy5NwQyvA1Zchy XBeRFURVIXrzcaQKfclAKmXHWSjHcKWj4VUaz4lprbZOmZcy7kKcBrw//JjM3WT5QgFt QAQg== X-Gm-Message-State: APjAAAVWdVrYuVLey3OkWOY1M9jOtYMKiF7ONDXTCTeZbxMEEL7t5Qis NR8vXwsm3Vl1lhhNanuaxyWaHnCrnh5NOVuhLN0= X-Google-Smtp-Source: APXvYqzNx/I8/38LMEjz4EO9j2a0dWINLatmn+/AvVwJMcVytz3I1DOsniY11U1YLVwJ4cVwNqbFcGN2tzKAnBY8lFs= X-Received: by 2002:a17:906:4c81:: with SMTP id q1mr4768247eju.185.1566107859724; Sat, 17 Aug 2019 22:57:39 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 18 Aug 2019 01:57:38 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 18 Aug 2019 01:57:38 -0400 Message-ID: Subject: Re: QUIC for IoT embeddeds system To: JH , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000a8add805905de667" 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, 18 Aug 2019 05:57:43 -0000 --000000000000a8add805905de667 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe the QUIC WG has its hand full just getting version 1 out of the door. The focus is not limited to HTTP although it is the only defined application protocol for the time being. There is a fairly strict separation between the transport layer (QUIC) and the application layer (HTTP etc. over QUIC). Game application etc. may also be relevant and there is separate ongoing work on WebRTC, Websockets, etc. in a new form over QUIC - the WebTransport work may cover some or all of this. The intention for IoT, as I undertand it, is for =E2=80=9Csomeone=E2=80=9D = to pick up the ball and specify a new QUIC version aimed for constrained devices. QUIC is designed to handle such protocol variations. In the simplest form such a specification might do away with Retry, migration, have a lighter initial packet, and support a only subset of crypto algorithms. Note that a lighter initial packet is open to amplification attacks so there might be some concerns about IP whitelisting= . Another aspect could be transport over non-UDP, non-IP fabric. That would not directly address HTTP/3 or other application protocols but it would be a precondition. I for one would like to see MQTT over a lighter version of QUIC. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 18 August 2019 at 02.03.06, JH (jupiter.hce@gmail.com) wrote: Hi, I am new to QUIC and just joined the mailing list, it seems to me that QUIC working groups focus on HTTP and Web applications. Are there any WG working for small socket level QUIC client server for embedded system? The requirements for embedded system QUIC is very much different to large size of QUIC for HTTP, using small size socket level QUIC in embedded system is long overdue, I will be very interested in involving the embedded system QUIC development, appreciate more information about IETF WG agenda and clarification. Thank you. Kind regards, - Jupiter --000000000000a8add805905de667 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I believe the QUIC W= G has its hand full just getting version 1 out of the door.
The focus is not limited to = HTTP although it is the only defined application protocol for the time bein= g. There is a fairly strict separation between the transport layer (QUIC) a= nd the application layer (HTTP etc. over QUIC). Game application etc. may a= lso be relevant and there is separate ongoing work on WebRTC, Websockets, e= tc. in a new form over QUIC - the WebTransport work may cover some or all o= f this.

<= /div>
The intention= for IoT, as I undertand it, is for =E2=80=9Csomeone=E2=80=9D to pick up th= e ball and specify a new QUIC version aimed for constrained devices. QUIC i= s designed to handle such protocol variations.

In the simplest form such a specification might d= o away with Retry, migration, have a lighter initial packet, and support a = only subset of crypto algorithms. Note that a lighter initial packet is ope= n to amplification attacks so there might be some concerns about IP whiteli= sting.

Another aspect= could be transport over non-UDP, non-IP fabric.

That would not directly address HTTP/3 or other= application protocols but it would be a precondition.

I for one would like to see MQTT over a l= ighter version of QUIC.


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


On 18 August 2019 at 02.03.06, JH (jupiter.hce@gmail.com) wrote:

Hi,

I am new to QUIC and just joined the mailing list, it seems to me that
QUIC working groups focus on HTTP and Web applications. Are there any
WG working for small socket level QUIC client server for embedded
system? The requirements for embedded system QUIC is very much
different to large size of QUIC for HTTP, using small size socket
level QUIC in embedded system is long overdue, I will be very
interested in involving the embedded system QUIC development,
appreciate more information about IETF WG agenda and clarification.

Thank you.

Kind regards,

- Jupiter

--000000000000a8add805905de667-- From nobody Sat Aug 17 23:10: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 9E607120041 for ; Sat, 17 Aug 2019 23:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=errxtx-net.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 O3YJTxNEEo0t for ; Sat, 17 Aug 2019 23:10:45 -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 B422A12001A for ; Sat, 17 Aug 2019 23:10:44 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id g8so8456818edm.6 for ; Sat, 17 Aug 2019 23:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=errxtx-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xTGIEZwYXN5w32qzaK/59EqOfMaEVl4kQ24qsfCc8Vw=; b=mhD0mjdYmxe4UaVa4QtN753aplgSBczgCItlJOaMzFkJn5eyQcSUAN2Y51Vy63R8YK pqhp1arIM6UmA3Q3JhIkxn3hjSz4PoGDLoFW0P5dtmls1+jbuhgkE2zs2LWrzENfp/lN Myl1DSdcZbOcvw5X8S/ZxapMTfKoxDrErtC/zodcfzJsHKNStJt5mNjjOpeIMEMs7c8P jhL3JIf0sLRVDzgL60VJA92E/WcwHCF6FvfCwsgOC0w18Ew6bYwXuzoCsEmYho1fYnRd 1V+HGlo4IYV7tJ0qXOC3nJ/7Dw7pkLBvnXov67e/ZT/Sqa84UYst0dkVbUHLZtHgRgQO K1YQ== 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=xTGIEZwYXN5w32qzaK/59EqOfMaEVl4kQ24qsfCc8Vw=; b=BnA1VnP7wzo4Mpdfa6CO1gGQEMxvODF0ggofs8wB3sH2D/uRtYTag8M9J65+2SpRrd 89g1ixcKprbDMRVJKP8iofXwbVdnK5TFtQj1TmnKk2TS4OaKyEgpu2GIJqHgra5gxWch BeUhqb2bJmWoxJdcAbfqo4PgGNB1gZYu+sN6Cn+SuttNJ5aw7zfiHHkI1I8CW38y7YuN DHEaHFkcM4pOwpDaedYhkkcMEIUhlticNFIU22db2oTAt7CMAOESfEQWhiX+iUGrsm0G uFYR0pd18T+31th/6AKLf57trNLOTuB4KBl47AYvrplWqv/nw+bCc5QaoNex1pP7oyTm eWSg== X-Gm-Message-State: APjAAAWxRhlad2LMMlbQLHXN5WvZCd9y5T7+UvrF3sCX11SbhAjnferZ IyUo5JLsnTZgUvn/o0QPXYhVm6tUPg4gAq3njsv9Hw== X-Google-Smtp-Source: APXvYqwj+R/sgNxcm3AxpgWBYAyPGkk4Ib8KzbGf8LyfMjPhwrt4kkQN1gFrTFdqjMZ2YeROnUs9WbTrzrKbeM3pHJ4= X-Received: by 2002:a50:94cc:: with SMTP id t12mr19031458eda.274.1566108642910; Sat, 17 Aug 2019 23:10:42 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> In-Reply-To: <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> From: Christian Meutes Date: Sun, 18 Aug 2019 08:10:32 +0200 Message-ID: Subject: Re: Blocking Quic traffic To: "Eliot Lear (elear)" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000057337805905e15b6" 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, 18 Aug 2019 06:10:47 -0000 --00000000000057337805905e15b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat 17. Aug 2019 at 22:45, Eliot Lear (elear) wrote: > It=E2=80=99s =E2=80=9Cunfortunate=E2=80=9D until it stops someone from ab= sconding with or leaking > your personal information. > > Let=E2=80=99s avoid using such loaded language. > With those boxes data is already leaked as soon as someone sends sensible data not meant to be possible to read by anyone but the trusted endpoint/website. When such box is on top compromised leakage becomes a new dimension. I stick with my opinion of =E2=80=9Eunfortunate=E2=80=9C, it=E2= =80=98s even an understatement. But not going to give more ot input here. --00000000000057337805905e15b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat 17. Aug 2019 at 22:45, Eliot Lear (elear) <elear@cisco.com> wrote:
It=E2=80=99s =E2=80=9Cunfortunate=E2=80=9D until it stops someone from= absconding with or leaking your personal information.

Let=E2=80=99s avoid using such loaded language.

With those boxes data= is already leaked as soon as someone sends sensible data not meant to be p= ossible to read by anyone but the trusted endpoint/website. When such box i= s on top compromised leakage becomes a new dimension. I stick with my opini= on of =E2=80=9Eunfortunate=E2=80=9C, it=E2=80=98s even an understatement. B= ut not going to give more ot input here.
--00000000000057337805905e15b6-- From nobody Sun Aug 18 00:53: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 42D15120026 for ; Sun, 18 Aug 2019 00:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=P9D/UWyo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hkqcCE1j Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLSDWSMLDfOJ for ; Sun, 18 Aug 2019 00:53:26 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25FA12001A for ; Sun, 18 Aug 2019 00:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4887; q=dns/txt; s=iport; t=1566114806; x=1567324406; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l8+9oU9vmjYSl8/eaBQNAKpC1hesjXBIHefkidLDHKw=; b=P9D/UWyolkwkEUqJ4LXIVr75P6EDCRABskJPEBR5aDR9vGvfPHOamHWX AWGEBWiLrhslEM08YnbTGIR6kUfiXsMsarlL7uQaTQjCnsPJIc2OgGUyC lCI/etIG/wlID1MfxqdJeAtfV3aYibfkBKqS17+SgtyNmG8eqlt0PC9nc 4=; IronPort-PHdr: =?us-ascii?q?9a23=3ALkEwBR10dsN/8yGnsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGPt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBEn2JeTCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAAB3Alld/4gNJK1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBgURQA4FCIAQLKoQfg0cDiniVZ4RagS6BJANUCQEBAQwBAS0?= =?us-ascii?q?CAQGEPwIXgwMjNgcOAgUBAQQBAQECAQYEbYUnDIVLAgEDEhEdAQE3AQ8CAQg?= =?us-ascii?q?EOwMCAgIwFBECBA4FIoMAgR5NAx0BAp1sAoE4iGFzgTKCegEBBYJHgkAYghQ?= =?us-ascii?q?JgTQBiR92H4EWHheBQD+BOB+CTD6HTzKCJowbKoJQhQ+XMQkCgh2UORuCMYt?= =?us-ascii?q?IikulZQIEAgQFAg4BAQWBVwwlgVhwFWUBgkGCQoNyilNygSmNTwEB?= X-IronPort-AV: E=Sophos;i="5.64,400,1559520000"; d="scan'208,217";a="312907532" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2019 07:53:25 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x7I7rOvN027571 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 18 Aug 2019 07:53:25 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 02:53:24 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 03:53:23 -0400 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 18 Aug 2019 02:53:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JIQjJjgtxngfY3UGQVQgS5mAeJPkvq2hH3ns9IiTNkXWXnk/K2aoeOe1Tx1n44wdvKu6/kHktCxp+QV2SkcAl8DFMMa1vp/SNfE1TDWmRyB7o/IsijotIsBaZiu3nE7IRYr6pUFxu0h/WkAPsuGWE09SmntuYxp4CXTf5VhxpKfc5gnKHrkgAY9PB1ncJ1mIAcxWl+ljdmIFYoNXApGpz8Y4ppKdd+n6GxQzrYsl2ftBoGnM502onAbdwQu/THuLL7cG4IIeQHKDK3tQqubLWAmzWr2he2Io+1TA5CS7VVVtn+YE4PPJw2LFqJ8rMFvwQ9kazLGzl9E4Pl1xHncevA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l8+9oU9vmjYSl8/eaBQNAKpC1hesjXBIHefkidLDHKw=; b=BLIVcIRZLVkdF381cIangZu3Y7cPey0uJMJi4QrO4stNF2j5UfRWVq5M6nn3RK1aUJpgnzbsk+2VcEpZZDDFqpfojUzlpQkqE8mIb7obPKQyTAWEZDCP5xvX6uzZ1Bzc/63mJYjeTlqzshXutcWyegfSlc9jCYKxdMHaMoC+lfdgKlUjeCuD8WiLmPc1cFYsFhfWZZJH+PmxOS9HVBQdT7wEHH7ZKNhiWHjd8mqdVTOK6PfG/fwC6EEfcI1lNOYK5z1A52NLA+Uamgl6BRN2oNkYYKQr7y1LdcKKUYixR41SmaxV7EZIuEY0gcr0vzBSoz1HqnPMVom/YhUk4ioBaQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l8+9oU9vmjYSl8/eaBQNAKpC1hesjXBIHefkidLDHKw=; b=hkqcCE1jCb5dnc23gRW0Dy995exbrH5CXYdAAz92Q4WKohyUJoPTggsyBYHCc3PZ9rZJw5cSxVWrXdx6Lu9o+h6ydjgVeNsIBdSQJ9zEe9lkY9KN+2DQFqduhsZDuM71rKo6Qff4CD7Jg58buTNMenJzXnk0g4MHiy07zUZ16ME= Received: from DM6PR11MB3820.namprd11.prod.outlook.com (20.179.17.28) by DM6PR11MB2731.namprd11.prod.outlook.com (20.176.97.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Sun, 18 Aug 2019 07:53:22 +0000 Received: from DM6PR11MB3820.namprd11.prod.outlook.com ([fe80::b8e0:1756:f2e7:2eee]) by DM6PR11MB3820.namprd11.prod.outlook.com ([fe80::b8e0:1756:f2e7:2eee%4]) with mapi id 15.20.2157.015; Sun, 18 Aug 2019 07:53:22 +0000 From: "Eliot Lear (elear)" To: Christian Meutes CC: IETF QUIC WG Subject: Re: Blocking Quic traffic Thread-Topic: Blocking Quic traffic Thread-Index: AQHVUe2wfsrAib4GYkCEHYQQKVuPIab5dhwAgAAEFwCABeBjgIAAetnUgACd/QCAABy7+A== Date: Sun, 18 Aug 2019 07:53:21 +0000 Message-ID: <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.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=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:38fa:312a:9f30:b93d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9bfc5f2d-3f51-47be-c40f-08d723b1243d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM6PR11MB2731; x-ms-traffictypediagnostic: DM6PR11MB2731: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(189003)(199004)(7116003)(99286004)(186003)(486006)(3480700005)(71200400001)(71190400001)(86362001)(33656002)(316002)(236005)(6512007)(54896002)(46003)(2616005)(476003)(6436002)(11346002)(36756003)(81166006)(81156014)(8936002)(8676002)(6116002)(4326008)(229853002)(6916009)(446003)(2906002)(25786009)(76116006)(76176011)(6246003)(91956017)(64756008)(478600001)(66556008)(66446008)(6486002)(53936002)(66476007)(14454004)(7736002)(14444005)(256004)(5660300002)(6506007)(66946007)(53546011)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2731; H:DM6PR11MB3820.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: iSpp3QabT+MORgb/Wq9uWaUTARFsCixqsDkVRbKNxh9nzVubqyPQWWFRcCgOiC+UEXqeZH0ci0BHmlUl0eZkL7gJu88b1rwb/jVT7Sb0L+st/Sbsf0CJ+6tBKMx0Tt/9saX1vyfSYFhTCj2E2oWIvVrZiouK9ycSumzAs2n9639WrD5T4lqoJB/tQiJgBnU33DdcMgTlXjN07Bxi+A4aAXrXh2Df4D1yDvkcZqBffwhcIsDyxjyqqj5h5QhIaUpB4Ke8jaO49wuRfSDXu+pDVRHnPiP196SyxDYY/J4vVS3gZMntNN/Qo3zZD/Nq2s5q0TcjDaJRR2ASP4NS5JtsTHgUGJNPiadlGtRapOICt99sR9CBVDqle70mi21bHbJcaCOoAa3Lv6cTxjA/khIIdweXxgOwCdBnyX0Lw2zaQtc= Content-Type: multipart/alternative; boundary="_000_09AF1E5B47BD406A885BAE1FFA2B511Eciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9bfc5f2d-3f51-47be-c40f-08d723b1243d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2019 07:53:21.8856 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rD5yQi0ICWLKvpRDgDZixOwYB2wfpcm5jWe+Ggqr9GHgFg2LSPzXXo3yQiaJ7Og/ X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2731 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: alln-core-3.cisco.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: Sun, 18 Aug 2019 07:53:28 -0000 --_000_09AF1E5B47BD406A885BAE1FFA2B511Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGFwcGVhciB0byBiZSBhcmd1aW5nIHRoYXQgYmVjYXVzZSBpdCBpcyBwb3NzaWJsZSB0byBk b3VibGUtZW5jcnlwdCB0aGVzZSBkZXZpY2VzIGFyZSBwb2ludGxlc3MuIFRoYXQgcHJlc3VtZXMg dGhhdCB0aGUgZW5jcnlwdGlvbiBpc27igJl0IGRldGVjdGFibGUuICBJZiB5b3UgYXJlIGFyZ3Vp bmcgYSBzdGVnYW5vZ3JhcGh5IGF0dGFjaywgaXTigJlzIHBvc3NpYmxlLCBidXQgbWF5IGFsc28g YmUgZGV0ZWN0YWJsZSBpZiB1c2VkIGluIGJ1bGsuDQoNCk5vbmUgb2YgdGhlc2Ugc3lzdGVtcyBh cmUgcGVyZmVjdCBidXQgc2VjdXJpdHkgaXNu4oCZdCBhIGJpbmFyeS4gSWYgeW91IHdlcmUgdG8g YXJndWUgdG8gdGhlIHBlb3BsZSB3aG8gdXNlIHRoZXNlIHByb3hpZXMsIGtub3dpbmcgdGhlaXIg Y29zdCBpbiB0ZXJtcyBvZiBjYXBpdGFsLCBzdXBwb3J0LCBhbmQgdGhlaXIgb3duIHJpc2sgYXMg YSBwb2ludCBvZiBmYWlsdXJlLCB5b3Ugd291bGRu4oCZdCBnZXQgZmFyLg0KDQpFbGlvdA0KDQpP biBBdWcgMTgsIDIwMTksIGF0IDA4OjExLCBDaHJpc3RpYW4gTWV1dGVzIDxjaHJpc3RpYW5AZXJy eHR4Lm5ldDxtYWlsdG86Y2hyaXN0aWFuQGVycnh0eC5uZXQ+PiB3cm90ZToNCg0KT24gU2F0IDE3 LiBBdWcgMjAxOSBhdCAyMjo0NSwgRWxpb3QgTGVhciAoZWxlYXIpIDxlbGVhckBjaXNjby5jb208 bWFpbHRvOmVsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KSXTigJlzIOKAnHVuZm9ydHVuYXRl4oCd IHVudGlsIGl0IHN0b3BzIHNvbWVvbmUgZnJvbSBhYnNjb25kaW5nIHdpdGggb3IgbGVha2luZyB5 b3VyIHBlcnNvbmFsIGluZm9ybWF0aW9uLg0KDQpMZXTigJlzIGF2b2lkIHVzaW5nIHN1Y2ggbG9h ZGVkIGxhbmd1YWdlLg0KDQpXaXRoIHRob3NlIGJveGVzIGRhdGEgaXMgYWxyZWFkeSBsZWFrZWQg YXMgc29vbiBhcyBzb21lb25lIHNlbmRzIHNlbnNpYmxlIGRhdGEgbm90IG1lYW50IHRvIGJlIHBv c3NpYmxlIHRvIHJlYWQgYnkgYW55b25lIGJ1dCB0aGUgdHJ1c3RlZCBlbmRwb2ludC93ZWJzaXRl LiBXaGVuIHN1Y2ggYm94IGlzIG9uIHRvcCBjb21wcm9taXNlZCBsZWFrYWdlIGJlY29tZXMgYSBu ZXcgZGltZW5zaW9uLiBJIHN0aWNrIHdpdGggbXkgb3BpbmlvbiBvZiDigJ51bmZvcnR1bmF0ZeKA nCwgaXTigJhzIGV2ZW4gYW4gdW5kZXJzdGF0ZW1lbnQuIEJ1dCBub3QgZ29pbmcgdG8gZ2l2ZSBt b3JlIG90IGlucHV0IGhlcmUuDQo= --_000_09AF1E5B47BD406A885BAE1FFA2B511Eciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpZ b3UgYXBwZWFyIHRvIGJlIGFyZ3VpbmcgdGhhdCBiZWNhdXNlIGl0IGlzIHBvc3NpYmxlIHRvIGRv dWJsZS1lbmNyeXB0IHRoZXNlIGRldmljZXMgYXJlIHBvaW50bGVzcy4gVGhhdCBwcmVzdW1lcyB0 aGF0IHRoZSBlbmNyeXB0aW9uIGlzbuKAmXQgZGV0ZWN0YWJsZS4gJm5ic3A7SWYgeW91IGFyZSBh cmd1aW5nIGEgc3RlZ2Fub2dyYXBoeSBhdHRhY2ssIGl04oCZcyBwb3NzaWJsZSwgYnV0IG1heSBh bHNvIGJlIGRldGVjdGFibGUgaWYgdXNlZCBpbiBidWxrLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+Tm9uZSBvZiB0aGVzZSBzeXN0ZW1zIGFyZSBwZXJmZWN0IGJ1dCBzZWN1cml0eSBpc27igJl0 IGEgYmluYXJ5LiBJZiB5b3Ugd2VyZSB0byBhcmd1ZSB0byB0aGUgcGVvcGxlIHdobyB1c2UgdGhl c2UgcHJveGllcywga25vd2luZyB0aGVpciBjb3N0IGluIHRlcm1zIG9mIGNhcGl0YWwsIHN1cHBv cnQsIGFuZCB0aGVpciBvd24gcmlzayBhcyBhIHBvaW50IG9mIGZhaWx1cmUsIHlvdSB3b3VsZG7i gJl0IGdldCBmYXIuJm5ic3A7DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPGRpdiBpZD0iQXBw bGVNYWlsU2lnbmF0dXJlIiBkaXI9Imx0ciI+RWxpb3Q8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxi cj4NCk9uIEF1ZyAxOCwgMjAxOSwgYXQgMDg6MTEsIENocmlzdGlhbiBNZXV0ZXMgJmx0OzxhIGhy ZWY9Im1haWx0bzpjaHJpc3RpYW5AZXJyeHR4Lm5ldCI+Y2hyaXN0aWFuQGVycnh0eC5uZXQ8L2E+ Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj5PbiBTYXQgMTcuIEF1ZyAyMDE5IGF0IDIyOjQ1 LCBFbGlvdCBMZWFyIChlbGVhcikgJmx0OzxhIGhyZWY9Im1haWx0bzplbGVhckBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj5lbGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxk aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJhdXRvIj4NCjxkaXY+SXTigJlzIOKAnHVu Zm9ydHVuYXRl4oCdIHVudGlsIGl0IHN0b3BzIHNvbWVvbmUgZnJvbSBhYnNjb25kaW5nIHdpdGgg b3IgbGVha2luZyB5b3VyIHBlcnNvbmFsIGluZm9ybWF0aW9uLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+TGV04oCZcyBhdm9pZCB1c2luZyBzdWNoIGxvYWRlZCBsYW5ndWFnZS48L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0i YXV0byI+DQo8ZGl2PjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPldpdGggdGhvc2UgYm94ZXMgZGF0YSBp cyBhbHJlYWR5IGxlYWtlZCBhcyBzb29uIGFzIHNvbWVvbmUgc2VuZHMgc2Vuc2libGUgZGF0YSBu b3QgbWVhbnQgdG8gYmUgcG9zc2libGUgdG8gcmVhZCBieSBhbnlvbmUgYnV0IHRoZSB0cnVzdGVk IGVuZHBvaW50L3dlYnNpdGUuIFdoZW4gc3VjaCBib3ggaXMgb24gdG9wIGNvbXByb21pc2VkIGxl YWthZ2UgYmVjb21lcyBhIG5ldyBkaW1lbnNpb24uIEkgc3RpY2sgd2l0aCBteQ0KIG9waW5pb24g b2Yg4oCedW5mb3J0dW5hdGXigJwsIGl04oCYcyBldmVuIGFuIHVuZGVyc3RhdGVtZW50LiBCdXQg bm90IGdvaW5nIHRvIGdpdmUgbW9yZSBvdCBpbnB1dCBoZXJlLjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_09AF1E5B47BD406A885BAE1FFA2B511Eciscocom_-- From nobody Sun Aug 18 03:58: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 15A4A120090 for ; Sun, 18 Aug 2019 03:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfVjijeNjMhH for ; Sun, 18 Aug 2019 03:58:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB633120013 for ; Sun, 18 Aug 2019 03:58:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 918D3BE50; Sun, 18 Aug 2019 11:58:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIMrCiZS87UV; Sun, 18 Aug 2019 11:58:25 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 131EFBE39; Sun, 18 Aug 2019 11:58:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566125905; bh=n7IxXt3uX/+6/3k4NKZ3J4EutaqvwlBlrq8Ur4i/Vgw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=yFYizNH1OZ4+kFl4LxVED4KWLmJ2eKQdR8Axw55XhdI9m7PJ+AuZPhcQxBqWkay4p kN5MJS3t9Q2gGwzxNuQahs3CK6HXwJ2Y5g8yMZ8TKqKh2/Wa9dK1CQ4o6g6dDcXyrK EZ3jTWdrYza1oNBEwDE851Dmx9e8JgpUGEL9NzfI= Subject: Re: Blocking Quic traffic To: "Eliot Lear (elear)" , Christian Meutes Cc: IETF QUIC WG References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sun, 18 Aug 2019 11:58:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LtVNYDW3uA3EhS4wwjRwYuHiN5TZIwuQT" 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, 18 Aug 2019 10:58:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LtVNYDW3uA3EhS4wwjRwYuHiN5TZIwuQT Content-Type: multipart/mixed; boundary="BQkeIDuS2QwEDneZmQLGoOegpcigGxohr"; protected-headers="v1" From: Stephen Farrell To: "Eliot Lear (elear)" , Christian Meutes Cc: IETF QUIC WG Message-ID: Subject: Re: Blocking Quic traffic References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> In-Reply-To: <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> --BQkeIDuS2QwEDneZmQLGoOegpcigGxohr Content-Type: multipart/mixed; boundary="------------A051044D5A53D542F7653DA9" Content-Language: en-GB This is a multi-part message in MIME format. --------------A051044D5A53D542F7653DA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 18/08/2019 08:53, Eliot Lear (elear) wrote: > If you were to argue to the people who use these proxies, knowing > their cost in terms of capital, support, and their own risk as a > point of failure, you wouldn=E2=80=99t get far. FWIW, while I've heard that argument numerous times, I've don't recall ever seeing any convincing evidence that it's true. That's likely off-topic for this list though. Cheers, S. --------------A051044D5A53D542F7653DA9 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------A051044D5A53D542F7653DA9-- --BQkeIDuS2QwEDneZmQLGoOegpcigGxohr-- --LtVNYDW3uA3EhS4wwjRwYuHiN5TZIwuQT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1ZL08ACgkQWrL68XsX K+rCkBAAgmtSDid7AXFmgT6KZt+ExU6OijGozIpDt/AhnpYbID0Yrmz0djb5vtM7 RmUhKfB6XedjdAa9E1Qxrq3t6C8vrUwMlTaOOOgTWv+glSMx9iH9s6ETlz8g29Dz hRY1At2rG0XSvr7ZalzxlgPeTz/cMWFiz3RwOHwh4/0jR3NzLye+TiA3IiqPzPP6 9vNoheHRUanT/Jn5ASNOx7QD43CY+CyPrQDj/4LXOJ9l2keRg/6afWYgRdkO2KUC U/MBus494PWP1If6zFOSkJukasEHNTUzSPyKlV28n2bVA7xX/wS0jE9byLoFmf8W Z8bn2ar8c3hcc89q/mjP2ZdYgAxuA77d5mlqC5yuix7XiEL+BGFiR7DC9dJK6F1X Cgz/tqtWGv8LgfpLW74LACu7epCxo1iVXokUarXAmxcV9PYaPlqVobOkq5AnV19n NGQ/qpxXyoXjfa4FB7YCNk5BQU3FhrkxMTf/hh8D0FG8LHQQ09JGVyo3PKOPEHD0 ccf6FpvOIVQ+G/i9DsgTcUORx5z+2d6euMsWF781qhUOraEeDJ7GPGsXSe3H8kH1 yZZvbqknuzQYXVQmqPYNaxIyBzDatd3SoKiqRaMpixHT78eKvZ7Zn9H5CZyICDJM l/+ARpnUVtTgY7lJZ7WmWoI/l3xDaje4HOMtdh/JvmLcVRjAW/U= =toDb -----END PGP SIGNATURE----- --LtVNYDW3uA3EhS4wwjRwYuHiN5TZIwuQT-- From nobody Sun Aug 18 04: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 2236F120077 for ; Sun, 18 Aug 2019 04:55:31 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80bHiE_EcS_e for ; Sun, 18 Aug 2019 04:55:28 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA31C120170 for ; Sun, 18 Aug 2019 04:55:27 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id i22so15075132ioh.2 for ; Sun, 18 Aug 2019 04:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=11h2iN62Z9y3mCllwgEEi0uAXRoBwIjg/TaBAOwTolY=; b=cUsVJJOQ1/jTI+/9NxZ/8r4/U2+HVT47HzGCoYAH+6GlxGlsJ9AFA797MmKLyaToYV Tdwqcy5AEQTCEn7dgV+PQ90VLajYQ8BuE8vzHbIepEyXhQcbVBgy4yCODqHJXtnKmjQZ hpy11XJOy1KC+EUIYo/zKmGHWWpJ6Hr6rX9QVEmwQmBA1BvJhiKGe1pxSX4cs7EUNE1Y U9SLpRj21QDk0u/c250KK0TcIwqkNoQN5Ht2wB0fJcYDWlqpdItya6rTGaWvliAHgjNS V1ttiHs9DQY5HUJm4Tux7nTybVtBtrpWalytCDdOlWaQ/DGZ68cogJPgdY+6NtkJ32IY Fqlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=11h2iN62Z9y3mCllwgEEi0uAXRoBwIjg/TaBAOwTolY=; b=KgDRvF9qm5T1pIvcBhXQQbuLLXcGMZXcW1ChdlyFjPFcnMzBsAk1ledwkkb0C1ZB8a bMnUUSy5hprFo7JQYMfTfAQP/qPYaAaIb7d4M5wZx5SI8BQ+orGYcUsGUOxVvEJ1uuLG 7vgIm2pdfrAIxylhqwXMDKdTSYC2GypG+xdwNHHa/9tEuavw+YgHZPkvPHGXm8I3nKSp 8As4RGhDzKtX9Br62yFJxdyFS1c0cq69+vifJsBe7TfMhd1dJa0DEpZhpOTTSWhbvRRQ Wq5LnM0tcR1QrAPBjlN20qliCKcs7FC8nF/KmP8ScP5SneV7YhKdVbN/1sMjAIx/hhE8 StGg== X-Gm-Message-State: APjAAAV0LQFPPYkmScZbPv9STDTMRY3F+VRRYeFm+GNdC65DKnElQKGA LNkA1JCwVTBE0wZQA6YS1I7kczw5LrtUYiUV008= X-Google-Smtp-Source: APXvYqxXSsJLqZ7FS2COK537FjrH7aTxaLqmNq0JNRJy3nWLBMztmpXfAs6qVTaBaGafPEK+KX4W8mno2xEd9O9KI70= X-Received: by 2002:a5e:c247:: with SMTP id w7mr18012819iop.72.1566129327252; Sun, 18 Aug 2019 04:55:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:a3c1:0:0:0:0:0 with HTTP; Sun, 18 Aug 2019 04:55:26 -0700 (PDT) In-Reply-To: References: From: JH Date: Sun, 18 Aug 2019 21:55:26 +1000 Message-ID: Subject: Re: QUIC for IoT embeddeds system 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: Sun, 18 Aug 2019 11:55:31 -0000 On 8/18/19, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I believe the QUIC WG has its hand full just getting version 1 out of the > door. > The focus is not limited to HTTP although it is the only defined > application protocol for the time being. There is a fairly strict > separation between the transport layer (QUIC) and the application layer > (HTTP etc. over QUIC). Game application etc. may also be relevant and the= re > is separate ongoing work on WebRTC, Websockets, etc. in a new form over > QUIC - the WebTransport work may cover some or all of this. Are there any IETF QUIC open sources for clearly separation? Ideally, a QUIC git source should only contain QUIC core functionality, the moment you added HTTP, WebRTC, Web sockets to mix with the QUIC source, there will never be a clear separation. > The intention for IoT, as I undertand it, is for =E2=80=9Csomeone=E2=80= =9D to pick up the > ball and specify a new QUIC version aimed for constrained devices. QUIC i= s > designed to handle such protocol variations. If the QUIC spec can define core functions mandatory, variations and options can be added or removed for specific platforms or applications, that will make it easier to be adapted and adopted. For IoT embedded system, the size is critical for many small devices. > In the simplest form such a specification might do away with Retry, > migration, have a lighter initial packet, and support a only subset of > crypto algorithms. Note that a lighter initial packet is open to > amplification attacks so there might be some concerns about IP > whitelisting. That details should be handled by implementation if it is capable of plugging different fmodules or cryto algorithms. > Another aspect could be transport over non-UDP, non-IP fabric. The IP is the Internet, same as UDP or TCP, I don't see any non-IP, non-UDP or non-TCP can be succeeded. > That would not directly address HTTP/3 or other application protocols but > it would be a precondition. > I for one would like to see MQTT over a lighter version of QUIC. Applications and high level protocols can come and go, QUIC should follow in UDP/TCP/IP footstep. I am not clear if IETF has already got an experiment of QUIC open source or if it is going to develop one, appreciate your advice. Thanks Mikkel, - jupiter > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 18 August 2019 at 02.03.06, JH (jupiter.hce@gmail.com) wrote: > > Hi, > > I am new to QUIC and just joined the mailing list, it seems to me that > QUIC working groups focus on HTTP and Web applications. Are there any > WG working for small socket level QUIC client server for embedded > system? The requirements for embedded system QUIC is very much > different to large size of QUIC for HTTP, using small size socket > level QUIC in embedded system is long overdue, I will be very > interested in involving the embedded system QUIC development, > appreciate more information about IETF WG agenda and clarification. > > Thank you. > > Kind regards, > > - Jupiter > From nobody Sun Aug 18 05:08: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 CA605120077 for ; Sun, 18 Aug 2019 05:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Chtks8ObaVk for ; Sun, 18 Aug 2019 05:08:42 -0700 (PDT) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81491201C6 for ; Sun, 18 Aug 2019 05:08:41 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id s49so8859288edb.1 for ; Sun, 18 Aug 2019 05:08:41 -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=iQTeO+SWnGBK56jQaDNCDc0ZrEUNcqaxGSH/yKQwFac=; b=CREs+OTiFFgllCufOHhBzpw1+wqe6IhDxO/7VLEGoNDnXMFFzlmNIuWAqDMXr9lSxM 8hoqTIkJlrX3lZ4aQKOhnx7ys1je57GkoXodhkMawlw5CG5cMmIZ5OObhm+cVW4I3upt cy88fStLvIVsd4WMuO0+xoREAhIsc7FiywqLKcmHIfMSfQe7WNe9zR45RdfnetYm+Gsg /tZatRO9y9yLpR8I8Mccg4cKj2e6D2g7VofPWjZImCkDRklpu8Iq15qsLwnJUVf7Crf2 jFturY2p/mRKmge3J7/EtHrdUPb4B40tNFcafUrkg6qYygxGlw628BSZptq9qCkp4q/a NMgg== 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=iQTeO+SWnGBK56jQaDNCDc0ZrEUNcqaxGSH/yKQwFac=; b=S44e0kvy51dbULs7ccn67rKQOj8+rk5TmKbpuytusmtd3Y84iXvmh1OctQ+OBSnCAt huoZ5AIYwA8NNwYZUHWVuJ8noEFNSFDTpXrTKiK601CDFo1ONGwv9p413XXe/Jqdxx2r 04l0FbseIC23hB02ozn7PbVqxBRyQZF2AgvKndugxs+eEqZxX7lxl/OVHulZXeS4TaV1 I6AwFcuep/ZI19q+Ay7ktw+ywdNkeN0+DGO3hdCSdGACPKv+iQmK7kJmqeUrONM5zDlG qhv42zd58yaaf+W5x2U3UQtaZ0FoRAnX2SZZx5JG710G76f+cJauqjwGPJAn4qUfOqjW ikuw== X-Gm-Message-State: APjAAAU+pm4M7833QBBV1vsHztM39pRk8i6A0OvlAzMfeSYEDiWC7Ky6 LVvCxe8sENslI4qGLb8GfpiJvHe/RzDKSUSKRb8= X-Google-Smtp-Source: APXvYqwW+HVkIRiUA1GL3mX+h6f2mn1MucNd4SnUGht7ash2k/QI9m58jRQOboB0G9VXoY1RRl77uX2C450pDD37lnU= X-Received: by 2002:a17:906:f211:: with SMTP id gt17mr16593552ejb.263.1566130120503; Sun, 18 Aug 2019 05:08:40 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 18 Aug 2019 08:08:39 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 18 Aug 2019 08:08:39 -0400 Message-ID: Subject: Re: QUIC for IoT embeddeds system To: JH Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000081361c0590631548" 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, 18 Aug 2019 12:08:44 -0000 --00000000000081361c0590631548 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See inline On 18 August 2019 at 13.55.27, JH (jupiter.hce@gmail.com) wrote: Are there any IETF QUIC open sources for clearly separation? Ideally, a QUIC git source should only contain QUIC core functionality, the moment you added HTTP, WebRTC, Web sockets to mix with the QUIC source, there will never be a clear separation. https://github.com/quicwg/base-drafts The invariants is what never change - it is very small document. The transport document is the core QUIC document - with supporting TLS and retransmission docs. The HTTP and QPACK are separate from that but still part of the eventual QUIC v1 delivery. > The intention for IoT, as I undertand it, is for =E2=80=9Csomeone=E2=80= =9D to pick up the > ball and specify a new QUIC version aimed for constrained devices. QUIC i= s > designed to handle such protocol variations. If the QUIC spec can define core functions mandatory, variations and options can be added or removed for specific platforms or applications, that will make it easier to be adapted and adopted. For IoT embedded system, the size is critical for many small devices. I personally don=E2=80=99t think modular plug and play is a good thing here= . Different QUIC versions with limited functionality is better - it keeps things simple and reduces interop complexities and attack vectors. As to encryption, I could imagine a version that doesn=E2=80=99t use TLS at all, = but simply settles for simplified ChaCha/Poly handshake with ED25519 key exchange, and optional AES-GCM. Such a version would use many primitives from TLS but with reduced overhead. The downside is if the crypto vulnerability is discovered, but that can be fixed in a new QUIC version. A QUIC version could be modular in the sence that you have multiple versions that each flag in one or more features from a base version such as QUIC v1 but then there might be say 4 different profiles or versions, rather than infinitely many combinations. QUIC versioning and fallback attack protection isn=E2=80=99t fully designed= yet but will likely be a priority just after v1 release. > Another aspect could be transport over non-UDP, non-IP fabric. The IP is the Internet, same as UDP or TCP, I don't see any non-IP, non-UDP or non-TCP can be succeeded. IoT isn=E2=80=99t necessarily running on the internet. You can have mesh ne= tworks for power metering or in-car electronics. That said, at least one IoT version would likely be UDP centric. --00000000000081361c0590631548 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = See inline

On 18 August 2019 at 13.55.27, JH (jupiter.hce@gmail.com) wrote:

Are there any IETF QUIC open sources for clearly separation? I= deally,=C2=A0
a QUIC git so= urce should only contain QUIC core functionality, the=C2=A0
moment you added HTTP, WebRTC, Web sockets= to mix with the QUIC=C2=A0source, there will never be a clear separation.=C2=A0

https://github.com/quicwg/base-draf= ts

The invariants is what never change - it is very small documen= t.

The transport document is the core QUIC document - with supporting= TLS and retransmission docs. The HTTP and QPACK are separate from that but= still part of the eventual QUIC v1 delivery.


>= The intention for IoT, as I undertand it, is for =E2=80=9Csomeone=E2=80=9D= to pick up the=C2=A0
> = ball and specify a new QUIC version aimed for constrained devices. QUIC is<= span class=3D"Apple-converted-space">=C2=A0
> designed to hand= le such protocol variations.=C2=A0

If the QUIC spec can define core functions mandatory, variation= s and=C2=A0
options can be = added or removed for specific platforms or=C2=A0
applications, that will make it easier to be adapted = and adopted. For=C2=A0
IoT = embedded system, the size is critical for many small devices.=C2=A0
=

I personally don=E2=80=99t think modular plug and play is a good thing h= ere. Different QUIC versions with limited functionality is better - it keep= s things simple and reduces interop complexities and attack vectors. As to = encryption, I could imagine a version that doesn=E2=80=99t use TLS at all, = but simply settles for simplified ChaCha/Poly handshake with ED25519 key ex= change, and optional AES-GCM. Such a version would use many primitives from= TLS but with reduced overhead. The downside is if the crypto vulnerability= is discovered, but that can be fixed in a new QUIC version.

A QUIC v= ersion could be modular in the sence that you have multiple versions that e= ach flag in one or more features from a base version such as QUIC v1 but th= en there might be say 4 different profiles or versions, rather than infinit= ely many combinations.

QUIC versioning and fallback attack protection= isn=E2=80=99t fully designed yet but will likely be a priority just after = v1 release.


> Another aspect could be transport= over non-UDP, non-IP fabric.=C2=A0

The IP is the Internet, same as UDP or TCP, I don't see an= y non-IP,=C2=A0
non-UDP or = non-TCP can be succeeded.=C2=A0

IoT isn=E2=80=99t necessarily run= ning on the internet. You can have mesh networks for power metering or in-c= ar electronics.

That said, at least one IoT version would likely be U= DP centric.


--00000000000081361c0590631548-- From nobody Sun Aug 18 05:16: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 895B61201DE for ; Sun, 18 Aug 2019 05:16:53 -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_HELO_NONE=0.001, 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 9m-_lwqz8ul1 for ; Sun, 18 Aug 2019 05:16:52 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67CD120077 for ; Sun, 18 Aug 2019 05:16:51 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id s15so8866996edx.0 for ; Sun, 18 Aug 2019 05:16:51 -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=Kfq600qA0YqtrnoSLGGXDxMbT0FE2RBMs6eIiU2OAa4=; b=saFplWjp1auXGY2nmyZGsjYMuIOKUpMZSkhIioBkRK3xYk6zTTPe6tdBNPRo/rSIE9 URuc8okRxdhzXGY6Idt+JXcTG1NUYZgweue9vp6ql0ZJdSnnjxvgXUX7U+w3YyVl6NL6 AunxXvFJoiv3k/ik+u1v6rDE0zOwoHVas0Yd8WKxpReiFaBUg4BFb6D/VNKmDwDaQ6eZ stL0vhB8WOJttksumCIcDR+syGFcUv4kzuc7j4XJwcOIUefZDhxFPjTAPvj9FNbFvrRh BnOuCwoC8mq47GKszUETIy2Tk5swPEF9kW0uKUZ0dMjMYsRZXyjfRA8qYI/ftrlz7Y5F 7jhg== 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=Kfq600qA0YqtrnoSLGGXDxMbT0FE2RBMs6eIiU2OAa4=; b=CRfhVN9unao2+5OJJ5EBL/06nHFHzqqleKGxWZ/Jqv4OfzhBRdznbHsC4EIjsVHhd2 kkdC8VW3KcTNsI0P00/82uOSTnVh38ssgsMBuK4ceKSqkKoTgkzA52zfaF6HsF460NJD O8A0sBz3+z5ci7bi5DVPCbuE5VVf+iBuYj7q8tA/Uckv74z7y4itdhbNajzTBW+s0h2c GHQ5jufcpvUReSItI2DtOk2JdK1HAI0iGQEucSZpQehWkT9Ax5eue5jZO8kp9rppFkZy YnL782k5AiKDMfXTGnFXlHgeXVxy+hXfhUCmI1Yw1FJ82M+0CgT58jl5QjEgVqRmYXhv g/4w== X-Gm-Message-State: APjAAAVMkPjn5f2t9pBezUKTNUSsmg+2S3+l/Q430LqX8Nuot/10Sjki YkOcbeFnzD2cxNaRcwmQ+imeKACLI2q/S91TRt4= X-Google-Smtp-Source: APXvYqxLsYCRns+NqtojMBQoRCEFW7hmaXeRyrQCiP2KBvnKBeTzwNL4cOD4xne/MIijJQYr7MS0vB1oerpTzBwdLj8= X-Received: by 2002:a17:906:158c:: with SMTP id k12mr17171209ejd.83.1566130610547; Sun, 18 Aug 2019 05:16:50 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 18 Aug 2019 08:16:50 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 18 Aug 2019 08:16:50 -0400 Message-ID: Subject: Re: QUIC for IoT embeddeds system To: JH Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b6afbf0590633226" 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, 18 Aug 2019 12:16:53 -0000 --000000000000b6afbf0590633226 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IoT isn=E2=80=99t necessarily running on the internet. You can have mesh ne= tworks for power metering or in-car electronics. That said, at least one IoT version would likely be UDP centric. Well, technically it is by definition the internet as IoT means "Internet of Things=E2=80=9D, but taken in a broader context, many non-trivial embedd= ed and constrained devices will run at the perimeter of the Internet with aggregators/gateways doing the actual Internet thing. --000000000000b6afbf0590633226 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

IoT isn=E2=80=99t necessarily running on the internet. You can hav= e mesh networks for power metering or in-car electronics.

That said, = at least one IoT version would likely be UDP centric.

=

Well, technically it is by definition th= e internet as IoT means "Internet of Things=E2=80=9D, but taken in a b= roader context, many non-trivial embedded and constrained devices will run = at the perimeter of the Internet with aggregators/gateways doing the actual= Internet thing.

--000000000000b6afbf0590633226-- From nobody Sun Aug 18 06:59: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 0641C12008C for ; Sun, 18 Aug 2019 06:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=m1DvTuUp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0It5dRE3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTZ6mcd9kzvz for ; Sun, 18 Aug 2019 06:59:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E40C120024 for ; Sun, 18 Aug 2019 06:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=986; q=dns/txt; s=iport; t=1566136755; x=1567346355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=x8ap4xaqDC7v7ELlrJkvRS0ENkY8akDPOtERl63RP9Q=; b=m1DvTuUpnhbhhapRjlgJyJEW54wIpWCL/LTfke415QKx3PKjN2XQG9Es 31EpJSemS2nUU4KGze6h0pewTaSn7LwIGlnnvKoyfwPV8fOSw8nvvqpOo p9sELfYg2cFT6PSfzhkCgxUW9WNZV5wJQpHOZc7BV5y5tgViBOC+KOVq/ Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AaTRkCxAxrDvugb4e2xddUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg93kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIfrnZjYSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AABiWVld/5pdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVgMBAQELAYFEUAOBQiAECyqEH4NHA4p5gjcll2WCUgNUCQEBAQw?= =?us-ascii?q?BAS0CAQGEPwIXgwMjNwYOAgUBAQQBAQECAQYEbYUnDIVKAQEBAQIBEhERDAE?= =?us-ascii?q?BNwEECwIBCBgCAiYCAgIwFRACBA4FIoMAgWsDDg8BAp0FAoE4iGFzgTKCegE?= =?us-ascii?q?BBYJHgkMYghQJgQwoAYtZDxeBQD+BEScME4JMPoREF4J0MoImjxWcQAkCgh2?= =?us-ascii?q?UORuYRKVlAgQCBAUCDgEBBYFmIoFYcBU7KgGCQYJCg3KKU3KBKY0TAQE?= X-IronPort-AV: E=Sophos;i="5.64,401,1559520000"; d="scan'208";a="530731821" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2019 13:59:13 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x7IDxD3a016712 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 18 Aug 2019 13:59:13 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 08:59:12 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 08:59:12 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 18 Aug 2019 08:59:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GRBYPDeRWH8fekZGBGNp/SBJI1bSo6wJ6HzEVvyevYCGFYJbgmtFlUAwGCKr7K5YQw9ep+PoMl+yPFvc9Wo5kN7fPDMGfWi384ehrIsYtzXJKBX2R2i6yM5Nl0u3h+c+qrxLqZR34FWOqUfgDxcqnZ6p0YXPWPzdDgyERHZmUpXY2gc2++W1Jk5LMD7GvElLk4iCFFEZqyexAWW1Nm2KaujkehFCGfJCN66UnfUchDC/QaWLmxdhge2wQfPHyfuZ7PVnjc5to1AsZG2tAC8WL8+WvbZwaYtEoWtDwSk5LC1WPgb+D+2LOSM8AEShN3jElTJ+NI36ZU6+pG2APBVHKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x8ap4xaqDC7v7ELlrJkvRS0ENkY8akDPOtERl63RP9Q=; b=Hhs5zEmoEhvW6MKYmDy8EfodrS6V0z4ULTf+198vukp6/iMqLf07tzu/J0eSFFx52QeF3sRhvsUN4SgoZz5t9CpWnVzdJDUpxuqI2VeUg7wi+anoySjNHz1Hc3ziFfVmQ6JgVxhq4GoMfiNVqpTG2i/KQTHnEVPCO0acxe7dgEa8VqAgo4pUXenDcrl9VRXA+SIkx/ZPmkeMI9FNKEd9csRUeATx+5F65EOj00pb4Yi4s1sPioEmtR4N1k3DBOHR1PgQL0LGH+14oM5rLhWpEDLHLc9lFLStJ7dg9obscEEew5Z97y9gk7GPTtk4poeimy0SXiQAxnbr8CYjQ6fsKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x8ap4xaqDC7v7ELlrJkvRS0ENkY8akDPOtERl63RP9Q=; b=0It5dRE394b/1OShQFbwcqgLvGQNfoahn9CumOtzH13Y7W9/5+PmJIhUIzJJGx9JezgelGQUPVkwFoOtiYym019bYykJuPeNrekIuPRWdKVsQwtDNBlQ5Ju2nHNccP/1l0V+CKb6aS+RYol64xBdBUDKr2WLCrqkB00fqaZ8Wu8= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB3206.namprd11.prod.outlook.com (20.177.127.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Sun, 18 Aug 2019 13:59:11 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::9c45:80a6:52eb:7f1d]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::9c45:80a6:52eb:7f1d%4]) with mapi id 15.20.2178.018; Sun, 18 Aug 2019 13:59:10 +0000 From: "Eliot Lear (elear)" To: Stephen Farrell CC: Christian Meutes , IETF QUIC WG Subject: Re: Blocking Quic traffic Thread-Topic: Blocking Quic traffic Thread-Index: AQHVUe2wfsrAib4GYkCEHYQQKVuPIab5dhwAgAAEFwCABeBjgIAAetnUgACd/QCAABy7+IAAM7KAgAAyg1A= Date: Sun, 18 Aug 2019 13:59:10 +0000 Message-ID: References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.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=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:38fa:312a:9f30:b93d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 50af240c-a978-4c3d-76de-08d723e43ed3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3206; x-ms-traffictypediagnostic: BYAPR11MB3206: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(346002)(39860400002)(396003)(199004)(189003)(4326008)(14444005)(76176011)(33656002)(64756008)(53936002)(25786009)(186003)(6512007)(102836004)(316002)(4744005)(14454004)(7116003)(3480700005)(54906003)(99286004)(6246003)(86362001)(5660300002)(6116002)(6486002)(76116006)(476003)(2616005)(91956017)(305945005)(71190400001)(71200400001)(8676002)(6916009)(446003)(66946007)(46003)(6436002)(478600001)(7736002)(11346002)(2906002)(53546011)(6506007)(36756003)(81156014)(81166006)(8936002)(66446008)(256004)(66556008)(229853002)(66476007)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3206; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: FWzgUwf8abbBnpO6L29a4rHEXP4XFgp8s3L9DWjpBc7RQduuMuIxirLzIsfgizOa2bHJC6ddWVg5MIUhIBPt9FmPBj42zC3RUqhiMWseDCGS8kv3xGumkhw/oDdfpFj1zHVcxspiBSsF9lW1Jp40nExko7lsWSkFkjjtL5j9AAf9BFbkyz/1YIoHy3129fm3716XgTNM3hBGrsKZqVDtVdSn4qLBN/BGerFF6HbTKIkvHsRP4C/K+9OJAYJDUBDD4Yd5XoCs+8aSRl6tcqUCfma98ySQIbs5Y/cVDAmjxl2+JLoUe3DHfaGVxXD99NKTn4GAIRXuMaZoRnR8s430QkqGawopGQKsj3MlY27ATuUTt8ZZvO6uyd4diMcx+bHlHgExcIyG3oRWgVoMG0koA/XIECRjgl5I2TdNfBuJHLY= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 50af240c-a978-4c3d-76de-08d723e43ed3 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2019 13:59:10.7937 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qcUy7qeVIJ3eJwRFu769VXktbqUvzU3vui2UfjtzL5kwxBPrJXHwLLtlznin0jgc X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3206 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-3.cisco.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: Sun, 18 Aug 2019 13:59:17 -0000 SXTigJlzIG5vdCByZWFsbHkgYW4gYXJndW1lbnQsIGJ1dCBhbiBvYnNlcnZhdGlvbiBvZiBjYXBp dGFsIGV4cGVuZGl0dXJlcyByZXN1bHRpbmcgZnJvbSBhIHJpc2sgYXNzZXNzbWVudC4gIFRoZSBt b25leSBzcGVha3MgZm9yIGl0c2VsZi4NCg0KRWxpb3QNCg0KPiBPbiBBdWcgMTgsIDIwMTksIGF0 IDEyOjU4LCBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3Rl Og0KPiANCj4gDQo+IEhpeWEsDQo+IA0KPj4gT24gMTgvMDgvMjAxOSAwODo1MywgRWxpb3QgTGVh ciAoZWxlYXIpIHdyb3RlOg0KPj4gSWYgeW91IHdlcmUgdG8gYXJndWUgdG8gdGhlIHBlb3BsZSB3 aG8gdXNlIHRoZXNlIHByb3hpZXMsIGtub3dpbmcNCj4+IHRoZWlyIGNvc3QgaW4gdGVybXMgb2Yg Y2FwaXRhbCwgc3VwcG9ydCwgYW5kIHRoZWlyIG93biByaXNrIGFzIGENCj4+IHBvaW50IG9mIGZh aWx1cmUsIHlvdSB3b3VsZG7igJl0IGdldCBmYXIuDQo+IEZXSVcsIHdoaWxlIEkndmUgaGVhcmQg dGhhdCBhcmd1bWVudCBudW1lcm91cyB0aW1lcywgSSd2ZSBkb24ndA0KPiByZWNhbGwgZXZlciBz ZWVpbmcgYW55IGNvbnZpbmNpbmcgZXZpZGVuY2UgdGhhdCBpdCdzIHRydWUuDQo+IA0KPiBUaGF0 J3MgbGlrZWx5IG9mZi10b3BpYyBmb3IgdGhpcyBsaXN0IHRob3VnaC4NCj4gDQo+IENoZWVycywN Cj4gUy4NCj4gPDB4NUFCMkZBRjE3QjE3MkJFQS5hc2M+DQo= From nobody Sun Aug 18 09:16: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 9FA9F12004C for ; Sun, 18 Aug 2019 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SP9FwK2a; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e+Ujh3v2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDUpZQIHCfFZ for ; Sun, 18 Aug 2019 09:16:40 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4068120059 for ; Sun, 18 Aug 2019 09:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1864; q=dns/txt; s=iport; t=1566145000; x=1567354600; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SoW2wmDb9gUYVBjWG/HWAbqrYL5bBJ0iAbMtrc5QBGk=; b=SP9FwK2a8y5bPKuXWvblo4ZR4wYMYxbYvInf79VIRQ0B6eAjzZvM8gZb zMSF4VuSZ4VVSLNs/LMikFe1woHFGKfqp/JVmieSvJFjdQI7g0cjZcmcA KjVQGnC/W/wEjDnUNFfukcsVYCisXBp6VgMYUTByrRdqrRz0FHKLQKZgy 4=; IronPort-PHdr: =?us-ascii?q?9a23=3APzLq0BG1vg84iN/2KvmwBZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efPuYiUgNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAADEeFld/5NdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVgMBAQELAYFEUAOBQiAECyqEH4NHA4p6gjcll2WCUgNUCQEBAQw?= =?us-ascii?q?BAS0CAQGEPwIXgwMjNwYOAgUBAQQBAQECAQYEbYUnDIVKAQEBAQIBEhERDAE?= =?us-ascii?q?BIxQBBAsCAQgYAgImAgICMBUQAgQOBSKDAIFrAw4PAQKcewKBOIhhc4Eygno?= =?us-ascii?q?BAQWFDhiCFAmBDCgBi2gXgUA/gTgME4JMPoQdJ4MLMoImjxWbU20JAoIdi2W?= =?us-ascii?q?IVBuRCYc7pWUCBAIEBQIOAQEFgWYigVhwFTsqAYJBgkIMF4NPilNygSmKTIJ?= =?us-ascii?q?SAQE?= X-IronPort-AV: E=Sophos;i="5.64,401,1559520000"; d="scan'208";a="312821525" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2019 16:16:39 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x7IGGdws010402 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 18 Aug 2019 16:16:39 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 11:16:39 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 11:16:38 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 18 Aug 2019 11:16:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GsNKDRlGnS0n4uGc1JRoIoqYfwfFri2cpk53tnS8RiGwpNBXV0aXnhLlmAYO5LdwupLBdBbq7JAEk2WbZ4uNR6MHTkUvZbIPTlm/AN8GBlAGQ6LXzoKEAwfaJH3XLhxQuqbseMem1ARlNOChML7uku0yCI8dk45GTsKSxEQpjohGFefv58HLmaVlqWLvzSAcLmUtipXa6OlqiTb1D+BYRVkPlZhI7oU87+E609babpe9Il4GqQeSikV59z7jsBw0OaN13rS11dJBR78vhKleBqHG6VEYKqkjNfpu3Ny2NloQUkL52DSd2h04WUShaL1vO0kRr6f2n1/xAnMiIq8kdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SoW2wmDb9gUYVBjWG/HWAbqrYL5bBJ0iAbMtrc5QBGk=; b=hGn9+N/Z9uDlQEmtylE0JKa0u0UBnmBHPnAr5iCQSJ00mLF6fehmwewvkQgl/QN7hpKxMosQsTJ0WgGxGyn+YJYFp676YIMa5JhMUQX5WzHQHRCaAiztLNPRDygj5EFRGiTXlJERyj+SNAxlGb0/5dDSrJbWKyVj2tQaEqJOQC0+B5wJxNLws3xvvl/q4D3Fj5lrns/UnNcSkhUB/RigiD/EZ8BYOMwe09/4w8aRRk4nJL1pxSK3iQi27NKscQ8563Fdjr0R6mm8Z31vhZb7rj9tZVgIUiBmaf6JTXIb+Jo8kqqk5MhJz5AdfPNDc7dwCL7q4c1cBGjabcI6/6QV7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SoW2wmDb9gUYVBjWG/HWAbqrYL5bBJ0iAbMtrc5QBGk=; b=e+Ujh3v2mYECq5s7t8g/6mwI8uKkgOSYvdgkIDxNrVnt8lLBhFhn03I+S/ZJpNBNrqE7I65xuXyn2eBPdwtngX6rDwlIAFa/4luL09dcxXZ88f+DhYw5VfdeB2dXHZ63cPAYZ6F3eRAI/kN9Zm5c/QmhJPIroHfGxjKizyTMVWI= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB2950.namprd11.prod.outlook.com (20.177.187.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Sun, 18 Aug 2019 16:16:37 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::9c45:80a6:52eb:7f1d]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::9c45:80a6:52eb:7f1d%4]) with mapi id 15.20.2178.018; Sun, 18 Aug 2019 16:16:37 +0000 From: "Eliot Lear (elear)" To: Christian Huitema CC: Stephen Farrell , Christian Meutes , IETF QUIC WG Subject: Re: Blocking Quic traffic Thread-Topic: Blocking Quic traffic Thread-Index: AQHVUe2wfsrAib4GYkCEHYQQKVuPIab5dhwAgAAEFwCABeBjgIAAetnUgACd/QCAABy7+IAAM7KAgAAyg1CAAB8JgIAAB14d Date: Sun, 18 Aug 2019 16:16:37 +0000 Message-ID: <73CCBDEB-9153-41F8-A318-87CEF3A5D8D0@cisco.com> References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> , <1118E0BB-7631-4D29-9264-22FE33E46FDD@huitema.net> In-Reply-To: <1118E0BB-7631-4D29-9264-22FE33E46FDD@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:38fa:312a:9f30:b93d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d18a9fcc-979b-4e19-089b-08d723f7723e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2950; x-ms-traffictypediagnostic: BYAPR11MB2950: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(366004)(376002)(346002)(189003)(199004)(296002)(102836004)(53546011)(316002)(256004)(14444005)(54906003)(6506007)(76176011)(33656002)(6916009)(478600001)(46003)(6486002)(7116003)(229853002)(71200400001)(14454004)(486006)(36756003)(71190400001)(99286004)(186003)(446003)(2616005)(6512007)(53936002)(66946007)(66556008)(76116006)(91956017)(6116002)(305945005)(7736002)(64756008)(6246003)(6436002)(476003)(66476007)(66446008)(11346002)(25786009)(86362001)(2906002)(4326008)(5660300002)(3480700005)(81156014)(81166006)(8936002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2950; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hULFu4JlMTU3MvERrYLxkB9z9pcwggOeledgFLLr6N6YaBIA35XH5feoYbp3j3Z0LLRcRX2WLm1Ztr1qbtj4R6aFj/aDi+3sAMGTVlAWhItZtcGzXtAcTPOtcJaV/8tFezhS/XZniNg8XMy7rc2aAGNKIYo0Rn8yjpEte3xtXGhLQWS5+zlGfw+m8Hqe1hfG2pTuPYj3iHJuIzE3dK9as7LReZ0o/ZeSxvc4OLw68WAefc0O+QnDP4qve92yc2J1ZQ+D3FaNm84rdOXlMl/bMrokJ+yTaB7mArhsY/L9JM1xfQF5eJK2jL3rhKBA/1+Il9XlHgBSQJYSAfp82EAszdDLekzyJ4QI3vjxd6WhbzVhVdMk4chLaDQGS5IapvSegVHUFoK4pL1//vaISnYeoqiSXRfSPCiTRtOheKtthew= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d18a9fcc-979b-4e19-089b-08d723f7723e X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2019 16:16:37.4438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nLTjYN6E7vti4MiBjNp35B1nxTL/jTewzKeKQpXH9htxBIF5/VAF2VRGbKHMSyzj X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2950 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-11.cisco.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: Sun, 18 Aug 2019 16:16:43 -0000 DQoNCg0KPiBPbiBBdWcgMTgsIDIwMTksIGF0IDE3OjU0LCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVp dGVtYUBodWl0ZW1hLm5ldD4gd3JvdGU6DQo+IA0KPiBUaGVyZSBpcyBubyBkb3VidCB0aGF0IHRo ZXJlIGFyZSBjdXN0b21lcnMgZm9yIHRoZXNlIGJveGVzLiBUaGUgdW5mb3J0dW5hdGUgcGFydCBp cyBub3QgYSBtYXR0ZXIgb2YgZGVwbG95bWVudCBjb3N0IG9yIHJlc2lzdGFuY2UgdG8gY291bnRl ciBtZWFzdXJlcyBsaWtlIGRvdWJsZSBlbmNyeXB0aW9uLiBUaGUgdW5mb3J0dW5hdGUgcGFydCBm b3IgdGhlIGVudGVycHJpc2UgaXMgdGhlIGV4cG9zdXJlIHRvICJ0b3hpYyBkYXRhIiwgcHJpdmF0 ZSBkYXRhIHRoYXQgaXMgZ2F0aGVyZWQgYXMgYSBzaWRlIGVmZmVjdCBvZiBicmVha2luZyBlbmNy eXB0aW9uLiBDb3VsZCBiZSBmb3IgZXhhbXBsZSBtZWRpY2FsIGRhdGEgb3IgZmluYW5jaWFsIGRh dGEgb2YgZW1wbG95ZWVzLiBTdWNoIGRhdGEgYXJlIHN1YmplY3QgdG8gc3RyaWN0IHJlZ3VsYXRp b25zLiBJbmFkdmVydGVudCBsZWFrYWdlIHdvdWxkIGV4cG9zZSB0aGUgZW50ZXJwcmlzZSB0byBh IHZhcmlldHkgb2YgbGF3c3VpdHMgYW5kIHBlbmFsdGllcy4gUHJvdGVjdGluZyBhZ2FpbnN0IHN1 Y2ggbGVha2FnZSBjYW4gYmUgdmVyeSBjb3N0bHksIGhlbmNlIHRoZSB0b3hpYyBkYXRhIG1vbmlj a2VyLiBJIGtub3cgYXQgbGVhc3Qgb25lIGVudGVycHJpc2UgdGhhdCBnb3QgcmlkIG9mIHRoZXNl IGVuY3J5cHRpb24gYnJlYWtpbmcgYm94ZXMgaW4gcGFydCBiZWNhdXNlIG9mIHRoYXQgY29uY2Vy bi4NCg0KWWVzLiBUaGF04oCZcyBhIHJpc2sgYXMgd2VsbC4gIEl04oCZcyBwYXJ0aWFsbHkgbWl0 aWdhdGVkIGluIHNldmVyYWwgd2F5czoNCg0KKiBBIGxpc3Qgb2YgZG9tYWlucyBvciBVUkxzIHRo YXQgYXJlIG5vdCB0byBiZSBkZWVwbHkgaW5zcGVjdGVkOw0KKiBMaW1pdGVkIG9yIG5vIGRhdGEg cmV0ZW50aW9uIChhdCBsZWFzdCBvbmUgc3lzdGVtIEkga25vdyBvZiBqdXN0IHNlYXJjaGVzIGZv ciB3aGF0IGlzIGxpa2VseSB0byBiZSBQSUkgaW4gb3JkZXIgdG8gcHJldmVudCB0aGF0IGxlYWth Z2UpOyBhbmQNCiogSGlnaGx5IHJlc3RyaWN0ZWQgYWNjZXNzIHRvIHRoZSBwcm94eSBpdHNlbGYu IA0KDQpOb25lIG9mIHRoZXNlIGNvbXBsZXRlbHkgZWxpbWluYXRlIGEgcmlzayBvZiBhIGxlYWsg LSB0aGVyZSBpcyBhbiBpbnRlcmxvcGVyLiBidXQgdGhhdCBoYXMgdG8gZ2V0IGJhbGFuY2VkIGFn YWluc3Qgb3RoZXIgcmlza3MuIEFuZCBieSB0aGUgd2F5LCBzb21lIG9mIHRoaXMgaXMgdGhlIGRp cmVjdCByZXN1bHQgb2YgcHJpdmFjeSByZWd1bGF0aW9uLg0KDQpFbGlvdA0KDQoNCg== From nobody Sun Aug 18 11:17: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 BFFC2120143 for ; Sun, 18 Aug 2019 11:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 tHGefCYhlrsx for ; Sun, 18 Aug 2019 11:17:31 -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 41E12120133 for ; Sun, 18 Aug 2019 11:17:31 -0700 (PDT) Received: from xse411.mail2web.com ([66.113.197.157] helo=xse.mail2web.com) by mx148.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1hzNTr-000aSC-1O for quic@ietf.org; Sun, 18 Aug 2019 17:53:28 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 46BM2c75MHzP7P for ; Sun, 18 Aug 2019 08:50:16 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1hzNRg-0000dn-Sr for quic@ietf.org; Sun, 18 Aug 2019 08:50:16 -0700 Received: (qmail 12168 invoked from network); 18 Aug 2019 15:50:16 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.143]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Aug 2019 15:50:16 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Blocking Quic traffic From: Christian Huitema X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Sun, 18 Aug 2019 08:50:15 -0700 Cc: Stephen Farrell , Christian Meutes , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <1118E0BB-7631-4D29-9264-22FE33E46FDD@huitema.net> References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> To: "Eliot Lear (elear)" X-Originating-IP: 66.113.197.157 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Wp43USNh4+oPQIPr3x336CpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fu1KYTzSdibbn2QtzALf3s5U7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/ixIHpNwYH6dG/jiqllt/T7yme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8SnwqlUrBK2R/GBg9vCpMGFHw53FxnHnL50HZvyS1o3x98IkV0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm2uprb+vd2Fz Rl4tm4DfGPPYb7x0LxPWX7Xb47z6RVoqYerePeoIGhTa8vNl/+O2oAeYUOp7A73HI6oJg7w/VocK FIxNlsy2WJpil5s07kEDyBw3j/aBxjxoZyMqfIL/jJq7xqDoiTjjGpNS1XGXbXLXiQnVqA9+05qw faTvv/ZAAztqzrCt4TZ/wLtujY/tpYnYjc99tBmdwv3EJZKqzHQa9CY4WZP+PiNsjrzmsOwzPAlb DjazCbhs7qBpykynMha5/rijjcguRYfyvX/qs6CppFXEET5vFUK03hUXmver83g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8= 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: Sun, 18 Aug 2019 18:17:33 -0000 =20 > On Aug 18, 2019, at 6:59 AM, Eliot Lear (elear) wrote: >=20 > It=E2=80=99s not really an argument, but an observation of capital expendi= tures resulting from a risk assessment. The money speaks for itself. There is no doubt that there are customers for these boxes. The unfortunate p= art is not a matter of deployment cost or resistance to counter measures lik= e double encryption. The unfortunate part for the enterprise is the exposure= to "toxic data", private data that is gathered as a side effect of breaking= encryption. Could be for example medical data or financial data of employee= s. Such data are subject to strict regulations. Inadvertent leakage would ex= pose the enterprise to a variety of lawsuits and penalties. Protecting again= st such leakage can be very costly, hence the toxic data monicker. I know at= least one enterprise that got rid of these encryption breaking boxes in par= t because of that concern. -- Christian Huitema=20= From nobody Sun Aug 18 14:10: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 9BA65120110 for ; Sun, 18 Aug 2019 14:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gveXt-yWIuZd for ; Sun, 18 Aug 2019 14:10:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B060D120047 for ; Sun, 18 Aug 2019 14:10:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D021BBE39; Sun, 18 Aug 2019 22:10:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQhVbpgw_UxZ; Sun, 18 Aug 2019 22:10:42 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 483D9BE20; Sun, 18 Aug 2019 22:10:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566162642; bh=evJ0yyG7SoND6AxO7VwUa6ky5ZDUZg+VLRrJKE3DUUE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=oo41sCBnjHlqrqZqGIET0RCL6ZQsBdQcdVxIe+0nvgwfRqrw6lNKpC2ej6MwBDmL/ gUrG4ZJZbl2+9YvSpANt4rK7i3Rmo/tSLgA/jcosXXsnRQ2JQh9OMMP9QPpgQ376yI TumSLsvOqgM/oWdn67JJZmg042bw6aqqDdKSa9FM= Subject: Re: Blocking Quic traffic To: "Eliot Lear (elear)" Cc: IETF QUIC WG References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <2ec8da3f-66f9-ec90-a80c-8b6e715a9c28@cs.tcd.ie> Date: Sun, 18 Aug 2019 22:10:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PMHhXciX3IstxYoaZE7pxHRaMNiR6dZtf" 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, 18 Aug 2019 21:10:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PMHhXciX3IstxYoaZE7pxHRaMNiR6dZtf Content-Type: multipart/mixed; boundary="qbgsqMjTR3ed0pncQVPvpfRwFirVw8oBk"; protected-headers="v1" From: Stephen Farrell To: "Eliot Lear (elear)" Cc: IETF QUIC WG Message-ID: <2ec8da3f-66f9-ec90-a80c-8b6e715a9c28@cs.tcd.ie> Subject: Re: Blocking Quic traffic References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> In-Reply-To: --qbgsqMjTR3ed0pncQVPvpfRwFirVw8oBk Content-Type: multipart/mixed; boundary="------------5D5451CBD68E1251FE9B298A" Content-Language: en-GB This is a multi-part message in MIME format. --------------5D5451CBD68E1251FE9B298A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, (Again, this is likely off topic so chairs, please feel free to cut this off but in the meantime...) On 18/08/2019 14:59, Eliot Lear (elear) wrote: > It=E2=80=99s not really an argument, but an observation of capital > expenditures resulting from a risk assessment. The money speaks for > itself. The money speaks for itself is not a reason to believe there's any real value in those MitM boxes. People and organisations spend money on all sorts of things that range from being placebos, to counter-productive to self-destructive. I do continue to find the ongoing inability to produce convincing evidence of efficacy interesting to say the least. Cheers, S. PS: I agree with Christian H's toxic-data argument too. >=20 > Eliot >=20 >> On Aug 18, 2019, at 12:58, Stephen Farrell >> wrote: >>=20 >>=20 >> Hiya, >>=20 >>> On 18/08/2019 08:53, Eliot Lear (elear) wrote: If you were to >>> argue to the people who use these proxies, knowing their cost in >>> terms of capital, support, and their own risk as a point of >>> failure, you wouldn=E2=80=99t get far. >> FWIW, while I've heard that argument numerous times, I've don't=20 >> recall ever seeing any convincing evidence that it's true. >>=20 >> That's likely off-topic for this list though. >>=20 >> Cheers, S. <0x5AB2FAF17B172BEA.asc> --------------5D5451CBD68E1251FE9B298A Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------5D5451CBD68E1251FE9B298A-- --qbgsqMjTR3ed0pncQVPvpfRwFirVw8oBk-- --PMHhXciX3IstxYoaZE7pxHRaMNiR6dZtf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1ZvtEACgkQWrL68XsX K+pajQ//UGAyFf5ALAN6UUCmzch++guuyJUnu6CjuBCIBWPhtHSswAg5B0pdbH4N 7fbqeXEqA4/7RAn8j7ALJF49pYzBshZE18HOG2UQ1BJskl3uT4o0evMdyK0YhI6q iKLAEh9fOAj04HEvXI7qyOZ6jRNjuG8WFsl0jDjbKsBWNOWdixW0PUBbJ6k9OaA9 8BxO6xLTbEcVCZALoS+HIvIzJtDqnWdQBJVhC5BMud2G+KCkN+IP+gIU5i9Imcxi JEEiQqxDx+2SNqfzySse9pNGG+DVcIpRIy5DSrD/q3BgHc29Ct/bL4kqcAoq6Inm +d8B5iFkMQaQw5+X6QVpmsUmrW0yYNEkR898pcncqclbTlEER2buYaB5C1JjSnk4 uaKzXgEAK82LeGIDSuhqmv9kC7o5dBQtYOuP8AOY21mnzousGknYqOBj4LxdKzMD Td00EQCjns5gL3Yce4kLfuI6SwzH4nndFEu5hIki7isxKHiINVz34VqD351QtBnp EFe8Ib8VmaZ4EjVPJjpftDJSLBlpA/vY6PurDYkEUQZtOxuzKNpDyOpU7FiS4Tr2 ntCUqmDFb4Wy8G1QOFI3irjreUO9SWhZ6stUn1ANikIjgrexPsgVWltqnC0QGMZL if37JaMdoG5OXrJbnd8b+DsLtHiGIb0xv/tsw8c8XYBdifqVQCo= =N3Hz -----END PGP SIGNATURE----- --PMHhXciX3IstxYoaZE7pxHRaMNiR6dZtf-- From nobody Sun Aug 18 23:30: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 7F8B8120255 for ; Sun, 18 Aug 2019 23:30:09 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgfTQLLtZjJQ for ; Sun, 18 Aug 2019 23:30:07 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20EC412026E for ; Sun, 18 Aug 2019 23:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1566196205; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1UNg/qFDDUamtfE2VjZp27goh273GJ9FD8gngsP9hOE=; b=LGYHV0433F4ppln87FvIpJcR/422TgrIaSXJuopvQ2J/fbqASwfKOtxKkLo5TANt+Bshcu O5NJeyIC7YjXknqN6Qdf/zxWsDPp0ouTb+opLOzyFbLkBnzHVp/oFiVU6x1FqlApzHPaLy 3aUkOHhkhvs545MX4oqpJ4Cv2Njb2iE= Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-37-46WHO07AP-eEgT2N1otVgw-1; Mon, 19 Aug 2019 02:30:04 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1fac_ffc9_99c89941_74a0_48c6_ae60_54f81b51750b; Mon, 19 Aug 2019 02:30:48 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 19 Aug 2019 00:27:41 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 19 Aug 2019 00:27:41 -0600 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 19 Aug 2019 00:27:41 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1530.namprd16.prod.outlook.com (10.173.215.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Mon, 19 Aug 2019 06:27:39 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::532:f001:84e1:55ba]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::532:f001:84e1:55ba%10]) with mapi id 15.20.2178.018; Mon, 19 Aug 2019 06:27:39 +0000 From: "Konda, Tirumaleswar Reddy" To: Christian Huitema , "Eliot Lear (elear)" CC: Christian Meutes , IETF QUIC WG , Stephen Farrell Subject: RE: Blocking Quic traffic Thread-Topic: Blocking Quic traffic Thread-Index: AQHVUe2wfsrAib4GYkCEHYQQKVuPIab5dhwAgAAEFwCABeBjgIAAetnUgACd/QCAABy7+IAAM7KAgAAyg1CAAB8JgIAA8dWA Date: Mon, 19 Aug 2019 06:27:39 +0000 Message-ID: References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> <1118E0BB-7631-4D29-9264-22FE33E46FDD@huitema.net> In-Reply-To: <1118E0BB-7631-4D29-9264-22FE33E46FDD@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.17 dlp-reaction: no-action x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59a91f01-94b5-4cdb-fce5-08d7246e5588 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5PR16MB1530; x-ms-traffictypediagnostic: DM5PR16MB1530: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(396003)(366004)(39850400004)(199004)(189003)(13464003)(32952001)(14454004)(86362001)(52536014)(486006)(478600001)(71200400001)(76176011)(305945005)(74316002)(33656002)(4326008)(25786009)(8936002)(55016002)(7696005)(9686003)(76116006)(7736002)(80792005)(66446008)(446003)(229853002)(64756008)(5660300002)(186003)(6116002)(66476007)(66556008)(26005)(66066001)(476003)(66946007)(11346002)(71190400001)(7116003)(2906002)(102836004)(6436002)(6246003)(81156014)(81166006)(8676002)(316002)(110136005)(3846002)(6506007)(53546011)(54906003)(14444005)(53936002)(256004)(5024004)(3480700005)(99286004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1530; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HOQ8ZciKauhsbPN6WCY0BRmnVqrLx7AgXq/Ndd22KnnXUbhzdjmkChIeOOpiC9UF93k79QtF2uN5ldPjwDOjnQreY9kWb4k0CvS6fsKJbXxiKVkmG9ICjXPXNyIh2qhhRWqdRBxUr1eAFKT6p64Rr/xBxnc8HGx5FqVqIyO1Srv8SkHGIVyWE81xYOLWer1H4r6tCBAvAY9DHYw3/be1jPusm5a7wnibFpvKdxR1uAVwENmVoh5lXZ62JoL9eV9qQV87gQ2YMt20KSkD9lLSFE+RnuuV0LkGwuw5LyEZyYHc+JtM5MWM98XGGIO/n7lQSYI+UnS2utFdqF60HWPIg76G9mY0jcuxAbs95qV6zPbCdeNPeoZ6QcMTL/6qk0PvAP2++1xsEWUIvCW2vk7sI+kVQkAsdYRr3YXHlnXJGk0= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 59a91f01-94b5-4cdb-fce5-08d7246e5588 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2019 06:27:39.5538 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9hkB09Katyeyao2uWpQKHDDyJJcvHpZzco+UV+a2mIBfYdz0J2Hbv0eu0AfRAy2jEZloKVuLf6XiXah0r6+GbMzbqWL7w2p6UXd44bOoa6gphYB0Oi/Wsgj8JK6a7+XM X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1530 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6614> : inlines <7135> : streams <1830549> : uri <2886111> X-MC-Unique: 46WHO07AP-eEgT2N1otVgw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 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, 19 Aug 2019 06:30:10 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KPiBTZW50OiBTdW5kYXks IEF1Z3VzdCAxOCwgMjAxOSA5OjIwIFBNDQo+IFRvOiBFbGlvdCBMZWFyIChlbGVhcikgPGVsZWFy QGNpc2NvLmNvbT4NCj4gQ2M6IENocmlzdGlhbiBNZXV0ZXMgPGNocmlzdGlhbkBlcnJ4dHgubmV0 PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsNCj4gU3RlcGhlbiBGYXJyZWxsIDxzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllPg0KPiBTdWJqZWN0OiBSZTogQmxvY2tpbmcgUXVpYyB0cmFm ZmljDQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdh bml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVz cyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMNCj4gc2Fm ZS4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiA+IE9uIEF1ZyAxOCwgMjAxOSwgYXQgNjo1OSBBTSwg RWxpb3QgTGVhciAoZWxlYXIpIDxlbGVhckBjaXNjby5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSXTi gJlzIG5vdCByZWFsbHkgYW4gYXJndW1lbnQsIGJ1dCBhbiBvYnNlcnZhdGlvbiBvZiBjYXBpdGFs IGV4cGVuZGl0dXJlcw0KPiByZXN1bHRpbmcgZnJvbSBhIHJpc2sgYXNzZXNzbWVudC4gIFRoZSBt b25leSBzcGVha3MgZm9yIGl0c2VsZi4NCj4gDQo+IFRoZXJlIGlzIG5vIGRvdWJ0IHRoYXQgdGhl cmUgYXJlIGN1c3RvbWVycyBmb3IgdGhlc2UgYm94ZXMuIFRoZSB1bmZvcnR1bmF0ZQ0KPiBwYXJ0 IGlzIG5vdCBhIG1hdHRlciBvZiBkZXBsb3ltZW50IGNvc3Qgb3IgcmVzaXN0YW5jZSB0byBjb3Vu dGVyIG1lYXN1cmVzDQo+IGxpa2UgZG91YmxlIGVuY3J5cHRpb24uIFRoZSB1bmZvcnR1bmF0ZSBw YXJ0IGZvciB0aGUgZW50ZXJwcmlzZSBpcyB0aGUNCj4gZXhwb3N1cmUgdG8gInRveGljIGRhdGEi LCBwcml2YXRlIGRhdGEgdGhhdCBpcyBnYXRoZXJlZCBhcyBhIHNpZGUgZWZmZWN0IG9mDQo+IGJy ZWFraW5nIGVuY3J5cHRpb24uIENvdWxkIGJlIGZvciBleGFtcGxlIG1lZGljYWwgZGF0YSBvciBm aW5hbmNpYWwgZGF0YSBvZg0KPiBlbXBsb3llZXMuIFN1Y2ggZGF0YSBhcmUgc3ViamVjdCB0byBz dHJpY3QgcmVndWxhdGlvbnMuIEluYWR2ZXJ0ZW50IGxlYWthZ2UNCj4gd291bGQgZXhwb3NlIHRo ZSBlbnRlcnByaXNlIHRvIGEgdmFyaWV0eSBvZiBsYXdzdWl0cyBhbmQgcGVuYWx0aWVzLg0KPiBQ cm90ZWN0aW5nIGFnYWluc3Qgc3VjaCBsZWFrYWdlIGNhbiBiZSB2ZXJ5IGNvc3RseSwgaGVuY2Ug dGhlIHRveGljIGRhdGENCj4gbW9uaWNrZXIuIEkga25vdyBhdCBsZWFzdCBvbmUgZW50ZXJwcmlz ZSB0aGF0IGdvdCByaWQgb2YgdGhlc2UgZW5jcnlwdGlvbg0KPiBicmVha2luZyBib3hlcyBpbiBw YXJ0IGJlY2F1c2Ugb2YgdGhhdCBjb25jZXJuLg0KDQpFbnRlcnByaXNlIG1pZGRsZS1ib3hlcyBk byBub3QgYWN0IGFzIFRMUyBwcm94aWVzIGZvciBhbGwgZmxvd3MuIEZvciBleGFtcGxlLCBtaWRk bGUtYm94ZXMgdHlwaWNhbGx5IGRvIG5vdCBhY3QgYXMgVExTIHByb3hpZXMgZm9yIGRvbWFpbnMg d2l0aCBoaWdoLXJlcHV0YXRpb24gc2NvcmUgKGUuZy4sIGJhbmsgc2l0ZXMpLiBJbiB0aGlzIGNh c2UsIG1pZGRsZS1ib3ggbWF5IG9ubHkgaW5zcGVjdCB0aGUgVExTIGhhbmRzaGFrZSB0byB2YWxp ZGF0ZSB0aGUgc2VydmVyIGNlcnRpZmljYXRlIChlLmcuLCB0byBkZXRlY3QgbWFsd2FyZXMgbHlp bmcgYWJvdXQgU05JKSBidXQgbG9va3MgbGlrZSBtaWRkbGUtYm94ZXMgd2lsbCBoYXZlIHRvIHBy b3h5IGFsbCBRVUlDIGZsb3dzIC4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KPiANCj4gLS0gQ2hyaXN0 aWFuIEh1aXRlbWENCg== From nobody Mon Aug 19 00:10: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 B889412022A for ; Mon, 19 Aug 2019 00:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=errxtx-net.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 tHxk7pTmT4ns for ; Mon, 19 Aug 2019 00:10:04 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB0312020A for ; Mon, 19 Aug 2019 00:10:03 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id w20so686869edd.2 for ; Mon, 19 Aug 2019 00:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=errxtx-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dkoKPJgcv2Xai14zLRzh45tCbUJDDWqbTfmrQrVL0VM=; b=e7r4Cyd5KcF9aqqY04tHM3mIFdgJWFzz5dCrcig2/ItuIMHxbp1KsT/4PR/1/ZDwe7 XtUvkLdG46DKyGVKmkxh/cRGO2LKB7e3N6udVEM5qJEgK0nJ/43TcFacfz3Ch8vuugFR Si9H7tULf8/hC/zVsWvC0UDtyBkMt8cBtIKMtt6hCnX+Uo2afFKTGGt0yFj9Be43Rshl w3Imo9VExwFPM0UGhjpGtroe9IObCrZ/7T1ycO3JJUPws/aXaKI+EkGwDkcLOcS1P/pY KRqxQy1awsPUu+AANHRTyd4jw61Pqr4on2TFF4dDkwhPivCuqXxFlUcQvdZYp/TKDHqV nn0Q== 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=dkoKPJgcv2Xai14zLRzh45tCbUJDDWqbTfmrQrVL0VM=; b=YwSvbTsv1getUwIY3ZXs9fU1wB7K5Dg/MyX9vyyPqyH43B9t+Gffb0zw0furfp0O0o XRyWR2ZFhL6UYY9dYgg8GbewpwrGfq6PntdS/pJ92PtbOO9RNBUh8sOQdJsY7tYPFbSZ f1Zzsab6WzslMtQPVu/cumCP9sBNb0aqaOCaVQVCj0ZgMn++d1hi4XbKf4nw+ulUymC7 DLnd3aJWPB1rSBWKfk581oFiTFNbwL/puk8XVEbtWVeOMvBplXC47DLf3O7o8oS17LyB noNUP3+jkHQZpzckIVZnrisMCW4QSUSG9KE3k32LPdefpdBiy3FN8HNvtu1Xob3hoigi slLQ== X-Gm-Message-State: APjAAAXTAFBRt0LYQ+5mHdlb4CCO0f8YglJk6+JAh6k6yEf3EVPoKfvY BMvmGnJzh3jBusUVhGnJc16i8FySXYZTGgUBSZoleoMK X-Google-Smtp-Source: APXvYqzb1hIheE1rwxw4IwU+zYuufxnFHuLLU6blx9GF7KY4ZU5II4vOIAegbO8TjsPmcD9SzuY8Ln4ggTaspqlrVGM= X-Received: by 2002:a17:906:9b1:: with SMTP id q17mr5540804eje.224.1566198602297; Mon, 19 Aug 2019 00:10:02 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> <1118E0BB-7631-4D29-9264-22FE33E46FDD@huitema.net> In-Reply-To: From: Christian Meutes Date: Mon, 19 Aug 2019 09:09:50 +0200 Message-ID: Subject: Re: Blocking Quic traffic To: "Konda, Tirumaleswar Reddy" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000005686a205907307da" 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, 19 Aug 2019 07:10:06 -0000 --0000000000005686a205907307da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon 19. Aug 2019 at 08:30, Konda, Tirumaleswar Reddy < TirumaleswarReddy_Konda@mcafee.com> wrote: > Enterprise middle-boxes do not act as TLS proxies for all flows. For > example, middle-boxes typically do not act as TLS proxies for domains wit= h > high-reputation score (e.g., bank sites). In this case, middle-box may on= ly > inspect the TLS handshake to validate the server certificate (e.g., to > detect malwares lying about SNI) but looks like middle-boxes will have to > proxy all QUIC flows . Everything they don=E2=80=98t know is TLS-spoofed (with the exception of transparent implementations without SNI client support), so from a user perspective you cannot trust your communications if you care about your privacy. I don=E2=80=98t think TLS was meant to be possible to intercept. B= rowsers in such environments should by definition not letting users believe that their communication is secured end-to-end, because it isn=E2=80=98t (and th= ey can figure it out). > --0000000000005686a205907307da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon 19. Aug 2019 at 08:30, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@mcafee.= com> wrote:
Enterprise middle-boxes do not act as TLS proxies for all flows. For exampl= e, middle-boxes typically do not act as TLS proxies for domains with high-r= eputation score (e.g., bank sites). In this case, middle-box may only inspe= ct the TLS handshake to validate the server certificate (e.g., to detect ma= lwares lying about SNI) but looks like middle-boxes will have to proxy all = QUIC flows .

Ever= ything they don=E2=80=98t know is TLS-spoofed (with the exception of transp= arent implementations without SNI client support), so from a user perspecti= ve you cannot trust your communications if you care about your privacy. I d= on=E2=80=98t think TLS was meant to be possible to intercept. Browsers in s= uch environments should by definition not letting users believe that their = communication is secured end-to-end, because it isn=E2=80=98t (and they can= figure it out).
--0000000000005686a205907307da-- From nobody Mon Aug 19 02:29: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 D0A98120816 for ; Mon, 19 Aug 2019 02:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RReo8quDVWY0 for ; Mon, 19 Aug 2019 02:29:27 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0AD0120804 for ; Mon, 19 Aug 2019 02:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1566206965; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RcHuSN4GQEJnLkWP50Oqx4h+aSWvmLdsm5XinhzuQFE=; b=XhcNlo5svRjx911c0udY41QODtALI6pir1ReBxwNIzNRfBA0EC43yq0zRVwEjiJbCgI2es sz9SjUCyvh0dLOWVJwex6dhJHJbA2nFYfnHN6EzZ7Jbfpt1Re+cqg5xEAnj72O4q8T4Z4V Y5qpiPcxy7X0FttKRcVXhnYcSdVhw4w= Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-337-UswNtG4YNJePFpQynUIdyg-1; Mon, 19 Aug 2019 05:29:22 -0400 Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1fac_6410_6251837a_b896_466a_91f1_a5c3fdd007ce; Mon, 19 Aug 2019 05:30:06 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 19 Aug 2019 03:28:49 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 19 Aug 2019 03:28:49 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 19 Aug 2019 03:28:48 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1609.namprd16.prod.outlook.com (10.173.211.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Mon, 19 Aug 2019 09:28:48 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::532:f001:84e1:55ba]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::532:f001:84e1:55ba%10]) with mapi id 15.20.2178.018; Mon, 19 Aug 2019 09:28:48 +0000 From: "Konda, Tirumaleswar Reddy" To: Christian Meutes CC: IETF QUIC WG Subject: RE: Blocking Quic traffic Thread-Topic: Blocking Quic traffic Thread-Index: AQHVUe2wfsrAib4GYkCEHYQQKVuPIab5dhwAgAAEFwCABeBjgIAAetnUgACd/QCAABy7+IAAM7KAgAAyg1CAAB8JgIAA8dWAgAAPGQCAAB/tYA== Date: Mon, 19 Aug 2019 09:28:48 +0000 Message-ID: References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> <1118E0BB-7631-4D29-9264-22FE33E46FDD@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.17 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0a5c9ff-ba0e-45f6-4905-08d72487a3b6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1609; x-ms-traffictypediagnostic: DM5PR16MB1609: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(366004)(136003)(376002)(189003)(199004)(32952001)(476003)(76116006)(53936002)(6916009)(66066001)(66946007)(6246003)(53546011)(6436002)(2906002)(66446008)(64756008)(66476007)(102836004)(80792005)(3846002)(6116002)(66556008)(790700001)(25786009)(4326008)(256004)(14444005)(5024004)(52536014)(236005)(478600001)(74316002)(86362001)(14454004)(11346002)(55016002)(446003)(486006)(5660300002)(966005)(7696005)(76176011)(7116003)(26005)(6506007)(606006)(186003)(99286004)(71190400001)(71200400001)(8936002)(33656002)(229853002)(54896002)(6306002)(9686003)(316002)(8676002)(7736002)(3480700005)(81166006)(81156014)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1609; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dWuh80/Bff7a+DARgaRjnvvX3QFVfOdFuQ4Hgxfthu8P0YgBFgXxrKwVbtcTsVRVLvQPRlQDFXbTSKYfWdH9gSsHpjU4hKvrjCjFfuUC7eZu9tz8iISNo+3E2ojFDsI6fpJxgD5gHWsXsaKGcDbS8RB8xSpjxHlbj5ddayszV8qKAJeBDfcDIq9MTmvLKi3upwY3CkKwPEranF2qE5p6yuEatqXnibjr+ni/XJNWMl0LQ0M31erVPbWc6KlSBiz28XudcznlJiS2x+8pyhKefRR7Q0Ck9fQ9seCI5PToCgMo2IQNEOKh96upuNbmDqdUJNQEDDLY2gnA/7S8/YMspELIBzsYuHe/fuv2cP5rG4OiN5sdOYXJRuNNq+8SWb34VBx0Cs8nabK113GgrG92xsf61xjFImI4kNZTQuPX1jA= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a0a5c9ff-ba0e-45f6-4905-08d72487a3b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2019 09:28:48.1622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P9DIy0oaMVws3mN3n14nmwkyM7ViAZW6TSN6gZmfVaiXWUpGrQTXfKgb6eR5ogWvLmQseoy35t4ali9o4IWX3H9i1Hwbups0UImnUMSZi8J41bxI0R3zvYtLlkysMrLD X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1609 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6614> : inlines <7135> : streams <1830549> : uri <2886169> X-MC-Unique: UswNtG4YNJePFpQynUIdyg-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1705E6CBCED4C18B0679C6EBEAA80DM5PR16MB1705namp_" 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, 19 Aug 2019 09:29:30 -0000 --_000_DM5PR16MB1705E6CBCED4C18B0679C6EBEAA80DM5PR16MB1705namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFu IE1ldXRlcw0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTksIDIwMTkgMTI6NDAgUE0NClRvOiBLb25k YSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29t Pg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBCbG9ja2lu ZyBRdWljIHRyYWZmaWMNCg0KDQpDQVVUSU9OOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IGNsaWNr IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRl ciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KT24gTW9uIDE5LiBBdWcgMjAxOSBhdCAwODozMCwgS29uZGEsIFRpcnVtYWxl c3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbTxtYWlsdG86VGly dW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbT4+IHdyb3RlOg0KRW50ZXJwcmlzZSBtaWRk bGUtYm94ZXMgZG8gbm90IGFjdCBhcyBUTFMgcHJveGllcyBmb3IgYWxsIGZsb3dzLiBGb3IgZXhh bXBsZSwgbWlkZGxlLWJveGVzIHR5cGljYWxseSBkbyBub3QgYWN0IGFzIFRMUyBwcm94aWVzIGZv ciBkb21haW5zIHdpdGggaGlnaC1yZXB1dGF0aW9uIHNjb3JlIChlLmcuLCBiYW5rIHNpdGVzKS4g SW4gdGhpcyBjYXNlLCBtaWRkbGUtYm94IG1heSBvbmx5IGluc3BlY3QgdGhlIFRMUyBoYW5kc2hh a2UgdG8gdmFsaWRhdGUgdGhlIHNlcnZlciBjZXJ0aWZpY2F0ZSAoZS5nLiwgdG8gZGV0ZWN0IG1h bHdhcmVzIGx5aW5nIGFib3V0IFNOSSkgYnV0IGxvb2tzIGxpa2UgbWlkZGxlLWJveGVzIHdpbGwg aGF2ZSB0byBwcm94eSBhbGwgUVVJQyBmbG93cyAuDQoNCkV2ZXJ5dGhpbmcgdGhleSBkb27igJh0 IGtub3cgaXMgVExTLXNwb29mZWQgKHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0cmFuc3BhcmVudCBp bXBsZW1lbnRhdGlvbnMgd2l0aG91dCBTTkkgY2xpZW50IHN1cHBvcnQpLCBzbyBmcm9tIGEgdXNl ciBwZXJzcGVjdGl2ZSB5b3UgY2Fubm90IHRydXN0IHlvdXIgY29tbXVuaWNhdGlvbnMgaWYgeW91 IGNhcmUgYWJvdXQgeW91ciBwcml2YWN5LiBJIGRvbuKAmHQgdGhpbmsgVExTIHdhcyBtZWFudCB0 byBiZSBwb3NzaWJsZSB0byBpbnRlcmNlcHQuIEJyb3dzZXJzIGluIHN1Y2ggZW52aXJvbm1lbnRz IHNob3VsZCBieSBkZWZpbml0aW9uIG5vdCBsZXR0aW5nIHVzZXJzIGJlbGlldmUgdGhhdCB0aGVp ciBjb21tdW5pY2F0aW9uIGlzIHNlY3VyZWQgZW5kLXRvLWVuZCwgYmVjYXVzZSBpdCBpc27igJh0 IChhbmQgdGhleSBjYW4gZmlndXJlIGl0IG91dCkuDQoNCltUUl0gVGhlc2UgZGV2aWNlcyBhcmUg bWFuYWdlZCBieSB0aGUgSVQgYWRtaW5pc3RyYXRvciBhbmQgRW50ZXJwcmlzZSBDQSBpcyBjb25m aWd1cmVkIG9uIHRoZSBlbmRwb2ludCwgc2VlIGh0dHBzOi8vYnVnemlsbGEubW96aWxsYS5vcmcv c2hvd19idWcuY2dpP2lkPTEyNjUxMTMgYW5kIGh0dHBzOi8vc3VwcG9ydC5tb3ppbGxhLm9yZy9l bi1VUy9wcm9kdWN0cy9maXJlZm94LWVudGVycHJpc2UvcG9saWNpZXMtY3VzdG9taXphdGlvbi1l bnRlcnByaXNlL3BvbGljaWVzLW92ZXJ2aWV3LWVudGVycHJpc2UNCg0KQ2hlZXJzLA0KLVRpcnUN Cg== --_000_DM5PR16MB1705E6CBCED4C18B0679C6EBEAA80DM5PR16MB1705namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9i Pg0KQ2hyaXN0aWFuIE1ldXRlczxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAxOSwg MjAxOSAxMjo0MCBQTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAm bHQ7VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IEJsb2NraW5nIFF1aWMgdHJhZmZpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjMiIGNlbGxw YWRkaW5nPSIwIiBzdHlsZT0iYmFja2dyb3VuZDojRjNGRjMzO2JvcmRlcjpzb2xpZCAjOUI5QTg3 IDEuNXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzou NzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cD48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5QjhCM0UiPkNBVVRJT048 L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzlCOEIzRSI+Ojwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IEV4dGVybmFsIGVt YWlsLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3Blbg0KIGF0dGFjaG1lbnRzIHVubGVzcyB5b3Ug cmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlciI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24gMTkuIEF1ZyAyMDE5 IGF0IDA4OjMwLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDs8YSBocmVmPSJtYWlsdG86 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbSI+VGlydW1hbGVzd2FyUmVkZHlfS29u ZGFAbWNhZmVlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbnRlcnByaXNlIG1p ZGRsZS1ib3hlcyBkbyBub3QgYWN0IGFzIFRMUyBwcm94aWVzIGZvciBhbGwgZmxvd3MuIEZvciBl eGFtcGxlLCBtaWRkbGUtYm94ZXMgdHlwaWNhbGx5IGRvIG5vdCBhY3QgYXMgVExTIHByb3hpZXMg Zm9yIGRvbWFpbnMgd2l0aCBoaWdoLXJlcHV0YXRpb24gc2NvcmUgKGUuZy4sIGJhbmsgc2l0ZXMp LiBJbiB0aGlzIGNhc2UsIG1pZGRsZS1ib3ggbWF5IG9ubHkgaW5zcGVjdCB0aGUgVExTDQogaGFu ZHNoYWtlIHRvIHZhbGlkYXRlIHRoZSBzZXJ2ZXIgY2VydGlmaWNhdGUgKGUuZy4sIHRvIGRldGVj dCBtYWx3YXJlcyBseWluZyBhYm91dCBTTkkpIGJ1dCBsb29rcyBsaWtlIG1pZGRsZS1ib3hlcyB3 aWxsIGhhdmUgdG8gcHJveHkgYWxsIFFVSUMgZmxvd3MgLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlcnl0aGluZyB0aGV5IGRv buKAmHQga25vdyBpcyBUTFMtc3Bvb2ZlZCAod2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRyYW5zcGFy ZW50IGltcGxlbWVudGF0aW9ucyB3aXRob3V0IFNOSSBjbGllbnQgc3VwcG9ydCksIHNvIGZyb20g YSB1c2VyIHBlcnNwZWN0aXZlIHlvdSBjYW5ub3QgdHJ1c3QgeW91ciBjb21tdW5pY2F0aW9ucyBp ZiB5b3UgY2FyZSBhYm91dCB5b3VyIHByaXZhY3kuIEkgZG9u4oCYdCB0aGluayBUTFMNCiB3YXMg bWVhbnQgdG8gYmUgcG9zc2libGUgdG8gaW50ZXJjZXB0LiBCcm93c2VycyBpbiBzdWNoIGVudmly b25tZW50cyBzaG91bGQgYnkgZGVmaW5pdGlvbiBub3QgbGV0dGluZyB1c2VycyBiZWxpZXZlIHRo YXQgdGhlaXIgY29tbXVuaWNhdGlvbiBpcyBzZWN1cmVkIGVuZC10by1lbmQsIGJlY2F1c2UgaXQg aXNu4oCYdCAoYW5kIHRoZXkgY2FuIGZpZ3VyZSBpdCBvdXQpLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5bVFJdIFRoZXNlIGRldmljZXMgYXJlIG1hbmFnZWQgYnkgdGhlIElUIGFkbWluaXN0cmF0 b3IgYW5kIEVudGVycHJpc2UgQ0EgaXMgY29uZmlndXJlZCBvbiB0aGUgZW5kcG9pbnQsIHNlZQ0K PGEgaHJlZj0iaHR0cHM6Ly9idWd6aWxsYS5tb3ppbGxhLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTI2 NTExMyI+aHR0cHM6Ly9idWd6aWxsYS5tb3ppbGxhLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTI2NTEx MzwvYT4gYW5kDQo8YSBocmVmPSJodHRwczovL3N1cHBvcnQubW96aWxsYS5vcmcvZW4tVVMvcHJv ZHVjdHMvZmlyZWZveC1lbnRlcnByaXNlL3BvbGljaWVzLWN1c3RvbWl6YXRpb24tZW50ZXJwcmlz ZS9wb2xpY2llcy1vdmVydmlldy1lbnRlcnByaXNlIj4NCmh0dHBzOi8vc3VwcG9ydC5tb3ppbGxh Lm9yZy9lbi1VUy9wcm9kdWN0cy9maXJlZm94LWVudGVycHJpc2UvcG9saWNpZXMtY3VzdG9taXph dGlvbi1lbnRlcnByaXNlL3BvbGljaWVzLW92ZXJ2aWV3LWVudGVycHJpc2U8L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi1UaXJ1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB1705E6CBCED4C18B0679C6EBEAA80DM5PR16MB1705namp_-- From nobody Mon Aug 19 02:53: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 7728E12001A for ; Mon, 19 Aug 2019 02:53: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=mnot.net header.b=lyO2nmmk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Xn78sp89 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV_JbFLSiAUq for ; Mon, 19 Aug 2019 02:53:34 -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 56A22120045 for ; Mon, 19 Aug 2019 02:53:34 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 93B6D21E3E for ; Mon, 19 Aug 2019 05:53:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 19 Aug 2019 05:53:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :date:references:to:in-reply-to:message-id; s=fm3; bh=CCJLSsI0Rm QcCqHXKCyjO8pGgj9zfh0R/OlnNpdQKds=; b=lyO2nmmkZxcTHU4ofxjXjk9JdU 1AHcuBmjmiC2e+S2ql/jCGY906DwsrEqrU7pEi4pPO8nl0Zpsj8M0LZcKP38kfrn 8O7P8HVoERqJqHdlfZPLpOfJgwpyutPQ5pRhP7hliBK89B1Qfe7tni8oBOfwiLZG KwnTEBmVodb4iP+VPXlE6wsd2KHDNFb6aPwpc/PylRyjzUYEtWII6FC4+UCdRMyC 88Zbw3SVY1GUMiw+0x4+orPlLIh3JHIExUFTcdTS0C4DE1lNJVVpp2PEX39Wxi3k 0E7kvXYWedcyYU+XXC7B/+KJ9BPi8ZUNHAcjfXmf9tHGptw18bDMmbYx7Nww== 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=fm3; bh=CCJLSsI0RmQcCqHXKCyjO8pGgj9zfh0R/OlnNpdQK ds=; b=Xn78sp89rJkV0YkaWD5Mv4EQg3ZQEn0l9yIB9ZvWDWHzRJaD4qkC13Q3F tZbsOvRRH4jdcvf/K0HsM+wtrJtRv/dS3QIeeS5RSixfT9eKwe94wjvcr0vUI92J Kw8iYcNWzEhIhwNo5pHgZf6dHusYEBfSYPEyrYMhBxDNZ64g9V+d4kRz3whWqi2A 5H/H/O4JxhVBj3j0tYB15ZD2Da2FTvogQ6kK316nWDaakN/WrVk3cT0cNRNHCTJx 40Axo7k0gkB1K6z6A3waLc10yNxlrVWqL+UHbwF8GsOKB9lk6i/AD/z6nmJpdzqU VA+giVCa39gi05SmSB5OzEVkGytOg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefledgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffffhfvjgfkofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 946FC380086 for ; Mon, 19 Aug 2019 05:53:30 -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.11\)) Subject: Re: Blocking Quic traffic Date: Mon, 19 Aug 2019 19:53:25 +1000 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> <1118E0BB-7631-4D29-9264-22FE33E46FDD@huitema.net> To: IETF QUIC WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) 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, 19 Aug 2019 09:53:49 -0000 Folks, This thread is indeed getting off-topic for this list (and onto = well-worn territory in other IETF discussions). Please let us focus on = the work here. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Aug 19 03:02: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 06E2E120045 for ; Mon, 19 Aug 2019 03:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=errxtx-net.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 aBqgoRsb6PXG for ; Mon, 19 Aug 2019 03:02:45 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B434E12001A for ; Mon, 19 Aug 2019 03:02:44 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id p28so1125987edi.3 for ; Mon, 19 Aug 2019 03:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=errxtx-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DVf21akLrX0UIqrlqQUQ++jbO6/J0BXmWUG7ZLz0HNs=; b=EjB0ZHWg9fD21yGarvbrFXWyFHbUyvBVqeSW5n0UEMNTtqAkz8LS12KpBDaVKmqpY+ 7ofPz04bk/k23kNQokjFvSvOs/miLvZeaODSGGikRJhWCc29uQw0JJYDMHAf2Pkeqjq1 8yJfTHyDjnBcQDOoVpL+4J5fa8+glLienWbFD1UG+XdgMCXe1iOIyg7fLnXAvGOBbvrf FAbI66ELfG3at8PTUcT0SXI6cutY2k4hsJjfXWbkld4pYDO5ht+IPl233kSlaNnNtR8U 8ZuJ3ZA3P+ONpcE5tGSsP3hSjkZ1WW1h+Ej+H2klzLqsC42vD34HVq9YoRjVGzFkrQPr sauQ== 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=DVf21akLrX0UIqrlqQUQ++jbO6/J0BXmWUG7ZLz0HNs=; b=sBjc2KCUYbe2OGAW3uUo2sIcWCjIcA2eqe6y7BvaJdhoejeBmXdmit5+OjAVGd/dER 4Ztro21xh4wvLNSWl0abK8mTa9Ty7lD19ljxmMC51/UaVF1HzPxuvP1ZpaYEoO3/62SJ vLQpR4gb921Vn63lh79vJ6uE2RISL7mGRS+6aSStNXg9tccFg2dzhDxlc/Xp46Wv+/pB iQuj5oSq0Uq3Zvdd0ovgK6TX5FUqPz3Ya/KYCa8ZL2FVevng3GiPYES1XHbgLX5/lCNx x9jxboeK+F4OHNq05TjR7MqxjpzQGEAXtxi+l77E1QnkglaxhcmCNRqkgOmXZ4RxhRsf CfZQ== X-Gm-Message-State: APjAAAVssp6vvrNaEzF5/urZs9XwfhQAkfhhcsp4+NCffKi/Kc6DyP3f 3Ky/cgO9dTY5Gr4dCqv8HQkbVE1izEv1jwVloDzkWw== X-Google-Smtp-Source: APXvYqy/dF3t6lQbxg7eFuc/d0z+ghGCqbhj0F8RNYy65U8MSAhedslH8LSFG6h3a/jwNWoCU+AHehFMzwo47e7YhJY= X-Received: by 2002:a05:6402:1594:: with SMTP id c20mr24264394edv.130.1566208963293; Mon, 19 Aug 2019 03:02:43 -0700 (PDT) MIME-Version: 1.0 References: <95198D4B-63F4-4363-B49C-AB254CF24030@ericsson.com> <9CBEED96-1419-4CB0-A8B4-D2A548FD06F1@cisco.com> <09AF1E5B-47BD-406A-885B-AE1FFA2B511E@cisco.com> <1118E0BB-7631-4D29-9264-22FE33E46FDD@huitema.net> In-Reply-To: From: Christian Meutes Date: Mon, 19 Aug 2019 12:02:31 +0200 Message-ID: Subject: Re: Blocking Quic traffic To: "Konda, Tirumaleswar Reddy" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e6c3f705907570b9" 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, 19 Aug 2019 10:02:47 -0000 --000000000000e6c3f705907570b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon 19. Aug 2019 at 11:29, Konda, Tirumaleswar Reddy < TirumaleswarReddy_Konda@mcafee.com> wrote: > [TR] These devices are managed by the IT administrator and Enterprise CA > is configured on the endpoint, see > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1265113 and > https://support.mozilla.org/en-US/products/firefox-enterprise/policies-cu= stomization-enterprise/policies-overview-enterprise > I do know that it requires an installed trust anchor/CA on the client side while the middlebox uses this Root to fake sign foreign server names/CNs. I still do believe that it=E2=80=98s a mess for the enduser and that there co= uld be done more about it. But wait... H3/QUIC/DANE for the rescue!? --000000000000e6c3f705907570b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon 19. Aug 2019 at 11:29, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@mcafee.= com> wrote:

[TR] These devices are managed by the IT ad= ministrator and Enterprise CA is configured on the endpoint, see=C2=A0https://bugzilla.mozilla.org/show_bug.cgi?id=3D1265113=C2=A0and=C2= =A0https://support.mozilla.org/en-US/products/firefox-enterprise/polic= ies-customization-enterprise/policies-overview-enterprise


I do know that it requires an installed trust anchor/CA on the client s= ide while the middlebox uses this Root to fake sign foreign server names/CN= s. I still do believe that it=E2=80=98s a mess for the enduser and that the= re could be done more about it. But wait... H3/QUIC/DANE for the rescue!?



--000000000000e6c3f705907570b9-- From nobody Mon Aug 19 03:14:14 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 F2EE21200EC for ; Mon, 19 Aug 2019 03:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 DU26dPcFg_ca for ; Mon, 19 Aug 2019 03:14:10 -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 2A74712001A for ; Mon, 19 Aug 2019 03:14:10 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id BBAF030134; Mon, 19 Aug 2019 13:14:07 +0300 (EEST) Received: from [219.243.198.97] (unknown [219.243.198.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id C706A613170; Mon, 19 Aug 2019 13:14:00 +0300 (EEST) From: Lars Eggert Message-Id: <26871C9E-3538-4C57-BBDB-CC30A5FDD517@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_B58553F0-2381-46D7-9587-0A8E4CC09245"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: QUIC for IoT embeddeds system Date: Mon, 19 Aug 2019 18:13:55 +0800 In-Reply-To: Cc: IETF QUIC WG To: JH References: X-MailScanner-ID: C706A613170.A038B 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, 19 Aug 2019 10:14:13 -0000 --Apple-Mail=_B58553F0-2381-46D7-9587-0A8E4CC09245 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2019-8-18, at 8:02, JH wrote: > Are there any > WG working for small socket level QUIC client server for embedded > system? my implementation (https://github.com/NTAP/quant) can be compiled for = the particle.io platform and currently weighs in at around 90KB code = size. It would probably be possible to shave off another few KB by = making it client-only. Additional savings would require changing some = key data structures and are therefore more painful. Lars --Apple-Mail=_B58553F0-2381-46D7-9587-0A8E4CC09245 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAl1admMACgkQHbmKvSnu NPh7ohAAjwInlaW6JDgYame3qurei80v+Sx3unb1+yeNJkZdr72uHaQAZ0x4f7a1 5kSG4H2IHB8IxjLBl+wRIZ9FgUjKf1na7c8kXa9KIS2z0mlEnSlDgTKMX+0yIE1L LDOI3PMH8o8G3MWCEbDHqFgoAlBTYRtho91X1oKPc63WyFz6/Lex0qfimUV6g46X nWoxSaldE3C0oGABPcNxQzvXG5TgG6EVdqA5MJU/T9pPj203Xow6SFfeGwUiXxQz b9K7kP+lgSPt8heWEeQJr460PmyxaLrLz3+gw7TdXy2fGONMt1LpGvFS/9nAZTFk AO55OCGPgnDigBdDYEtMSzctqcXtrP4KAahFlasQlqY2WYlD75Ukyx7Me+Gxj0nr AyTnOQfBJS567smhDmf6P9OT/tT/WUiJwOj7/gzi6lf8HYu4MH2234TdhoR/prqy RcE9qo4fHzLaTAwf1gtuVQyY4cKf8eVfzfYkH9WLVs3b3xKeIGzxe6ZlbvKVZov5 bbsR6r/M/ns3wfqyflDy4lTzO4cSPxB+w7IF80zK4Bp+4wqbPgOlyx5byyKqTAGe 2vqq0yn+HBo7GrBatBK2g4wlUBQGSa2V7DZsXsFaWlpxQSxRmUGLWhZSAgB7kGJW TxLOPCW1LSI/fOaczm/nL0LYK6PPsWVrJZTrzlqi2EJVWlgJqzY= =nq7w -----END PGP SIGNATURE----- --Apple-Mail=_B58553F0-2381-46D7-9587-0A8E4CC09245-- From nobody Mon Aug 19 03:17: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 322FD1200EF for ; Mon, 19 Aug 2019 03:17:41 -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_HELO_NONE=0.001, 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 hVI3zLf3n-XT for ; Mon, 19 Aug 2019 03:17:39 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B0B12001A for ; Mon, 19 Aug 2019 03:17:39 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id w5so1159184edl.8 for ; Mon, 19 Aug 2019 03:17:39 -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=8+o7pnisTOX5pHFVzRaPeHTipk2UeY1t03U0oYtKaXY=; b=XeGogLyd+pJizpfJfLm7FPH7FZ9StL650ZBfRLOlE35oMYbC2B0kqXvz6dsp6TUoSk BHzvvzCjrsq/7KefW33zbeL0dy0Q1zmsoTOHstA310Gyo4Y8f2/FOke2yeJbvwJqCa6E Eu0WSu+rKxZlgQzx6zn0o4HmCR4GQ9Ulu5mcYlN2sF1DhwDdOoNE+82UQYbvwTqsMbdv 2IQztZclm39qAcAFYYnh+sSa8NHF1q8xQ7aLE7JvGsJCQY/0la15YcZYsBuGP5ZeIZHd 0lmbqV6kzsjISH3bcL9vfjK+lrYKFhHKQSnj3JBFPG1Gi5/u0LZOepRx9tm0NT3ichwB Nwuw== 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=8+o7pnisTOX5pHFVzRaPeHTipk2UeY1t03U0oYtKaXY=; b=SpM+ZI4wv+CqanAA5HTVw0/MgktS8v71pRaS1aJhUW8jKLNb38j/Y+mAfhjHzVMCZx Y7x+NqcDAB3+P5rZoCRIfvZcNicrJHLiayka/H83EltOfRgEdmwW0+OUna43E5eImgpy BaBf+Z5E5p6WzzwuN9bhfTaW3uhdzDufDBB6SdxOlF/Fbmur4zKImwX0uj1SN5ATFWlU F7Vdhp6dG0D1ZLDMFVfgfmtYBOmNCzw/yv2yM9go76Cmv+8jxBcgxfL80BhmuzH65qq4 /ZoIkBRrctC4EkOFri0gn17F0yqNeai/YuK7F0an/9ulDxJD+v+sPuN0mvCk5OQIRLaO 52PA== X-Gm-Message-State: APjAAAXgrB6OHIWVSKcDDkQiiBHro0w0hHlF9MQSU3Tdb25Ak176Ud0m OcCHt/kwrF1i1gRGw/dEDvRxeSXIaqqQ339gYjY= X-Google-Smtp-Source: APXvYqzIJKkU+MdEtr8XdbbTUg+x0MPTgOd23B0IKElVyO/+jf6ZqNU1Fcv4+vRX0ys7liBoTk/5C6HQpW2g+rc4z5M= X-Received: by 2002:a17:906:8392:: with SMTP id p18mr20405015ejx.17.1566209857889; Mon, 19 Aug 2019 03:17:37 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 19 Aug 2019 03:17:36 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <26871C9E-3538-4C57-BBDB-CC30A5FDD517@eggert.org> References: <26871C9E-3538-4C57-BBDB-CC30A5FDD517@eggert.org> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 19 Aug 2019 03:17:36 -0700 Message-ID: Subject: Re: QUIC for IoT embeddeds system To: Lars Eggert , JH Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000392a4c059075a6fa" 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, 19 Aug 2019 10:17:41 -0000 --000000000000392a4c059075a6fa Content-Type: text/plain; charset="UTF-8" Is that size including the TLS implementation? Mikkel On 19 August 2019 at 12.14.29, Lars Eggert (lars@eggert.org) wrote: Hi, On 2019-8-18, at 8:02, JH wrote: > Are there any > WG working for small socket level QUIC client server for embedded > system? my implementation (https://github.com/NTAP/quant) can be compiled for the particle.io platform and currently weighs in at around 90KB code size. It would probably be possible to shave off another few KB by making it client-only. Additional savings would require changing some key data structures and are therefore more painful. Lars --000000000000392a4c059075a6fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Is that size includi= ng the TLS implementation?

Mikkel

On 19 August 2019 at 12.14.29, Lars Eggert (lars@eggert.org) wrote:

Hi,

On 2019-8-18, at 8:02, JH <= jupiter.hce@gmail.com> wrote:
> Are there any
> WG working for small socket level QUIC client server for embedded
> system?


my implementation (https://gi= thub.com/NTAP/quant) can be compiled for the particle.io platform and currently weighs in at around 90KB code s= ize. It would probably be possible to shave off another few KB by making it= client-only. Additional savings would require changing some key data struc= tures and are therefore more painful.

Lars
--000000000000392a4c059075a6fa-- From nobody Mon Aug 19 03:48: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 04CF6120116 for ; Mon, 19 Aug 2019 03:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 5e-C3aSDocdo for ; Mon, 19 Aug 2019 03:48:02 -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 668A1120044 for ; Mon, 19 Aug 2019 03:48:02 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id ED89C400F1; Mon, 19 Aug 2019 13:47:59 +0300 (EEST) From: Lars Eggert Message-Id: <8910E393-4F93-4BF4-B7C4-AA8110AFA6A0@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_091C3925-2ACA-4A29-94B8-44C1BB8CC7CB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: QUIC for IoT embeddeds system Date: Mon, 19 Aug 2019 18:47:48 +0800 In-Reply-To: Cc: JH , IETF QUIC WG To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= References: <26871C9E-3538-4C57-BBDB-CC30A5FDD517@eggert.org> X-MailScanner-ID: E8E13613154.A09B3 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, 19 Aug 2019 10:48:04 -0000 --Apple-Mail=_091C3925-2ACA-4A29-94B8-44C1BB8CC7CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2019-8-19, at 18:17, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: > Is that size including the TLS implementation? Yes. But there is no H3. Lars --Apple-Mail=_091C3925-2ACA-4A29-94B8-44C1BB8CC7CB 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAl1aflQACgkQHbmKvSnu NPjIBRAAo7puG3cKknroAFz9ysjDp9LCrvNzqLFQ7OZ90I315GwOgSpc6hWTZlDm 4V0Zl1fIwBmGcOEdNMH4/FS6bDWk7DNfBXveFfxkZoJDQdBAWzJ1+PwfXOnzZKFe b/7acneEnmQbFHqx9JjTuumhfy9HaLcCLYCMTYD+GfMhRzYi7JOynFfouGPHbeSE LbtyWKBqheq7o3ylKknVrukKSvwaHw3MshBltQeIguJpdwWaTq4Ylgv/yihSYZrf ysnloTKKmcr96alpfVfTyKbV+I9YUH7aMKzC1sQ7+feUQnuN3TLIZTyAGeykWHf3 D+fLw/bNcjj8PXD6jCAmo1/Y4jE4kSPibEGCgwtt8BVOfEkZSs312PJoED6h3mC+ 2X3GvhDZ2uYecO0gVH4614u4duJS++IiWzl0Wo65U9qD7TFT0TcoBGs1zDjfVkKu w9t0SezeGazA0fTs1Nr2aVFj4PTEmJEcjhHxhIOwfqQxy/7O4hTAfcErHBCp5Oe6 XReEzd0Bhafrj5GOi+w55Y8s2r2/94lOgARjmEUQ412plQxUnsFLFKbtGYo+XkZP H07ZEuM+TWTg8u/JzKSdj/S/9EBqLg2RQdFEigxjRdcKEqE59K+30HoemhG5rqEi 5wuFUc9sM38lf+IqznYJ3cgjLQILMgY39NlAjxgjWanlnEzDXBI= =xtfR -----END PGP SIGNATURE----- --Apple-Mail=_091C3925-2ACA-4A29-94B8-44C1BB8CC7CB-- From nobody Mon Aug 19 20: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 D72621200FB for ; Mon, 19 Aug 2019 20:28:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 2J7DECU8lt-p for ; Mon, 19 Aug 2019 20:28:44 -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 007751201DB for ; Mon, 19 Aug 2019 20:28:43 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 9FC4E30015 for ; Tue, 20 Aug 2019 06:28:41 +0300 (EEST) Received: from [219.243.197.37] (unknown [219.243.197.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id F2C4D6174D8 for ; Tue, 20 Aug 2019 06:28:35 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_90167187-4047-4846-AA47-73AD1EB86572"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Doodle poll for Sep 2019 QUIC Virtual Interop Event Date: Tue, 20 Aug 2019 11:28:29 +0800 References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> To: QUIC IETF mailing list In-Reply-To: Message-Id: <4A68E217-71E0-47D4-840B-2AC53F3EFA52@eggert.org> X-Mailer: Apple Mail (2.3445.104.11) X-MailScanner-ID: F2C4D6174D8.A389E 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, 20 Aug 2019 03:28:46 -0000 --Apple-Mail=_90167187-4047-4846-AA47-73AD1EB86572 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/27q27ezcvriyu6n6 (This will be a remote interop. Next physical one will be before the WG = interim meeting in Cupertino, CA.) Lars --Apple-Mail=_90167187-4047-4846-AA47-73AD1EB86572 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAl1baN0ACgkQHbmKvSnu NPgtiA/+KJX2GOShLBOMOZdjhIcwSGyJ2kIPfCshNDwI8r87uZWja8PSwfhynKCa f0u1KrwhLFCaUrbwlLFFbBJI7VYufvhmoi1Lz1HBwMWVNfK1KOttEE6eklNgEoOI rX7cLomtKtq03DdTZ5mL4opcpMaF6FEJZ+7CLlYiwVIEIEjKhagUYYj5mW6lvQG1 f8dyMVI2S87baQqQshHnh+AqXKFplH5cxAGp2CcKqFAl/JlbXsC+oRomKzSUcO/S G74xZQ/vY+dWlqZYZe0bdD9BWct64uRBe6L8KpJFRVDRPp6ZvH/phFrggejLI3DC L28x1S9YEy6WpMSu5Mk8W4dtp+TEfXzZaWqQRnOGdBciMnOKXwm9ZzEONFNwJdMQ yHybAU/PCro48yLn8Xo7BpozgKKURmUX5Zvc2+xR4UnSomrvgXBVblsCts3/Gega 7EHsq0DiKwBedhqUZC6bWtd6EDlT++D/YOORPGr7CbhWZyardhEQ1T9W3x9eLkEw 2ywAu/yTQn8eDbzIbKxee7vowt//hwQWbvvhY4dkSg3gtkdYJ/UG5W8f3FKHQD34 tLtpbnzXopTRtPTXMnD5be4cV1eINYj3hvSdSZbKEq6n0MqXMPOks2FSd7TZ1B3v M7YXRU9/Mhkj8pUbYVrWqEpeVnnDQ5SIoD/wlRb75JcWD3jvuds= =QOPm -----END PGP SIGNATURE----- --Apple-Mail=_90167187-4047-4846-AA47-73AD1EB86572-- From nobody Mon Aug 19 20:34:05 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 3338B120024; Mon, 19 Aug 2019 20:34:04 -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 106 X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156627204420.5149.18207806478601577686.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2019 20:34:04 -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, 20 Aug 2019 03:34:04 -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: Chair Conflict: httpbis Technology Overlap: saag tsvarea tsvwg tcpm iccrg tls 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 and area-wide meetings. --------------------------------------------------------- From nobody Mon Aug 19 23:04:04 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 1AC721200CC; Mon, 19 Aug 2019 23:04:03 -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 - Update to a Meeting Session Request for IETF 106 X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156628104307.5207.12358216926502738256.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2019 23:04:03 -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, 20 Aug 2019 06:04:03 -0000 An update to a 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: Chair Conflict: httpbis add Technology Overlap: saag tsvarea tsvwg tcpm iccrg tls Key Participant Conflict: capport doh 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: Special Requests: Two consecutive days early in the week, if possible. Please avoid colliding with all BOFs and area-wide meetings. --------------------------------------------------------- From nobody Mon Aug 19 23:04:40 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 4AB621200CC; Mon, 19 Aug 2019 23:04:38 -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 - Update to a Meeting Session Request for IETF 106 X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156628107829.5064.2214381777995147027.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2019 23:04:38 -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, 20 Aug 2019 06:04:38 -0000 An update to a 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: Chair Conflict: httpbis Technology Overlap: saag tsvarea tsvwg tcpm iccrg tls mptcp Key Participant Conflict: capport doh add 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: Special Requests: Two consecutive days early in the week, if possible. Please avoid colliding with all BOFs and area-wide meetings. --------------------------------------------------------- From nobody Mon Aug 26 00:01: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 B4C12120827 for ; Mon, 26 Aug 2019 00:01:38 -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=Wbujjzbn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yd842aBD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJLQL356f7SV for ; Mon, 26 Aug 2019 00:01:35 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920A9120180 for ; Mon, 26 Aug 2019 00:01:35 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AC1AF30B; Mon, 26 Aug 2019 03:01:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 26 Aug 2019 03:01:34 -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=fm3; bh=R vnKStTW06iwb4jUcqmnF+h1QXXsRIQnJhTxFk/Yygk=; b=WbujjzbnKu2znjdTT bEFMgGzKLUBIAaRBr1LNiDWoOEycmozidP6ScnVmhlM/dejJiMX6tJJt1JEV3kQb fQjZpnOjKbWHUbR43gDXs761AyQBY9FGWxu6d686srxbh14xBWdCsfqO28I16gT4 tKnEk4YZ3WJUhGmCeJVOJ5PaCBLRSBzukBdbePCw5ksd2aeoPAmYz3truli7BBUc BI3x7/JVCZ39YjU6FMYf9eRPvK2NnVb5JdKBuqBsGKjmPUTaxcIF8xtJ7vjO8ZwZ nqluA13R158FvR8TFMPiu1mmWX8A1ljwMwwxBBSYKxIANQ1FGJZOuwy+xwNJSM/K nxDBg== 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=fm3; bh=RvnKStTW06iwb4jUcqmnF+h1QXXsRIQnJhTxFk/Yy gk=; b=yd842aBDA04aZHUKt40ht0g3eDb3f8vMAWRjE0r28KvXg2E7djHYnm6VK 6F9Clb7bddJfTLED63mjfyzBHjkbSKmYnZpJ112ar9wL1/vBh4TeOTkVxf/VKbz2 tGxw4FJnESFUsHv/5qtgCdFFPFjpL33vlc01I8QQ2jx9Jp2+n9EUBVkVuDMX1KwQ gR2839s1P8TmC8zlhnYfF6AgrUQEmLF96AwmSIkr4k5a/HWnkn6bEek4eT9CV0s8 XzLxQuI/uq7pQ2CDbruzd47MC74mEePyoJ69xo5/jmlUx6JNCxu4fboEl9bPdtiT z0rKo56DPWuk426LD42gmGmr5J2Yw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudehfedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrih hnpehonhhthhhurghughduhedvtddulegrthekgeelphhmmhgrrhhknhhothhtihhnghhh rghmmhhnohhtmhhnohhtrdhnvghtpdiffedrohhrghdpghhithhhuhgsrdgtohhmpdhivg htfhdrohhrghdpuhhhrghsshgvlhhtrdgsvgdpmhhnohhtrdhnvghtpdhhthhtphefrdhi thdphhhtthhpphhrihhorhhithhivghsfhhorhhtohholhhonhhgohhthhgvrhifihhsvg ifvgifohhulhgunhhtsggvihhnthhhihhstghurhhrvghnthhmvghsshdrnhgvgihtnecu kfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmh hnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 381F5D60062; Mon, 26 Aug 2019 03:01:30 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Call for consensus: HTTP/2 Priorities From: Mark Nottingham In-Reply-To: Date: Mon, 26 Aug 2019 17:01:26 +1000 Cc: IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> To: Robin MARX X-Mailer: Apple Mail (2.3445.104.11) 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, 26 Aug 2019 07:01:39 -0000 Hi Robin, Thanks for taking the time to respond. I think these points are well taken; by far most people want to get a = priority hinting mechanism into H3. Personally I view this as clearing = the decks to let that happen; if we aren't distracted by the myriad = issues with H2 priorities, it looks like we can get something simple in = pretty quickly. Additionally, this is definitely NOT a consensus call to ship H3 without = priority hints at all; if we do that, we'd need to come to a separate = consensus for that first, and my current reading is that there's not a = will to do so yet. Cheers, > On 17 Aug 2019, at 11:54 pm, Robin MARX = wrote: >=20 > At the risk of repeatedly screaming into the void: >=20 > I do not have a problem with the removal of HTTP/2-style priorities = per se. The setup is certainly quite complex and can be simplified in = terms of implementation. > However, the dependency tree is also very flexible and able to = represent a wide variety of different prioritization schemes. > That this flexibility has been severely under-utilized to this day, = does not necessarily mean it's not needed in my opinion.=20 > And sure, we can drop it now, ship with something simple, and move to = a more complex/flexible setup again down the road once we have more = insights.=20 >=20 > However, that latter point is still not what seems to be on the table = here. I still feel like we're proposing dropping priorities completely = right now and -maybe-,=20 > just maybe (NOT necessarily as Mark says) shipping H3 with some form = of priorities on-board (i.e., "priorities should not block H3"). The way = I see this going forward=20 > is that many people just won't bother implementing any prioritization = concept until it's clear what will end up chosen (and it's in the spec).=20= > Consequently, people will keep testing QUIC stack performance without = caring about multiplexing (much): downloading a single file over a = single stream,=20 > which imo is only part of the equation. I see us ending up with = shipped implementations that don't have decent prioritization support, = this time not because they can't=20 > be bothered to implement a dependency tree, but simply because nobody = told them they should. Thus we run the risk of H3 performing worse than = H2.=20 >=20 > As such, I am not really in favor of removing priorities from the spec = until we have a replacement. Or if we do, I feel priorities should block = H3 (even if it's just for a simplified setup). >=20 >=20 > I really feel we're sticking our heads in the sand on this. We've been = ignoring HTTP priorities for too long (otherwise we wouldn't be in this = current mess). Next to that, > we've also been ignoring QUIC-level priorities (with the very vague = https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-2.3 as = only indication). I've asked this > of multiple implementers on multiple occasions and no one had a = concrete idea of how they will/should be mapping application-layer = priorities to QUIC stream priorities yet.=20 > People seem to expect this to somehow resolve itself or that it can be = bolted on as an afterthought, and maybe it will/can, but I doubt it.=20 >=20 > The only other conclusion I can draw from all this, is that priorities = don't really matter in the big picture. I certainly see enough = indicators to that end. For example Microsoft Edge > not bothering to use them in the first place. For example browsers not = seeming to a/b test optimal approaches for over 4 years. For example, = some people advocating that "passive" > resource request order + content-type is enough of a signal in itself = to provide good page loading performance. For example, people proposing = not letting them block H3.=20 > This viewpoint is 100% contradictory to my own prioritization research = and my understanding of current web page building techniques. Maybe I'm = missing things others take for=20 > granted. Maybe I'm making mistakes. Maybe priorities are not the = cornerstone of a multiplexed protocol that I view them to be. In that = case, by all means go ahead and continue=20 > down this proposed route, as it indeed seems the best way forward. If = not: please give them the attention they deserve. >=20 > With best regards, > Robin=20 >=20 >=20 > On Sat, 17 Aug 2019 at 14:10, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: > +1 >=20 >=20 > On 17 August 2019 at 00.08.06, Jana Iyengar (jri.ietf@gmail.com) = wrote: >=20 >> +1 to removing the current priorities from HTTP/3. >>=20 >> On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham = wrote: >> In Montreal, we had a discussion about priorities, where the outcome = was that people in the room agreed to defer to the HTTP Working Group = regarding whether HTTP/3 should ship with something compatible with = HTTP/2 priorities in it: >> = https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-p= riorities >>=20 >> Since then, the HTTP Working Group has come to consensus that it does = not believe we should do so: >> = https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net >>=20 >> This consensus call is to confirm this approach in this WG. In = practical terms, it means we will remove the current HTTP/2-aligned = priorities machinery from HTTP/3. It does NOT necessarily mean that = HTTP/3 will ship without any form of priorities; just not this one. = Doing so will resolve a number of outstanding issues, and make way for a = replacement scheme, currently under discussion in a design team in the = HTTP Working Group. >>=20 >> Please respond by the middle of next week; we'd like to move forward = with this resolution. >>=20 >> Kind regards, >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >=20 >=20 > --=20 >=20 > Robin Marx > PhD researcher - web performance > Expertise centre for Digital Media > =20 > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > =20 > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > =20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Aug 26 00:06: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 E90BC120829 for ; Mon, 26 Aug 2019 00:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=hO9+TYwJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qxNh14aP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6tjiY5r6-CA for ; Mon, 26 Aug 2019 00:06:25 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D54120827 for ; Mon, 26 Aug 2019 00:06:25 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A3F2833E; Mon, 26 Aug 2019 03:06:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 26 Aug 2019 03:06:24 -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=fm3; bh=f 0eizRNiMEKC+ZnihDPyNq1fKg80HU6wYQvKDr7JbzE=; b=hO9+TYwJ2Jy/e5eXB xa/jqML1jAlT4CTssBvFDooHcNbaM7alEcXUmwUWkwx8arpC9s9nN9AUR6xovOs7 TvWTcpI2Ju0020rkJNzCfYa+LfE/l+yKRUcjjAXVwXNM2Ew5NQq7v9jS8+Zk0nUH tDJeMg99CO2WaahORdl/mL7FgWOUtMYZ2a5I0kICH1Y+VAnl6UzwkPtQ5d40Lyf3 Hywc2OQBkjRmt/FwGOjzu5OM+G4KB02Ft08Oa87/GAnYudSLeOPo5+VWYw54W1BG NAr+/Fa36lyC1914W8h+r8yVvUQN7wlUTwK6vCwkIYi78XPSJKk2AGPaxukjlyHP BnvZw== 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=fm3; bh=f0eizRNiMEKC+ZnihDPyNq1fKg80HU6wYQvKDr7Jb zE=; b=qxNh14aPhYiW4dbjEtH7bCDG8l5rPQQMg2bxoMSVjiYg2ISIN7faC3SbT R8EjR5y3o1YUzs5bSBHPlX7TOJ3Lcnbs9hx4S4M4WTHXRmaoz+OP83RZ8Yrtqn0K k09DRbuL70jf1TlfxC0C+2r6zNc+JQopi54QBaspHI9BtOxfzhdouPVM9MCxsFhU 50HBqyaCvXPm9tWq76TtQH3TBXIcb+MlXHq46Bn9wEA37IeIjUB8Y9ZcNvG+PC5J kmLYvcejPOT6wE/rSORiODKm9qnfhORF6a+BoIAnv3KYsBEIAYZN0g4kIEsMj+gy P7JIKL3WbENy0Mhlr+4C/q5SKGhlw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudehfedguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrih hnpehgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddu jeehrddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth enucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D4D3D60057; Mon, 26 Aug 2019 03:06:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Consensus Calls on Recent Transport/TLS Issues (again) From: Mark Nottingham In-Reply-To: <8EDCB64E-68BC-4D3C-83CD-7455B3155E88@mnot.net> Date: Mon, 26 Aug 2019 17:06:18 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <3F6294F5-3AD0-4238-9E95-EE383E939E94@mnot.net> References: <8EDCB64E-68BC-4D3C-83CD-7455B3155E88@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.104.11) 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, 26 Aug 2019 07:06:28 -0000 Hearing no pushback, consensus declared. > On 16 Aug 2019, at 2:18 pm, Mark Nottingham wrote: >=20 > The following issues have proposals for resolution, and discussion so = far seems to support consensus to accept them. If you object, please do = so on the issue or in response to this message (changing the Subject = appropriately!). Absent any pushback, we'll direct the editors to = incorporate them next week. >=20 > See for the current = state of issues in the Late Stage process, itself defined at = . >=20 > * #2869: Stateless Reset packet sizes should not depend on the maximum = connection ID length > The proposal is: >=20 > * #2834: Long Header Packets and Routing Connection IDs > The proposal is to close with no action. >=20 > * #2770: If you want a Stateless Reset you need to send a larger = packet than before > The proposal is: >=20 > * #2656: Discarding connection state at server on unvalidated client > The proposal is to make this an editorial issue. >=20 > * #2541: Clients cannot abandon Initial packets while server can still = send initial close > The proposal is: >=20 > * #2534: ECN text disables ECN too aggressively > The proposal is: >=20 > * #2205: Largest acked in ACK frame MUST NOT decrease > The proposal is: >=20 > * #2151: Where can you send CONNECTION_CLOSE > The proposal is: >=20 > * #2084: Discuss requirement that connection IDs not be correlatable > The proposal is: >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Aug 26 15:49: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 B1DC012008A for ; Mon, 26 Aug 2019 15:49:12 -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=gWPVpIQ1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AXvcEimt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GACjVOvTfWbK for ; Mon, 26 Aug 2019 15:49:09 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0301201EA for ; Mon, 26 Aug 2019 15:49:09 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id DB2836B5; Mon, 26 Aug 2019 18:49:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 26 Aug 2019 18:49:09 -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=fm3; bh=o Q/oJJekrluY7a/Em8eixbxYviwtRTnyJarQAnSJk7U=; b=gWPVpIQ1nJEEuFBJz 0O+FgE8gxY9csNudWUwsHNIg9iqf5TS/2gg5TkWvkHyE8ylqh0dY4jZ4F6IFjnly 8jvgiIPkB7cbYg3CdL3DLn3Ep+ZeeJbO+52TY0ttoPjJtf96BgJdcyCYLrEJpiri NukQb1JVk+tjj0KZuctI27fmhzlR1PXHqupGYtI7LRZ6yVy7qGbO74K0hPtxlP84 xOP1dOB6Xs1DL0XJjRQXnNbvEYNmMPS4xoo2+68hQg5yVITMRTbuFfrkl2oQ7pRc OcRFt6nNO+9sv0wzEbD3aOJUCQ2FosEEe+jY0cYWbSn3TjxeI/NMZx9sA9AAbnWk sCg8w== 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=fm3; bh=oQ/oJJekrluY7a/Em8eixbxYviwtRTnyJarQAnSJk 7U=; b=AXvcEimtOEXnpCZTGEVVolOg/uIiKHNCWa8T999deyFGKNt8Ff+YlLyEx miNoO+tE1W8MGeCmiN6Tmw9pg/7oMW36Ax9BDIkOXAkDf0gcuejGf/gVo7uthhFs 3AKQWnGapkzWc4j8qjcKO5G31NjpO6AFcf3dWmGJQ52Qq0Kou7Bf0EpJ3VxvFIb0 nH8H6gxVTqAgXCRfH4UO5IyCkubWswZgeF3B3a7zp/mQWL+ttv/qNyjE07fSpsPP OgIHsbAi+NZmsFHuRMOByzi48N35f0we5bbPYBhS0uLmUQ4dtLZoDMJRZxlRKjAu L+P59RiZg3F9puGPl39uTTwNvZHJA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudehhedgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epfiefrdhorhhgpdhgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtpdhhthhtphefrdhi thenucfkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhroh hmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 0B0F9D60057; Mon, 26 Aug 2019 18:49:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Call for consensus: HTTP/2 Priorities From: Mark Nottingham In-Reply-To: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> Date: Tue, 27 Aug 2019 08:49:01 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.104.11) 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, 26 Aug 2019 22:49:13 -0000 After the discussion in the room and on the list, it appears we have = consensus. Cheers, > On 16 Aug 2019, at 1:49 pm, Mark Nottingham wrote: >=20 > In Montreal, we had a discussion about priorities, where the outcome = was that people in the room agreed to defer to the HTTP Working Group = regarding whether HTTP/3 should ship with something compatible with = HTTP/2 priorities in it: > = https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-p= riorities >=20 > Since then, the HTTP Working Group has come to consensus that it does = not believe we should do so: > https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net >=20 > This consensus call is to confirm this approach in this WG. In = practical terms, it means we will remove the current HTTP/2-aligned = priorities machinery from HTTP/3. It does NOT necessarily mean that = HTTP/3 will ship without any form of priorities; just not this one. = Doing so will resolve a number of outstanding issues, and make way for a = replacement scheme, currently under discussion in a design team in the = HTTP Working Group. >=20 > Please respond by the middle of next week; we'd like to move forward = with this resolution. >=20 > Kind regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 27 01: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 D231E1200F7 for ; Tue, 27 Aug 2019 01:37:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 2qZH4BVQl04t for ; Tue, 27 Aug 2019 01:37:18 -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 0B37E1200F5 for ; Tue, 27 Aug 2019 01:37:18 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 655E4400EF for ; Tue, 27 Aug 2019 11:37:15 +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 89CBB64071A for ; Tue, 27 Aug 2019 11:37:09 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_F27F9053-0E73-467F-A3B0-01F89C2C76F5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Doodle poll for Sep 2019 QUIC Virtual Interop Event Date: Tue, 27 Aug 2019 11:37:08 +0300 References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> <4A68E217-71E0-47D4-840B-2AC53F3EFA52@eggert.org> To: QUIC IETF mailing list In-Reply-To: <4A68E217-71E0-47D4-840B-2AC53F3EFA52@eggert.org> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-MailScanner-ID: 89CBB64071A.A3ACC 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, 27 Aug 2019 08:37:20 -0000 --Apple-Mail=_F27F9053-0E73-467F-A3B0-01F89C2C76F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please fill out now if you haven't - will close the poll soon. Lars On 2019-8-20, at 6:28, Lars Eggert wrote: >=20 > Please indicate your availability, if you have a stack you wish to = test: https://doodle.com/poll/27q27ezcvriyu6n6 >=20 > (This will be a remote interop. Next physical one will be before the = WG interim meeting in Cupertino, CA.) >=20 > Lars --Apple-Mail=_F27F9053-0E73-467F-A3B0-01F89C2C76F5 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl1k67UACgkQVLXDCb9w wVeZFQ/7Bc4LVHR60ZMLxRkjpukMOwBz8jKQqCDtazIawITMyBgmGKxt/FxPctI9 /wYwgwOkdm/i3g63f1hUQ3hn393QDspDo3gNufW9jkxUIkzlWNRQWoXO7htfAIKE xL09XnzrJ7l7drOUY+YaNLpUTyGZQsIc/R+BOupF2IdS9K7Ppa31iwnokKLmncfZ 0erqJxbf7bleQjqDtdVgUvdK1tnuE4lCCt3ScsDIlHiCOgWyyf0eoM+w1YwuV3Jv TxSZLqx4Vy2M+z9iPqGFBjKBeEMXOZ94yWsZ+DVPyiwWzjdhtVxvNYk4KiJD3ZRw LgMH+yJk2y+vG7zhAh19Puz7XPVBbNClZVo+1/FbJ4/71ubqKZhQVfjsTw73/4BJ a89dclgXBiOT1AMDRderSO8GBg4xzhJWxD1NP3wcvWxRypbznRfF59A3T50dPoe+ zqDjalCu0Tsq7UQ1GGlrEdbOgpAeOonHyH7HNDwvYdHnzdvF2ucHPJ5cMmyxJUFk G+i72krHM87Wh2//ZSpaVe+BzBdxD4U7loHiEf+HaW91zsAzlGRlxWM5FfDXlw4A 7AevMxq6YEfnLSgPbVUCdmd9UUwKmBd1EUwrHsE0nHO0lI336dqKgsGbr2oGLw7w eOpu+6DZZO5BDzlxbhW9YbkNGSl3zF4dKdmWylTH2ZVRqoZZSaM= =5NtU -----END PGP SIGNATURE----- --Apple-Mail=_F27F9053-0E73-467F-A3B0-01F89C2C76F5-- From nobody Tue Aug 27 15: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 DF52E120130 for ; Tue, 27 Aug 2019 15:47: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_HELO_NONE=0.001, 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 qcLzywZSDEBX for ; Tue, 27 Aug 2019 15:47:53 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2575D12004D for ; Tue, 27 Aug 2019 15:47:53 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id e16so431098wro.5 for ; Tue, 27 Aug 2019 15:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Yb9FfL9KQ1uhtr8goXMmBlD/HkKkXC+ZVrz8uf8sx+o=; b=oMnNFGXZHj3R9sN5NhLSNu5t38pmKZuu7WaJO+ak/6emtJnqw4/JgLsOjL30LTLzOe 3MA1DAhQHicRlh41/Hj408vBJjVp+vb6B+CXKFyCrk2bzyOugwVJ1amA4g12dozR5Wmp 2QW1tlgjVYCEc/mbX3n8sBS+rnDXJ8xgk4vQsTOUCXHYK7Z4+2xD+24JZXRNQFSqAN4w oTHz03QBN/W3sqLMOvf9Qk65czcLFLVj+1fFQ1AQ5MHbfC7esAXfHSJMXmuuj6dG0sgn 2iRcfV2N+IB8+yZem6lMqp9yeoFQ0RZsyKTDrluzYVnOwqkrHEWT+itjxKX+7PE1Bv66 fykA== 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=Yb9FfL9KQ1uhtr8goXMmBlD/HkKkXC+ZVrz8uf8sx+o=; b=NseB1Prqz0WPt8uDX+4DR8uOSmC9TtCn+/CANyu9xy6xBqZ14djHqxFC9JAW3V7/7x 0GG5MF777+CYbTmkrjhklyq6ARuTz31VYHjInQEPRpxHTsccMZQ1+sPKBD6qDSKgLiol zDy8PFCC/eafk97piJQjULB1Z0/pvYE6nm45lfnJIA0sywGISkBPx5ut4eNzT5FRIiuP 4tZUEpq6YCCNgfF0KJbZOXxeV+aKD2dXSmnIT2VEMmb6SJ+QojHlOqrmjPCuJ212RtxH pmbmtuz8PXlrSkE164Z2xxCy9zxa9TKw8/B/YQRwKDe1WJw/N6pXzXqyYiKhRd4kzNtY 3IZg== X-Gm-Message-State: APjAAAXouetD0KLuWx3Q1p0v/U+cvC1hqd+GBb7HvCFDKF9gk5MRZJgu BIWpVW4BLVqbgzXlftA5Py1gWMbhdhs1tnzDot6lHWpD4Gc= X-Google-Smtp-Source: APXvYqx928x89diKCrULS5cOVOk4hFr/PVXML5iT4PIa9+4guY7mT+Qu/0p282AEXrZmbam66qbni53kBUCnXdjyulc= X-Received: by 2002:adf:afe7:: with SMTP id y39mr436980wrd.350.1566946070790; Tue, 27 Aug 2019 15:47:50 -0700 (PDT) MIME-Version: 1.0 From: Ryan Hamilton Date: Tue, 27 Aug 2019 15:47:38 -0700 Message-ID: Subject: Lost initial MAX_PUSH_ID is unfortunate To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000eef7000591210fc2" 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, 27 Aug 2019 22:47:55 -0000 --000000000000eef7000591210fc2 Content-Type: text/plain; charset="UTF-8" Howdy Folks, In some testing we've been doing, we realized that if the packet containing the initial MAX_PUSH_ID frame is lost (or reordered until after the first request) then the server is unable to push responses. This is a bit unfortunate. We could, of course, bundle the MAX_PUSH_ID with all packets that send a new request until the MAX_PUSH_ID is ACK'd. This feels a tad inelegant and I wondered if there's any appetite for an alternative. We've been talking about the prospect of putting SETTINGS into transport params. If we did this, we could add a new setting for the initial max push id value which would be guaranteed to be delivered before requests. This seems like a much more elegant solution to the problem. What do folks think? Cheers, Ryan --000000000000eef7000591210fc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy Folks,

In some testing we've been= doing, we realized that if the packet containing=C2=A0the initial MAX_PUSH= _ID frame is lost (or reordered until after the first request) then the ser= ver is unable to push responses. This is a bit unfortunate. We could, of co= urse, bundle the MAX_PUSH_ID with all packets that send a new request until= the MAX_PUSH_ID is ACK'd. This feels a tad inelegant and I wondered if= there's any appetite for an alternative.

We've been= talking about the prospect of putting SETTINGS into transport params. If w= e did this, we could add a new setting for the initial max push id value wh= ich would be guaranteed to be delivered before requests. This seems like a = much more elegant solution to the problem.

What do folks thi= nk?

Cheers,

Ryan
--000000000000eef7000591210fc2-- From nobody Tue Aug 27 16:06: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 BED501201EF for ; Tue, 27 Aug 2019 16:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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_HELO_NONE=0.001, 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 q01ZhKyjGk-1 for ; Tue, 27 Aug 2019 16:06:27 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DED12004D for ; Tue, 27 Aug 2019 16:06:27 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id q16so607001vsm.2 for ; Tue, 27 Aug 2019 16:06:27 -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=7v3Ls9skjnDbn06s4xRMauSVQn87ixPVVK/8bhdD7qU=; b=uQo53LHY9Fwe0fhtcGWqn7kbVu3eMxjStBUQHWS6puXFdeRneTaslVZLReoPdcsuWG lASBPRdWQDOLcpzSDqcpjnDvy1tmQKHd4sewtm25zc4G/sOax9o5i108yZcIz0JNNnjz 3nRKvdQMD7DNHZSlHdXKWDao9r5snGC/mHSbVv2S5ZMkuqGC9pk079nV2iTmfuz+4zaC ufOfPgBl3qkoeD4Gj6+o/DEcsHQDc7X4enefKAT3rdzWgxakw8ItFWdQuxk6B2eExEtt sdzclgX2pwxT2jJwGxLRH6QUgCOzfHihrKKK9JjOiZAf+McAH4bVIIkKDbUHDHmPRx+Q 38bA== 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=7v3Ls9skjnDbn06s4xRMauSVQn87ixPVVK/8bhdD7qU=; b=rMbj5Qj4t0nGxlP4qZdOB68FNPXAYSY7sLhqixKi5NasMkI5daA+t9JD3RY6dTwXS3 PvXt0RQ8NBq3DxVOxuyDdvTrsDwUIJVUlf3l58Jyr9Epykys/BaOq7LrdoeQqC2c4Pfe egpssazNKC1OVl1zTC+bbzvCk/uQaydHyECMT7CciAku2EC65a9dxJCHULazhtcp66Ga OUp1baIBD7Vyy/5VJRL83zXWDESygys/x4UQJtmRPET+h65iwsZ/c2ESJJ2tT1ZxUwyP sODBCzCe09n8mihfwHUSUIiW3BuPLEyDXR/UcppGwUDZzUjqdGLKeraYMoqryzZVBlJ3 jcTw== X-Gm-Message-State: APjAAAVFhUtrnd2U+3D8vkaYb6NPTiJVQm4gXsK/Yx2PdHoJXTQpqZEE JQyfMXi5HCA3ui0hoPcKyOk4O4OaHcwlrFl4F0GYCQ== X-Google-Smtp-Source: APXvYqzZqtkrTOiQGpgckz0C+tR9VqsiwhE867GogtfIR6/6E2PmpSZGniTvnu0Xp/yO0/mVgyzBVQMfQA30khoLqKc= X-Received: by 2002:a05:6102:100f:: with SMTP id q15mr737755vsp.100.1566947186155; Tue, 27 Aug 2019 16:06:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Wed, 28 Aug 2019 00:06:18 +0100 Message-ID: Subject: Re: Lost initial MAX_PUSH_ID is unfortunate To: Ryan Hamilton Cc: QUIC WG Content-Type: multipart/alternative; boundary="00000000000069a58a05912152dd" 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, 27 Aug 2019 23:06:29 -0000 --00000000000069a58a05912152dd Content-Type: text/plain; charset="UTF-8" Hi Ryan, This doesn't sound any different to the case when a server receives a request when the push ID limit is reached; a client may have attempted to update the limit but the delivery or processing of the frame happened after the request was received. Because this can happen at any time during a connection, I would be opposed to adding special case code for the initial max value; it seems it would be simpler for implementations to have one path for dealing with this eventuality. Cheers Lucas On Tue, 27 Aug 2019, 23:48 Ryan Hamilton, wrote: > Howdy Folks, > > In some testing we've been doing, we realized that if the packet > containing the initial MAX_PUSH_ID frame is lost (or reordered until after > the first request) then the server is unable to push responses. This is a > bit unfortunate. We could, of course, bundle the MAX_PUSH_ID with all > packets that send a new request until the MAX_PUSH_ID is ACK'd. This feels > a tad inelegant and I wondered if there's any appetite for an alternative. > > We've been talking about the prospect of putting SETTINGS into transport > params. If we did this, we could add a new setting for the initial max push > id value which would be guaranteed to be delivered before requests. This > seems like a much more elegant solution to the problem. > > What do folks think? > > Cheers, > > Ryan > --00000000000069a58a05912152dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ryan,

Thi= s doesn't sound any different to the case when a server receives a requ= est when the push ID limit is reached; a client may have attempted to updat= e the limit but the delivery or processing of the frame happened after the = request was received.

Be= cause this can happen at any time during a connection, I would be opposed t= o adding special case code for the initial max value; it seems it would be = simpler for implementations to have one path for dealing with this eventual= ity.

Cheers
Lucas

On Tue, 27 Aug 2019, 23:48 Ryan Hamilton, <rch=3D<= a href=3D"mailto:40google.com@dmarc.ietf.org">40google.com@dmarc.ietf.org> wrote:
Howd= y Folks,

In some testing we've been doing, we realized t= hat if the packet containing=C2=A0the initial MAX_PUSH_ID frame is lost (or= reordered until after the first request) then the server is unable to push= responses. This is a bit unfortunate. We could, of course, bundle the MAX_= PUSH_ID with all packets that send a new request until the MAX_PUSH_ID is A= CK'd. This feels a tad inelegant and I wondered if there's any appe= tite for an alternative.

We've been talking about the p= rospect of putting SETTINGS into transport params. If we did this, we could= add a new setting for the initial max push id value which would be guarant= eed to be delivered before requests. This seems like a much more elegant so= lution to the problem.

What do folks think?

=
= Cheers,

Ryan
--00000000000069a58a05912152dd-- From nobody Tue Aug 27 20:00: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 975911207FD for ; Tue, 27 Aug 2019 20:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=v7MB31u6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Pee4sDK8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sCIwdkt4L9t for ; Tue, 27 Aug 2019 20:00:29 -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 68A4C120220 for ; Tue, 27 Aug 2019 20:00:29 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AD147220C7 for ; Tue, 27 Aug 2019 23:00:28 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 27 Aug 2019 23:00:28 -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=fm3; bh=MXD6myCimMC0yTphiGbk5c09Wv0zk1f cIEK3qmaGhIw=; b=v7MB31u6uoRgG68nrMdl4V2pPOVn86sFfAWHmq+P4L448zR m5/R1Uq0Gr4RKzZrxmLtN+8IpsHQILPRlT+RVkn0vB9Dorfml3xIXZwm/VInlFpW aqPLdHtIdzU3TWHN5yWyGq/XxqwosIonHfaI8wB2WQrBuSWSI32wApf6o3xZxxrk Jmc+kC8gXiNxH+ymR5BLF1tIX92iXM3k39gFEcoHFNxH3xDsTEi8z3DbkX0zce23 Xzd4C0Fu/Y4i4777jVFtGJHGq4vEHeqpWpmnvBTfjO2aIwAFW89UxVjT9UeU/a87 nzNYb3FvI2Y7Jq8fpWR1vAe0bRGRYTLNOTfudVQ== 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=fm3; bh=MXD6my CimMC0yTphiGbk5c09Wv0zk1fcIEK3qmaGhIw=; b=Pee4sDK8OAaD0mIgZntDcc LgTOnW/5HzAf6OoKrB08CJOQbsE1+Uv7dy/9KBRgmnE5VzgaEoYAezy9mec6axVc mcLdBhslBwwH9B2564iGrPyfwa4u0xZCBZkuP/g0w47qU2oAy5Dut3uCacrl2jIG pMV9TF2hmSWDeXQ2ANhreIkiKP3yJZDxjt5HsRxTTbtsHLXm29fhdKBq46GkMj2a p/9ydV8SdPGAUwk9OzwILqW5LAJSkj8Ji4SD8tFzO1/es5YNC/zO9s/QcQX+rzbo aYUmxngk8ZaQ2tA+kARBG8LyGcR+KbGY+D/FoaVQ5h6TgQnz2Tw4nJiLAefsPTCA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudehledgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6909FE00A3; Tue, 27 Aug 2019 23:00:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-139-g73fcb67-fmstable-20190826v1 Mime-Version: 1.0 Message-Id: <1931a6f6-a25f-478e-b150-a200e0c3c69e@www.fastmail.com> In-Reply-To: References: Date: Wed, 28 Aug 2019 13:00:09 +1000 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Lost initial MAX_PUSH_ID is unfortunate 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, 28 Aug 2019 03:00:30 -0000 On Wed, Aug 28, 2019, at 08:48, Ryan Hamilton wrote: > In some testing we've been doing, we realized that if the packet > containing the initial MAX_PUSH_ID frame is lost (or reordered until > after the first request) then the server is unable to push responses. > This is a bit unfortunate. We could, of course, bundle the MAX_PUSH_ID > with all packets that send a new request until the MAX_PUSH_ID is > ACK'd. This feels a tad inelegant and I wondered if there's any > appetite for an alternative. I don't think that this is great justification for that sort of change. We explicitly removed head of line blocking from the processing of SETTINGS. In practice, I suspect that this situation also results in no access to QPACK also. Performance might suffer, but at least you can send something sensible in a round trip when you would otherwise (with h2 for instance) be twiddling thumbs. From nobody Tue Aug 27 23:02: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 5AD1D12083D for ; Tue, 27 Aug 2019 23:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 IzKcGjuWPyW0 for ; Tue, 27 Aug 2019 23:02:23 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF2D12083C for ; Tue, 27 Aug 2019 23:02:23 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 8FBF2B0072 for ; Wed, 28 Aug 2019 09:02: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 F166364F719 for ; Wed, 28 Aug 2019 09:02:14 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_A8F5B80F-3C93-4749-B074-A3A7A6679173"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Next QUIC Virtual Interop Event: Oct 1+2 Date: Wed, 28 Aug 2019 09:02:14 +0300 References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> <4A68E217-71E0-47D4-840B-2AC53F3EFA52@eggert.org> To: QUIC IETF mailing list In-Reply-To: <4A68E217-71E0-47D4-840B-2AC53F3EFA52@eggert.org> Message-Id: <291111C6-B687-4AFA-9C8E-0D7F39087969@eggert.org> X-Mailer: Apple Mail (2.3445.104.11) X-MailScanner-ID: F166364F719.A201F 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: Wed, 28 Aug 2019 06:02:25 -0000 --Apple-Mail=_A8F5B80F-3C93-4749-B074-A3A7A6679173 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Oct 1 and 2 both had the best availability, so I propose we (again) do a = two-day virtual interop, it seemed to help a bit with testing across = timezones. Expect new draft versions shortly. Lars --Apple-Mail=_A8F5B80F-3C93-4749-B074-A3A7A6679173 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl1mGOYACgkQVLXDCb9w wVcIoBAA2azhD7xoIU4yq2Z3W35XM7+jjhPOpi0DEF1HIsZX5o009w8/RoNJel04 fwbrOli92luy2hOucJSeWxHtKryasWqFrzUEdVzM9RYblhsbXAoX7Nzg2V9gMW1d 2FmmOYfOdzX6ZJV9iRdF7wJr6oHa1IQQrNrIH15DPja0LUbo9KmRqrfi1wsMxMFY Y/W83laxtcGZTYoAVYbUp/9Z6hTrDxcGUy4L1ilQ3vJo/eBae6lBPZlxchrHQr95 DL7N0AehlSi3Qfm3MH0SqObfQNoBty/3vG83yNrl2hXafZOEdsuilTvhna2zJWrm TrVbCvqVx9fQYyqOhTsLgk5L2DXnLs2wcqAT3MxKVRTKEEuGnmK0TZ6ygl54csMU CpCJ2GBnbH0PV+SpiWNdE7kyEm3I+D3ZXbtNxeTcWxRQDNM/XQUYLYqsJGDdpjW+ xwi/S2xIhPXy5Fcj45ogAWGN7yax/R8B2NhkxFNtjg6bfuckvrNKlwLWmQd+QOKo OAgSyThC/B/BVFiVml27Hw8c1MqASSZ05gClpgnQgfg2CArEvO8VNGB2uOLtF/h1 khNHBDyE9eFNgGFQ43/WFHEScJMo+wDfbDLqEQ9bv1unYApEls3HcJuoFVKBgdwX IiMRCtCOQGNm8FAF7xBsuQ62zXHfSL4sQIn3fziaETNLXQwog6s= =eTh0 -----END PGP SIGNATURE----- --Apple-Mail=_A8F5B80F-3C93-4749-B074-A3A7A6679173-- From nobody Wed Aug 28 11:38: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 3242612002E for ; Wed, 28 Aug 2019 11:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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_HELO_NONE=0.001, 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 DI31ttWDapDj for ; Wed, 28 Aug 2019 11:38:55 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0: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 784C912001B for ; Wed, 28 Aug 2019 11:38:55 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id b1so820546otp.6 for ; Wed, 28 Aug 2019 11:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0eZoaAVs3iYBxUdHGZlVJCXTVXM8SPjBC3lEliYqA44=; b=IiOzystxN0Cm5hpIwpnLjmsjXeVbEYu1H4L0sSD67R9lt5wpYuieTGXR48nz2beEv4 xQmgI6Al66l59FdzY+giIg8sIYiUHAsorU9SlCubIaELuh7g3dukCW6T71gmcL3pFXyP I/0OA2JNc7siHNzSYpt23a0mO02T/yoQVE6HYYhoNHVLZ3zH6s72fu9sWNTlzKn2U1Bf WC77avCwbAjYNehedOl8/NIk3krx6nzHDYYwMLQpRAF7TwswXE4aJFudWTq7Fu7mOdhq egMnXr3PFQlfJZcXfKzbsBIng64EW9FEqx8vcG8/YQlMaIuhsBAPM12R1p2nOEfzT3v5 i3lg== 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=0eZoaAVs3iYBxUdHGZlVJCXTVXM8SPjBC3lEliYqA44=; b=Kbz+15noTv53QBSZSXwB0VjukOMC55tsAAJ5FLkTSattsEWjfhmJztt6RU+ZV3/yKh 4mqK95vrfFggnhTead4HnNmlv5UdKA6PVh4576PJn3uym60nYoYoQMpTc9y9TvCx/mCI OmPierQ8vamwbjYEBc6qO122oehlS6KwQEy/UKw0U5G+9lBfAiBsEsggw352/eY/sZLD N/0PbZ8Zgz8qAtLy+j2HkGdMFDltbgEpuwRa2n/IiFU85p7Df7rS0rRTTqMx8KNPe8Vs t7iJN29/EWNT9VWoWo0JttNt3Rvng9na5MNQNIMm9lCxXVb81RZijCV7PyEbqAgv5NPO PojA== X-Gm-Message-State: APjAAAX8K0HklGYLEtN6DyxGbdcQfGaGOS3dZLotlRoH77yjCCyydfCt 7nmqCE+r1HI3h2PoHB8uR8e4lethRWxTZDzLGKQwIQwRMx4= X-Google-Smtp-Source: APXvYqzRwudymnY8Ye1GOk2HlZSSNwG6lJY5f/GQ9MnmfnNd+9oX8sMhDDQCqH+0EwrfFJQk3Wss/WlmtRtPnEDiCaY= X-Received: by 2002:a9d:390:: with SMTP id f16mr4476198otf.93.1567017534245; Wed, 28 Aug 2019 11:38:54 -0700 (PDT) MIME-Version: 1.0 References: <1931a6f6-a25f-478e-b150-a200e0c3c69e@www.fastmail.com> In-Reply-To: <1931a6f6-a25f-478e-b150-a200e0c3c69e@www.fastmail.com> From: Nick Harper Date: Wed, 28 Aug 2019 11:38:42 -0700 Message-ID: Subject: Re: Lost initial MAX_PUSH_ID is unfortunate To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000007cac28059131b35f" 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, 28 Aug 2019 18:38:57 -0000 --0000000000007cac28059131b35f Content-Type: text/plain; charset="UTF-8" On Tue, Aug 27, 2019 at 8:00 PM Martin Thomson wrote: > On Wed, Aug 28, 2019, at 08:48, Ryan Hamilton wrote: > > In some testing we've been doing, we realized that if the packet > > containing the initial MAX_PUSH_ID frame is lost (or reordered until > > after the first request) then the server is unable to push responses. > > This is a bit unfortunate. We could, of course, bundle the MAX_PUSH_ID > > with all packets that send a new request until the MAX_PUSH_ID is > > ACK'd. This feels a tad inelegant and I wondered if there's any > > appetite for an alternative. > > I don't think that this is great justification for that sort of change. > We explicitly removed head of line blocking from the processing of > SETTINGS. In practice, I suspect that this situation also results in no > access to QPACK also. > > Performance might suffer, but at least you can send something sensible in > a round trip when you would otherwise (with h2 for instance) be twiddling > thumbs. > > Why can't we have the best of both worlds? If we put this signal in the crypto handshake, the application protocol can guarantee that it arrives before any STREAM frames, and we don't introduce any more head of line blocking because the connection is already blocked on the crypto handshake messages to derive 0-RTT or 1-RTT application data keys. --0000000000007cac28059131b35f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 27, 2019 at 8:00 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
On Wed,= Aug 28, 2019, at 08:48, Ryan Hamilton wrote:
> In some testing we've been doing, we realized that if the packet <= br> > containing the initial MAX_PUSH_ID frame is lost (or reordered until <= br> > after the first request) then the server is unable to push responses. =
> This is a bit unfortunate. We could, of course, bundle the MAX_PUSH_ID=
> with all packets that send a new request until the MAX_PUSH_ID is
> ACK'd. This feels a tad inelegant and I wondered if there's an= y
> appetite for an alternative.

I don't think that this is great justification for that sort of change.= =C2=A0 We explicitly removed head of line blocking from the processing of S= ETTINGS.=C2=A0 In practice, I suspect that this situation also results in n= o access to QPACK also.

Performance might suffer, but at least you can send something sensible in a= round trip when you would otherwise (with h2 for instance) be twiddling th= umbs.

Why can't we have the best of both worlds? If we = put this signal in the crypto handshake, the application protocol can guara= ntee that it arrives before any STREAM frames, and we don't introduce a= ny more head of line blocking because the connection is already blocked on = the crypto handshake messages to derive 0-RTT or 1-RTT application data key= s.
--0000000000007cac28059131b35f-- From nobody Wed Aug 28 12:27: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 45AB61200A3 for ; Wed, 28 Aug 2019 12:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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_HELO_NONE=0.001, 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 4s00D7jf5FU1 for ; Wed, 28 Aug 2019 12:27:38 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F61120041 for ; Wed, 28 Aug 2019 12:27:38 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id j25so733000vsq.12 for ; Wed, 28 Aug 2019 12:27:38 -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=S3ZRvIX3qXnuYQLJ8hdVz1cluGz/dBmpWJUQDufif18=; b=UStAq1vJZH/3PPLzCq+3tGxHOfHTj95L+IjeaK9xmSmwxXZqRd+Kk8vPRz7vy+J5UQ QemV3xpPntooyVHYfWuWJpB26Q8LokNe6FxO0HsHQeOUSyLTSjlAh+q/+L2FQJPm9xpl wUqtopho9fTP/22feFevxj904xw7aDbL3nTV6SanLI8bn3rfSyNfW6vRctR4+Tzn6mz3 gAkzSDWBsBh+/Ox1wwmDoaSXYskEjVQQb9M93WprU+rZCtzG4UBtH+BnstbeL7eWjq+X U7mmw28NxAVP6sJxIAvXHsxVWIr1ExXfe7USP3rA7uwN6+TjmlpGtu3OxSItp7hGZeog 1hig== 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=S3ZRvIX3qXnuYQLJ8hdVz1cluGz/dBmpWJUQDufif18=; b=AhqIRI0NFlB/ahcGkMXQlksUucIYQj66th7NDlucQU6dzj02il2a3VUBSXyoq28GP4 djEAgwjd7DUln7dMg28Gdb25HkA4/blWy/xc7gwAKSagr5dFleRTU9BC2E9pH4YfsgUB WyrfVlhT4DAzDYw43TtWam8gLIGOU2k7FXZnuCQyMZzWqZCspoGjDZuw2zvoe0RLq31d l/OJm2dWl7TCq+RSH79m3v9IG35ql3lAtA/BfiIj3KE+DFTV1eHm3fUFsZHQfrop6sDZ 0ZN5LEuESniG+tRBYIBeoir6v1wbTYa9Yaj28/0nVKWEeyV1gSxgH044aAvBWO5gz7Ir bIxA== X-Gm-Message-State: APjAAAUquBX5Y9vpD4vMcrHG1sCR5b+7eJUx3OJUdgoZ9q8NXMATbabq w2OCoI1CoQ6YY4QFMdkfnKkF9SVVOINVUoUYaKUq0A== X-Google-Smtp-Source: APXvYqwm6DcJdk33FzKY/smwsHNqDx2A2iQsF/bWRTHkUzSXqFVijvRWa+vr0p49NFSTTpp0Z5sHhJwsBsbdFe87zxI= X-Received: by 2002:a67:d48f:: with SMTP id g15mr3542043vsj.143.1567020457495; Wed, 28 Aug 2019 12:27:37 -0700 (PDT) MIME-Version: 1.0 References: <1931a6f6-a25f-478e-b150-a200e0c3c69e@www.fastmail.com> In-Reply-To: From: Lucas Pardue Date: Wed, 28 Aug 2019 20:27:26 +0100 Message-ID: Subject: Re: Lost initial MAX_PUSH_ID is unfortunate To: Nick Harper Cc: QUIC WG Content-Type: multipart/alternative; boundary="000000000000b9a231059132614d" 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, 28 Aug 2019 19:27:40 -0000 --000000000000b9a231059132614d Content-Type: text/plain; charset="UTF-8" Lets take an extreme case, the client sends an initial max push ID of 1. On the first request the server sends a push promise - now its out of credit when chances are it wanted to push more than one thing. So it's back to "waiting" for a MAX_PUSH_ID or just giving up on push. The server needs all the logic to manage this exhaustion case. I think we are ok with what we have. But if we want off the wall ideas: allow MAX_PUSH_ID frames on request streams before HEADERS (solving the sequencing problem) and relax the rules for connection errors on limit decrement. On Wed, 28 Aug 2019, 19:39 Nick Harper, wrote: > > > On Tue, Aug 27, 2019 at 8:00 PM Martin Thomson wrote: > >> On Wed, Aug 28, 2019, at 08:48, Ryan Hamilton wrote: >> > In some testing we've been doing, we realized that if the packet >> > containing the initial MAX_PUSH_ID frame is lost (or reordered until >> > after the first request) then the server is unable to push responses. >> > This is a bit unfortunate. We could, of course, bundle the MAX_PUSH_ID >> > with all packets that send a new request until the MAX_PUSH_ID is >> > ACK'd. This feels a tad inelegant and I wondered if there's any >> > appetite for an alternative. >> >> I don't think that this is great justification for that sort of change. >> We explicitly removed head of line blocking from the processing of >> SETTINGS. In practice, I suspect that this situation also results in no >> access to QPACK also. >> >> Performance might suffer, but at least you can send something sensible in >> a round trip when you would otherwise (with h2 for instance) be twiddling >> thumbs. >> >> Why can't we have the best of both worlds? If we put this signal in the > crypto handshake, the application protocol can guarantee that it arrives > before any STREAM frames, and we don't introduce any more head of line > blocking because the connection is already blocked on the crypto handshake > messages to derive 0-RTT or 1-RTT application data keys. > --000000000000b9a231059132614d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lets take an extreme case, the client sends an initi= al max push ID of 1. On the first request the server sends a push promise -= now its out of credit when chances are it wanted to push more than one thi= ng. So it's back to "waiting" for a MAX_PUSH_ID or just givin= g up on push. The server needs all the logic to manage this exhaustion case= .

I think we are ok with= what we have. But if we want off the wall ideas: allow MAX_PUSH_ID frames = on request streams before HEADERS (solving the sequencing problem) and rela= x the rules for connection errors on limit decrement.=C2=A0

On Wed, 28 Aug 2019, 19:39 Nick Harper, <nharper=3D40google.com@dmarc.ietf.org&= gt; wrote:


On Tue, Aug 27, 2019 at 8:00 PM Martin Thomson <mt@lowen= tropy.net> wrote:
On Wed, Aug 28, 2019, at 08:48, Ryan Hamilton wrote:
> In some testing we've been doing, we realized that if the packet <= br> > containing the initial MAX_PUSH_ID frame is lost (or reordered until <= br> > after the first request) then the server is unable to push responses. =
> This is a bit unfortunate. We could, of course, bundle the MAX_PUSH_ID=
> with all packets that send a new request until the MAX_PUSH_ID is
> ACK'd. This feels a tad inelegant and I wondered if there's an= y
> appetite for an alternative.

I don't think that this is great justification for that sort of change.= =C2=A0 We explicitly removed head of line blocking from the processing of S= ETTINGS.=C2=A0 In practice, I suspect that this situation also results in n= o access to QPACK also.

Performance might suffer, but at least you can send something sensible in a= round trip when you would otherwise (with h2 for instance) be twiddling th= umbs.

Why can't we have the best of both worlds? If we = put this signal in the crypto handshake, the application protocol can guara= ntee that it arrives before any STREAM frames, and we don't introduce a= ny more head of line blocking because the connection is already blocked on = the crypto handshake messages to derive 0-RTT or 1-RTT application data key= s.
--000000000000b9a231059132614d-- From nobody Wed Aug 28 16:49: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 022BA1201AA for ; Wed, 28 Aug 2019 16:49:56 -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=K/4IpTT1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lsms2Gr5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFvdEbbI_ghv for ; Wed, 28 Aug 2019 16:49:53 -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 D25BD1200B7 for ; Wed, 28 Aug 2019 16:49:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id ED1B72205C for ; Wed, 28 Aug 2019 19:49:52 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 28 Aug 2019 19:49:52 -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=fm3; bh=lNLesna0N4/zUQP/HODxpquBH54Uyxu rEhdsq929qMY=; b=K/4IpTT1r+PSkMW5rcI1NSxTiKoSx4X3Clv52YwOg+x74YO b6LbjMB9RmJYMqISFDtTyGON08IG+jvMEQLmNKSXwECKdCbzICQPRAuUoSexnTSi obbzFhCs5eD9bpSotPATIkuqo3prlF/VEH+vnSqJWxBr9BHMNK1tygov6T1PVBvX XUPy8HCIdVmt090lgtuwTZdZ2RA7lrjGbzr+1PyJt418ciGnXUGkWOtj+C7oZ+G/ RfboYa/ugZt7l5mfqUriVOxWG0EhuMWGuxL3/uvytvdCRV/XkIeWcqGOubcIYGyy H3QtAOujMOJFAUBMXLFJv5q4QNZAJUxOR/RhHdw== 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=fm3; bh=lNLesn a0N4/zUQP/HODxpquBH54UyxurEhdsq929qMY=; b=lsms2Gr5PetCxCOABzMKYh eqEPKbD1sl9nbjSCndVhe3xhq0kC2dkGDZBQVcHxxei+uiGaEM33D1qd1XfLNiyy Uz93po3Q9K08wCtEIKvWEdwm7B5I/hgScRXg2+9o/Jsv/JTextv06Mapdw5NybmI /P1XFb/oJ8ugogMGTzluJjGtX+dkwv0DOKQbUNZwKlt7z0VeQHBZHEzNH9frsMOj O3XBEM0/Cu1wU4myWG8xmj3LnxLHabWV0ixdjpgD/MaiR0iQ2QwfBoDeUz5MdAWh JLuGhnoE0V1FkB4T//TQzKHQLkM4peW1zIFStW/lFUkuxac1UOdWucjUAyTqTlPg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeiuddgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 72D00E00A3; Wed, 28 Aug 2019 19:49:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-139-g73fcb67-fmstable-20190826v1 Mime-Version: 1.0 Message-Id: <3db7ef09-36fc-4adf-933c-39d3ae4be5c5@www.fastmail.com> In-Reply-To: References: <1931a6f6-a25f-478e-b150-a200e0c3c69e@www.fastmail.com> Date: Thu, 29 Aug 2019 09:49:32 +1000 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Lost initial MAX_PUSH_ID is unfortunate 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, 28 Aug 2019 23:49:56 -0000 On Thu, Aug 29, 2019, at 04:39, Nick Harper wrote: > Why can't we have the best of both worlds? If we put this signal in the > crypto handshake, the application protocol can guarantee that it > arrives before any STREAM frames, and we don't introduce any more head > of line blocking because the connection is already blocked on the > crypto handshake messages to derive 0-RTT or 1-RTT application data > keys. You can already have that. Coalescing the packet containing SETTINGS/MAX_PUSH_ID with the last Handshake packet is entirely possible and has the same net effect. And most implementations will be able to manage that (at least on the client side, coalescing 0.5RTT from the server is a little challenging). But it's not best of both worlds, that would be forcing head of line blocking. Right now, implementations choose their level of exposure. From nobody Thu Aug 29 06:52:01 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 B496912007C for ; Thu, 29 Aug 2019 06:51:59 -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_HELO_NONE=0.001, 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 0BzI_9NaWRgK for ; Thu, 29 Aug 2019 06:51:58 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD14712004A for ; Thu, 29 Aug 2019 06:51:57 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id u16so3562859wrr.0 for ; Thu, 29 Aug 2019 06:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hGiL3bQsMUtMAg6l97xSWE7OAM2sX/yHgvvFYpiAFvM=; b=UU0ONvPsmOOSeRPBHWGV1le/PH16CDu4bUCdhg1rxuE78I3svXFiyypdB5+DyCcrrG CZ9Cikk4/OlgO9miRCYh6Nt8Rocao3ENKVUboVu44LimrG9ytVi4tDsbpvPmzE7leYBV Rb54CI6rWfhKOXSDB9ObbmRznMoSZZWAc5xTuW3iKSNuIF7LnhcJMZhL36x+379Bn/Pb 2WDuqItDd+wocAhTOISwY9XwDejcxw0VCCuavmhwhRMmiyYAnliNE43BSQDIol4CZCJ2 UcK4n+3Qf8EeHnKsLNu6YxXUAg12omLfs6gDZ+zIpgne0Zby89YRtRvXR1TDvftfOHJR 2kzA== 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=hGiL3bQsMUtMAg6l97xSWE7OAM2sX/yHgvvFYpiAFvM=; b=oSrCw7jiABSqkGvvLQGucDHlVfFx2a9wYlfwmfrfUBsfjlNYKyN8+5nXLGxXgnlLI3 jmQb40xPlh1lB0/02yyqASUz2kTNYMcSEZolVBzo+I7ihoTrNbnuy1GNCaUf2qwJYeo8 OCMtHyRSbNeqyb2YVdmrMYRpT/60zhJgG54xzY0Or8bW/Vbe/kvgyblau5ttnpYSniQD PLuRwE22fqBM/ti4q1053p+Etr2dJAP+YMF2z8Tg+XfKJd3zQBSU8vRLCSvV/9VGrkmy XMdeBWG2/Q6B36v/OLZAW+8IVGYr/Xo+EcsTo5uhyojw/OS2/KLxAV8giL98rrcIOng7 NAYQ== X-Gm-Message-State: APjAAAXhsJ2PsDIUcKiqt0z7B6Y02n/wfYwJNpboPmTm9Hp+mNaGoq5l atoVal/ZhZZyBkO3EPSOCFfLjiG6boH12Izc+cRUSfgrD9U= X-Google-Smtp-Source: APXvYqy5Mo/0eJ3H6CT3o2u0Dl40WbbZyBOT2EfP24mTIUjmByc6j/U51iQoNyH/lgJmRKYEhi6b/aommk59p+l8gPg= X-Received: by 2002:a5d:62c2:: with SMTP id o2mr4106239wrv.350.1567086715833; Thu, 29 Aug 2019 06:51:55 -0700 (PDT) MIME-Version: 1.0 References: <1931a6f6-a25f-478e-b150-a200e0c3c69e@www.fastmail.com> <3db7ef09-36fc-4adf-933c-39d3ae4be5c5@www.fastmail.com> In-Reply-To: <3db7ef09-36fc-4adf-933c-39d3ae4be5c5@www.fastmail.com> From: Ryan Hamilton Date: Thu, 29 Aug 2019 06:51:43 -0700 Message-ID: Subject: Re: Lost initial MAX_PUSH_ID is unfortunate To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000007efd7059141cffb" 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, 29 Aug 2019 13:52:00 -0000 --00000000000007efd7059141cffb Content-Type: text/plain; charset="UTF-8" On Wed, Aug 28, 2019 at 4:50 PM Martin Thomson wrote: > On Thu, Aug 29, 2019, at 04:39, Nick Harper wrote: > > Why can't we have the best of both worlds? If we put this signal in the > > crypto handshake, the application protocol can guarantee that it > > arrives before any STREAM frames, and we don't introduce any more head > > of line blocking because the connection is already blocked on the > > crypto handshake messages to derive 0-RTT or 1-RTT application data > > keys. > > You can already have that. Coalescing the packet containing > SETTINGS/MAX_PUSH_ID with the last Handshake packet is entirely possible > and has the same net effect. And most implementations will be able to > manage that (at least on the client side, coalescing 0.5RTT from the server > is a little challenging). > > But it's not best of both worlds, that would be forcing head of line > blocking. Right now, implementations choose their level of exposure. > Yeah, coalescing SETTINGS/MAX_PUSH_ID along with the last handshake packet is definitely a possibility, and is the option I'm planning to pursue in our implementation if the proposal to put SETTINGS in Transport Params is really dead :) On the other hand if that proposal gains traction, I'd love to see an initial max push id setting. --00000000000007efd7059141cffb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 28, 2019 at 4:50 PM Martin Thomson <mt@lowentropy.net> wrote:
On Thu, Aug 29, 2019, at 04:39, Nick Harper wrote:
> Why can't we have the best of both worlds? If we put this signal i= n the
> crypto handshake, the application protocol can guarantee that it
> arrives before any STREAM frames, and we don't introduce any more = head
> of line blocking because the connection is already blocked on the
> crypto handshake messages to derive 0-RTT or 1-RTT application data > keys.

You can already have that.=C2=A0 Coalescing the packet containing SETTINGS/= MAX_PUSH_ID with the last Handshake packet is entirely possible and has the= same net effect.=C2=A0 And most implementations will be able to manage tha= t (at least on the client side, coalescing 0.5RTT from the server is a litt= le challenging).

But it's not best of both worlds, that would be forcing head of line bl= ocking.=C2=A0 Right now, implementations choose their level of exposure.

Yeah, coalescing SETTINGS/MAX_PUSH= _ID along with the last handshake packet is definitely a possibility, and i= s the option I'm planning to pursue in our implementation if the propos= al to put SETTINGS in Transport Params is really dead :) On the other hand = if that proposal gains traction, I'd love to see an initial max push id= setting.
--00000000000007efd7059141cffb-- From nobody Fri Aug 30 06:37: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 CE8641200F9 for ; Fri, 30 Aug 2019 06:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=uclouvain.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 C3vuYrrAzze7 for ; Fri, 30 Aug 2019 06:37:02 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140115.outbound.protection.outlook.com [40.107.14.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A931200F4 for ; Fri, 30 Aug 2019 06:37:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mEJJ+fsfpjrYc0S+zUQjCu/CooR0K8Yf4PRkylNdsLe4ObyhryxgpLMviwafQJ4zrmc2wlq/2XCNZCbKxGmuKG6xO4pN71/v2Rtx2lDYDy1xjbTLPZG8aV+4cGCs+rhEfpG/BZ0bRWhimf+dViHbRCHZ3Y3U6CYd8pdpVtyVrFOwr0LsN40gbyVa3amemCTn8qBww9wKdGOZxJaCGavzMY+nU9n6eCiEoSx2gKG0JQEQxdprotaAWUThp77xWXYzdEiiBiucpzm0GZeu3Mpk2BzifuqzCNmNPTYFbA5cn9A7fQtYcM+eTBkroot7b2hezjJs5sYyAel6Fe2UAWCo6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7mb6L5d3/KTK7nj4RY8WohkAkPFiuKSL4mmA3sUEo3k=; b=FBudH3qr9Yy06POcQ7HoQfTO/WcqCdaJXGv2Y8QId5R1bORaY1NWK+e/JpW7EKqSB1wflJ7mnyi1t56aFoGdn6WiVf7vN7lpPbVUkmITSEGKakDXHwpumGVp1absToStCCC9zTrwY9KUod7LI51+o+cG0C8GrBkYP/s4GRCJQVDc6/vSe4RdZPhMlpcVbk0LhkoMeHGYU8F7A5zXmi5FmsqCbd/3L0Vm4CKGHMQ2rKwxP1sSflP2BINSR+dGulH/S7PosbgiO2kCO2vtRzhekBnRPxcU73ZVLy5k1XdMsl7FXZ/wVDjt4jSmyOU/fgth4YmT6Do9dts1d0OwgqNj/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uclouvain.be; dmarc=pass action=none header.from=uclouvain.be; dkim=pass header.d=uclouvain.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7mb6L5d3/KTK7nj4RY8WohkAkPFiuKSL4mmA3sUEo3k=; b=dDycIMmSLIehr1ucFptQtxSdxuP5hF6/v0M7vByul3Z8wADhaLvY3WVMw4Amu/V4F6cVg55u80C+0+6zns+5cBa34h3Woqf+w3hdYqljUMpRwAvkXeQcQlWxkBxzHj7kmqslX0oWquPa+bKvUhXn/pw7qtkLRkuFyd4q7d4YYOQ= Received: from AM6PR0302MB3463.eurprd03.prod.outlook.com (52.133.10.24) by AM6PR0302MB3206.eurprd03.prod.outlook.com (52.133.31.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Fri, 30 Aug 2019 13:36:59 +0000 Received: from AM6PR0302MB3463.eurprd03.prod.outlook.com ([fe80::1879:b2b7:439f:8413]) by AM6PR0302MB3463.eurprd03.prod.outlook.com ([fe80::1879:b2b7:439f:8413%7]) with mapi id 15.20.2199.021; Fri, 30 Aug 2019 13:36:59 +0000 From: Quentin De Coninck To: IETF QUIC WG Subject: Pluginizing QUIC Thread-Topic: Pluginizing QUIC Thread-Index: AQHVXzf/3wf+BIP4RESzcjdSiYo/Aw== Date: Fri, 30 Aug 2019 13:36:59 +0000 Message-ID: <1b1ac685-73ce-da3e-9c7e-ad210e40d76d@uclouvain.be> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0161.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::29) To AM6PR0302MB3463.eurprd03.prod.outlook.com (2603:10a6:209:24::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=quentin.deconinck@uclouvain.be; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [130.104.228.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dd886a2e-f2f7-43c6-352b-08d72d4f2201 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM6PR0302MB3206; x-ms-traffictypediagnostic: AM6PR0302MB3206: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(39850400004)(396003)(366004)(136003)(53754006)(189003)(199004)(2906002)(99286004)(31696002)(14454004)(66476007)(6506007)(36756003)(66946007)(386003)(6436002)(102836004)(66446008)(66556008)(64756008)(6916009)(52116002)(221733001)(86362001)(31686004)(6306002)(6512007)(25786009)(186003)(5660300002)(26005)(3846002)(66066001)(6116002)(8676002)(4744005)(81156014)(486006)(81166006)(966005)(2616005)(476003)(6486002)(8936002)(478600001)(7116003)(3480700005)(256004)(53936002)(316002)(786003)(71200400001)(305945005)(7736002)(71190400001)(79990200002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR0302MB3206; H:AM6PR0302MB3463.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uclouvain.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EbrnoX+J+ahu8TfxZ+cpN/YwQulxhi5417HnU8aS6o7f4mtWnR5nrUFpe0+V6aLggtIpaHhjFtGBh+UxcSo2pZyAyElbTObsJx7cJL3QlZRkzHMlv4CZFQXIkLrmsGGSUIXPR7GH2ue6gMmAAIPaesPUr61i++FGLPt+GITXl3JCq9cCVfWBg3yVfF4mThG1yiyV0RvVGTlN4n0B0IhuV8dfz1VAuImqfgeTJjFFL/CQTmthPbRyph2jaCo76nEERIGxJP8glOJ/vR573UkZdnH1Bh98svf0LKEGqgGQV+eXlr0ik5VWhkyYjKB5ael9reKIlgr+tcCdAd21SjDE79cNGepp+/Qr61AgCcf5eG1fJ1KIHksHt/xobney22zIxbmZqG2BfQCQe3JJ53NQPZBem7Cp1cguMlr7E6rjS8joTX7bL4IOczDi904RlUt9Msbd8zqzbnmsbAtMtwSKEg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <827D9BADD47C7E46BEEF16EFF9010996@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: uclouvain.be X-MS-Exchange-CrossTenant-Network-Message-Id: dd886a2e-f2f7-43c6-352b-08d72d4f2201 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 13:36:59.4663 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6DEYeklrNqA4fHbewNokhin/6mqTY6X0CTnj8Zo+CY6PZ2pz+5JvfwwgqoJSEl6HT2NG7X+rtPhLyQORZp/6ARqTzH4iORN1Cpnxdsz043o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0302MB3206 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, 30 Aug 2019 13:37:05 -0000 SGkgYWxsLA0KDQpXZSByZWNlbnRseSBwcmVzZW50ZWQgb3VyIHBhcGVyICJQbHVnaW5pemluZyBR VUlDIiBhdCBTSUdDT01NIHRoaXMgeWVhci4gDQpJdCBleHBsb3JlcywgaW50ZXIgYWxpYSwgaG93 IGEgY2xpZW50IGNhbsKgIHN1cHBvcnQgb24tdGhlLWZseSBuZXcgUVVJQyANCmV4dGVuc2lvbnMg KGFkZGluZyBtb25pdG9yaW5nLCBtdWx0aXBhdGggc3VwcG9ydCwgRkVDLXByb3RlY3RlZCANCnBh Y2tldHMsLi4uKSBvbiBhIGdpdmVuIGNvbm5lY3Rpb24uIFRoaXMgaXMgYWNoaWV2ZWQgYnkgZHlu YW1pY2FsbHkgDQppbmplY3RpbmcgcGx1Z2lucyBpbiB0aGUgaG9zdCBpbXBsZW1lbnRhdGlvbi4g UGx1Z2lucyBhcmUgYnl0ZWNvZGVzIHRoYXQgDQppbXBsZW1lbnRzIHNwZWNpZmljIGZlYXR1cmVz IG9mIFFVSUMgbWVjaGFuaXNtcy4gUGx1Z2lucyBjYW4gYmUgDQpleGNoYW5nZWQgb3ZlciBhIFFV SUMgY29ubmVjdGlvbi4NCg0KVGhlIHBhcGVyIGFuZCBvdXIgcHJvb2Ytb2YtY29uY2VwdCBpbXBs ZW1lbnRhdGlvbiBhcmUgYXZhaWxhYmxlIGF0DQoNCmh0dHBzOi8vcHF1aWMub3JnDQoNCmh0dHBz Oi8vcHF1aWMub3JnL3B1YmxpY2F0aW9ucw0KDQoNCkJlc3QgcmVnYXJkcywNCg0KUXVlbnRpbiBE ZSBDb25pbmNrDQoNCg== From nobody Fri Aug 30 13:02: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 AB98912097F for ; Fri, 30 Aug 2019 13:02:10 -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_HELO_NONE=0.001, 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 nT2JS_GducWZ for ; Fri, 30 Aug 2019 13:02:09 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45080120AD9 for ; Fri, 30 Aug 2019 13:02:09 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id s25so2693725uap.7 for ; Fri, 30 Aug 2019 13:02:09 -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=EOxbaF3t2l+ITi/6U+KttMO1qtdke8UOa1eaU355RMM=; b=DVi5pE7EedVDh9wSBKQ/RMJTtUaEOiFDb71PSLQD95AGj64emW9SBWzC4cQBxe5QmA wujEKhWOG1XCSRsZt8/Ofoet4TbA+4w702uQIfBwFzLONHkSdaXCCB0wmwGCryT5ebqJ fQ+iE1HsH4I0l9ujjfGgehY6T6GS8kdft6OTsCpmrX1qLz8ur4m7NqE97TVOKyjUdewX QDbX70HqZDxr1iIbQvNwjRaOvyUUuvWbc2PMSDMzCWCn9nYBL93i2DbgM05iR7IBV3tP 1qE1QaGdnCJ9nJc3RjM1QSi96VvLrAjT3NGO6XnhLWb+JOlIsNySQjklKmNIoC52g6BY OonA== 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=EOxbaF3t2l+ITi/6U+KttMO1qtdke8UOa1eaU355RMM=; b=fvFxLM5ZX8L+nkjkLczLAzzdcXXxFNgVop8KnYQbZkXcvXh5VO9NCRylg/9L7kfcm5 ZeeBpjRFm/W02F+c6Kt0AP8L/IZdI42u7obcF6j7OEA3X1WP/oYJxEBNpbyE3s1e0TMd B30mPZKTd70pCbkzsu2pyVRNxob9B6YopNb8iQ7n+I/8sqjEekYG0KlrKHhsFHgIr3zv LmPCip1U39xt2S6hRrgLChP1PFTp+/QfN4xI/xbhFvypkW39ZQnCluIcS34CZs56tMtR fvlMjZam6Ghp3Y2yOyaGoG9xxt3d1Jlf0G5/rUUf5j2XDNJu0smftVWnfpMislJ/sH53 jjKw== X-Gm-Message-State: APjAAAUkiJPS7/n0KZW1XptxFWX+tJgGAHYroFAuE7PZtH3Ue9XNIIXE uwCre2LTDyZXVqGMfwV06IKp5dJnPubxWhN2Z9uno6j3 X-Google-Smtp-Source: APXvYqwEIU/YEiZzZxpnlkHMPNhg9a+o+AX573YELY7fg4yNZq3eQ7AHLOS+siHCScwTSt7e2HGh9dknZG1u7TH+XWY= X-Received: by 2002:ab0:7393:: with SMTP id l19mr875350uap.102.1567195328008; Fri, 30 Aug 2019 13:02:08 -0700 (PDT) MIME-Version: 1.0 References: <608f1832-2ac3-4459-875e-bdc9a86ad8b8@www.fastmail.com> In-Reply-To: From: Lucas Pardue Date: Fri, 30 Aug 2019 21:01:49 +0100 Message-ID: Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME To: "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d1d7d505915b18a7" 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, 30 Aug 2019 20:02:23 -0000 --000000000000d1d7d505915b18a7 Content-Type: text/plain; charset="UTF-8" For anyone not tracking the GitHub repo, I created a PR that collpses all frame-related errors into HTTP_FRAME_ERROR in order to see if that moves the needle for anyone. https://github.com/quicwg/base-drafts/pull/2996 Lucas --000000000000d1d7d505915b18a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For anyone not tracking the GitHub repo, I created a = PR that collpses all frame-related errors into HTTP_FRAME_ERROR in order to= see if that moves the needle for anyone.


Lucas
--000000000000d1d7d505915b18a7--