On 12/16/2020 2:44 PM, Martin Duke wrote:
This is not how I read the draft at all. There are two separate paths,
no? client->server and server->client?
4.5.2:
This has no direct effect on reverse paths from this endpoint to the
peer. If the peer wants to direct the endpoint to abandon such
paths, it should send PATH_STATUS(abandon) frames for the relevant
paths.
So IIUC PATH_STATUS refers to the peer's CID/identifier, and
RETIRE_CONNECTION_ID refers to the sender's CID/identifier, so both
are necessary to tear down both ends?
Let's get some experience of what works or not. If we believe that the
client is ultimately in charge of resource management, then a logical
sequence would be:
1) Client asks server to abandon path x.
2) Server does that and sends RETIRE_CONNECTION_ID(x)
3) Client sends RETIRE_CONNECTION(y) -- the value that was used for
"return path".
-- Christian Huitema
