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