multipath icon indicating copy to clipboard operation
multipath copied to clipboard

Sending NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames when multipath has been negotiated

Open michael-eriksson opened this issue 1 year ago • 5 comments

It should be explicitly specified if it is allowed/discouraged/forbidden to send NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames (implicitly referencing path ID 0) when multipath has been negotiated.

michael-eriksson avatar Mar 18 '24 07:03 michael-eriksson

I think we have to allow it because it could be sent before multipath is "negotiated". Also not that QUIC does really negotiate but rather another, which is another reason why forbidding based RFC frames is generally hard.

We could say this more explicitly but we don't have to because it is a general thing about how QUIC transport parameters work.

mirjak avatar Mar 18 '24 08:03 mirjak

FWIW I think we have the option to state that use of multipath, specifically the maximum number of paths, is remembered. Then, endpoints can send the correct frame in 0-RTT too, depending on if the original connection was MP or not.

At the moment, we state that use of multipath is not remembered, but I don't think anybody had a strong argument one way or anotther; see https://github.com/quicwg/multipath/issues/219.

kazuho avatar Mar 19 '24 06:03 kazuho

We can plausibly say that a legacy NEW_CONNECTION_ID frame is equivalent to MP_NEW_CONNECTION_ID with pathID=0. That means it would be allowed at the beginning of the connection, but disallowed if the pathID 0 was Abandoned.

Which brings a related issue. Is it legit to send an MP_NEW_CONNECTION_ID with pathID=N after path N has been abandoned?

huitema avatar Mar 19 '24 18:03 huitema

Indirectly yes, since packets can be reordered and the receiver can't tell the difference. The receiver should obviously ignore the frame like any other stale frame.

michael-eriksson avatar Mar 21 '24 14:03 michael-eriksson

In summary:

  1. NEW_CONNECTION_ID and RETIRE_CONNECTION_ID are still allowed and associated to path ID 0. The document says this already, at least that path ID 0 is used. It doesn't explicit say that these frames can still be used. I don't think that is needed, or would people prefer to be explicit?

  2. Control frames that have an abandoned path ID MUST be ignored. We don't say that explicitly yet. But do we need to add that?

mirjak avatar May 14 '24 16:05 mirjak

We actually already say that abandon path IDs MUST be ignored in Section 7 (New Frames):

If an endpoint receives a multipath-specific frame with a path identifier that it cannot process anymore (e.g., because the path might have been abandoned), it MUST silently ignore the frame.[¶](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#section-7-4)

Closing it now.

mirjak avatar Jul 01 '24 10:07 mirjak