Are MP_PATH_(AVAILABLE|STANDBY) probing frames?

[MikeBishop]

The draft does not modify RFC 9000's definition that "PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTIONID, and PADDING frames are 'probing frames', and all other frames are 'non-probing frames'." However, it does say that "A PATH(AVAILABLE|STANDBY) frame MAY be bundled with ... a PATH_RESPONSE frame in order to indicate the preferred path usage before or during path initiation."

This suggests that these frames might be treated as probing frames. Either way, the draft should explicitly state that they are or are not.

(Alternatively, the concept of probing packets/frames might be outmoded in a multipath world. This concept seems largely unused in this document except in Section 4.3.5.)

[mirjak]

We discussed this already and decided that we don't need the concept of probing frames. This is why the draft has the following text in section 4.1:

Section 9.1 of [[QUIC-TRANSPORT] introduces the concept of "probing" and "non-probing" frames. 
When the multipath extension is negotiated, the reception of "non-probing" packet on a new path 
needs to be considered as a path initiation attempt that does not impact the path status of any
existing path. Therefore, any frame can be sent on a new path at any time as long as 
the anti-amplification limits (Section 21.1.1.1 of [[QUIC-TRANSPORT]) and
the congestion control limits for this path are respected.

Can we close this issue or is there anything else needed?

[MikeBishop]

If so, I think I would make that an explicit statement that there is no distinction between probing/non-probing frames or packets once this extension is negotiated. However, 4.3.5 does still make distinctions between probing and non-probing packets with regard to idle timeouts, I think?

[mirjak]

Okay, we can double-check that!

[mirjak]

Actually I wonder if it is still correct that "the reception of a "non-probing" packet on a new path needs to be considered as a path initiation attempt" or can we now say that only packets with a path_challenge should be considered as an initiation attempt (and other packets that use a non validated path ID should be ignored)?

[mirjak]

I created PR #389 to remove the concept of proving frames and (re-)move some outdated text on migration.

I opened a new issue on the question what happens if the first packet for a new path ID does not contain a path_challenge. See issue #390 and please reply there (so we can close this issue after merging PR #389).

[mirjak]

389 has not been merged yet because it also contains a normative change saying that a path "MAY" be closed with an PATH_ABANDON frame after an idle time out (instead of SHOULD). This is discussed further in issue #397. I believe this issue is addressed by PR #398 and does not need any further discussion but as I said we will leave it open until #398 is merged.