Skip to content

QUIC milestones and interop testing

Jump to bottom
Christian Huitema edited this page Jun 20, 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.

Further milestones

The next interop test is set for July 2018, during the IETF hackhaton, based on draft 13. There is a huge change planned: incorporate the design changes proposed by the "stream 0" design team. The new design changes how TLS data are exchanged. Instead of special-casing stream 0, the data will be sent in dedicated frames. The design also changes how encryption keys are scheduled, obtaining the keys directly from TLS instead of using exporters. This guarantees key changes synchronized with the TLS state changes, and also eliminates double encryption during the handshake.

We want to check connection migration, which involves testing connectivity with the new address presented by the client. Multipath will come later.

The interop plan is also punting on application mapping. The data transfers are using 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.

Clone this wiki locally