retransmit path_abandon on another path #473
Conversation
Thanks Co-authored-by: Quentin De Coninck <[email protected]>
There was a problem hiding this comment.
My feeling is that It may not be necessary to include this level of detail here. multipath QUIC, as a reliable protocol, will inherently address frame loss, and the decision on how best to handle it—including on which path to retransmit—should be guided by the path scheduler. But I do like the fact that the loss of path_abandon could hurt performance and is called out here.
|
I agree with @yfmascgy. This is a general issue, not specific to path abandon. We don't need more text. |
|
For sure this text is not necessarily needed but I think having a PTO for the path_abandon frame is an important case and therefore pointing this out could people help to get at least this case right. But I have no strong opinion. I think the question is would it potentially help implementors? |
|
I agree with the majority here and still stick with my original opinion that this text is not really needed (or at least not there). We may add something in the implementation considerations regarding the scheduling and the potential performance issues we may have -- though again, I would not fight to have such text in the draft. |
|
I do not think that additional text would help implementers. We have to assume that people implementing a complex real-time transport protocol have sufficient skills and exercise judgment. Piling up extra text leads to generally increasing the size of the document -- maybe one paragraph at a time, but it does add up. And then we have the next issue: making the document so large that implementers shudder at the idea of reading it all. Also, let me reiterate that we have very little operational experience. We can make recommendations, but they are based on that limited experience. When there are lots of possible valid strategies, it might be better to say nothing. |
fixes #470