RE: Connection coalescing in HTTP/QUIC

Mike Bishop <mbishop@evequefou.be> Fri, 02 November 2018 05:14 UTC

Return-Path: <mbishop@evequefou.be>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB6012D4EA for <quic@ietfa.amsl.com>; Thu, 1 Nov 2018 22:14:40 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 39BLnufBA5Md for <quic@ietfa.amsl.com>; Thu, 1 Nov 2018 22:14:37 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810119.outbound.protection.outlook.com [40.107.81.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F3D127B92 for <quic@ietf.org>; Thu, 1 Nov 2018 22:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IPuChY3FhAExg+xoIrMcJwkOXqIH4t9+zg7UUWsY4tQ=; b=rRWKmmfwuNlJXSpAL4GMlF3ynaiwsa+iMt+Ms68sGEGI75t0pmeweV3WmSS5T7Ql0HJ5BFdHJImY4ffB5W/Jn+aku/CnyyNPByRQHfopmeYuG0IjbGI30sI4QXaX7+IHoAhWlE3XamOaE4hxSwjtpFT2YDc5b0udEDXPPIwunco=
Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0168.namprd22.prod.outlook.com (10.169.185.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.22; Fri, 2 Nov 2018 05:14:34 +0000
Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::706e:6d82:cc25:531f]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::706e:6d82:cc25:531f%10]) with mapi id 15.20.1294.024; Fri, 2 Nov 2018 05:14:34 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Frederik Deweerdt <fdeweerdt=40fastly.com@dmarc.ietf.org>, "lucaspardue.24.7@gmail.com" <lucaspardue.24.7@gmail.com>
CC: "quic@ietf.org" <quic@ietf.org>
Subject: RE: Connection coalescing in HTTP/QUIC
Thread-Topic: Connection coalescing in HTTP/QUIC
Thread-Index: AQHUcWvn7qyxDjY/jEuHp4znl63eM6U5+O4AgAEa/gCAANyjkA==
Date: Fri, 2 Nov 2018 05:14:33 +0000
Message-ID: <CY4PR22MB0983ED21433C7C9B55912C12DACF0@CY4PR22MB0983.namprd22.prod.outlook.com>
References: <CAM8YLW=xxHQpLdrOmy_i5gOFRyax8UC7P9cXRSNE=xQ+gHUtDA@mail.gmail.com> <CALGR9oZvCDdp6c=CNNsFoexmB92VTMsH_b0jjRc1f5X_Bu5-bQ@mail.gmail.com> <CAM8YLWm4tQv4CG4ea6Usc1LvE-D4hoVv1Ynttqo_MiQJc4C4SQ@mail.gmail.com>
In-Reply-To: <CAM8YLWm4tQv4CG4ea6Usc1LvE-D4hoVv1Ynttqo_MiQJc4C4SQ@mail.gmail.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: [71.91.75.197]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR22MB0168; 6:7+i3i6wolBi16SDiHDQCpB+J6QjKfQtr1y0rFgGebOt2AQGThTcSMJwlcLzX8odirDezYCu9iQcgrcgOUZoeE29QC4yPb1zCaBP6uZgWQ/DwUa+Fan2QVbLfW9t/zkq2ckTjVQw5gLTdVJNTmsZ4EK1preXWa8dZV77U7rT97tFzNvlQ6XFUvQwlPLnsXv7aDvJzBUxjgZgWsE0iJ67yLBF7IVjZeT+dVcJgwLYEfDwmR9Zha24AcOpLmeOCsVj+ypEm15mic2DOoJvZ7wOf/K7M6KTqLH4dx9OIMQHF8LRdGwHacSqxDUAzPmsiI2jSDbrJ6UOBrhMwnKLyZwQ8/OkAQcUBWbRBMM27eeQzN3JoUZWpuLCpvzQ9lK4vu9lwT581Iu12+hQEL07uSlk550inNJSWDz0ewnnwPsiBv1L4dZ0WsoGRURVLrhD9hNn61KN44X+/UpsCO7KM0wzqTQ==; 5:GLahHHo+N7ssOXhUW97Tx2HS93+lbB6IkYETQuTmXj+Oj2/N6cyAiNHhSynckIdqlrFsZfcOTlNkFn9eGHxVEZ10zUxCdDxyT5XBKwrCc3TvQHyEnyGPoer6FFcuKJy08DAKXuNssmwVrVC1dc3YmdwcYpvEkIzbckv/sUGnh4M=; 7:1l9toHsu+DxFKfv/sg/MZYGdaNW7nyWts3xs/sOubZ1SPvgfFmQi2Wwy6WyclfyvMwGr+etlXGrCQiaZoDZwF8N+FaiZAyD8j79AWseijhe4TNgCuRF3TwmGIyDy09X3cCkv2c6/5vt7/hvjuHCu0A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 28f549bd-057c-488e-a05e-08d6408213f4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0168;
x-ms-traffictypediagnostic: CY4PR22MB0168:
x-microsoft-antispam-prvs: <CY4PR22MB0168B6FF44ECF0B03F733E51DACF0@CY4PR22MB0168.namprd22.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(150554046322364)(85827821059158)(166708455590820)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231382)(944501410)(4982022)(52105095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(2016111802025)(6043046)(201708071742011)(7699051)(76991095); SRVR:CY4PR22MB0168; BCL:0; PCL:0; RULEID:; SRVR:CY4PR22MB0168;
x-forefront-prvs: 08444C7C87
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(366004)(396003)(136003)(376002)(346002)(51914003)(189003)(199004)(476003)(186003)(68736007)(11346002)(229853002)(2900100001)(446003)(86362001)(53546011)(6506007)(3846002)(790700001)(6116002)(66574009)(102836004)(81156014)(8936002)(8676002)(256004)(81166006)(486006)(14444005)(76176011)(74482002)(33656002)(14454004)(606006)(66066001)(7696005)(97736004)(25786009)(4326008)(39060400002)(5660300001)(2501003)(74316002)(55016002)(316002)(110136005)(71190400001)(71200400001)(508600001)(26005)(966005)(105586002)(53936002)(2906002)(7736002)(236005)(99286004)(6246003)(9686003)(106356001)(6436002)(6306002)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0168; 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-microsoft-antispam-message-info: mNvRtICmhUs1quYxImMAmQmKbpKfBsFdYpOw41sDOYZbjGHE0OWME+BC6WJ/VlVI8z4mK+OXmmSUfwqbETOujskZpWBLfQ3mjLjS5RQWI8h65lunjgaluTJO1HsEpVfpcpzO+baiPwvlDQXcU5yz/ItXTTV4Lr9dQl+pgBbPaGFq39jJr3bSegYIaePQCS3czVk8JA2GzskS0LC3nwFIWT3cPp1jBlOzwww584p6F6nHG9w6E5npQWU3RigKJsAkSOq6bcP16dCL7C9nO8hI5bt3CYQSmXMhLIw6tDy/XvBO4l0lS8qaXp2W3UAd2tMm/Y9qVQTXdns9qkFZbCasXnR7ozDWUaY+vv3XcikY5BE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983ED21433C7C9B55912C12DACF0CY4PR22MB0983namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 28f549bd-057c-488e-a05e-08d6408213f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 05:14:34.1516 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0168
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Mn0LEkg8yojyBwjrmKm0TZtbifM>
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: Fri, 02 Nov 2018 05:14:41 -0000

The short version is that the formal definition of a URI is to a particular hostname, protocol and port.  The protocol is always implied by the URI scheme; there’s no mechanism to specify it in the URI.  “http” and “https” both define the protocol to be TCP.

We’ve defined a mechanism (Alt-Svc) by which one hostname/port/protocol actor can delegate its authority to a different hostname/port/protocol.  We’ve defined a mechanism (ORIGIN) by which one host can assert that it is also other hostnames independent of DNS.  In both cases, the certificate helps to verify that claim.  But nothing so far defined by HTTP allows a client to guess that a different port and protocol might serve the same content referenced by a URI and then accept it with confidence.  There has to be some delegation path from the endpoint referenced by the URI and the endpoint you’re talking to.

There have also been discussions about how to create a URL where the authoritative endpoint is reached via QUIC instead of TCP.  So far, those discussions haven’t borne out anything concrete.  That’s not blocking, however, because that doesn’t require changes to QUIC – if we need it, we can define it later.

From: QUIC <quic-bounces@ietf.org>; On Behalf Of Frederik Deweerdt
Sent: Thursday, November 1, 2018 10:56 AM
To: lucaspardue.24.7@gmail.com
Cc: fdeweerdt=40fastly.com@dmarc.ietf.org; quic@ietf.org
Subject: Re: Connection coalescing in HTTP/QUIC

Hi Lucas,


On Wed, Oct 31, 2018 at 4:03 PM Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>> wrote:
On Wed, 31 Oct 2018, 22:48 Frederik Deweerdt, <fdeweerdt=40fastly.com@dmarc.ietf.org<mailto:40fastly.com@dmarc.ietf.org>> wrote:

Hello,

In draft-ietf-quic-http-16 "2.4. Connection Reuse" states:


>  Clients MUST NOT assume that an HTTP/QUIC endpoint is authoritative for other origins without an explicit signal.



The explicit signal bit (is it referring to an origin frame?) reads more restrictive than connection coalescing for HTTP/2. Does that mean that clients wouldn't

be coalescing connections based on what the certificate is authoritative for and the DNS resolution results?



Thanks,

Frederik

This PR might be the best explanation https://github.com/quicwg/base-drafts/issues/940

Another side effect of not having an HTTP/QUIC native URI.


Thanks for the pointer. I think it's unclear to me why a browser wouldn't optimistically try to establish QUIC connections for domains that resolve to the same IP and are also present on the cert? How does that relate to not having a native URI?

Regards,
Frederik