[+] Explicit path identifier first shot #292
Conversation
There was a problem hiding this comment.
Thank you @Yanmei-Liu! I added some suggestions.
The biggest open question I have is what happens to the path identifier when peers have reached max_concurrent_paths. In your proposal, it sounds like path identifiers are reused. This might have weird corner cases when packets are delayed.
The other way to implement this is to have path identifiers increment. We need to have a consistent view of how many paths are currently in use between the two peers.
draft-ietf-quic-multipath.md
Outdated
| for its peer. When endpoints address a path in multipath control frames, | ||
| it refers to the Path Identifier field of the destination Connection ID | ||
| used for sending packets on that particular path. Note that the Path Identifier | ||
| for initial path is always 0. |
There was a problem hiding this comment.
This should include a precise definition of what we mean by "path". Crucially, a "path" is not defined by the 5-tuple, since NAT rebindings change the 5-tuple without one of the peers knowing about it.
Instead, a new path is opened when a peer intentionally starts sending packets from a new address.
There was a problem hiding this comment.
I am implementing this right now. The good thing about the "unique path ID" is that the header now carries a clear intention. If the destination CID correspond to path X, then the intention was clearly to send the packet on path X -- even in cases when the CID is not exactly the same that was used for that path previously. This closes the ambiguity of "CID renewal and NAT Rebinding at the same time".
There was a problem hiding this comment.
Record in issue #291
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
That's an important point that we need to make it clear. I think it's better to reuse than increment, as we can add some limitation for the corner cases(e.g. Path Identifier can only be reused after 3 max PTOs after the path is abandoned and all the CIDs belonging to this path is retired). It's more friendly for resource limitation of endpoints. If we use increment, then we need to discuss when to increase the max Path Identifier in the new connection IDs without breaking the limitation for max concurrent paths. |
There was a problem hiding this comment.
I am really happy to see such a proposal as a PR. Here and there comments and suggestions.
I think such a proposal also opens the door for a more explicit and controlled path management. While we could have up to max_active_paths paths, an endpoint could only enable its peer to open them when needed (e.g., by proposing a new Path ID when it thinks it would benefit from a new path). We could also revisit the notion of "path abandon" and make this a strong signal (i.e., retire the Path ID) instead of a recommendation (i.e., please remove associated CIDs and stop using the path).
There was a problem hiding this comment.
Thanks for doing this work. I think three key points need to be fixed:
- the CID should be uniquely identified by their sequence number, not by the combination of path-id and sequence number.
- we do not need MP_RETIRE_CID
- we should never reuse path-ID, because they are part of the cryptographic nonce.
Co-authored-by: Quentin De Coninck <quentin.deconinck@umons.ac.be>
Co-authored-by: Quentin De Coninck <quentin.deconinck@umons.ac.be>
Co-authored-by: mirjak <mirja.kuehlewind@ericsson.com>
Co-authored-by: mirjak <mirja.kuehlewind@ericsson.com>
Co-authored-by: mirjak <mirja.kuehlewind@ericsson.com>
| a zero-length value. | ||
|
|
||
| If any of the endpoints does not advertise the enable_multipath transport | ||
| - initial_max_paths (current version uses 0x0f739bbc1b666d07): the |
There was a problem hiding this comment.
Probably better: initial_max_path_id. This would mirror the meaning of the frame as suggested in https://github.com/quicwg/multipath/pull/292/files#r1527500161.
There was a problem hiding this comment.
I think it should remain initial_max_paths to be symmetric with initial_max_streams_*.
The explanation can be copied from RFC 9000:
Setting this parameter is equivalent to sending a MAX_PATHS of the corresponding type with the same value.
There was a problem hiding this comment.
My 2c: There's only so much value you get from consistency with RFC 9000. This has created a fair amount of confusion in the review of this PR, and it seems like calling it initial_max_path_id (and the corresponding renaming of the frame), would make it 100% clear what is meant, without the need for long explanations.
There was a problem hiding this comment.
Well, then I think that the frame type should be MAX_PATH_ID to further reduce the confusion and increase the multipath specification consistency.
There was a problem hiding this comment.
Record in issue #324
| of the associated Path Identifier. When endpoint received PATH_ABANDON frame, | ||
| it SHOULD not use the associated Path Identifier in future packets, it can | ||
| only use the Path ID in ACK_MP frames for inflight packets or | ||
| in MP_RETIRE_CONNECTION_ID frames for CID retirement. |
There was a problem hiding this comment.
Should PATH_ABANDON automatically retire the connection IDs, without the need to send any frames? It would be nice if we don't have to deal with a malicious / misbehaving peer that abandons a path, but keeps the CIDs active.
There was a problem hiding this comment.
Yes, it should! Or at least the complete closing of a path, with dual PATH_ABANDON frames should.
| Each endpoints pre-allocate a Path Identifier for each new Connection ID. | ||
| The Path Identifier 0 indicates the initial path of the connection. | ||
| Endpoints SHOULD issue at least one unused Connection ID with unused Path Identifier. |
There was a problem hiding this comment.
This seems backwards. Connection IDs are issues for paths, not the other way around.
Also, if I allow you to open 1 million paths, you're probably wise to not issue me 1 million CIDs.
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
[+] Explicit Path ID: solving issue #297
As the design required revision of the entire draft, this PR attempts to be a start point.