Re: [quicwg/base-drafts] Simplify version negotiation (#2133)

[ekr <[e-mail]>]

On Wed, Dec 12, 2018 at 2:38 PM Mike Bishop <[e-mail]>
wrote:

> This feels like doubling down on the previous idea of
> mutually-intelligible "compatible" versions
>
Yes.  My argument is that this is basically the situation we have had with
every TCP-using protocol forever. Nobody thinks you can send an HTTP
request to a SSH server and have that work, but we do expect SSH clients
and servers to be able to negotiate with each other despite some diversity
of versions.

-- now you're essentially saying that, while QUIC has stated invariants,
> there are walled gardens of version sets within those invariants which are
> all QUIC but are not straightforward to use together.
>
I view the invariants as primarily for the benefit of intermediaries, not
for the endpoints.


> That's trading potential implementation simplification for deployment and
> maintenance complexity, isn't it?
>
> I agree that this is a simplification by reducing an axis of movement. I
> remain unconvinced that we can guarantee all versions of QUIC used for a
> given scenario will be "compatible."
>

I have two answers to this:

1. The invariant you need to retain isn't that all versions are compatible
but that the client never has to guess whether to send an Initial of type A
or B because the server might not understand A but might understand B (or
vice versa). I've been trying to think of a non-hypothetical situation in
which this might arise that can't be easily dealt with by retaining compat
of the Initial. Do you have one?
2. If, despite the above, we run into a situation where we have that, we
can always implement something like the existing VN mechanism at that point.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2133#issuecomment-446773113