Add next Sequence Number to PATH_CIDS_BLOCKED #492
Conversation
|
Note that this would be a wire-breaking change, therefore this PR also updates the transport parameter. |
| } | ||
| ~~~ | ||
| {: #fig-path-cid-blocked-frame-format title="PATH_CIDS_BLOCKED Frame Format"} | ||
|
|
||
| Path Identifier: | ||
| : Identifier of the path for which unused connection IDs are not available. | ||
|
|
||
| Maximum Sequence Number: | ||
| : The largest sequence number issued for a connection ID for this path by the peer. | ||
|
|
There was a problem hiding this comment.
What if the peer has not yet sent any CID?
There was a problem hiding this comment.
Okay, we would make this the next expected CID sequence number. So effectively the largest+1 or 0 if no CID was issued yet?
There was a problem hiding this comment.
Yes. But then, what is supposed to happen if the peer receives a fanciful number?
There was a problem hiding this comment.
Notice that having a sequence number does not by itself solve the repetition problem. Suppose the peer has not sent a CID yet. I observe that the packet has not been acked. Should I repeat the frame? What if this is a spurious repeat. Will I repeat the spurious repeat as long as the number has not increased?
In the end, I think I will have to keep the workaround that I had in the code -- a flag that says "there is an unacked CID blocked frame for this path", cleared when the frame is acked or when new CIDs arrive. But if I have that flag, the number of CID in the frame is just informational. The value is mostly to be nice with the receiver, as in "if the number expected is lower than what you have sent, don't bother." Kinda nice to have.
There was a problem hiding this comment.
Exactly this change is to help the receive to figure what to do.
There was a problem hiding this comment.
OK. I think this is overall a good change, because it aligns the syntax of PATH_CIDS_BLOCKED with that of the very similar STREAM_DATA_BLOCKED. It helps processing at the receivers: they can ignore PATH_CIDS_BLOCKED if they have already sent more CIDs for this path than indicated by the sequence number.
The change does not completely solve the retransmission problem. It helps a bit -- no point repeating if the peer has already sent more CIDs. Endpoints still need to track acknowledgements if they want to avoid spurious retransmissions -- but then, that's true of every frame, so there may not be much need to say that again.
| } | ||
| ~~~ | ||
| {: #fig-path-cid-blocked-frame-format title="PATH_CIDS_BLOCKED Frame Format"} | ||
|
|
||
| Path Identifier: | ||
| : Identifier of the path for which unused connection IDs are not available. | ||
|
|
||
| Maximum Sequence Number: | ||
| : The largest sequence number issued for a connection ID for this path by the peer. | ||
|
|
There was a problem hiding this comment.
OK. I think this is overall a good change, because it aligns the syntax of PATH_CIDS_BLOCKED with that of the very similar STREAM_DATA_BLOCKED. It helps processing at the receivers: they can ignore PATH_CIDS_BLOCKED if they have already sent more CIDs for this path than indicated by the sequence number.
The change does not completely solve the retransmission problem. It helps a bit -- no point repeating if the peer has already sent more CIDs. Endpoints still need to track acknowledgements if they want to avoid spurious retransmissions -- but then, that's true of every frame, so there may not be much need to say that again.
|
@huitema I prosed changes to rename to "Next Sequence Number". Does that work? |
There was a problem hiding this comment.
If the semantic of PATHS_BLOCKED is "I cannot open a new Path ID because of the peer limit" and PATH_CIDS_BLOCKED is "I cannot use a (valid) path with Path ID because there is no usable CID", then I agree with the suggestion to advertise the expected next sequence number -- receiving Next Seq Num 0 would be a clear indication that the host is willing to open a new path with a valid Path ID.
Co-authored-by: Quentin De Coninck <[email protected]>
mirjak
changed the title
No description provided.