[+] Explicit Path ID: Clarify that endpoints use the same Path ID in both directions. #315
Conversation
… in both directions.
Yanmei-Liu
requested review from
qdeconinck,
mirjak,
gloinul,
yfmascgy and
huitema
Yanmei-Liu
changed the title
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Quentin De Coninck <quentin.deconinck@umons.ac.be>
… in both directions.
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Quentin De Coninck <quentin.deconinck@umons.ac.be>
…uicwg/multipath into dev/path_id_for_both_direction
Co-authored-by: Quentin De Coninck <quentin.deconinck@umons.ac.be>
| If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID | ||
| for the specific path, it MAY choose to ignore the PATH_CHALLENGE, or it can | ||
| choose to send the PATH_RESPONSE frame upon reception of a | ||
| MP_NEW_CONNECTION_ID frame containing the corresponding Path ID. |
There was a problem hiding this comment.
I think the client should only try to open a path if it had send CIDs for that path ID (and the reception has been ack'ed). Then if the server received a path challenges for a path ID it doesn't have a CID for, it should either be an error or it should send a path abandon on another path.
There was a problem hiding this comment.
I think the client should only try to open a path if it had send CIDs for that path ID (and the reception has been ack'ed).
We could be in the situation where the server has sent MP_NEW_CONNECTION_ID frames to the client, and the client wants to open a new path by sending a PATH_CHALLENGE along with a MP_NEW_CONNECTION_ID frame with the associated Path ID.
There was a problem hiding this comment.
Yes sending it in the same packet is fine as well because than it cannot be lost or reordered separately.
| If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID | ||
| for the specific path, it MAY choose to ignore the PATH_CHALLENGE, or it can | ||
| choose to send the PATH_RESPONSE frame upon reception of a | ||
| MP_NEW_CONNECTION_ID frame containing the corresponding Path ID. |
There was a problem hiding this comment.
I think the client should only try to open a path if it had send CIDs for that path ID (and the reception has been ack'ed).
We could be in the situation where the server has sent MP_NEW_CONNECTION_ID frames to the client, and the client wants to open a new path by sending a PATH_CHALLENGE along with a MP_NEW_CONNECTION_ID frame with the associated Path ID.
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>
Solving issue #294