Skip to content

QUIC milestones and interop testing

Christian Huitema edited this page Oct 5, 2018 · 4 revisions

The QUIC working group has defined a set of implementation milestones for the successive interoperability tests. These are listed on the QUIC Wiki.

First implementation draft

The first implementation draft (https://github.com/quicwg/base-drafts/wiki/First-Implementation) required setting a connection and then tearing in down. It was the basis for the interop tests performed during the IETF meeting in Prague in July 2017. Picoquic meets these requirements and has demonstrated successful connection setup and teardown with mozquic (https://github.com/mcmanus/mozquic) and with ngtcp2 (https://github.com/ngtcp2/ngtcp2).

Second implementation draft

The next milestone was the second implementation draft (https://github.com/quicwg/base-drafts/wiki/Second-Implementation-Draft). It was used as the basis for interop tests in Seattle in October 2017. Picoquic supports all of these features, including:

  • Handshake
  • Version Negotiation
  • Stream Data (encrypted)
  • Close
  • HTTP/0.9 exchange
  • server stateless retry
  • stateless reset
  • flow control

We demonstrated interop with a number of implementations, and also found a few bugs that have been fixed -- see closed issues for details.

Second and an half implementation draft

The interop test during the Singapore IETF were still based on the second implementation draft. The feature set and the tests remained the same, the emphasis being on actually verifying that all these features work. This entailed documenting the tests that should pass to claim interop on the various functions. The only change is that the interop will be based on draft-07 instead of draft-05.

Just changing the draft number does not look like much, but the draft-07 brought in a number of protocol changes:

  • Change the protection of clear text packets to use AES-GCM instead of FNV-1A, with a version dependent key that prevents "dumb" firewalls from messing with the packet content.

  • Removal of the option to send 1-RTT packets using the long header form.

  • Change the ACK format to remove the timestamps. (They may be reintroduced later as a negotiated option.)

  • Addition of an APPLICATION_CLOSE frame.

  • Change of the format of the Stateless Reset packet.

  • Change of the format of the CONNECTION_CLOSE and STOP_SENDING frames, with the error code now being 16 bits instead of 32 bits.

These are all incompatible changes, and the developers had to implement and test them before the IETF meeting in Singapore. All these changes are now implemented in Picoquic, which supports the version 0xFF00007. We have managed already to demonstrate interoperability with several implementations of draft-07, such as nghttp2 and winquic.

Third implementation draft

The next Interop was held "on line", on December 18, 2017. It was based on draft-00, which brought a number of changes, some of which are very disruptive:

  • Format changes of pretty much all frames, with a new variable length integer format replacing the multiple ad hoc compression schemes inherited from Google QUIC.

  • Redefinition of the "stream ID", to allow both bidirectional and unidirectional streams.

  • Redefinition of the "ping" frame to carry an optional payload that the peer should repeat in a "pong" frame.

  • Allowing connection close frames before the completion of the handshake, to indicate handshake failures.

  • Tightening of the closing logic.

  • Change of format of the QUIC header, with the version field moving in front of the sequence number, and the redefinition of the version negotiation frame.

  • TLS/1.3 draft 22, instead of the draft 18 version used in the previous interop tests.

All of these were already implemented in the test version of Picoquic, which in principle supports draft-08. By December 18, Picoquic supported "session resume" but not "0 RTT". But since this is an online test, it could continue. We tested Picoquic's implementation of 0-RTT on December 22, and demonstrated 0-RTT interop with mozquic, winquic and nghttp2.

If you look at the interop matrix, you will see that many other implementations were not yet ready in December, but many more ineroperated successfully during the next interop test during the QUIC WG meeting in Melbourne in January 2018. The lessons for us:

  • Client and server are doing quite well compared to other implementations

  • We had some interop issues due to lack of support of Chacha20/Poly1035 in the server. This has been partially mitigated by forcing a negotiation with a stateless reset when the client does not send an appropriate key share.

  • We also had an issue that some implementations of HTTP/0.9 clients where using a request format that we did not support. This is fixed.

Fourth Implementation draft

This was tested in February 2018, and then during the IETF meeting in London in March 2018. The main new feature in draft 09 was the support for TLS/1.3 draft 23, hopefully very close to final.

Interop tests were successful.

Fifth implementation draft

This took place on May 16, based on draft-11. The big features are the use of asymmetric connection ID, and also the revised migration handling. Picoquic only implements the basic NAT traversal for now, but that is sufficient for interop.

Sixth implementation draft

The sixth implementation draft was based on draft-12. The big change there was the inclusion of packet number encryption, but there were also a set of smaller changes,such as always starting the packet sequence number at 0. We demonstrated interop between picoquic and several other implementations.

Seventh implementation draft

The seventh implementation draft was based on draft 13, plus a set of PR (https://github.com/quicwg/base-drafts/wiki/7th-Implementation-Draft). It was used as the basis for interop tests in Montreal in July 2018.

The main feature of draft 13 was the migration from the old TLS mapping using stream 0 to the new mapping using three crypto stream, carried by crypto stream frames at four levels of encryption: initial, 0-RTT, handshake and application.

Eight implementation draft

The eight implementation draft was based on draft 14, which was essentially a clarification of draft 14 (https://github.com/quicwg/base-drafts/wiki/8th-Implementation-Draft). It was used as the basis for interop tests in New York in September 2019.

Picoquic supports all teh features of draft 14. We were able to demonstrate interoperability of the "connection migration" feature with two other implementations, Quant and ATS.

Ninth implementation draft

The ninth implementation draft is based on draft 15 (https://github.com/quicwg/base-drafts/wiki/9th-Implementation-Draft). It will be used as the basis for interop tests in Bangkok before the IETF meeting in November 2019.

Draft 15 incorporates a lot of feedback received during development and test of draft 14:

  • The TLS 1.3 mapping uses a TLS 1.3 extension to remove the requirement to send an EOED message over 0-RTT if 0-RTT is negotiated. This removal significantly simplifies the QUIC handshake, but is incompatible with the TLS version used in draft 14 interop.

  • A new RETIRE_CONNECTION_ID frame enables better management of connection identifiers during migration.

  • The ACK and ACK-ECN frames are fused into a single ACK frame with an optional ECN component.

  • The handling of RETRY packets was constrained to prevent deployment of middleboxes uncoordinated with the QUIC servers.

Further milestones

The next Interop test is set for November 2019, during the IETF hackhaton, based on draft 15. At this point, the base transport specification seems fairly stable. Most features have been tested, except for key rollover, which we expect to test in Bangkok. There may still be some fixes in the next months, but they should only be smallish bug fixes based on interop results or security analysis.

The interop plan is still relying on HTTP 0.9, which is a fine test tool but not quite on par with HTTP 2.0. We don't know yet whether we will implement an HTTP2 mapping in Picoquic. We might, but that's a lot of work. If someone is interested doing that and want to collaborate, they are welcome.