Subject: How will we test version-negotiation?

From: Christian Huitema <[email-masked]>
Date: Fri, 24 Apr 2020 09:58:22 -0700

I am reading draft-ietf-quic-version-negotiation-00 with an eye on
implementing the version negotiation, and I wonder how we are going to
test interoperability of different implementations.

The proposed version negotiation only kicks in if the client sets the
version number that the server also supports. Then, the server checks
whether a "better" version is also available and supported by the
client, and negotiates that. This does not mesh very well with our
current interoperability tests, which require support for the latest
draft. In the current tests, every implementation supports draft 27 and
proposes version 0xFF00001B. There is no version to upgrade to.

Some implementations also support earlier drafts, and could test
upgrades from draft-25 to draft-27, and we could define a test that way.
But many don't, and it seems weird to require support of old versions
just for the sake of testing version upgrade. I don't think that's a
good idea. I think we need a better proposal, and here is one: let's
define a "virtual" version that is only used for testing upgrades.
Better yet, let's define a virtual version that just matches the latest
draft -- say 0xFFFF001B for draft 27. The interop test could work this way:

1) Client sets the version number to the latest draft (0xFF00001B) in
the Initial packet header, and mentions support of 0xFFFF001B in the
Version Negotiation Transport Parameter.

2) Server accepts the Initial packet, parses the transport parameters,
discovers the proposed support for the "better" version.

3) test succeeds if the server negotiates version 0xFFFF001B and the
data exchanges succeed.

What do you think? Should we add this test mechanism to the draft, or
would it be enough to describe that in the interop wiki pages?

-- Christian Huitema

---

From: Marten Seemann <[email-masked]>
Date: Mon, 27 Apr 2020 20:27:19 +0700

This seems like a reasonable proposal. Using a virtual version that is
identical to the current draft version make sense to me.
It would also make it easy to add a test case for this to the interop
runner.