Skip to main content
  • IETF 126 Highlights

    The IETF 126 meeting was held 18–24 July 2026 at the Hilton Vienna Park in Vienna, Austria, and online, hosted by Cisco. The week included the IETF Hackathon and Code Sprint, the New Participants' Program, five Birds-of-a-Feather (BoF) sessions, and more than 100 working group and research group sessions. The Applied Network Research Workshop also took place during the IETF 126 meeting week.

    1 Sep 2026
  • IETF email infrastructure transition planned for 11 September

    A transition to a new modern, modular, and containerized infrastructure for email services provided for ietf.org, iab.org, irtf.org, rfc-editor.org (including email lists) is scheduled for 11 September 2026 starting at 2200UTC, with message delivery delayed up to 60 minutes. Further updates will be provided closer to the transition.

    28 Aug 2026
  • Post-Quantum Authentication: Up Next

    Post-quantum key establishment has moved from standards into deployment. Post-quantum authentication has not moved nearly as far, and specification work is no longer the only constraint. The IAB is holding a workshop in Prague on 11 and 12 October 2026 to bring deployment experience together with the people working on the relevant protocols and standards.

    27 Aug 2026
  • IETF 126 post-meeting survey: what we heard

    The IETF 126 Vienna meeting was held 18-24 July 2026 and the results of the post-meeting survey are now available.

    27 Aug 2026
  • Meet our new IETF NOC Lead

    Joe Clarke has been appointed as the new IETF NOC Lead and in this post Joe introduces himself and sets out his priorities for the IETF Network.

    10 Aug 2026

Filter by topic and date

Filter by topic and date

Automating interoperability testing to improve open standards for the Internet

8 Sep 2020

While interoperability testing has been one of the hallmarks of open standards and Internet protocol development for more than three decades, the process itself has been limited by manual and inconsistent testing.

Automated QUIC Interoperability testing

To address these shortcomings, we created QuicInteropRunner (QIR), a framework that enables implementers to maintain and update their own endpoints, making it easier for them to set up and run interoperability tests using carefully constructed and repeatable network scenarios. We have also set up continuous testing with QIR and a page where the results are available.

As implementations of the emerging QUIC protocol being developed in the Internet Engineering Task Force (IETF) began to mature, interoperability testing became increasingly important to ensure that independently-developed implementations worked as expected. However, the existing approach to testing was limited in a number of ways, including:

  • the number of implementations that could be tested, since there are a quadratic number of combinations to test;
  • the number of features that could be tested—a problem exacerbated by the complexity of protocols built for the modern Internet; and 
  • the range of network conditions under which the protocol could be repeatedly tested (which meant that the wide variety of network conditions under which the protocol would be expected to perform well on the global Internet could not be replicated). 
QUIC badge

As a result, identifying issues with the protocol and implementations took longer than it should have, and the existing tests could miss scenarios likely to be found once they were widely in use.

The QuicInteropRunner (QIR) is our attempt at overcoming these limitations. Using simple container orchestration and network simulation, QIR makes it possible to meet the constraints of implementers while automating this process for on-demand, continuous, and repeatable interoperability and performance testing. A more complete explanation how QIR uses Docker containers and the ns-3 network simulator is available in our paper, which was recently presented at the EPIQ ‘20 conference.

Currently, 13 QUIC implementations (two of which only implement a QUIC server and one which only implements a QUIC client) are included in QIR. Importantly, any implementer can include their implementation in QIR by building a compatible container image, making it publicly available, and adding it to the list of implementations.

To enable continuous interoperability testing, we have set up a QIR instance that continuously pulls the implementation images and runs all the tests in the framework. The results of this continuous testing are posted on this webpage.

As a network of networks, the global Internet we know today works because independently deployed and managed components work well together through open protocols. Internet interoperability testing traces its history back to at least 1986 and remains a key part of new protocol development and deployment. While QIR was developed for testing QUIC implementations, we believe the central ideas, components, and even code can be repurposed for testing other protocols that will help the Internet evolve and work better.


Share this page