Re: Collecting measurements with Multipath QUIC

[Ian Swett <[e-mail]>]

Thanks for the updated doc.  I think it embodies the goals of the QUIC WG
much better than the past version.

Some comments below:

In 3.3 "The negotiated value will determine how many bytes will be used to
encode the Path ID in frames."


I think it's easier, and more in keeping with the overall QUIC design to
use a varint for Path ID?

In 3.5, there is discussion of NEW_CONNECTION_ID in a way that makes me
think this document needs an update now that QUIC has adopted asymmetric
connection IDs?

In 3.6 "The presence of the Path ID in the public header ensures that the
packets sent over a given path will contain monotonically increasing packet
numbers."

There is no explicit Path ID in this draft, so I suspect this should be
reworded to talk about the implicit path ID associated with the connection
ID?

In 3.7, I feel like it's cleaner to supply alternate addresses once in
transport params, which Mike Bishop's PR#1251
<https://github.com/quicwg/base-drafts/pull/1251> does, though with a
slightly different use case in mind.  As a corollary, I'm not convinced the
REMOVE_ADDRESS frame is really necessary.  If it is, I think I'd rather
combine Mike's PR with an UPDATE_TRANPORT_PARAMS frame, which I have a few
other use cases for already.

In 3.10, I'd prefer to say each path needs to have it's own congestion
controller, rather than just specifying it's own congestion window, since
there are other aspects of congestion control besides a CWND.  And I'm
confused why they MUST be coupled together?  Given the flow control is not
path specific, I'm unclear on the benefits of coupling the congestion
controllers?  Possibly you can send me some background reading to clarify
that?  I read some indication this was for fairness in the RFC, but that
seems questionable, given it's possible no portion of the path is shared
until you get to the host, in which case it's the host's responsibility to
ensure a peer isn't given an unfair share of bandwidth.

5.2  As I mentioned in reference to 3.3, I'd just use a QUIC varint, which
simplifies this quite a bit, and makes the typical cases of a small number
of paths very efficient.

6.1 Given the NEW_CONNECTION_ID frame already has a sequence, it seems
simpler to use that than add another PATH ID.

7.1 MAX_PATHS could also be replaced by an UPDATE_TRANPORT_PARAMS frame.

7.5 It's clear the PATHS frame could be useful to close a path, but I'm not
sure what other uses it has?  If it has no other uses, I'd prefer a
PATH_CLOSE frame.  If it has other uses, can you clarify it's purpose?







On Thu, Mar 22, 2018 at 8:05 AM Quentin De Coninck <
[e-mail]> wrote:

> Hello,
>
> During today's discussions, we heard several times questions on
> Multipath QUIC and even more mentions on the benefits of having
> measurement data before taking decisions. Multipath QUIC will be
> discussed later this year within the IETF, but in the mean time we have
> already proposed a first design (recently updated, see
> https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/) and
> even more written an implementation of Multipath QUIC which allows to
> collect data in a variety of networks. Experience with Multipath TCP
> shows that the performance of a multipath transport depends on a variety
> of algorithms such as path management and packet scheduling that
> interact together.
>
> During the MPTCP working group this afternoon, I will briefly present an
> iOS application that includes our Multipath QUIC implementation. It
> allows collecting different types of measurements. As it runs on iOS, we
> can also compare Multipath QUIC and Multipath TCP together. If you have
> an iPhone, I encourage you to install the MultipathTester application
> below and run it in different networks and notably outside the ietf WiFi.
>
> https://itunes.apple.com/us/app/multipathtester/id1351286809
>
> We have already confirmed experimentally the importance of validating
> addresses in QUIC through a firewall that blocks UDP port 443 in one
> direction (see
> https://multipath-quic.org/2018/03/15/firewall-address-validation.html).
> We'll probably find other strange results thanks to your measurements,
> we will update our findings on https://www.multipath-quic.org
>
> Best regards,
>
> Quentin De Coninck
>
>