End-to-Path Close Signal

[martinduke]

As discussed in Paris, there will be a secret signal between endpoints in "Public Reset" situations. The CONNECTION_CLOSE (or silent close) will also be invisible to the path.

This is desirable because it allows endpoints to operate in a maximum-privacy mode. However, a non-spoofable but widely readable end to path connection-is-over (or I'm-done-with-the path) signal or series of signals would, I submit, allow many internet systems to work better. The QUIC standard should specify a means of doing this, which would be optional (SHOULD, not MAY, IMO).

I think the PLUS working group is working on solutions that are relevant to this problem.

[martinduke]

This is a descendant of Issue #353.

[britram]

...well, there's not a PLUS working group, but a lot of thought about how to design mechanisms for this went into the preparation for the PLUS BoF...

[martinthomson]

Just to make this distinction, which I think is important:

The signal that the path needs is a signal that the endpoints no longer intend to use the path. Connection termination (in any form) is only one reason that the path might stop being used, but with migration termination is not comprehensive.

You might reasonably argue that migration is often learned of after the fact (especially with user-mode implementations). That would suggest that covering the various termination events with an explicit signal is all that is possible and that is therefore adequate. That said, I'm not sure that this is universally true when it comes to endpoints with multi-interface-aware implementations and make-before-break interface management.

[mnot]

This is parked until we resolve the spin bit discussion.

[martinthomson]

Tokyo conclusion: closing.

As a connection close, this is an explicit non-goal. As a "not using this path" signal, this is extremely difficult.