Re: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"

Andreas Kassler <andreas.kassler@kau.se> Tue, 13 July 2021 13:33 UTC

Return-Path: <andreas.kassler@kau.se>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452533A0E4F for <tsvwg@ietfa.amsl.com>; Tue, 13 Jul 2021 06:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 J63vk1wVKDqz for <tsvwg@ietfa.amsl.com>; Tue, 13 Jul 2021 06:33:27 -0700 (PDT)
Received: from smtp1.kau.se (smtp1.kau.se [130.243.21.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5FB93A0E53 for <tsvwg@ietf.org>; Tue, 13 Jul 2021 06:33:26 -0700 (PDT)
Received: from mailfilter-ng-1.sunet.se (mailfilter-ng-1.sunet.se [192.36.171.207]) by smtp1.kau.se (Postfix) with ESMTP id 947C71850250 for <tsvwg@ietf.org>; Tue, 13 Jul 2021 15:33:22 +0200 (CEST)
X-Halon-ID: 0c3fee10-e3df-11eb-8cbd-0050569a42e2
Received: from Exch-A3.personal.kau (exch-a3.kau.se [130.243.19.84]) by mailfilter-ng-1.sunet.se (Halon) with ESMTPS id 0c3fee10-e3df-11eb-8cbd-0050569a42e2; Tue, 13 Jul 2021 13:34:28 +0000 (UTC)
Received: from Exch-A2.personal.kau (130.243.19.83) by Exch-A3.personal.kau (130.243.19.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2176.14; Tue, 13 Jul 2021 15:33:21 +0200
Received: from Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60]) by Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60%6]) with mapi id 15.01.2176.014; Tue, 13 Jul 2021 15:33:21 +0200
From: Andreas Kassler <andreas.kassler@kau.se>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
Thread-Index: AQHXS0epjP9TCiXXAEOzhnXobcemAqsVYfOAgAK/wgCAAdHSAIAH3CGAgAfvloCABgMfgIARXNYA
Date: Tue, 13 Jul 2021 13:33:21 +0000
Message-ID: <F573B981-D081-4C8D-A17D-48328EB5A1A9@kau.se>
References: <162127490513.10263.5800886336891576953@ietfa.amsl.com> <12030134-E2F9-4621-9F26-A7139E2D784F@akamai.com> <FRYP281MB0405C8042C5D6355DF665EBDFA0E9@FRYP281MB0405.DEUP281.PROD.OUTLOOK.COM> <26C03E8C-FA89-4D74-855F-A056DE9604B0@akamai.com> <59a9e1ec358f4cd7aad804b36f241cef@kau.se> <FRYP281MB040575B104C7275DC494059AFA039@FRYP281MB0405.DEUP281.PROD.OUTLOOK.COM> <LO0P265MB295622335EEA4C84644D13A4D31F9@LO0P265MB2956.GBRP265.PROD.OUTLOOK.COM>
In-Reply-To: <LO0P265MB295622335EEA4C84644D13A4D31F9@LO0P265MB2956.GBRP265.PROD.OUTLOOK.COM>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.243.27.149]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9AB0F9BE7A095C4F824999BD09768AEB@personal.kau>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/5iyhzLoPNNPckqXgwLN5-yDD9Rk>
Subject: Re: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2021 13:33:32 -0000

Hi Veselein, Markus, all,

at Karlstad University we have two testbeds based on the open-source version of MP-DCCP from https://multipath-dccp.org. One is based on the kernel space version and we also re-implemented MP-DCCP in user space under Mininet which allows us for rapid prototyping of new schedulers and reordering mechanisms. Using these two testbeds, we implemented a new packet scheduler “Adaptive Cheapest Path First”, which removes some problems with strict priority scheduling (CPF) when using it with congestion controlled tunnels. More information is available in our upcoming ANRW paper “Adaptive Cheapest Path First Scheduling in a Transport-Layer Multi-Path Tunnel Context”.
A preprint is available at https://arxiv.org/abs/2106.16003

We also have initial results for both switching versus splitting for mobile scenarios.

with regards

Andreas


