Definition of path in quic-multipath

[Zäschke Tilmann <[e-mail]>]

Dear all,
I have some questions related to my previous question (https://github.com/quicwg/multipath/issues/285)

>From the draft, 1. Introduction:
"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." ?

Question #1: Is that statement still fully correct, considering that paths are now also
defined by PathIDs? Isn't the path determined by the PathID?

Question #2:
As far as I understand, paths are not identified by a 4-tuple anymore but by PathID (and, on the packet
level, implicitly by CID). It seems the 4-tuple has become a mere property of a path but not a property
required to distinguish paths.
Are 4-tuples even necessary to determine a path?

Question #3:
What would be the impact if we allowed multiple paths using the same 4-tuple?
- Wouldn't it decrease complexity if 4-tuple were downgraded to a property of paths and PathIDs
  would be the sole defining feature?
- What would be the impact on existing implementations?

Question #4:
Are there any complications arising from allowing multiple paths per 4-tuple?
I considered that it may affect congestion control because the routes may overlap. However, that would
only be true if the paths (routes) were identical. The idea of having multiple paths per 4-tuple
would be that they are *not* identical.

Aside:
As was pointed out in the interim meeting yesterday (if I understood her correctly):
with server side connections, server and client may try to occupy the same 4-tuple at the same time.
I am aware that serverside connections may be moved to a separate extensions, but the point is still
interesting and may be resolved by allowing multiple paths per 4-tuple.

TL;DR It seems to me that removing the 4-tuple uniqueness would clarify/simplify the draft and
at the same time open some interesting possibilities. However, I am lacking insight whether it has some implications that
would cause another many-months-major-change PR.

What do people think about this? Would that be a major change (to be moved to an extension)
or possibly a (smallish) simplification that increases flexibility?

Kind regards,
Tilmann Zäschke