Subject: [QUIC] Starting work (and getting to interop)

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Nov 2016 10:14:29 +1100

Everyone,

We'd very much like to see diversity of implementations throughout the work, so that there's a healthy feedback cycle between the implementations and drafts. 

In discussions so far, we've heard two alternative ways of starting the work:

* "Full stack" -- Starting interop work with core, encryption, congestion control and HTTP

* "Minimal" -- Starting interop work with just the core spec (version negotiation, framing, streams...), leaving encryption and congestion control until later. 

"Full" is a higher bar, but exercises everything we'll be working on. "Minimal" would be only suitable for testing on controlled networks, not for use on uncontrolled networks -- but may be easier for new implementations getting up to speed.

It'd be great to hear people's preferences and thoughts here (including other approaches, or refinements of those above), especially from implementers (since they'll be the ones most directly impacted).

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Joerg Ott <[email-masked]>
Date: Fri, 4 Nov 2016 07:57:04 +0100

Hi,

we may even have three levels: minimal (base spec, handshake, framing),
intermediate (add congestion control and repair), and full (add crypt).

I believe it would be useful for feedback to the spec to not depend
on the full crypto bit simply to be able to get broader and earlier
feedback.  While we are doing our implementation, we make many
notes on the spec (and "discuss" items in there).  So will others
and moving on to minimal interop will help us consolidating those
different inputs to the spec.

At this point, depending on TLS 1.3 would appear to be a bit
like head of line blocking.

In any case, we would need to document the "expectations" for the
different levels.

Cheers,
Jörg

---

From: Lucas Clemente <[email-masked]>
Date: Fri, 4 Nov 2016 10:44:24 +0100

Hi all,

One experience from our implementation (https://github.com/lucas-clemente/quic-go) was that getting to interop asap helped us a lot. We basically worked through the handshake from the beginning, adding features as they were required to continue. That way, we could always do integration testing with the quic_client or Chrome. For example, we only added frames as we encountered them, such that WINDOW_UPDATEs appeared only way after the crypto was fully implemented. Similarly, we started with very basic loss detection (fast retransmisison), and only later added proper RTOs, and still have some work to do there.

Of course, there’s currently a lot of stuff in the protocol not covered by the drafts (e.g. the crypto doc is quite outdated), so just implementing everything from the spec without looking at Chrome’s source would probably have been impossible for us.

We have some notes on the drafts that we made while implementing, but we don’t really feel like mailing lists are an efficient way of discussing these ideas and proposals. We look forward to having the specs on Github :)

Ciao,
Lucas

> On 4 Nov 2016, at 07:57, Joerg Ott <[email-masked]> wrote:
> 
> Hi,
>