Subject: Bugs of the interop

From: Christian Huitema <[email-masked]>
Date: Thu, 1 Mar 2018 20:16:56 -0800

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/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=207940156
looks quite good!

-- Christian Huitema

---

From: Ian Swett <[email-masked]>
Date: Fri, 02 Mar 2018 14:06:25 +0000

> acknowledgement, send a Ping. Or, if we really need to ack the Pad, then

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
<https://github.com/quicwg/base-drafts/issues/837> and #838
<https://github.com/quicwg/base-drafts/issues/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.

> Thanks for the summary!

---

From: Patrick McManus <[email-masked]>
Date: Fri, 2 Mar 2018 10:53:53 -0500

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