Re: Multipath

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 19 December 2019 13:33 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 AAA6712029C for <quic@ietfa.amsl.com>; Thu, 19 Dec 2019 05:33:18 -0800 (PST)
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 STRai8P5dOqQ for <quic@ietfa.amsl.com>; Thu, 19 Dec 2019 05:33:16 -0800 (PST)
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 C143F12023E for <quic@ietf.org>; Thu, 19 Dec 2019 05:33:16 -0800 (PST)
Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:c1c0:8fb8:bdd1:2917]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 67EAE1B000A6; Thu, 19 Dec 2019 13:33:02 +0000 (GMT)
Subject: Re: Multipath
To: Ryan Hamilton <rch=40google.com@dmarc.ietf.org>, Olivier Bonaventure <olivier.bonaventure@tessares.net>
Cc: Quentin De Coninck <quentin.deconinck@uclouvain.be>, Jana Iyengar <jri.ietf@gmail.com>, Mark Nottingham <mnot@mnot.net>, Christian Huitema <huitema@huitema.net>, Lars Eggert <lars@eggert.org>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <1E872371-F543-4822-8C11-05601913A72E@tessares.net> <752D0B90-8B29-4DBC-9B2F-09E834335598@eggert.org> <49366B32-6425-486C-9453-96D27E2E8EAE@tessares.net> <CAN1APdfNyMBzeWKVRQojo4W_mgxXSSwj4X4EvFC9Pfz4bZ+Pdg@mail.gmail.com> <DF4E42C3-3D90-4C68-989C-6B11833005F9@tessares.net> <CAN1APddWow_QBs+_6GRLyauWFrLVvcr7LA9Mjqdgw-Bcp0d=tQ@mail.gmail.com> <9bc43313-7a06-8b01-75ef-ff1c3925a6cc@huitema.net> <CACpbDccdpKHygp87Be-ytC7juYZmUrfh-3a=4ESLCWMfE-t6Ww@mail.gmail.com> <839F7E31-FB6A-4846-A3C4-C5539E14407E@tessares.net> <CAJ_4DfT_riJr0n0KyD43iRZ+pmkqFiU3YPaTobZcLdqPJVUYYw@mail.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <37e2866a-ceab-bbdd-83e9-53fb52803845@erg.abdn.ac.uk>
Date: Thu, 19 Dec 2019 13:32:56 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAJ_4DfT_riJr0n0KyD43iRZ+pmkqFiU3YPaTobZcLdqPJVUYYw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/JggCvWsTxV_62wUF3KIvNbA7x7A>
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: Thu, 19 Dec 2019 13:33:19 -0000

On 18/12/2019 22:42, Ryan Hamilton wrote:
>
>
> On Wed, Dec 18, 2019 at 10:40 AM Olivier Bonaventure 
> <olivier.bonaventure@tessares.net 
> <mailto:olivier.bonaventure@tessares.net>> wrote:
>
>     [snip]
>
>     A second use case is for mobile devices that need to preserve
>     connectivity while switching from one wireless network to another.
>     When such a device detects another wireless network, it needs to
>     bet whether migrating the connection to the new network would
>     improve performance. With a multipath transport, there is no need
>     to bet as the transport will automatically select the best
>     performing network. Apple’s deployment of Multipath TCP is a good
>     example of the benefits of such a multipath strategy.
>
>
> FWIW, QUIC connection migration was designed to do explicitly this and 
> has been very successful in Google's deployment. I don't think this is 
> a good justification for multipath QUIC.
>
> Cheers,
>
> Ryan

Just as an observation - It seems you can design connections:

(1) to survive rebinding here you expect normally the same path (or set 
of devices on path),

(2) to fail-over between different paths where you expect diverse 
characteristics -  SCTP separated path fail-over (a standardised feature)

and (3) to do multi-path sharing (not currently in the RFC series) - 
where you may wish to schedule to minimise delay; maximise throughput; 
optimise for some other metric.


I can see merit in acquiring experience that migration works well in the 
first and second case before starting on scheduling/cross path sharing.

gorry