> On 2 Jul 2021, at 14:24, Rakocevic, Veselin <Veselin.Rakocevic.1@city.ac.uk> wrote:
>
>
>
>
> Hi Markus, all
>
> At City, University of London we have a testbed based on the open-source MP-DCCP code from https://multipath-dccp.org. We also use Google Pixel phones running the MP-DCCP framework and run tests with real applications, both WebRTC-based and file downloads, over commercial networks, testing the performance of MP-DCCP in different switching and steering scenarios. In future we plan to extend this towards the splitting scenario. We already published some academic papers with results and will continue our work on this.
>
> While the steering and switching already delivers promising results, the splitting seems to have some implementation issues. We are looking forward to the next revision of the open-source software.
>
> with regards
>
> Veselin
>
> --
>
>
>
>
>
>
>
>
>
> From: tsvwg <tsvwg-bounces@ietf.org> on behalf of Markus.Amend@telekom.de <Markus.Amend@telekom.de>
> Sent: 28 June 2021 17:35
> To: anna.brunstrom@kau.se <anna.brunstrom@kau.se>se>; jholland=40akamai.com@dmarc.ietf.org <jholland=40akamai.com@dmarc.ietf.org>
> Cc: tsvwg@ietf.org <tsvwg@ietf.org>
> Subject: Re: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
>
> CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and believe the content to be safe.
>
>
> Hi Anna, all,
>
> Thanks for raising this important point, why DCCP is a good choice for multipath support especially for non-TCP traffic.
>
> I wonder if there are already testbed installation available which prove and verify MP-DCCP to be lightweight, as well as efficient due to access to path characteristic information (available bandwidth, RTT, ...)? Moreover, are there use cases in which you like to explore MP-DCCP?
>
> For Deutsche Telekom I can reveal, that we have three testbed implementation using the open source Linux reference implementation from https://multipath-dccp.org. These testbeds are setup for PoC and trial activities with real devices and customers.
>
> 1. Provide Multipath in enterprise environment, converging Wi-Fi and 5G access.
> Autonomous Guided Vehicles (AGV) is a first use case in this scenario, which verifies the resilience provided by MP-DCCP in a real industry environment. Integrated in the AGV and a MP-DCCP Proxy attached to a converged Wi-Fi6 and 5G SA core, builds the foundation of the testbed which is ready to be used in real customer PoCs. See also https://www.telekom.com/en/company/details/deutsche-telekom-demonstrates-multipath-for-fixed-mobile-convergence-on-campus-625838
>
> 2. Integrated in Google Pixel 4 devices as part of the OS (and controlled by the Android Network Manager) to verify its applicability towards 3GPP ATSSS. In this scenario, the MP-DCCP proxy is hosted in the public Internet and enables multipath transport between the phone and ANY Internet service. A video demonstrating this with a real Skype call can be found on the start page of https://multipath-dccp.org/. For the purpose of ATSSS, the GSMA ZTC taskforce identified MP-DCCP to be a solution, to close the open gap towards UDP support and therefore triggered the LShttps://datatracker.ietf.org/liaison/1741/ towards TSVWG. DT provides all the members in the ZTC round access to their MP-DCCP testbed.
>
> 3. As part of internal residential gateway prototypes, MP-DCCP allows us to investigate its Hybrid Access capabilities according to BBF TR-470 on Wireless Wireline Convergence.
>
> To all: I'm highly interested in your experience on MP-DCCP, details about existing testbeds and your potential plans with MP-DCCP. Please feel free to share your insights here...
>
> Br
>
> Markus
>
>
> > -----Original Message-----
> > From: Anna Brunström <anna.brunstrom@kau.se>
> > Sent: Mittwoch, 23. Juni 2021 17:25
> > To: Holland, Jake <jholland=40akamai.com@dmarc.ietf.org>rg>; Amend, Markus
> > <Markus.Amend@telekom.de>
> > Cc: tsvwg@ietf.org
> > Subject: RE: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
> >
> > > -----Original Message-----
> > > From: tsvwg <mailto:tsvwg-bounces@ietf.org> On Behalf Of Holland, Jake
> > > Sent: den 18 juni 2021 17:23
> > > To: mailto:Markus.Amend@telekom.de; mailto:jholland=40akamai.com@dmarc.ietf.org;
> > > mailto:statements@ietf.org; mailto:david.black@dell.com; mailto:gorry@erg.abdn.ac.uk;
> > > mailto:wes@mti-systems.com
> > > Cc: mailto:GSMALiaisons@gsma.com; mailto:tsvwg@ietf.org
> > > Subject: Re: [tsvwg] New Liaison Statement, "LS to IETF TSVWG on MP-DCCP"
> > >
> > > Hi Markus,
> > >
> > > Thanks.  I think those diagrams are helpful.
> > > https://multipath-dccp.org/intro.html
> > > It looks like the idea is to wrap generic UDP traffic in a multipath-capable
> > > tunnel at the OS level.
> > >
> > > That makes sense, and it looks like maybe ease of implementation on the
> > > client devices is among the reasons to prefer it to other kinds of tunnels, if
> > > I'm understanding it.  That seems like a fine reason.  Thanks for clearing that
> > > up.
> >
> > I think you are correct here Jake, that MP-DCCP is quite light weight is a benefit.
> > You also have the congestion control state, with RTT estimates etc., that can be
> > used as input for scheduling and path management. This of course is a main
> > benefit shared with other transport layer solutions.
> >
> > Best Regards,
> > Anna
> >
> > >
> > > Best,
> > > Jake
> > >
> >
> > När du skickar e-post till Karlstads universitet behandlar vi dina
> > personuppgifter<https://www.kau.se/gdpr>.
> > When you send an e-mail to Karlstad University, we will process your personal
> > data<https://www.kau.se/en/gdpr>.

Kind regards, Andreas Kassler
====================================
Prof. Dr. Andreas J. Kassler
Computer Science Department
Universitetsgatan 2
SE-65188 Karlstad
Sweden
Tel:   ++46 (0)54 700-2168
Fax:   ++46 (0)54 700-1828
eMail: andreas.kassler@kau.se
skype: andreaskassler
Web:   www.kau.se/forskare/andreas-kassler

När du skickar e-post till Karlstads universitet behandlar vi dina personuppgifter<https://www.kau.se/gdpr>.
When you send an e-mail to Karlstad University, we will process your personal data<https://www.kau.se/en/gdpr>.