Subject: Invariants draft

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Dec 2017 15:09:38 +1100

I've just submitted a personal draft that describes the invariants
that I think we agreed to in Singapore.

https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants

This is just me for the moment (though Jana and Mike were very helpful
in reviewing an even draftier draft).  It also assumes a few things
about the current drafts that aren't yet true, and may not even become
true.  Don't focus too much on the specific content of what is in or
out, because that sort of detail is easy to fix.

More than content, I'd like to concentrate on the general approach and
scope.  My hope is that we can agree that those are more or less
correct.  And then adopt the draft.  A draft like this should help
address questions people have been asking about what can and cannot
change between QUIC versions.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 30 Nov 2017 20:46:49 -0800

> out, because that sort of detail is easy to fix.
Thanks for writing that, Martin. It provides a very clear description of
the "invariant" approach, and helps me understand the motivation behind
several changes that were proposed recently.

> change between QUIC versions.

As far as the general approach is concerned, your draft leaves me
somewhat uneasy. I understand the concern to beat ossification, and to
ensure that future developers can easily define and use extended
versions of QUIC. But at the same time, I am concerned with the tension
between "focusing on extensibility" and "ensuring interoperability". At
one end of the spectrum, we could define nothing but extensibility
mechanisms, and let application developers define an application
specific transport protocol. At an other end of the spectrum, we could
rigidly specify a protocol, its formats, and its state machine. I do
think that the working group has to strike somewhere in the middle, a
well specified protocol that can be easily extended, but maybe not
infinitely extensible.

Developers have spent a lot of time testing features, and testing
whether these features can be implemented in compatible ways between
implementations. This is valuable, and I wish that we progressively
converge on a "version 1" of QUIC that benefits from these tests. I
think of that as some kind of simulated annealing process. At some
point, part of the crystal is deemed pure enough, and we move the
annealing ring up to check the next part. That may not be the best
analogy, but the high level summary is that interoperability is
important, that is requires some stability, and that the better is the
enemy of the good.

-- Christian Huitema

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 1 Dec 2017 07:25:39 +0100

On Thu, Nov 30, 2017 at 08:46:49PM -0800, Christian Huitema wrote:
> But at the same time, I am concerned with the tension

I think this draft clearly leaves a *lot* of room for extensibility,
and defining invariants helps us (and future generations) decide when
a new protocol needs to be specified because it conflicts with the
definition of what was guaranteed to be invariant. It's normal to
reach an end with a protocol when new concerns need to be addressed
that were out of the initial scope. Here in short, as long as we can
use UDP with a few fixed bits and 64-bit connection IDs, we don't
need to define a new protocol.

I personally find it well balanced.

Regards,
Willy

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 1 Dec 2017 06:26:31 +0000

Thanks for writing up.
Some input:
Appendix A, incorrect assumptions:
- A 5-tuple is unique to a single connection.
- A client uses ephemeral ports.

More generally: I find it unfortunate that UDP is made an invariant, anf possibly even IP.

The routability of packets could also be questioned, e. g. for some embedded device busses.
________________________________
From: QUIC <[email-masked]> on behalf of Christian Huitema <[email-masked]>
Sent: Friday, December 1, 2017 5:46:49 AM
To: [email-masked]
Subject: Re: Invariants draft

-- Christian Huitema