Re: HTTP Delays

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 14 January 2021 13:53 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EE73A1367 for <quic@ietfa.amsl.com>; Thu, 14 Jan 2021 05:53:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 yZppu2yq6YCL for <quic@ietfa.amsl.com>; Thu, 14 Jan 2021 05:53:56 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2079.outbound.protection.outlook.com [40.107.21.79]) (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 5848A3A0E04 for <quic@ietf.org>; Thu, 14 Jan 2021 05:53:56 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T3pcfmfctewBbOPiKVYVAl1NngteWsNgpQZaNIxB/PuIhhN11srM3ZCpA2IXz3o7Klj3w21P5cy2+Lql60I72YcspwvTdorHlCYk9h6Xjty0URWPesXuePL+hJmtL2T7rc86ZECMXOFJpG1MwVWtor7+4dFm/T7Qc1/4kJSWd3rmZ6p5PAu8k/WK3oclX+bmQ1MVLgOH2aQ9G8VgwyJ8HmYvRkWDknPf77XhZ3B+orqtV+IhkcwJ2vhC2Orkvsaf+scO1lLoumc2jmIh3rHH0hai/KZ05AKi2jS9/96lG/2jzXmXhKZA+1ymwWNZEW8Ng4i/otw0p9/7kjsfpCJWbQ==
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=qUuhbn0UlFVHX2t9zA5BGZMd0jY2uL+KcoXesea8S0s=; b=DeFjsdT8CX374ZNC1y4fUbM8JRYY7IJkJ4F4fpzZZ5bpSDCTs0GlRGE3CG5xO+T0fWmHKLU9HyhbvnGGbVuGKJ2JrMHFW8b1d26ARPZv9PQKPM7WnBQd8gpIrix+D6vBiiFCUStN3M8pC2aK4A5mumpxHI9R/9a2Zh2ZVxhzGtEDnfgk/S45m1zh1BUtVzDTS3FQxIm772hczD9/gJbkAiNIUIFSAEPZ0fY4TifAdZ+i98NLCenAtTLLRYkR00T00lVj4VUuxyTqPQz08AZASACc7yQNnDRRDRRRaC2zjp9TaVF17a3sAn9qYxKo3II2unJzNQ5hiKJqrzw0cA1Neg==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qUuhbn0UlFVHX2t9zA5BGZMd0jY2uL+KcoXesea8S0s=; b=igNCNoqX1h/Agh5AYkLXoF/qjtAYGhB1Lo7hQVGFUqQnF0Bkx3pU0kUUODdxTL+COM1EWmOkKBYreoqcR4Se0tp2hnGV0KPa/VVGvqVgQxseKqq+3mnz448kMgk4yOUfXASFEaoJB4z3H6S/ksRWxm4vT6mNftHj7j5TJ8mR84Y=
Received: from (2603:10a6:7:8e::14) by HE1PR0702MB3771.eurprd07.prod.outlook.com (2603:10a6:7:88::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.6; Thu, 14 Jan 2021 13:53:53 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%6]) with mapi id 15.20.3784.006; Thu, 14 Jan 2021 13:53:53 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "julian.reschke@gmx.de" <julian.reschke@gmx.de>, "quic@ietf.org" <quic@ietf.org>
Subject: Re: HTTP Delays
Thread-Topic: HTTP Delays
Thread-Index: AQHW6FxPATl0FYPkr0GAYz81a2atM6oi6cwAgAE4yQCAAT3ggIAAUKyAgAAyFoCAAAdaAIAAAy8AgAE66IA=
Date: Thu, 14 Jan 2021 13:53:53 +0000
Message-ID: <7b3fe48634ddd2c93172656c44cf64ec0e3cdd3f.camel@ericsson.com>
References: <CAM4esxSObWwLfzRWazAg+Q+9=BHGzXaSSduONozHF_zGCqC-kg@mail.gmail.com> <CA+9kkMA++3QYnXiVwuKSPZDYycERRrC11b-jHTG6JcyjngDhqA@mail.gmail.com> <CAM4esxQ9w0h2-rZ1ynhEMKAxwq0gfSVJtfGXV8ydGdUTEefMuA@mail.gmail.com> <029bd6e66fb81e2ecf16e35adf30b90c816c9962.camel@ericsson.com> <CAM4esxQeFaYytwyeB+m_yDrn8SSR8Yy4BHTsvxngTjG3=y0Zag@mail.gmail.com> <4459A34C-ED70-4354-9653-BA5165EC887A@gbiv.com> <CA+9kkMAqj2B8VprF_j=jLJ2CKbWvR6oO+ciHaTCSF1Sd3f_KtQ@mail.gmail.com> <f64ca7ca-0f54-3a8d-b5aa-428835bef6bb@gmx.de>
In-Reply-To: <f64ca7ca-0f54-3a8d-b5aa-428835bef6bb@gmx.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: gmx.de; dkim=none (message not signed) header.d=none;gmx.de; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7ba2fb92-882c-48ce-7a00-08d8b893d420
x-ms-traffictypediagnostic: HE1PR0702MB3771:
x-microsoft-antispam-prvs: <HE1PR0702MB377165C5C3EB2214C84AC39695A80@HE1PR0702MB3771.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: R2OLFXN55ky0Xx1FDi2/8R+UXPgb8R3nQKFXP3la9T46UNUhyUX7E2ZCBiMSNW22otwYsVfjx5DjPqBY3np4osLuIiKadHNoqNO4FbE1ZGhyfqcNChzo2bGtjlNRL07toPpipClH+R5hVmtS+ugr4gtVE1lMiWI0XlrGXUsrwZEdka95qLN30+f2K12NflbKGvuUOEycnBYOohgQynBWKGPN3VZf51Ea+v9eJhr7HgieltALglw/zUc6JHBUap8+XynmTR8HWiqUjuzfVOjegsxRLJ4SevhhsYU2MygFzbULCVgAU5k6DZGqnYRjRp/Eh6T/idX4+HycuoJTh2mbFu8TW/XbundX/X/72glQIXqZRZXgB4iGsd8JG2UjTCgFhVK63e90RPDdRAnWs8fIDVLBzMI1w8otqiYvQA0EtPAkieJoPgUn6ps0HsqEEFcH
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(366004)(376002)(39860400002)(136003)(186003)(83380400001)(3480700007)(99936003)(26005)(478600001)(7116003)(66556008)(66616009)(6506007)(2906002)(66476007)(76116006)(66946007)(44832011)(64756008)(66446008)(5660300002)(86362001)(8936002)(8676002)(36756003)(71200400001)(316002)(2616005)(110136005)(6486002)(6512007)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?TG9xYktzZDNHNlArSm5LR1YvVWZ5ZnhWaHhQeGZtcmJSVFFwNHV5TGZQK2dD?= =?utf-8?B?OFROYXFkbXJwLzZuSFRpRC8renhqbHBlU3l6ZXk1T0ZmUUI1bWJUM3NuM2VV?= =?utf-8?B?QTZPeTBodThSOHIyNnlwVDFmSmpZaktldG15TjNhTDJIMDJTRktCVkkwVTls?= =?utf-8?B?VzBCS2Evek5lcmpsVFg1ZS9sK0JYSUx6eGhYbmFkcTlhUGxHOFN6TEFIMERU?= =?utf-8?B?U1VQUmZDT2Ywb20zVUpZdlNoUGZHM2N4YmgzSGdnbzVobVp3ak52aUdMeWFW?= =?utf-8?B?QzlvK0IvVkd4SSsxdjVQK0kwdy9SRDBkQll5SlVGaHdTemVoanNkT0JMMWVN?= =?utf-8?B?cStWbFB6YytJaFRUTVZSQ0FKVCtyTDFjWFRFTWkxTTBCK01MMFQ3eXN6akF3?= =?utf-8?B?R0luWGY5SmZHaGRLbUZmd1pBNzk2dGliSXpoUlZONlNlMVdZQzJzUWo4T2lR?= =?utf-8?B?aVR0TUJXOEUyL1JMbVU3VEtjdW5PNDVYMjB6eVpXWEYveWV4WU9zZkh4QTlY?= =?utf-8?B?SHZTUnM3Y29iejh0MUhIdHVpa1BZK3p6TmROc0RDeFFnRmJvMWc0amJIWXhL?= =?utf-8?B?Qi9PNFhHTlpaNWR2SzVLSUtWMFpXSGpiNU5JRFd2K2tHdU9UbE9nV2U4MW15?= =?utf-8?B?eHYxNENPb0pZRytoOTNzM2lvWTdwcEJmVDNMVWhEdmU4TnR0dE5rQVA4R3Ji?= =?utf-8?B?RlNGb3FWQUpZYzBpbE5WVXNiUGNnRFVHNlgrWXAvdEJpODIvL1JsU3FCbFJr?= =?utf-8?B?dENxWTU1Q3B0THQzaHV5Y2F6MWdVT2V2a29JOU5aTG5SSDZDRFd2RXlkYkRI?= =?utf-8?B?bWdEQkVnTFB6Mk8xaXNkSlE3WEdxbGlNbWlmb0c4bmQ1QzA0aldHYmgrcDBG?= =?utf-8?B?ZkJoR0hwZnhVVU45bk1JYU1TQU54VGxzN3k2MlQxUGs5QVloSW9GSE1LYStZ?= =?utf-8?B?UHh6RVkvZE85bDNGaFZUYlQzR2Z5OEwwMmN0NVBEcDhOY0JuTHRoUEVCM01F?= =?utf-8?B?TVZubkphVzExc1ArckE4QWszWC9GTEU2Q1JVOGxFekl5L29PK1ZpWTJCemds?= =?utf-8?B?RitvY2QyWkN2S1BUc1R4Z3JlZHhrTjlzNXRlY2JqQUhRRUVMUmxxbnAvejd4?= =?utf-8?B?STBYZ05CRHYrRHpUenpwRVpDN1FOR1JFNzNjc1poa0ErZlZtYmVBdDR6aEh3?= =?utf-8?B?Qk4weFYvSDhMNGJJbUZJY2tOMEhaUUFkdUdWTWRUVFV1TjJKb0J3aXRjMnFW?= =?utf-8?B?emsrVWd0d2NOYkNXRUR0NnVGSmRkR0FjdVZaRktva282U0dpWEZnVi9CUlJ5?= =?utf-8?Q?L9xxL81nTTJUfB3AjNIkjI2gpRLHjQgskg?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-dveCuo+GPKJwFJMlwc1L"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ba2fb92-882c-48ce-7a00-08d8b893d420
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2021 13:53:53.0867 (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: AGLKUV+H7JPGG0bHO1UrGFbWyomyL7wSTI/g3gwUppurzMK5E0i9lCxpae8FG/IF2k1jXDrqnJcHZr8jCBKccTtuhxRdzhH8ImlubgFZFm4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3771
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/JWKNNbedOXlnxaKQxTqSXcY717Y>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2021 13:53:59 -0000

Hi,

On Wed, 2021-01-13 at 20:06 +0100, Julian Reschke wrote:
> Am 13.01.2021 um 19:55 schrieb Ted Hardie:
> > ...
> > While they could theoretically pre-assign it, the RFC Editor won't
> > publish the document without the documents actually being available for
> > retrieval.  That's a big reason you get clusters.  This is why we do
> > downrefs to the drafts; since there is an onward pointer from the
> > referenced draft to the final RFC in the tools, that's considered okay
> > as anyone who seriously wants the reference can readily find it.  [Note:
> > my opinion on that is separate from my recitation of what I think the
> > facts are.]
> > ...
> 
> Maybe we need a separate discussion about easily (or even
> semi-automatically) updating published RFCs when their downrefs become RFCs.

Which isn't done at all. The main body of the RFC when published is inmutable.
Thus, if you want to align any language changes or anything with the new HTTP
specs when going for do a "downref" means a new RFC. 

That is why I didn't understand Roy's comment:

> In short, there's no need to be pedantic. As soon as the QUIC RFCs
> enter the RFC ed queue, we can fix their content as such including
> the final protocol versions and ALPNs. If the HTTP Semantics spec
> needs additional changes, we can choose those changes deliberately
> without impacting any content or references within HTTP/3. We don't
> xref by page number. 

What you can do is do a last alignment in AUTH48 with the status of HTTP
semantics and cache at this point. If we want the rfc numbers of the HTTP specs,
then you have to wait until they are ready and also in AUTH48. So, if the HTTP
semantics and cache aren't ready when we come to AUTH48 you still have the risk
of missalignment if going down the downref path. 

I would like to point out that just this week a PR was merged to the HTTP/3 spec
to align with the latest changes done in the HTTP semantics. So the risk for
missalignment is not zero here. Sure the HTTP specs are mature, but you can
still end up in a situation where it becomes hard to interpret HTTP/3 correctly
when section numbering and terms don't align. 

This might be primarily directed to Ted. However, I don't understand how we
could do a downref in this case when we have a normative reference to a IETF
draft. This case is not the type of downref that RFC 3967 discusses, where the
normatively referenced document is an lower maturity (Informational or
Experimental) RFC or an external document. So I want to understand what process
diviation Ted really had in mind when he suggested this? 

Sorry to be a damper, but I don't see we can do Option 3) within our process
without violating our process. 

Cheers

Magnus Westerlund
Responsible AD