Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 03 April 2020 09:17 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2883A156D for <quic@ietfa.amsl.com>; Fri, 3 Apr 2020 02:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEwez-dFRdsu for <quic@ietfa.amsl.com>; Fri, 3 Apr 2020 02:17:49 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id D824E3A156A for <quic@ietf.org>; Fri, 3 Apr 2020 02:17:48 -0700 (PDT)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7C6611B00081; Fri, 3 Apr 2020 10:17:39 +0100 (BST)
Subject: Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]
To: Olivier.Bonaventure@uclouvain.be, Lars Eggert <lars@eggert.org>, Ted Hardie <ted.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Martin Thomson <mt@lowentropy.net>
References: <CA+9kkMBcsuJGy5A7cVuooCycfskGLDPnng6O7iN_5t9KWm21DQ@mail.gmail.com> <09D76C30-BB5D-43E5-8F93-661A6C7C105D@eggert.org> <85eefd12-1e10-df7f-d66e-3d0e317b1f00@uclouvain.be> <76ddd8dd-e70d-94e1-3982-d2cb1e176618@erg.abdn.ac.uk> <7e52ea36-24fb-e8d3-dad7-232295d3ceb6@uclouvain.be>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <187b93e8-a033-7d78-8566-2c9aed26b101@erg.abdn.ac.uk>
Date: Fri, 03 Apr 2020 10:17:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7e52ea36-24fb-e8d3-dad7-232295d3ceb6@uclouvain.be>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Td6OTc4HwZO48zZN17ggTIV0TFg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2020 09:17:51 -0000
On 03/04/2020 10:09, Olivier Bonaventure wrote: > Gorry, >>>> >>>> what we have done with MPTCP is build a system that is reasonably >>>> good at pooling the capacity of multiple paths for one connection, >>>> *if* these paths have reasonably similar characteristics, esp. RTT. >>> > >>>> With paths with dissimilar RTTs, we can still pool the capacity, >>>> but only make it available for use to the application at pretty >>>> much the maximum of the individual RTTs. That’s still somewhat >>>> useful if you care about bulk throughput. It’s basically useless if >>>> you care about small-transfer latencies, which the web has been >>>> gravitating to for years. (Remember that the MPTCP design is ten >>>> years old - from a different world. Bandwidths have gone up a lot, >>>> making capacity pooling less urgent, but late cues have not >>>> decreased much.) >>> >>> This corresponds to the hybrid access network case that pools >>> bandwidth. >>> >>>> To make multi path useful to today’s mostly latency-sensitive >>>> applications, we need a path scheduler that can pool (some of) the >>>> capacity of multiple dissimilar paths at some effective RTT that is >>>> much lower than the maximum of the individual ones. I am not aware >>>> of any proposed scheduler - for MPTCP or otherwise - that achieves >>>> that. >>> >>> AFAIK, this is exactly what Apple is doing with MPTCP. They call >>> this the "interactive mode" and the stack dynamically selects the >>> path (wifi or cellular) having the best performance (rtt, losses) >>> for interactive applications. See >>> https://developer.apple.com/videos/play/wwdc2017/707/ >>> >>>> Even if we change the argument from pooling latency to increasing >>>> resilience, I still doubt that increased resilience at the cost of >>>> much-increased late zu is a worthwhile trade off for many apps. >>> >>> AFAIK, Apple calls that the "handover mode", it is probably less >>> useful that the interactive one. Maybe Apple engineers who are on >>> this list can comment and provide more details. >>> >>> I don't think that Apple uses MPTCP to pool bandwidth. They use >>> MPTCP to improve user experience and mainly latency. >>> >>> >>> Olivier >> >> When you says "select" do you mean "change to send data using the new >> path"? > > This is a packet scheduler decision. When new data needs to be sent > and there are two subflows, the scheduler selects the most suitable > one. I think that Apple uses its WiFi assist monitor to inform the > packet scheduler of the most suitable path on the client. On paper > that describes a similar approach is > > https://inl.info.ucl.ac.be/publications/tuning-multipath-tcp-interactive-applications-smartphones.html > > > In MPTCP, it is difficult for the client and the server to easily > exchange information about the quality of the paths due to middlebox > interference and a set of heuristics are used. For example, the server > replies on the subflow chosen by the smartphone to send the request. > > With MPQUIC, we can use ping frames to measure the quality of paths > and react accordingly. In MPTCP, this would require a complex machinery. > > >> I f so, I think this is close in operation to a "path failover", even >> if it uses a trigger metric that isn't just a loss of connectivity, >> but the result of some other path metric - e.g. significantly lower >> RTT, availanility of PvD information, ... . > > Apple's deployment shows that maintaining the two paths is useful > because there are situations where latency sensite applications can > use both paths, e.g. during the handover when the connectivity is weak > but not yet broken. > >> In my mind, this is quite different to a proposal for somehow >> "sharing" traffic/capacity between several paths, which means >> understanding capacity and the impacts of variability in path >> characteristics, the impact of traffic on pooled bandwidth, etc. > > The same techniques apply in these different cases. >> >> It still does pose some issues in estimating the capacity on the >> "new" path, but ... The mechanisms to do this seem to exist within >> the design expected of QUIC. > > QUIC is clearly both cleaner and more powerful than MPTCP for this. > You can find a detailed discussion on this in Quentin De Coninck's PhD > thesis which is available from https://www.multipath-quic.org > > > Olivier Thanks for the reply, this helps confirm my thoughts on mechansims. Gorry
- [Fwd: New Liaison Statement, "LS on need for Mult… Magnus Westerlund
- Re: [Fwd: New Liaison Statement, "LS on need for … Matt Joras
- Re: [Fwd: New Liaison Statement, "LS on need for … Spencer Dawkins at IETF
- Re: [Fwd: New Liaison Statement, "LS on need for … Martin Thomson
- Re: [Fwd: New Liaison Statement, "LS on need for … Spencer Dawkins at IETF
- Re: [Fwd: New Liaison Statement, "LS on need for … Martin Thomson
- Re: [Fwd: New Liaison Statement, "LS on need for … Gorry Fairhurst
- Re: Re: [Fwd: New Liaison Statement, "LS on need … Olivier Bonaventure
- Re: Re: [Fwd: New Liaison Statement, "LS on need … Olivier Bonaventure
- Re: [Fwd: New Liaison Statement, "LS on need for … Spencer Dawkins at IETF
- Re: [Fwd: New Liaison Statement, "LS on need for … Ted Hardie
- Re: Re: [Fwd: New Liaison Statement, "LS on need … Qing An
- Re: [Fwd: New Liaison Statement, "LS on need for … Lars Eggert
- Re: [Fwd: New Liaison Statement, "LS on need for … Olivier Bonaventure
- Re: [Fwd: New Liaison Statement, "LS on need for … Gorry Fairhurst
- Re: [Fwd: New Liaison Statement, "LS on need for … Olivier Bonaventure
- Re: [Fwd: New Liaison Statement, "LS on need for … Gorry Fairhurst
- RE: [Fwd: New Liaison Statement, "LS on need for … Markus.Amend
- Proposed response to Liaison Statement "LS on nee… Lars Eggert
- Re: Proposed response to Liaison Statement "LS on… Spencer Dawkins at IETF
- Re: Proposed response to Liaison Statement "LS on… Lars Eggert
- Re: Proposed response to Liaison Statement "LS on… Spencer Dawkins at IETF
- Re: Proposed response to Liaison Statement "LS on… Lars Eggert
- Re: Proposed response to Liaison Statement "LS on… Spencer Dawkins at IETF