PATH_STANDBY PATH_AVAILABLE Sequence number spaces

[gloinul]

Section 8.3: A variable-length integer specifying the sequence number assigned for this PATH_STANDBY frame. The sequence number space is shared with the PATH_AVAILABLE frame and the sequence number MUST be monotonically increasing generated by the sender of the PATH_STANDBY frame in the same connection. The receiver of the PATH_STANDBY frame needs to use and compare the sequence numbers separately for each Destination Connection ID Sequence Number.

So are sequnce number spaces per CID? But shared across the PATH_STANDBY and PATH_AVAILABLE

[mirjak]

No one number space but you only compare to the number that you previously received for the same CID.

E.g. you received

SEQ=1 CID=1 SEQ=2 CID=2 SEQ=4 CID=1 SEQ=3 CID=2

That means you have to update both paths and not throw away the frame with SEQ=3

[mirjak]

I think this issue is still true but you use now one sequence number space for all path IDs (instead of CIDs). I guess we could also define a separate sequence number path for each path ID now that the path IDs are stable, however, I don't think that makes a real difference.

However, I guess we should clarify this in the draft?

[mirjak]

I believe in the current version of the draft (-09) the behaviour is clearly specified:

The sequence number space is shared with the PATH_AVAILABLE frame and the sequence number MUST be monotonically increasing generated by the sender of the PATH_STANDBY frame in the same connection. The receiver of the PATH_STANDBY frame needs to use and compare the sequence numbers separately for each Path ID.

However, I created PR #396 that proposed to use per-path sequence numbers instead. Both works. We just need to decide which one we prefer.

[Yanmei-Liu]

The current draft uses a single space of sequence in the whole connection, the hidden profit is that endpoints could know the original action sequence of Path Status Frames although action frames could be in different order after transmission.

Consider a case: Endpoints have 2 Paths{A, B}. At first, path A is standby and path B is available. When it sends Path Available{A} and also Path Standby{B}, but these 2 frames are sent in different packets and are received in reversed order. When the peer receive Path Standby{B} first, it consider all the paths are standby and might cause an error. But with a whole connection sequence, the peer have a chance to notice that these Frames are received in reversed order and might not cause any error.

[huitema]

There is some logic in having a global number, preserving order of actions, etc. But that's not what the counter does. It is just meant to make sure that if I say "path A standby" in packet 1, then "path A available" in packet 2, the result is "A is available", even if packet 1 is delayed and arrives after packet 2.

At a minimum, the counter acts as a virtual clock, and that can be global. But the implementation requires keeping a value per path. With that, both a "global counter" and a "per path counter" could work.

[gloinul]

I will note that -10 still are unclear in regards to the sequence number. I understand that implementation wise one is expected to record the sequence number set the status currently applied, and before changing check that the incoming frames sequence number is higher. But, that is not clear from the text.