Re: [multipathtcp] MPTCP Schedulers

Alexander Frömmgen <> Sun, 17 February 2019 12:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B573012941A for <>; Sun, 17 Feb 2019 04:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 37DG7RlFfdBV for <>; Sun, 17 Feb 2019 04:35:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A1B9128B14 for <>; Sun, 17 Feb 2019 04:35:43 -0800 (PST)
Received: from [IPv6:::ffff:] ([]) by (mreue012 []) with ESMTPSA (Nemesis) id 1Mae7u-1hT2rP09tK-00cDa5; Sun, 17 Feb 2019 13:35:33 +0100
MIME-Version: 1.0
To: Olivier Bonaventure <>, Christoph Paasch <>, Vladimir Olteanu <>
Cc: "" <>
From: Alexander Frömmgen <>
Date: Sun, 17 Feb 2019 13:35:34 +0100
Importance: normal
X-Priority: 3
Thread-Topic: [multipathtcp] MPTCP Schedulers
In-Reply-To: <>
References: <> <20190215180722.GR1880@MacBook-Pro-19.local> <>
Content-Type: multipart/alternative; boundary="_D4ECA3B4-C38F-4DD2-84A1-4092406B93EB_"
Message-ID: <>
X-Provags-ID: V03:K1:/+ocLRMsUC4uHgvIAHrT2o/NpU46L3yKtB9/7jmKp9hO2oco1Wx osPTQ/+oeCJtMeGDg0o9fVvC0CL43i8G3bSYTW+z4a+bjyihs3V2QL4LJ7sZizogZUVSQFY u1Wxbivs7UIaI2qdxmQhIcSHvw4G4Po04lr4ZNs72odNgysU/UCSJoHPicBqDu5USFxXx8g EStUY2Lbnj49pa662J5zw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:PV1efo7bOPY=:t1Xaps3YIVqHj0X4nB4y+s xNBxu8b8qXowR6rYQg4qGbXbuH8rIWffMRFWZad6to7ID5pHwX58vKQEWnrD0BdqhaGea/A/9 5TQmIKCWBD3aq8DuH4i0uPsFQt04KTZqy8rQANswyhHDwnAnA7alb/opA745xV0e4oGkKKRHX 7eAOxMUjEPZDUayjo5yZymsvV4iss5wktfFSyPZpCJdh87LOnyGWDosp+frI9avU9S5pLhsSe fR1FWP9ye34G5NcsNdX4MNmf2b7fA1iX+llMrYvg1ikGMsLWTLMsmC+l15xdPuEVi0UtqoHKi rHASXRkFxKWB3jqfgopLIh7nVAueWX8q5zDky0/JQxrT7PQD9cj0jvg0j0ZqSqLwgM7fIoTXK VBSBSnNGLLGcIoO2UWgHIcjSZKcDQdwVjJWCtmaVMW3p925ywEN4XrRBKMmD+EMGqRP/efdaR ollep64VrwEhIy86zT9d0fNLofCnw5lrpCzLj4WRmjW5l4GNFJ0e7Tc1CFxMpx50FmuWHFKA+ PB0C1Nu5QJ/4LqlYmNQipp9p40/cEVWUPZp9Z9dtEQLfcFZ3srzrvc77gffKNQJjYBWjwapwo nxXd2zDN0ZsJmsGA5JXocWbAKWgaookJulGucfsvSWSgqbo8soXBrR5IcHaha3Q5lTobW75XE UNDHnEPNyJkOwBkT39Tu00mtxlbMaDaGmjN/4kV7wevEbMucGgOjUl2llJhdvLoOZ4/9lo5Aj uLJ85P8F0najmrH8FvbUX/+/wpP/dLf74flkJ82p0J/W+MotNxY+wbU8YnY=
Archived-At: <>
Subject: Re: [multipathtcp] MPTCP Schedulers
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Feb 2019 12:35:46 -0000


some remarks and questions inline.

> Do you think it would be worthwhile to standardize the MPTCP schedulers? I
> think an informational or best practice RFC would be useful.

What level of scheduler standardization do you consider? While an informal description of the scheduler behavior should be feasible, I have the feeling that a detailed specification of the scheduler behavior is not possible, e.g., i) details of todays scheduler behaviors emerged from the dependencies to the Linux Kernel (round trip time is calculation, packet queues), and ii) intuitive descriptions, such as "redundant“, are very imprecise (prefer old or new packets for heterogenous subflow environments?). [0]

> I agree, but this control could be provided by defining an MPTCP option 
> that enables a client to request the utilisation of a specific scheduler 
> by a remote server.

> 1. agree on a small list of schedulers that should be supported by MPTCP 
> implementations. The literature contains a variety of schedulers, we'd 
> need to select some of them

1.1 How to select the concrete schedulers? Given that there is a variety of proposed schedulers, as of today, the Linux implementation contains only three of them. Does this imply that there was no need for further schedulers outside of academia so far?
1.2 How should we deal with the concrete parameters of these schedulers and scheduler Evolution?

> If we can define a small list of identifiers for 1, then we can use the 
> same technique as the one described in recent work by Hoang Tran Viet

Sounds great. Can you elaborate a bit the concrete usecase? Why is the eBPF flexibility required? 

> B. an API that enables an application to interact with the MPTCP stack

It might worth to start with the high level  "goals" and the target audience of such an API. For application developers, for example, the choice of the concrete scheduler might be inappropriate. The Apple API [2], for example, is on a much higher abstraction level than explicitly selecting the scheduler.

A high level API to specify the preferences [3], e.g., the required throughput, might enable scheduler innovations to optimize for these preferences and speed up the MPTCP adoption by simplifying the application developers life.

Obviously, the high level API might be implemented on top of a lower level API. In this case, the goal for the lower level API should be to enable the implementation of the high level API on top.



[1] Section 2.2