Re: Bugs of the interop

Patrick McManus <pmcmanus@mozilla.com> Fri, 02 March 2018 15:53 UTC

Return-Path: <pmcmanus@mozilla.com>
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 7738012D961 for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 07:53:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 417HLQ4y3gxC for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 07:53:56 -0800 (PST)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4709F129502 for <quic@ietf.org>; Fri, 2 Mar 2018 07:53:56 -0800 (PST)
Received: from mail-ot0-f179.google.com (mail-ot0-f179.google.com [74.125.82.179]) by linode64.ducksong.com (Postfix) with ESMTPSA id 004563A0A0 for <quic@ietf.org>; Fri, 2 Mar 2018 10:53:55 -0500 (EST)
Received: by mail-ot0-f179.google.com with SMTP id y11so9141355otg.0 for <quic@ietf.org>; Fri, 02 Mar 2018 07:53:54 -0800 (PST)
X-Gm-Message-State: AElRT7FgjNpsrA50U0JQQXWoerQVSTjqG+GTS7xYO+fvzXoWH3Mcd7ta gttbBvvhbAB4NircqEq1VKVkp9TVwEaVAr3qeoU=
X-Google-Smtp-Source: AG47ELuUuaU6mhMo2NCPPfInOVzgdyBcf86fwWvj6E3dzxcNO3ZUXnVwEaPV+jEg0Bd+u07AQAr103hyUW4h8XNdJe8=
X-Received: by 10.157.14.146 with SMTP id 18mr4071842otj.263.1520006034518; Fri, 02 Mar 2018 07:53:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.66.212 with HTTP; Fri, 2 Mar 2018 07:53:53 -0800 (PST)
In-Reply-To: <0fe67894-1f65-735f-6b47-6ee9db4f2cc6@huitema.net>
References: <0fe67894-1f65-735f-6b47-6ee9db4f2cc6@huitema.net>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Fri, 2 Mar 2018 10:53:53 -0500
X-Gmail-Original-Message-ID: <CAOdDvNqFvgd9==+-tZiMpk4vs0rP37fbz7gbZmhMXtQVKYPoAg@mail.gmail.com>
Message-ID: <CAOdDvNqFvgd9==+-tZiMpk4vs0rP37fbz7gbZmhMXtQVKYPoAg@mail.gmail.com>
Subject: Re: Bugs of the interop
To: Christian Huitema <huitema@huitema.net>
Cc: "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a11409d1abe7bc705666ffb00"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/3lBPAV5WmCyUQ0NmRXR_reZo8H4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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 Mar 2018 15:54:05 -0000

Christian, thanks for sending this!

I have a few conclusions to draw from the experience:

1: these events, both f2f and virtual, generate two valuable outputs. One
is the feedback you summarized and the other is a set of reference
implementations that will help later implementations that want to interop
be of higher quality. These benefits come specifically from interop events
not just implementations. And that's working.

2: this was the first time I saw fairly wide testing of Retry 0-RTT and
Resumption. Especially 0-RTT. That's really great - though I don't know if
anyone was doing address validation with 0-RTT yet. On my own scoreboard
that leaves migration, key updates, and qpack as the biggest bits of
unexplored spec.

Thanks to everyone for keeping up the cadence. Hope to see you in London.

-P


On Thu, Mar 1, 2018 at 11:16 PM, Christian Huitema <huitema@huitema.net>
wrote:

> 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.
>
> 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
> https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE
> 6xyLk0l4JtvTVg/edit#gid=207940156
> looks quite good!
>
> -- Christian Huitema
>
>
>
>
>