Re: Invariants draft

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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 <[e-mail]> on behalf of Christian Huitema <[e-mail]>
Sent: Friday, December 1, 2017 5:46:49 AM
To: [e-mail]
Subject: Re: Invariants draft

On 11/30/2017 8:09 PM, Martin Thomson wrote:

> 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.
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.

> 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.

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