Re: Definition of path in quic-multipath

[Mirja Kuehlewind <[e-mail]>]

Hi Tilmann,

you are right that this was a necessary requirement before we had the explicit path ID and we can reconsider this now. I opened an issue for this: https://github.com/quicwg/multipath/issues/378
If possible, please add your comments there.

Also, as you say below and as indicated yesterday, we probably need to decide this before we can decide on server-initiated path because it impacts the question if we need to deconflict the case where both ends open the same path with different path IDs or not. However, I think it would be good to keep both questions mostly separate for now and I encourage people to comment on this new issue first!

Mirja



From: Zäschke Tilmann <[e-mail]>
Date: Wednesday, 5. June 2024 at 10:03
To: "[e-mail]" <[e-mail]>
Subject: Definition of path in quic-multipath

You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
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