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
<[email protected] <mailto:[email protected]>> wrote:
Hi Lucas,
On Fri, Oct 23, 2020 at 4:28 AM Lucas Pardue
<[email protected] <mailto:[email protected]>>
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
