RE: More context on ATSSS use case

mohamed.boucadair@orange.com Tue, 27 October 2020 07:48 UTC

Return-Path: <mohamed.boucadair@orange.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 A02A53A1620 for <quic@ietfa.amsl.com>; Tue, 27 Oct 2020 00:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 knZwLMQ8Kxxr for <quic@ietfa.amsl.com>; Tue, 27 Oct 2020 00:48:09 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DC03A161E for <quic@ietf.org>; Tue, 27 Oct 2020 00:48:08 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4CL3j26dzDz10C1; Tue, 27 Oct 2020 08:48:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603784886; bh=48/Y/PqlqZPEUv4rkS45YQ9gRIeACft+4UHOSB36bYg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=lnKE2tVTHgpQ+NZ1fam9P5HkHoBWEMhnPrsszIMHw1Uo38EIzrNPuaOQjJSFIOgXS ofs9rWgarBc65mCaUU6wpwDkvyaNmVEhNHTVGstzkZ95ZpLfCgLwE+tMwohmiFvc7E bN1KyUt0I6Wa134EDc53JlJDUFHsxRhaAi/cljAk76NaswLtKybciNX/RHcc7te4F1 QTkT36HD39lLrhNJblAep8znvHY7WK9hJNH836op+g2W26L6F5dwDIcRIy70ddHKru rTKi0oQ1cUMCBTjXBj8icgKe/9ypYjXzG3Z42Tg3BpCO+7bAyY4AoT0Ijl62sa3ZQ7 BoxSkY7G6Ocqw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4CL3j25dV2zFpWV; Tue, 27 Oct 2020 08:48:06 +0100 (CET)
From: mohamed.boucadair@orange.com
To: David Schinazi <dschinazi.ietf@gmail.com>, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
CC: QUIC <quic@ietf.org>
Subject: RE: More context on ATSSS use case
Thread-Topic: More context on ATSSS use case
Thread-Index: AQHWq7km71XX5oTs0kaHZcmiqgE+bamrDzLw
Date: Tue, 27 Oct 2020 07:48:05 +0000
Message-ID: <27337_1603784886_5F97D0B6_27337_324_1_787AE7BB302AE849A7480A190F8B933031567411@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <50316F2A-931B-483E-B2CC-023C91AE91F0@ericsson.com> <CAPDSy+6k13fW_oQuEhmyQsMY9PH2DrVvKQ-DnJ=kQk5tTsN7TA@mail.gmail.com> <77E53AF0-6435-492A-B20A-5C18372BD1F8@ericsson.com> <CAPDSy+5pc7bPDXUT0uNu2MtD-MgVD7fXpG22eYY+7pmVBi30pw@mail.gmail.com> <0d7b0483916b3876934ed195075d8d72@mail.gmail.com> <CAPDSy+5Rfy77=iNNeg--YinfKvhmSThDJ98sN6WNyNvhX-d9MQ@mail.gmail.com> <cdd11cd390de134c98c6aa51a2b9bca7@mail.gmail.com> <CAPDSy+4uQ_TxcfFZpTDNqjj6js3VABpntOLyAz0HV+q7fpCkXg@mail.gmail.com> <f1200a58-7cfe-b747-5be4-d22579bdaf68@uclouvain.be> <CAPDSy+4vbBign8JOs4EB3rakcA1FhYgKfPv+mSmi2yxwvrAdNA@mail.gmail.com>
In-Reply-To: <CAPDSy+4vbBign8JOs4EB3rakcA1FhYgKfPv+mSmi2yxwvrAdNA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031567411OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/0rBOmsMPhUkN-wA2l5V8fxN7nKs>
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: Tue, 27 Oct 2020 07:48:11 -0000

David,

The end-to-end QUIC connection will always survive.

If you refer to https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00#section-5.2, you will see that the external IP address seen by the remote server may be local to the ATSSS proxy or may be the one that is directly assigned to the UE.

Depending whether the UE’s address is preserved or not when the ATSSS proxy is involved, migrating flows outside the tunnel (for whatever reason) may or may not even require a connection migration!

Cheers,
Med

De : QUIC [mailto:quic-bounces@ietf.org] De la part de David Schinazi
Envoyé : lundi 26 octobre 2020 17:58
À : Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc : QUIC <quic@ietf.org>
Objet : Re: More context on ATSSS use case

Hi Olivier, responses inline.

>
> The ATSSS Proxy has IP_ATSSS.
> The packets sent by the client are not sent to IP_Server here, they're
> sent to IP_ATSSS.
> If the ATSSS proxy becomes unreachable mid connection, the client's
> connection will break - because it's sending to IP_ATSSS not IP_Server.

The client will detect the failure of the ATSSS proxy and will then be
able to switch to non-ATSSS to directly reach the webserver/edge node.
Since the client uses the ATSSS for multiple applications, a failure of
the ATSSS proxy will be quickly detected.

How can it do this without the end-to-end QUIC connection failing?
Are you saying that the Client will migrate its end-to-end QUIC connection
away from the virtual ATSSS interface and go straight over Wi-Fi?

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.