Hi Lars,
While this use case is not about a very large deployment such as Apple's
MPTCP, some of the discussion points in the email thread about the
multipath extension milestone (e.g., mapping flows to paths, exchanging
control information relevant for multipath between endpoint, policies
for scheduling in MPQUIC) resonated with what we are working on.
I thought it might be interesting to present a use case in a different
area (future Internet architecture) that requires similar
functionalities from a multipath transport layer protocol.
In any case, if the working group decides to start standardization
efforts in this direction, I would be happy to discuss useful
functionalities for future Internet architectures at another meeting.
Best,
Cyrill
On 15.10.20 18:36, Lars Eggert wrote:
Hi,
On 2020-10-15, at 19:17, Cyrill Krähenbühl <[email protected]>
wrote:
In this context, we see two topics of potential interest. First, multipath
scheduling, which has a large impact on the performance of a multipath
transport protocol, becomes challenging since we might not be able to
continuously probe 10+ (or even 100+) paths to infer which paths to send
traffic on.
Second, the SCION architecture can offer additional information for paths, for
instance AS-level information, lower bound on end-to-end path latency, expected
bandwidth, etc. An interesting challenge is how to expose this path information
to applications or transport protocols, so that path optimization is possible
for instance for different QUIC streams.
...
If the working group is interested and this use case has not already been
discussed in the group, I would be happy to give a short introduction in the
interim meeting.
thanks for the offer!
There are all kinds of interesting research questions related to multipath in
general and for QUIC in particular, including the ones you outline above.
The reason we're scheduling the interim is to help us decide if the QUIC
working group should start any standards activity in the multipath space, and
more concretely, what the desired (= currently missing) functionality is that
will need standardization. A key focus of interest are the large deployments of
IETF QUIC that are currently being planned or are already underway. I'm not
sure to what degree a presentation on research challenges would inform that
decision?
Thanks,
Lars
