search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
48 stars 17 forks source link

There is always a valid CID now for each path #374

Closed mirjak closed 2 weeks ago

mirjak commented 1 month ago

This text is not needed anymore, as this issue does exists as we now manage CIDs per path with MP_NEW/RETIRE_CIDS

qdeconinck commented 1 month ago

I am not sure to understand how you could not have any CID for a path once some packets went over it, unless you abandon the path. An endpoint should not retire the last (sending) CID of a path ID if it does not have alternative.

BTW, it is invalid to have active_connection_id_limit to be 1, as RFC9000 states that it must be at least 2.

Yanmei-Liu commented 1 month ago

I am not sure to understand how you could not have any CID for a path once some packets went over it, unless you abandon the path. An endpoint should not retire the last (sending) CID of a path ID if it does not have alternative.

BTW, it is invalid to have active_connection_id_limit to be 1, as RFC9000 states that it must be at least 2.

Yes, there is a limitation in RFC9000 that active_connection_id_limit MUST be at least 2, but we didn't claim that in the current multi-path draft. As the semantic of active_connection_id_limit has been changed (for per path), the limit is also needed to be declared(at least 'follow the limit of RFC9000').

The scene of migration could happen like this (e.g. set active_connection_id_limit = 2) :

  1. Client A and Server B have a connection negotiated active_connection_id_limit = 2, both endpoints issued 2 available CIDs for each path;
  2. Client A create a new path with Server B, Server B choose to use DCID(path_id = P1, CID_seq = C1) for peer address(IP1, Port 1);
  3. Client A is inside a NAT environment, after some time, the NAT port changed to(IP1, Port 2). While Server B find Client A is still using Path_id = P1, it consider the situation as NAT rebinding trigger the path migration, then it start to use DCID(path_id = P1, CID_seq = C2) for peer address(IP1, Port 2);
  4. When Client find out Server start to use DCID(path_id = P1, CID_seq = C2), it sends MP_NEW_CID(path_id = P1, CID_seq = C3, Retire Prio To = C2) containing the new CID. But this frame never touch the peer and waits to be retransmitted.
  5. When the NAT Port changes again at client side, the server have no unused available CID for the new address, it could still wait for the retransmission of MP_NEW_CID, and hold the path without any error.
mirjak commented 1 month ago

The situation described is not specific for the multipath extension and is the same for RFC9000, so we don't have to say anything specific here. Also not that the requirement from RFC9000 that active_connection_id_limit has be at least 2 still applies without specifying this explicitly if we don't say anything else. Re-specifying something that is already specified somewhere else is best avoided because that makes it harder to change things later.