search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
49 stars 17 forks source link

Sending NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames when multipath has been negotiated #320

Closed michael-eriksson closed 2 weeks ago

michael-eriksson commented 4 months ago

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.

mirjak commented 4 months ago

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.

kazuho commented 3 months ago

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.

huitema commented 3 months ago

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?

michael-eriksson commented 3 months ago

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.

mirjak commented 2 months ago

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 commented 2 weeks ago

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.