Re: Fwd: New Version Notification for draft-dawkins-quic-multipath-questions-00.txt

[Behcet Sarikaya <[e-mail]>]

On Mon, Dec 7, 2020 at 2:09 AM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> Thanks for working on this.
>
> I’m still looking for a discussion on symmetric vs assymmetric multipath.
>
> Today in QUIC v1 only the client can migrate.
> Is multipath going to be the same, or can both endpoints initiate multiple
> paths?
>
>
I think symmetric vs asymmetric makes some difference. For example in
ATSSS, maybe we can assume UPF does not move. Maybe we can even assume UE
also does not move because then it would be difficult to access the fixed
network path.

Even in symmetric scenarios, I don't see much value of migration because in
case of migration, it will no longer be multipath, i.e. UE can no longer
access WiFi.

Behcet
Behcet


>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> On 7 December 2020 at 06.27.12, Spencer Dawkins at IETF (
> [e-mail]) wrote:
>
> Dear QUIC working group,
>
> We've exchanged a lot of e-mail about what support for multiple paths in
> QUIC might look like on the mailing list, and talked about this at the
> October virtual interim meeting and at the QUIC session at IETF 109, and it
> seemed good to me, to try to summarize the discussions we've had so far.
>
> Because this topic is of interest outside the IETF, I thought it better to
> put the summary in an Internet Draft, than somewhere in Github issues or
> Slack, or on the mailing list.
>
> I also want to apologize in advance if I've misstated things - if so,
> please let me know. I'd point out this text in the draft:
>
>    Please note well that this document reflects the author's current
>    understanding of working group discussions.  It is likely that there
>    are more questions than currently included in the document, and it is
>    even more likely that some of the suggested answers are incomplete or
>    (unlike the people in Section 1.1) completely wrong.  Contributions
>    that add or improve questions and answers are welcomed, as described
>    in Section 1.4.
>
> As always, Do The Right Thing.
>
> Best,
>
> Spencer
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Sun, Dec 6, 2020 at 11:18 PM
> Subject: New Version Notification for
> draft-dawkins-quic-multipath-questions-00.txt
> To: Spencer Dawkins <[e-mail]>
>
>
>
> A new version of I-D, draft-dawkins-quic-multipath-questions-00.txt
> has been successfully submitted by Spencer Dawkins and posted to the
> IETF repository.
>
> Name:           draft-dawkins-quic-multipath-questions
> Revision:       00
> Title:          Questions for Multiple Paths In QUIC
> Document date:  2020-12-06
> Group:          Individual Submission
> Pages:          13
> URL:
> https://www.ietf.org/archive/id/draft-dawkins-quic-multipath-questions-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-dawkins-quic-multipath-questions/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-dawkins-quic-multipath-questions
> Htmlized:
> https://tools.ietf.org/html/draft-dawkins-quic-multipath-questions-00
>
>
> Abstract:
>    The IETF QUIC working group has been chartered to produce extensions
>    that would "enable ... multipath capabilities" since the working
>    group was formed in 2016, but because multipath was an extension,
>    work on multipath, and the other extensions named in the charter,
>    waited while work proceeded on the core QUIC protocol specifications.
>
>    After the QUIC working group chairs requested publication for the
>    core QUIC protocol specifications, they scheduled a virtual interim
>    meeting to understand the use cases that various groups inside and
>    outside the IETF were envisioning for multipath with QUIC.
>
>    As part of that discussion, it became obvious that people had a
>    variety of ideas about how multiple paths would be used, because they
>    weren't looking at the same use cases, and so had different
>    assumptions about how applications might use QUIC over multiple
>    paths.
>
>    This document is intended to capture questions that have come up in
>    discussions, with some suggested answers, to inform further
>    discussion in the working group.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>