Closed nandsky closed 9 months ago
The current draft already gives you the mechanism to do so. A server can use path_status frame to set the path to standby and also use path_abandon to close the path when necessary.
Can we close this is issue as PATH_STATUS (or new PATH_STANDBY) can be used or do we need to add some editorial explanation?
Can we close this is issue as PATH_STATUS (or new PATH_STANDBY) can be used or do we need to add some editorial explanation?
As you mentioned in https://github.com/quicwg/multipath/issues/218#issuecomment-1614940172,
That means it always the receiver that informs the sender. Note that as we don't have a path identified anymore the PATH_STATUS information in unidirectional and therefore it is possible that one peer says it okay to send on a certain path, while the other end does not what to receive anything on that same path.
So,
please correct me if I am wrong
Yes, it always the receiver that sends the PATH_STANDBY frame to inform the sender that it doesn't want to receive anything on a path. The sender does not need to tell the receiver that it decided to not send anything, it can just do it.
Can we close this issue?
ok, we can close this issue, thanks
As described in 4.3.1. Use PATH_ABANDON Frame to Close a Path
This means that PATH_ABANDON frame like abort_reading for the sender side, just like the RESET_STREAM frame does on the quic stream layer.
And described in 6.2. Path Closure
For a specific 4-tuple, the sending and receiving paths of packets are not alway the same.
In the scenario of HTTP file download, the server can better understand the quality of RTT or loss rate. So do we allow the server to actively stop sending and notify the peer?
Maybe a special frame similar to the STOP_SENDING frame is needed in multi-path quic?