Subject: Re: Collecting measurements with Multipath QUIC

From: Quentin De Coninck <[email-masked]>
Date: Fri, 4 May 2018 15:29:55 +0200

Hello Ian,

Thanks for your comments, my thoughts inline.

Le 29/04/18 à 21:25, Ian Swett a écrit :
> 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?
Sounds good to me
>
> 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?
I think that it's still desirable to keep a symmetric Path ID between 
hosts (for instance, performance metrics with RTT,...). Now that 
NEW_CONNECTION_ID frames can be sent by each host and that Connection 
IDs are asymmetric, two NEW_CONNECTION_ID should be exchanged before 
starting to use a new path ID. When an host agrees to let the peer use a 
given path ID, it communicates the corresponding NEW_CONNECTION_ID 
frame. A path ID can be used by an host once it is aware of both 
corresponding "source" and "destination" Connection IDs. Like this, both 
hosts can still control the number of paths the connection can use.
>
> 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?
Good catch, probably some old text from the previous draft version :-)
>
> 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.
I'm not against using transport parameters (and a corresponding update 
frame) to communicate addresses between peers, but I think it is 
valuable to keep the ability to communicate several addresses. With a 
dual-stacked server, it might be useful for the client to know about 
both addresses, especially is the client has two networks 
connectivities, one IPv4 only and another IPv6 only. The dynamic address 
changes can be needed if we consider the peer-to-peer case with QUIC.
>
> 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.
Keeping uncoupled congestion controls on paths is fine as long as those 
paths does not share any bottleneck. However, this is not always the 
case, and sometimes hosts are unable to figure it easily. An example a 
client connected to both a WiFi and a cellular network, where the WiFi 
Internet access is actually provided by the (same) cellular network. In 
such case, if the CCs on paths are uncoupled and the cellular base 
station is overloaded (i.e., it is the bottleneck), multipath 
connections will be unfair towards singlepath ones, as they will get 
twice the bandwidth of the bottleneck compared to singlepath. Also, at 
some points, hosts might face network migrations, such that two paths 
initially disjoint can share a common bottleneck. See for instance 
Wischik, Damon, et al. "Design, Implementation and Evaluation of 
Congestion Control for Multipath TCP." (NSDI) or Khalili, Ramin, et al. 
"MPTCP is not pareto-optimal: performance issues and a possible 
solution." (CoNEXT).

For the flow control, it looks like the receive window in TCP, i.e., to 
avoid flooding the peer (while the CWIN is IMHO to avoid flooding the 
network).
>
> 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.
Will change this in the next version
>
> 6.1 Given the NEW_CONNECTION_ID frame already has a sequence, it seems 
> simpler to use that than add another PATH ID.
The Path ID was added to the sequence number in order to allow 
Connection ID changes for a given Path ID, but it might be overkill to 
do this. If no one has use cases for this, the sequence number could be 
renamed as the Path ID.
>
> 7.1 MAX_PATHS could also be replaced by an UPDATE_TRANPORT_PARAMS frame.
Agreed
>
> 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?
The PATHS frame was initially though as a way to share path information 
between peers, but I'm not sure we need a standard way to do this, and 
the PATHS frame could be skipped. To close paths, we still have the 
PATH_UPDATE, that can both close a path and optionally propose to 
migrate the path over another one.
>
>
>
>
>
>
>
> On Thu, Mar 22, 2018 at 8:05 AM Quentin De Coninck 
> <[email-masked] 
> <mailto:[email-masked]>> 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
>

-- 

Quentin De Coninck
FNRS Research Fellow - PhD Student
ICTEAM / INGI
Ecole Polytechnique de Louvain
Bâtiment Réaumur (bureau A.010)
Place Sainte Barbe 2, bte L5.02.01
B – 1348 LOUVAIN-LA-NEUVE (Belgium)