gloinul
commented
6 months ago Another example where the spec is a bit confused on if a path is unidirectional or not.
Section 4.4:
"The endhost can use all the paths in the "Active" state, provided that the congestion control and flow control currently allow sending of new data on a path. Note that if a path became idle due to a timeout, endpoints SHOULD send PATH_ABANDON frame before closing the path."
mirjak
During the reading I found places where me as reader got confused about which direction a message was sent. An example of this is the below.
Section 4.3.1 and 4.3.3: Doesn't the use of Retire_connection_id is potentially in the reverse to how RFC9000 use it. Especially as the one receiving one a path can retire the connection ID, as well as the sender can indicate that it will not use it. However, to my understanding of how the frames are defined this can only be used in a particular direction. If A sends to B using DCID=X, which has sequence number Y. Then PATH_ABANDON with sequence Y can only be sent by B to A. And RETIRE_CONNECTION_ID can only be sent by A with seq=Y referencing DCID=X.
To my understanding of the text, this procedure is happening per direction independent and each path is going a unidirectional. However, one normally initiate the reverse direction path also. So I think it would be good if these section were a bit clearer with the various endpoints role in regards to who issued the CID etc so that it is less unclear in which direction this can be used. Because at first I thought you have reversed the usage of RETIRE_CONNECTION_ID. But that does not appear possible.
So I think the problem is that the document is not clear on when paths are used bi-directional, and when the path state in each direction can be different. Which also applies to closing it down aspects.