Re: [quicwg/base-drafts] Invert connection ID (#493)

[Martin Thomson <[e-mail]>]

@mirjak, I don't think that we require the connection ID as a confirmation signal.  In fact, none of the existing designs (this proposal, or what is in the draft) actually provide that in all cases.  I agree that it is double double duty regarding load balancers and migration, but that could be more generically referred to as "ensuring the packet ends up where it should".

@mikkelfj, I think that you are right with your fourth use case; it's the generalization above.  However, the notion of identification is subtly dangerous.  The goal is not so much to identify a connection, but ensure that packets arrive at the right place.  Identification implies some sort of permanence.

The model that I think we have here isn't perfectly symmetrical.  For the client, the 5-tuple is what ensures that packets arrive at the right place.  The server uses the connection ID, which allows the client to migrate.  In theory, the server can migrate, but not during the handshake, and not at the same time as the client, but this probably won't work in practice if you concede that certain types of middlebox are commonplace on the client ends of connections.  You can see this in practice with most Google clients allowing the server to omit the connection ID.

-- 
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/493#issuecomment-299050741