Do we allow the server to actively stop sending?

[nandsky]

As described in 4.3.1. Use PATH_ABANDON Frame to Close a Path

Both endpoints, namely the client and the server, can initiate path closure, by sending a PATH_ABANDON frame (see Section 8.2) which requests the peer to stop sending packets with the corresponding Destination Connection ID.

Usually, it is expected that the PATH_ABANDON frame is used by the client to indicate to the server that path conditions have changed such that the path is or will be not usable anymore, e.g. in case of a mobility event. The PATH_ABANDON frame therefore recommends to the receiver that no packets should be sent on that path anymore.

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

In this example, the client detects the network environment change (client's 4G/Wi-Fi is turned off, Wi-Fi signal is fading to a threshold, or the quality of RTT or loss rate is becoming worse) and wants to close the initial path.

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?

[yfmascgy]

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.

[mirjak]

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?

[nandsky]

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,

1. If the receiver does not want to receive packets on a path, he can use PATH_STANDBY to notify the sender to stop sending on that path identified by the Destination Connection ID Sequence Number. The Destination Connection ID Sequence Number is generated by the receiver and passed to the sender via NEW_CONNECTION_ID or initial packet.
2. The draft does not specify whether the sender can send PATH_STANDBY frame. The sender decides which path to send packets on according to the scheduling algorithm, and even if the sender wants to abandon a certain outbound path, it does not need to notify the receiver.
3. Assuming the sender actually sent the PATH_STANDBY frame to the receiver, does this mean that the sender does not want to receive packets identified by the Destination Connection ID Sequence Number of PATH_STANDBY from receiver?

please correct me if I am wrong

[mirjak]

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?

[nandsky]

ok, we can close this issue, thanks