Re: Bugs of the interop

Ian Swett <> Fri, 02 March 2018 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC33E120725 for <>; Fri, 2 Mar 2018 06:06:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gKgTwZiBukUS for <>; Fri, 2 Mar 2018 06:06:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F29AB1204DA for <>; Fri, 2 Mar 2018 06:06:37 -0800 (PST)
Received: by with SMTP id v194so1934769itb.0 for <>; Fri, 02 Mar 2018 06:06:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0FtTxJ3+oAjq+nM5cq/Gl5NKONqpfJLmsaGwvmV67Vs=; b=SXndoqTrHBXwnxSvWqYZTlRH9eNt7KLLg0il452lrY5mskMmCy63FEQlij2hI5sNMj jzSOmDLkboAvTBuX2mj5IrjjpMhWFfpmsf/cP4aFf0et+qnwnWuUra5rJgkXN6oztRZi TBliMfk32gLvMrQCEy6DCVGHab20OEx3DHukrEmVgQmZIEt3Fet61wGU2pSwpVAc14C6 deTuG9VhSbY2jVXgz7KjgiL0fGGVDKKsVuu5y6pEJxvaSmnhuOP31Ute8e2FYILDpcDm kkfBka+l0VNx9OhYOaI8fyXfRuCguaY9i7wNzxqS/NyVB8Z6+g00S+3fsLtzrZY5zsPS +hRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0FtTxJ3+oAjq+nM5cq/Gl5NKONqpfJLmsaGwvmV67Vs=; b=fHsza6IXXJUNR+h4j9Bd/S+Iffxu2dA69a7dG0/N7vf1geEhY6tHdqtdQrIYlqvk6R U6hHX6/lT6Iqdu77hMrBcck6cT1MQq6x3s6Xh9JPZ+5P3J1W/ZEu28fvgkD8rJwig0Jx pTg3hEHSG7MbnGjVtEN+E9ZLRfCgsHXMfzj7fhW6fKljD/FbT+A8xXLJORFXnwAeKvC1 Sh5rGf+6FEgpa79W42eIAPP9dOvBFswFD7H2adCVb5FC7IuWQpoh61pbyThENgTf4bxx 8wxbGlKadoYXZ/rIDMPha6uz9nuJa1F/7+a6XYovqTIZ51I3T5eGcQtjptzqFmxPOl9O C7Pg==
X-Gm-Message-State: AElRT7E7QZGUGKqOaEFPb3WJaSVouYRFikhfhG0Q8PQfEg7rYBKq8a3F 9F13K/ttlV0oV11PCqOi61FMqhzxEylFc6rbOB7VBt4D
X-Google-Smtp-Source: AG47ELuaau2SEvZp2Z+jVIx89vO7E5NKWVg0J18D5dFeWCnBdKZ9LMiA+3vhfCSb312nELPUiHlQVXaKySUXMeOA7a0=
X-Received: by with SMTP id r14mr2552418ita.146.1519999596746; Fri, 02 Mar 2018 06:06:36 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ian Swett <>
Date: Fri, 02 Mar 2018 14:06:25 +0000
Message-ID: <>
Subject: Re: Bugs of the interop
To: Christian Huitema <>
Content-Type: multipart/alternative; boundary="001a113a998606dc5805666e7c18"
Archived-At: <>
X-Mailman-Version: 2.1.22
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 Mar 2018 14:06:40 -0000

On Thu, Mar 1, 2018 at 11:17 PM Christian Huitema <>

> Technically, the March 1 interop will be continuing for a few hours, but
> I would like to list here the bugs that were found in a variety of
> implementations.
> 1) Whose bright idea was it to write that Padding should be
> acknowledged? Some developers think that this is silly. If you want an
> acknowledgement, send a Ping. Or, if we really need to ack the Pad, then
> kill the Ping.

I'll claim most of that bright idea.  The idea being that packets should
either cause acks or not count towards bytes in flight.  Currently the
draft indicates padding only packets contribute to bytes in flight, because
they're not ACK only.  Issues #837
<> and #838
<> discuss this and related
issues.  We could make PADDING or ACK only packets not count towards bytes
in flight or instigate acks, but that isn't perfect either.  As others have
mentioned, the current text may motivate clever people to send useless ack
frames as padding, which is certainly not the intent.  Suggestions welcome.

> 2) Stateless Reset changes the initial CNX-ID? If you look at the list
> of stuff changed "since draft-ietf-quic-transport-08", that's a
> surprise. Not hard to fix, but as one developer puts it, "I just run
> diff2 at this point". Otherwise, you have to trust the editors to
> actually write changes in the what changed section...
> 3) Really, I cannot send ACKs of 0RTT packets in the handshake packets?
> Oh, and no 1RTT either? It seems very natural if you have received CI
> and 0Rtt to send a single ACK. And if the server sends 1Rtt packet just
> after the TLS first flight, it seems natural to send an ACK for both
> with the Finished message.
> 4) Define immediately, as in "I can resume a connection immediately
> after closing the previous one". What about, "my server side of the
> previous connection is not closed yet"... and I can only have one
> connection in progress for a given client IP and Port.
> 5) And there is some joy in the interaction with various TLS stacks
> regarding Stateless Reset, and its interaction with Session Resume.
> Probably because TLS 1.3 is new.
> Given all that, the matrix at
> looks quite good!
> Thanks for the summary!

> -- Christian Huitema