I'm fine to do some experiments, but I'm quite unclear as to what the draft is specifying right now.
On Wed, Dec 16, 2020 at 3:06 PM Christian Huitema <[email protected]> wrote: > > 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 >
