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

Reply via email to