Re: Connection coalescing in HTTP/QUIC

Mikkel Fahnøe Jørgensen <> Fri, 02 November 2018 07:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DF9312D4F1 for <>; Fri, 2 Nov 2018 00:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id js-IEZX5VZdZ for <>; Fri, 2 Nov 2018 00:41:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC7DF12D4F2 for <>; Fri, 2 Nov 2018 00:41:37 -0700 (PDT)
Received: by with SMTP id a132so1713756qkg.1 for <>; Fri, 02 Nov 2018 00:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=2otI8XI30hKCNmIQ8E6J+Kv1dU4CwlNNpWtYLF01XVg=; b=YIs05CZdJfqU7Udz7ma1nS+gwIpdbcNIiP2MEUuTUc15DCi39cxfkrRxTUl0ImIyON Zc5whBgLWjCfndFzvzsDAhqofY109mvS01GHzhUBTbpTmqQ6lGDP4IrjXFaePdo269N7 H5R8t+uvcqjC+OItKpqiWsdwO+QbeHo9VyLBelQKbT+nZqfc1SS9X43Fou2CngCevgJg w2zj0pl0J9Sq49Yh1DflIug+NZGMV/ViwHQZ1yJkjXeNyEpdY+I3+OBjCuAWqeIpxBjV NMJUf/LFQp2N+FCjG/lce8CYMKE362DuS2DdrMt6fCu9/uegi3MmS3KFFp9uceIDedQU nYtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=2otI8XI30hKCNmIQ8E6J+Kv1dU4CwlNNpWtYLF01XVg=; b=R0qzMx7olR5O3lfjZN8+po0ug5fd47MO84f1xPNZ4oYuO3hCn/zuoO/PQPz000KYyI ztjJupgovPLmDjkWMXznwJ7a+sLaUIaFyQKLX+maAs2eqPhsL0L5TkfdQa+6k+vEQP6M hZFAnk5OtmapkAmCo/oZ4Rgu4pNl4RYdZeQYYMKxBJVp6PXixAWXhxrUPS0LrCGP2hyN EuyXtVqceSgcuAt/Ibw5uBPjhKRVUvgSr/sQ2XF/msGJ7aQR+xqxeDi240yWsZ2Hs70z rOMv8FpXyFXThGXoRhedvLr28jAKgj1qaB++neZaVL1SC4SsOIQkMrDpO5hD8ATlITqs ek/A==
X-Gm-Message-State: AGRZ1gILVi8VgpXb91KlFi4DvG+uGq/XPdpZxRY+H7yFW3W+aM4EvOWx 2VqpVn4xpjxVFKNcVXKq4WZm4nSH
X-Google-Smtp-Source: AJdET5eYp2gRpIb+zMPRNgNxGHJkcBipQbxPtTxE72mJKn5/J1hj5VIlZKGPmJESacTBX6JooaWGlQ==
X-Received: by 2002:ac8:474e:: with SMTP id k14mr9928846qtp.117.1541144496798; Fri, 02 Nov 2018 00:41:36 -0700 (PDT)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([]) by with ESMTPSA id c21-v6sm16779364qtn.82.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Nov 2018 00:41:35 -0700 (PDT)
From: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= <>
To: Mike Bishop <>, Frederik Deweerdt <>, "" <>
CC: "" <>
Subject: Re: Connection coalescing in HTTP/QUIC
Thread-Topic: Connection coalescing in HTTP/QUIC
Thread-Index: AUFFVWlIyZHysacfpgAPsUTXLm73qVExTUZEUV9vc1EwQzkxMJ/DtHC9
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 2 Nov 2018 07:41:32 +0000
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DB6PR10MB17663B1FFE5F82FE3DE462B9ACCF0DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: <>
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 Nov 2018 07:41:40 -0000

There is also the option to support a DNS record indicating QUIC support.

From: QUIC <>; on behalf of Mike Bishop <>;
Sent: Friday, November 2, 2018 6:14:33 AM
To: Frederik Deweerdt;
Subject: RE: Connection coalescing in HTTP/QUIC

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 <>; On Behalf Of Frederik Deweerdt
Sent: Thursday, November 1, 2018 10:56 AM
Subject: Re: Connection coalescing in HTTP/QUIC

Hi Lucas,

On Wed, Oct 31, 2018 at 4:03 PM Lucas Pardue <<>> wrote:
On Wed, 31 Oct 2018, 22:48 Frederik Deweerdt, <<>> wrote:


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?



This PR might be the best explanation

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?