RE: More context on ATSSS use case

mohamed.boucadair@orange.com Mon, 26 October 2020 13:57 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 E256C3A0B68 for <quic@ietfa.amsl.com>; Mon, 26 Oct 2020 06:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, 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 KP6BVrKtuBMW for <quic@ietfa.amsl.com>; Mon, 26 Oct 2020 06:57:15 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A9B3A0B67 for <quic@ietf.org>; Mon, 26 Oct 2020 06:57:15 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4CKbxP4hdBzCrSp; Mon, 26 Oct 2020 14:57:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603720633; bh=67HvDrI70p8FzwmqTWPmfah+gSH5cMW6GJIWETMeNoo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=iO4PgPDK1DPAyVjiTVDGy9NhSumAJ6KjDUpLBKKjiC+V8JrD4fnp5+cpv7JiM/iEo PIoVl+Mij/57HdbJ1/tJuHQyqZft+Yt9dQP19mANCGxPPuegrt3OV5fWteKatuQDeq qivxz4RSxqNcUdm2fxcnzoRSZXqx7kL5fB/8Obz377PNPvl5Ml3jRH/Es3INBtlSa+ LtxUyuNncveKlGflk5PpUmQRLhaY9cBbGADfQxWpPQNqQE9UpkUHBR93EMFO99GTPw W1/8UvSaqqm76oVL0EYjvuph/Gbne2Uu+uasePgPZAU1JBY3W8i2uhNkd9YD9giIhw 6rnmzsvjH+ziQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4CKbxP3bx7zFpWf; Mon, 26 Oct 2020 14:57:13 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>, David Schinazi <dschinazi.ietf@gmail.com>, Florin Baboescu <florin.baboescu@broadcom.com>
CC: QUIC <quic@ietf.org>
Subject: RE: More context on ATSSS use case
Thread-Topic: More context on ATSSS use case
Thread-Index: AQHWq3NgrtyUGNjx7UWosg00YfSZAqmp5Big
Date: Mon, 26 Oct 2020 13:57:13 +0000
Message-ID: <30191_1603720633_5F96D5B9_30191_367_1_787AE7BB302AE849A7480A190F8B933031566AD5@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>
In-Reply-To: <f1200a58-7cfe-b747-5be4-d22579bdaf68@uclouvain.be>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6LXyubJWTTbot1L8hBq0xyE0Fac>
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: Mon, 26 Oct 2020 13:57:17 -0000

Hi Olivier, all, 

> I don't see a difference between the failure of an Edge node and an
> ATSSS proxy. Both can be deployed with enough redundancy to limit
> the impact of failures. The only difference is that ATSSS nodes will
> probably be deployed by network operators while Edge nodes are
> deployed by CDN providers.

The main difference is that the ATSSS proxy will be ** explicitly signalled ** to the UE while the presence of any other on-path proxy is ** transparent ** to the UE.

The explicit mode in the ATSSS allows an UE to probe the path, react to path failures, decide to bypass the proxy, etc.

Cheers,
Med

> -----Message d'origine-----
> De : QUIC [mailto:quic-bounces@ietf.org] De la part de Olivier
> Bonaventure
> Envoyé : lundi 26 octobre 2020 09:38
> À : David Schinazi <dschinazi.ietf@gmail.com>; Florin Baboescu
> <florin.baboescu@broadcom.com>
> Cc : QUIC <quic@ietf.org>
> Objet : Re: More context on ATSSS use case
> 
> David,
> 
> >
> >
> > [DS] Let me clarify why ATSSS introduces a new point of failure.
> First
> > here's the common network topology today without ATSSS. In this
> > example the Client is a smartphone, and the user is browsing a
> website
> > hosted by WebServer.
> >
> > [Client] ----- { cellular } ------- [WebServer]
> >      \------------{ Wi-Fi   } ------------/
> >
> > The client has (at least) two IP addresses: IP_Client_cell and
> > IP_Client_WiFi.
> > The WebServer has IP_Server.
> 
> 
> My understanding of most of today's QUIC deployments is that the
> client is not connected to the webserver but to a CDN or edge node
> that serves as a proxy to the webserver.
> 
> Thus the setup is
> 
> [Client] ----- { cellular } ------- [Edge]   ---------[WebServer]
>        \------------{ Wi-Fi   } -------/
> 
> > Now let's assume the Client is happily browsing using QUICv1 over
> one
> > interface, if that network goes down, QUIC will automatically
> migrate
> > to the other network and the web browsing will not fail. The
> client
> > can send packets to IP_Server on any interface and as long as one
> > interface works they will reach the server.
> >
> > Now let's introduce ATSSS:
> >
> > [Client] ----- { cellular } ------- [ATSSS Proxy] --------
> [WebServer]
> >      \------------{ Wi-Fi   } ------------/
> >
> > 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.
> 
> > My point is that in this scenario ATSSS reduces reliability by
> adding
> > a point of failure.
> 
> I don't see a difference between the failure of an Edge node and an
> ATSSS proxy. Both can be deployed with enough redundancy to limit
> the impact of failures. The only difference is that ATSSS nodes will
> probably be deployed by network operators while Edge nodes are
> deployed by CDN providers.
> 
> Olivier


_________________________________________________________________________________________________________________________

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.