Re: My BoF report: multipath

[Jana Iyengar <[e-mail]>]

Thanks for kicking off this thread, Martin.

Yet again, I want to focus on what is most important for us to work on
right now. Rather than answering the theoretical question of what a
well-rounded transport looks like, we need to focus on the engineering
decision of what problems we need to work on right now in QUIC.

We have multipath in QUIC. It may not be enough, but we agreed in this wg
that this would be a good first cut to have. I believe this satisfies the
charter text as we have it right now. We've just finished building the use
of multipath in QUIC, and I'd like us to get some experience with it before
considering how to expand its scope or how to improve it further.

For those who want to experiment with other ways of using multiple paths:
QUIC has many ways of extending the protocol. All you need to do is to
build, deploy, gain experience, and share it with the rest of this group. I
would love to hear more about such experiments going forward.

In the meantime, let's not forget that we still have important unfinished
business (version negotiation, tooling, load balancer work, potential
optimizations). We're about to see wider deployment of QUICv1 and HTTP/3,
which will be a massive shift in traffic. We will need bandwidth to discuss
issues related to this deployment that are inevitable, and deal with
immediate protocol issues that arise from our deployment experience of all
things QUIC, including the multipath that we will be deploying.

- jana

On Fri, Oct 23, 2020 at 12:34 PM Roland Zink <[e-mail]> wrote:

> A application works with a single connection most of the time. As
> application developer you probably can't afford to put any effort in
> improving this when it isn't absolute necessary. If you do it on the
> application layer then the application may also get location information
> out of it, like IP addresses or WiFi names, and this is a privacy issue.
>
>
> Regards,
>
> Roland
>
>
> Am 23.10.2020 um 18:34 schrieb Lucas Pardue:
>
> Hi Behcet
>
> On Fri, Oct 23, 2020 at 4:15 PM Behcet Sarikaya <[e-mail]>
> wrote:
>
>> Hi Lucas,
>>
>> On Fri, Oct 23, 2020 at 4:28 AM Lucas Pardue <[e-mail]>
>> wrote:
>>
>>> Posting as an individual.
>>>
>>> Thanks to the time that people took to prepare, present and discuss, I
>>> gained a better understanding of this area.
>>>
>>> One main takeaway for me is that thinking of QUIC v1 as singlepath puts
>>> it in an unfair box. Others, such as Jana, articulated this point better
>>> than I.
>>>
>>> QUIC is path independent, path aware and provides mechanisms, written in
>>> the core document, for endpoints to interact  and interoperate about
>>> path-related things. Through the course of specification development things
>>> might have gone different, and we might be having a conversion now about
>>> whether the group should adopt a document that describes for instance just
>>> connection migration.
>>>
>>> But migration is in the core and, based on the Slack discussion
>>> following the interim, there appear to be several parties that have
>>> expressed an interest in testing deployments of Connection migration. This
>>> can be seen as some form of success.
>>>
>>> The use cases indicate that things like active-active paths or bandwidth
>>> aggregation are desirable. But I was unable to discern objectively how more
>>> of an optimal experience they would provide over a well tuned QUIC v1
>>> endpoint that use connection migration.
>>>
>>>
>>
>> Coming from IP layer, I have a message to QUIC enthusiasts:
>>
>> Connection migration is a solution for mobility at transport layer.
>> Ideally, it should be IP layer. If a node moves, its connections normally
>> break. So connection migration of QUIC solves that issue at the transport
>> layer.
>>
>> OTOH multipath QUIC is a solution for multiple interfaces. If a node can
>> be connected to  the Internet over more than one interface using them
>> simultaneously provides several advantages like increasing bandwidth, etc.
>>
>>
> As an individual. I'll repeat my comment, I've seen little evidence that
> some design that enables bandwidth aggregation in the QUIC transport over
> multiple paths offers advantages over a well-tuned QUIC stack that delivers
> over a single path. If the benefits of bandwidth are so huge, I might
> expect that people would be clambering to add this quickly with multiple
> QUIC connections coordinated in the application layer. That would allow
> deployment and testing without needing to wait for the transport to be
> redesigned.
>
> Let's not forget the disadvantages that bundling bandwidth can come with
> too. These could be perfunctory or monetary.
>
> Cheers
> Lucas
>
>