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.

[kazuho]

IIUC, the persuading argument that we heard from @MikeBishop at IETF 120 was that we could support both ways.

But assuming that that is the consensus, I would point out that we have to specify that the number space is per-path.

The point is that senders using per-path number space, would send PATH_STANDBY / PATH_AVAILABLE frames carrying the same sequence number. Such behavior would be a protocol violation if we state that the number space is per-connection, because different information would be carried using the same sequence number.

[mirjak]

Decision at IETF-120 was to not change the sequence number space (and keep the per-path space). However, we could provide guidance that it would still be possible to implement a connection-global sequence number, as you can skip numbers (in the per oath space) as long as they are monotonically increasing.

[mirjak]

Ups... the assumption during the discussion at IETF-120 was the current sequence number space is per path. However, it is not... sorry for mixing this up. But then it sounded during the discussion actually like we wanted to have per-path spaces and merge PR #396 ...?