RE: Fwd: Quic: the Elephant in the Room

Vasilenko Eduard <> Wed, 21 April 2021 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0690F3A3486 for <>; Wed, 21 Apr 2021 12:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jgorFW5dUCNv for <>; Wed, 21 Apr 2021 12:55:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 075233A3487 for <>; Wed, 21 Apr 2021 12:55:53 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4FQWHg2Jkzz6892Q for <>; Thu, 22 Apr 2021 03:45:35 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 21 Apr 2021 21:55:49 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 21 Apr 2021 22:55:48 +0300
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Wed, 21 Apr 2021 22:55:48 +0300
From: Vasilenko Eduard <>
To: Michael Thomas <>, "" <>
Subject: RE: Fwd: Quic: the Elephant in the Room
Thread-Topic: Fwd: Quic: the Elephant in the Room
Thread-Index: AQHXNuE3EkeuOp1AaEmwA+MYon03laq/K7AAgAA2udA=
Date: Wed, 21 Apr 2021 19:55:48 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6ec00a302b5a43ae903328b25460ce83huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Apr 2021 19:55:58 -0000

As my colleague said when we have discussed a similar problem: "closed club".
It was in relation to different WG. I do not know anything about QUIC WG.
From: ietf [] On Behalf Of Michael Thomas
Sent: Wednesday, April 21, 2021 10:38 PM
Subject: Re: Fwd: Quic: the Elephant in the Room

On 4/21/21 12:00 PM, Lars Eggert wrote:

for context, and to correct some misrepresentations, here is my reply to Michael from the QUIC list.

I counted the number of messages from the rest of the working group before one of the chairs called it off topic and for me to go way and it was 4 or maybe 5. And "as chair" is not a suggestion, it is a command. It sure seems to me that the number of messages a transport protocol needs to start a session is pretty on topic, or at least of interest.

Getting told to go elsewhere *is* dramatic, if not predictable.



Begin forwarded message:

From: Lars Eggert <<>>
Subject: Re: Quic: the Elephant in the Room
Date: April 21, 2021 at 19:46:57 GMT+3
To: Michael Thomas <<>>
Cc: Eric Rescorla <<>>, Phillip Hallam-Baker <<>>, Matt Joras <<>>, Lucas Pardue <<>>, David Schinazi <<>>, IETF QUIC WG <<>>


On 2021-4-21, at 19:11, Michael Thomas <<>> wrote:

I am a newcomer. I came here against my better judgement as I stated on the IETF list.

I have emails from you in my IETF mail archive at least as far back as 2006. But I assume you mean that you are a newcomer to the QUIC WG.

I immediately had my head chopped off and told to go away by a working group chair in less than 24 hours.

I don't think you're helping your case by using dramatic phrases.

To recap: You brought a proposal that had been discussed elsewhere to the QUIC WG list. You got feedback from a number of different participants on your proposal. The discussion veered away from QUIC to other protocols that this WG is not working on. A chair suggested you continue the discussion on a mailing list better suited to your topic.

If the number of packets exchanged in the initial handshake of a transport protocol is off topic, I am speechless. My better judgement wasn't that it was off topic, it was that this outcome is the ordinary behavior of insular IETF working groups.

A number of participants have commented on this already, for example, pointing out that the number of round trips matter much more than the number of packets, and that in their opinion your suggestion would not lead to further substantial enough gains. You then moved the topic of the discussion to why Google (and I assume other companies) are not signing their zones and offered theories as to why that is, which is not a topic of relevance to this WG. Hence the request to discuss it elsewhere.

I also got told that signing a zone is tantamount to "boiling the ocean".

You're misquoting David. He said:

On 2021-4-20, at 20:20, David Schinazi <<>> wrote:

I'm not saying that a 3-packet handshake would be bad, I'm saying
that it's not worth boiling the ocean to remove 2 packets.

Nowhere in that sentence or the rest of David's email do I see any mention of signing zones.

As IETF chair, do you agree with that? Because if it's true then there are serious issues with DNSSec and we should do something about it. I think it's nonsense, fwiw.

Again, not a topic for *this* mailing list.

Mike, and what exactly are those venues? tia.

I'd start at DNSOP and ask if there is a more appropriate list.