Interop and performance result for quicly

[suddas]

Can you share any interop and performance result for quicly as shown in https://interop.seemann.io/?

At, https://interop.seemann.io/, I see all the automation testcases for quicly are failing. I also don't see any successful old result.

[larseggert]

The quicly docker image is still speaking the older draft-29 QUIC version rather than 0x1 that is required by the interop runner. Hence all the failures.

[rmarx]

As I assume you're not really looking for the raw results but rather the conclusions you can draw from them:

Historically speaking, quicly has done very well in the interop tests with other stacks, being actively maintained by several of the main contributors to the QUIC specification. It is one of the most feature-complete implementations you'll find.

Additionally, it is also a highly performant stack, using for example custom cryptographic optimizations, advanced kernel-level features and manual tuning. Much of that is discussed in this blogpost: https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency.

Finally, inside the H2O webserver it is used to back Fastly's rollout of QUIC and HTTP/3. As such, you can be pretty sure it's (mostly) production ready.

[suddas]

Thanks @rmarx for your response. I like h2o's quicly pretty much from the beginning for some of the reasons as you have mentioned. We are also thinking to use H2O's HTTP implementation in our multiple products because of high performance.

At the same time, some raw result would help me to convince multiple different teams in our organization.

[suddas]

By when quicly is supposed to support RFC version 0x1?

Is there any plan to enable interop testing for quic?

[marten-seemann]

I think they just need to rebuild their Docker image. @janaiyengar?

[suddas]

Is there any plan to enable interop testing for quic again (in https://interop.seemann.io/)?