Endpoint symmetry

[mikkelfj]

The draft appears to be focusing on a client server model such as an http server, but client and server can be peers, for example in peer to peer file sharing networks.

This becomes visible in
#170
#442
where the client may experience highly likely collisions because the server is not required to generate random identifiers. The client is then forced to rely on dest address, but this ties the protocol to IP/UDP more than necessary.

It can also be seen in the assymetric direction of PUBLIC_RESET. A client cannot, in the current draft, shut down a connection like a server can, after a crash.

[martinthomson]

Note that this latter point is incorrect. I was careful to make public reset symmetric. Now, the utility of that is pretty low for HTTP, and is probably even lower in p2p cases based on my experience with the NAT traversal systems that are needed there (see ICE).

The notion that the client might use a non-unique source address and port for a new connection is really stretching the design too much for me.

[mikkelfj]

I was careful to make public reset symmetric.

Good, I just seem to recall the wording "a server can send... "

If you cannot associate initial state based on connection id, what is the point of doing it later on?

[mikkelfj]

A Public Reset packet is only sent by servers and is used to abruptly terminate communications. Public Reset is provided as an option of last resort for a server that does not have access to the state of a connection.

[martinthomson]

Hmm, we definitely need to sort that out. Arguably the server is the only peer that matters here. If you have a case where a client needs to send a public reset, then you should make a case for that (preferably in a new issue).

[mikkelfj]

I provided a use case for public reset in the above issue.

A use case for connection id based connection binding with non-unique ports is: Using the netmap highperformance network interface, all traffic goes directly to the QUIC connection handler and ports do not really exist other than because UDP is used to punch through firewalls. Many, or at least several, connections may be created to a peer, and maintaining unique port numbers here is just overhead. In addition, for symmetric peer-to-peer, this allows middleboxes on either side to only allow UDP traffic to/from a specified port. But the main point is that being able to just rely on a single connection ID simplifies issues significantly for implementations that are not wedded to traditional socket operation.

[martinthomson]

Right now we are moving on the connection ID issues: #1151

The connection migration issue is defining endpoint-agnostic mechanisms, but limiting applicability (the text needs work in my view, but it's basically right): #1012

Stateless reset is workable after #1151, but we'll need to change the wording somewhat, probably along the lines of what I requested in #1012.

The handshake is inherently asymmetric. I think that we'll have to just live with that.

And I think that is the entire list of asymmetries. Is there something else you think needs attention?

[mikkelfj]

My opinion on reset is all over the place in these issues - #1177 - but that aside:

The symmetri in server p2p with fixed IP/port at both ends, i.e. static tuple. This in part handle ephemeral port exhaustion, notably from reverse proxy to app server, and in part allows for simpler raw socket / netmap implementations, and non-IP/UDP transports in special cases.

This was almost supported at one point, but apparently it was reverted in Melbourne though I'm not sure why, or if this still applies, or if it applies for the duration of the connection or only during handshake. (Assuming updates to Connection ID).

[martinthomson]

The idea here would be, after #1151, to allow stateless reset from clients. A stateless reset wouldn't be usable until the server moved to a connection ID that was provided with NEW_CONNECTION_ID though.

The reason symmetric stateless reset was dropped was that the token couldn't be carried with confidentiality protection.

[MikeBishop]

(And note that the client can, after the in-flight PRs, force a change of CID by changing its own CID. However, a client that doesn't require a CID also can't issue the server a new one, and hence can't issue the server a PR token. This is reasonably similar to the current strawman algorithm's requirement of CIDs as an input to the token creation, but goes a step further in making it part of the protocol.

[janaiyengar]

Closing this issue since we have issues tracking the various individual mechanisms listed, and symmetry is not driving design for QUICv1.