IETF Logo Mail Archive

RE: More context on ATSSS use case

"Flinck, Hannu (Nokia - FI/Espoo)" <hannu.flinck@nokia-bell-labs.com> Mon, 26 October 2020 06:50 UTC

Return-Path: <hannu.flinck@nokia-bell-labs.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 F03643A1971 for <quic@ietfa.amsl.com>; Sun, 25 Oct 2020 23:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 8Z6NCiMEN47s for <quic@ietfa.amsl.com>; Sun, 25 Oct 2020 23:50:52 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2131.outbound.protection.outlook.com [40.107.22.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5EE3A196D for <quic@ietf.org>; Sun, 25 Oct 2020 23:50:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FHFT25y7UFmSGUs5K0G8Y9sbkrsLre86q78OPhjkzHBPqmhas2Mme+Wwwm5NIDvvdTx5qsBQB8+p9GLVmzGh2lGvaqjnOK6ZJwtoiPHlIKfoGiDAyxd71UwtpctpiH8pjWCpHvYPr0ySevke/mKBQDJN7kDirG1bUzBlKeTLeOgboosBezFQaBUM8+2YKMgSElA8Q3ij3RbNk28oRomfmXBoxrLkmV0KPimhUQz7jEjJ072DIaDBZRq3mnl6c1UvKcbDugseVlmX+NJq2+KxUgl0w637yNH/rC1E1Obrc8Imghu/Mh3h+3MbJMcJ3ZZMMwZR08AYeYAofuT8ARArfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XVP35wQtTQYC8zzpucv8P4woUqkbKMIxVBojd5NdiD0=; b=OikqICOIHwft7zOooJMit8R0Q1ZYwyizUPdDxa9/pnKRJylH1Rymt8B5c1ci8hZLcwYMc/WvzNUg329E0VLcBK7WrHAx/xl952u2AD9wWafAZIv/52cok4Wg271bmzXOimogsjlsa08N+9OZPd59l7oJYgW3fotcMEMOYDsRlIFfh4FLWvTX/y4m8Ds2nlF3UyRuHF7yW+LOm4Ra6Kl9mzkM9cpHEFUB9mP0iFUZGBzj1KpGARKfMrhiUNlzwzqWQwt5Sajke5dkTbITOcN6BXYa6uC0uAcudmlf6RZgarKOYoxdxLczyLfMpXRyZU/IKKAIfOYDpQHYFTM+df/8NQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XVP35wQtTQYC8zzpucv8P4woUqkbKMIxVBojd5NdiD0=; b=ty1IidPOQ/gGnlNEwJkhkI+tY8rfCBQ1ulAdeMup/maR1Fiy+GzJZfpWI6quaihgJ/VED/rCPYvJj2BPdv+NDjBu5zlnBVWWnpdAEGP3yb3az69bfXPyVXjR/cXTrvXPS80tBdbjeqV5V3pHWA6mIh5A0aoukYLX0J84vInWgd4=
Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR0702MB3819.eurprd07.prod.outlook.com (2603:10a6:7:83::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.15; Mon, 26 Oct 2020 06:50:48 +0000
Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::f8c8:5ad8:f747:3fbf]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::f8c8:5ad8:f747:3fbf%4]) with mapi id 15.20.3499.018; Mon, 26 Oct 2020 06:50:48 +0000
From: "Flinck, Hannu (Nokia - FI/Espoo)" <hannu.flinck@nokia-bell-labs.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
CC: Florin Baboescu <florin.baboescu=40broadcom.com@dmarc.ietf.org>, David Schinazi <dschinazi.ietf@gmail.com>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, "quic@ietf.org" <quic@ietf.org>
Subject: RE: More context on ATSSS use case
Thread-Topic: More context on ATSSS use case
Thread-Index: AQHWqYC42e4II73LxU+v0/faox0YzKml8Q+AgAABUYCAABxyAIACjVUwgAAHU4CAANDSIA==
Date: Mon, 26 Oct 2020 06:50:48 +0000
Message-ID: <HE1PR07MB3386F98EBC4EC6DF9BDC6BBE9B190@HE1PR07MB3386.eurprd07.prod.outlook.com>
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> <HE1PR07MB3386230A22CAAC0816DB3B149B180@HE1PR07MB3386.eurprd07.prod.outlook.com> <CALGR9oarzEuLXNaqwttrZSS-SR4MmMvT2YZHKmapfaL9JdmxaQ@mail.gmail.com>
In-Reply-To: <CALGR9oarzEuLXNaqwttrZSS-SR4MmMvT2YZHKmapfaL9JdmxaQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia-bell-labs.com;
x-originating-ip: [91.154.146.213]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 42bc9176-97f1-49a8-3577-08d8797b78ae
x-ms-traffictypediagnostic: HE1PR0702MB3819:
x-microsoft-antispam-prvs: <HE1PR0702MB3819C0B6FB4FF7B946C363B79B190@HE1PR0702MB3819.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +j6BmMrLTHaHx5jXGQlnp6m8oY/HfuT0+33eesmKt0DEPo6JBC/IbaNwutp2CXLtxRAhcs4QvhtIvGoJCFDNnm9CqzCac6XM28vRz8ziJzInCuC7wXpB2F0a6q9d8XRaawxxffOHqrVdFsOIeFVkuoX75iwHCkJBNj7ZRZ6HIGayaeFPBGNC+MpwMDfzyyGmFz8QekGMIz+f4qWGIqcEVZCXz6AFh01JFgS0ogiqiVf9vEF1NBy0UDsSvxm57PrDkumKvLEXsMUTwaW2zfZk54svRi53JogI+szvfZzGw9hnrS4DOaclUUY/ZEIGkoreSZiCjeddvCawYkRh0OS8RQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(346002)(136003)(376002)(366004)(478600001)(5660300002)(8676002)(9686003)(2906002)(86362001)(83380400001)(4326008)(33656002)(53546011)(71200400001)(55016002)(186003)(6916009)(66446008)(8936002)(64756008)(66556008)(66476007)(7696005)(26005)(52536014)(54906003)(66946007)(76116006)(6506007)(316002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: n5cKDkKuPXwfyIHmzGPJ5Fs2E559araE/TFQe9UPfJC2N8NeBhqiH/qo7rJaZpxd6vnxwX8kalvFLyzIPyjAfBQR925IqSaAMlkqcDWx+Blqux+2HEqzBdar4CvTGM4Y6GgdqqgNaSR0Ap9XJu90qvLX+TsFWaT6fmdj0NOpm2d6uHuk47Pfc/UHnCkjTWX7hfm5GoZwbYg8Bh6oRfB2R/uwUCf3XeChDb8LCIk2keM9YkQKbyWy0f70GhO2Qw/ioBhB1AmGUEqkxjrG+mN1AtHHqwrzZSjbn0w2fru7ZEtxdXCsC1ZSR6FD8e/TWNbO7xj7qiIQs45Vt0SUxDZ2U5h6AbMOSHtNcA1D32nnqpIzMSyZEEF4aNNXI7NiWilHaa4POVcoKVUqMDqfVUED+oX1svu9ZuuX8y2UN29Sdm39BPr+5jOUHCi1U+Irur0cyCTQz8zNTFAl3gsYOMP63yj1k4tcNuxSJfev0rBBUbAw1qmr5W004IIcl1p3UPNyPfNs8bxlFC//5P3DzV/pkag/c978WbBLJfRQQ7DlBQPrkPKqmH63LYHq3Pn1UZMp9MvCjsciF0C+hsyInZ3LJa7Io3lcjFFA7FAvIRktBIVCFvKGFHDTRG6+qjX/rSiGNUCcc3jvpBVuePDmZEHi2g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3386F98EBC4EC6DF9BDC6BBE9B190HE1PR07MB3386eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3386.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 42bc9176-97f1-49a8-3577-08d8797b78ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2020 06:50:48.4427 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5JZ1luvWz4A/LZ+Qm/g1a9oXHFJ//t3ZcLmjQwI8GRZazYkO+RJuwFk5pB23UNLlaRHMt++hyos/4EkTEgOJWDWtUaWLxRDFI9Cif+9/3h9w+V5YymMCoBz5gBsuh9wR
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3819
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/M_NGIVtxFsTSdlULjsC4q_fGe9I>
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 06:50:54 -0000

Hello Lucas

When a PDU session is established (PDU session is like setting up L2) a set of attributes will be exchanged between the UE and the 5G network. Part of the is the type of PDU session, such as multiaccess-PDU with steering mode information (e.g. load balancing, active-standby, etc. see the presentation for more details). The MP-QUIC connection is established per IP flow (5 tuple). With this information the UE will steer the traffic to the corresponding multipath-quic connection.

Best regards
Hannu

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Sent: Sunday, October 25, 2020 8:19 PM
To: Flinck, Hannu (Nokia - FI/Espoo) <hannu.flinck@nokia-bell-labs.com>
Cc: Florin Baboescu <florin.baboescu=40broadcom.com@dmarc.ietf.org>; David Schinazi <dschinazi.ietf@gmail.com>; Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>; quic@ietf.org
Subject: Re: More context on ATSSS use case

Hey Hannu,
On Sun, 25 Oct 2020, 18:05 Flinck, Hannu (Nokia - FI/Espoo), <hannu.flinck@nokia-bell-labs.com<mailto:hannu.flinck@nokia-bell-labs.com>> wrote:
Hello David and others,

ATSSS supports low latency applications in the following way (this is a quote from 23.700-93) as part of its “Priority-based” mode:

“RTT Threshold: Supported by using the RTT estimation mechanism defined in draft-ietf-quic-recovery, with which the QUIC protocol can estimate the RTT of a QUIC connection. Example of ATSSS rule using this steering mode: "Send the traffic of App1 to the access with RTT < 100ms; if both accesses have RTT < 100ms, send it to non-3GPP access". … As long as the selected access has RTT < 100ms, the traffic can remain on this access.”

I hope this clarifies that ATSSS is supporting what was called as Interactive service/Siri service in Christoph’s presentation.

And as explained by Mirja earlier it is the application that requests what kind of session it would like to have.
So part of the benefit of QUIC is that connections can be reused for different purposes. Using streams I can handle both an application that requires low-latency (such as an API) along with bulk data transfer (such as a software download) that has no hard requirement for completion time.

Iiuc ATSSS correctly, all it can do is forward QUIC packets. So how can it pick the correct path the cases where a connection is mixed use?

Cheers
Lucas

v2.23.0 | Report a Bug | By Email