Terminology clarification of "path"

[tzaeschke]

Section 1 states:

• A path is determined by the 4-tuple of source and destination IP address as well as source and destination port. Therefore, there can be at most one active paths/connection ID per 4-tuple.

As I understand it, this would preclude the possibility of having different or evolving paths (i.e. routes) for a single 4-tuple. For example, paths may additionally be determined by

• Flow labels in IPv6, for example when using ECMP, which allows multiple paths between 4-tuples, see RFC 6437
• Multipath routing approaches such as SCION which also allows multiple paths per 4-tuple, see https://datatracker.ietf.org/doc/draft-dekater-panrg-scion-overview/

Would it make sense to soften this requirement by allowing multiple paths (i.e. routes) for identical 4-tuples? Or, if "path" is synonymous with "4-tuple", could it make sense to add a clarification of terminology to that effect? I.e. clarifying that "there can be at most one active paths/connection ID per 4-tuple" is not saying anything about the actual (and possibly diverging or evolving) paths that packets on this "path" actually take?

Such a change should not affect the packet format or any part of the protocol. It would be merely a clarification on the meaning of "path".

(Disclaimer: I work on the SCION protocol).

[huitema]

I am not sure that we should address the complexities of using IPv6 flow labels or maybe diffserv marks to establish multiple paths. Yes, in theory we could use such marks to qualify a path, but we would also need to worry about handling of these fields in multiple networks, detecting behavior such as "blanching" or resetting the IPv6 flow ID, or simply not using the flow ID for routing at all. We would also have to worry about potential misuse, such as splitting a 4 tuple into a large number of paths and then running independent congestion control for each path, which could have a dramatic effect on other users of the 4-tuple.

All this sounds a lot like active research. One plausible solution would be for the SCION project to define a QUIC extension to handle path as 6 tuples of addresses, ports and IPv6 flow-id. Parties could negotiate that extension using a dedicated transport parameter. The extension definition would provide solutions for the problems mentioned above...

[LPardue]

speaking as an individual

The definition of path is the same as when we adopted the draft to the WG. So asking for a change in definition is effectively a request to expand the scope of the document. That risks delaying the standardization of multipath for the deployments that are happy with the current scope.

I agree with Christian that extensions can expand the scope on their own terms, and spend their own time and effort to figure out what works and what doesn't.

[tzaeschke]

Dear @huitema & @LPardue, thank you for your feedback. This RFC is obviously more progressed than I had realized. It seems we'll have to find another way, maybe by way of an extension (as you suggested).