RE: connection migration

Roni Even <roni.even@huawei.com> Wed, 15 November 2017 07:44 UTC

Return-Path: <roni.even@huawei.com>
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 A674A12954B for <quic@ietfa.amsl.com>; Tue, 14 Nov 2017 23:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 GybhxLE2bheb for <quic@ietfa.amsl.com>; Tue, 14 Nov 2017 23:44:03 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8E975127444 for <quic@ietf.org>; Tue, 14 Nov 2017 23:44:03 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 06BBE9930FE5 for <quic@ietf.org>; Wed, 15 Nov 2017 07:44:00 +0000 (GMT)
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 07:44:01 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 15:43:55 +0800
From: Roni Even <roni.even@huawei.com>
To: Mike Bishop <mbishop@evequefou.be>, QUIC WG <quic@ietf.org>
Subject: RE: connection migration
Thread-Topic: connection migration
Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iAAAgH6gAAC4MDg
Date: Wed, 15 Nov 2017 07:43:55 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com>
References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <MWHPR08MB243212D50C3C7A8CB1585F21DA290@MWHPR08MB2432.namprd08.prod.outlook.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <MWHPR08MB24329EDF1A8C660D2F715A7CDA290@MWHPR08MB2432.namprd08.prod.outlook.com>
In-Reply-To: <MWHPR08MB24329EDF1A8C660D2F715A7CDA290@MWHPR08MB2432.namprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.43.147]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD837112DGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Crida1P7fTDuN1_1Hr75D4qXcT4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 15 Nov 2017 07:44:06 -0000

inline

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: יום ד 15 נובמבר 2017 08:23
To: Roni Even; QUIC WG
Subject: RE: connection migration

Exactly the same way that TCP-to-TCP handoff between these interfaces works today, because (non-MP) TCP isn’t capable of changing to a different interface.  We’re trying to build a better answer, but you’re positing from the start that connection migration fails, so we’re now in “no worse” land.

The QUIC stack in the client device will see a new interface is available.  It attempts to switch to it, because of some local policy.  The transition fails for whatever reason, but the cellular connection is still active.  It is the application’s choice
[Roni Even] which application if there is more than one? In the TCP case you stay in the cell. Here there are two options, stay on the cell with QUIC or move to wifi on TCP
whether it wants to wind down and close that connection and start a new one using TCP, or keep using the old one if the interface remains available.  If there are multiple applications, each application makes that choice independently.

And if the first interface becomes unavailable for whatever reason, the choice is made for it, and the application will have to recover.

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>; QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>
Subject: RE: connection migration

So what is the connection migration flow here. The quic stack in the cell network will try to migrate to wifi without application request and fail but will not fall back to TCP.
There may be multiple application running over quic? HTTP and peer to peer at the same time, so who will handle this case?

Roni

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: יום ד 15 נובמבר 2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

That may well be the case, but it’s not the QUIC stack’s choice to make.  The application could choose to open a new connection, but that remains outside the scope of the transport and the mapping to it which we’re defining.

For HTTP, this is fairly straightforward – it could stop issuing new flow control credit, let currently-in-transit data arrive and any losses recovered, and open a TCP connection to issue a range request starting at whatever data offset it hasn’t seen.  But that’s still a property of an HTTP management above the HTTP/QUIC mapping.

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>
Subject: connection migration

Hi,
When moving from cell to wifi the reason may be due to cost (money or quota). In this case the  user (client) may want to move to wifi even if it will mean dropping to TCP.

Roni