IETF Logo Mail Archive

Re: Quic: the Elephant in the Room

Paul Vixie <paul@redbarn.org> Mon, 19 April 2021 21:13 UTC

Return-Path: <vixie@redbarn.org>
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 39AAB3A2763 for <quic@ietfa.amsl.com>; Mon, 19 Apr 2021 14:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 b8bZFNCrsMAg for <quic@ietfa.amsl.com>; Mon, 19 Apr 2021 14:13:48 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA703A2760 for <quic@ietf.org>; Mon, 19 Apr 2021 14:13:48 -0700 (PDT)
Received: by family.redbarn.org (Postfix, from userid 716) id BFC357599B; Mon, 19 Apr 2021 21:13:44 +0000 (UTC)
Date: Mon, 19 Apr 2021 21:13:44 +0000
From: Paul Vixie <paul@redbarn.org>
To: Matt Joras <matt.joras@gmail.com>
Cc: Michael Thomas <mike@mtcc.com>, IETF QUIC WG <quic@ietf.org>
Subject: Re: Quic: the Elephant in the Room
Message-ID: <20210419211344.oniiygocqojrryt2@family.redbarn.org>
References: <311e3e67-2e87-1650-22b3-614378fbf88f@mtcc.com> <CADdTf+jRMfNo1EiFBj-fOeZJkKM2TCvN9yJFEmJEVcZj5JMD_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADdTf+jRMfNo1EiFBj-fOeZJkKM2TCvN9yJFEmJEVcZj5JMD_Q@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/94pcR8W-piC0k1uRsxYIeM0pFSM>
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: Mon, 19 Apr 2021 21:13:52 -0000

hello. can you explain how you get from:

On Mon, Apr 19, 2021 at 01:45:48PM -0700, Matt Joras wrote:
> ... The
> vast majority of QUIC connections in our deployment (and TCP + TLS for
> that matter) are resumed.

to:

> ... Resumption makes
> this particular concern a non-issue for most real world connections
> and has other positive benefits.

that is, how is your deployment known to represent most real world use?

i love resumption -- that's why RFC 6013 had it. but i also love DANE, which
is having strong success in the SMTPS market but has been eschewed by the
HTTPS market. thus my question as to how the QUIC team is prioritizing use
cases. "big tech" is shiny but not nec'ily representative of the whole web.

-- 
Paul Vixie

v2.23.0 | Report a Bug | By Email