Re: [multipathtcp] MPTCP Schedulers

Vladimir Olteanu <> Mon, 18 February 2019 00:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFB65130DC4 for <>; Sun, 17 Feb 2019 16:46:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SuWgUdFUGoIn for <>; Sun, 17 Feb 2019 16:46:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 73367130DC2 for <>; Sun, 17 Feb 2019 16:46:29 -0800 (PST)
IronPort-SDR: SD6TW5eAV9PYzHpHun9wfgAHF0BdnF9i0voX1yLv7NVpT2g0Uu5bEeyRgQsNjRrTLOxemDNgT/ 8wlyCZojXQSw==
IronPort-PHdr: 9a23:YJD5ABJKlkn4s6lzPtmcpTZWNBhigK39O0sv0rFitYgULP/xwZ3uMQTl6Ol3ixeRBMOAtKIC1rKempujcFJDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBX660e/5j8KGxj5KRE9ZqGsQtaT3IyL0LWV/5zNYghSzBC6Z7psIROqsB/c/p0RhYp8K6srjBHOpHJWduJK2HllDU+YmxHh+M6x+thp/nIU8/c889JBSazmf7gzVfQMCSkiL2Et7dHrqRLbZQqC+nVaVX8ZxElmGQ/AuS/+V5vwtyrg/s15xCSTO9C+Ga4wUDij6qZxDhjslCoOMSMR+3qRktF6yrhc9kHy7ydjypLZNdnGfMF1ebnQKJZDHTJM
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.58,382,1544479200"; d="scan'208";a="3193025"
Received: from (HELO ([]) by with ESMTP; 18 Feb 2019 02:46:24 +0200
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC2AD1A60057; Mon, 18 Feb 2019 02:46:24 +0200 (EET)
Received: from ([]) by localhost ( []) (amavisd-new, port 10032) with ESMTP id NF8wIyeNMqDs; Mon, 18 Feb 2019 02:46:24 +0200 (EET)
Received: from (localhost []) by (Postfix) with ESMTPS id 8A99B1A6006C; Mon, 18 Feb 2019 02:46:24 +0200 (EET)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 7CCD11A60057; Mon, 18 Feb 2019 02:46:24 +0200 (EET)
To: Olivier Bonaventure <>, multipathtcp <>
References: <> <>
From: Vladimir Olteanu <>
Message-ID: <>
Date: Mon, 18 Feb 2019 02:46:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
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: Mon, 18 Feb 2019 00:46:34 -0000

On 2/17/19 12:20 PM, Olivier Bonaventure wrote:
> Vlad,
>> I'm trying to tie up any loose ends in the SOCKS 6 draft. There is some
>> functionality which lets you change the MPTCP scheduler used by the
>> proxy. The available schedulers are basically the ones available in the
>> Linux kernel implementation.
>> (
>> Do you think it would be worthwhile to standardize the MPTCP schedulers?
>> I think an informational or best practice RFC would be useful.
> I think that this would make sense, but we could also encode the
> requested MPTCP scheduler inside an MPTCP option instead of putting it
> in an application level message as you propose in your draft. The
> advantage of using MPTCP options is that the same solution would work
> for any application.
> Olivier


I agree that it is worthwhile doing it at L4. As far as SOCKS is 
concerned, this would also open the door for the client controlling the 
scheduler used not only by the proxy, but also by the remote host.

I'd argue that being able to do it at the application layer is also 
useful, even if your proposed option gets standardized. The scheduler 
option will not fit inside a SYN + MP_CAPABLE + TFO (along with SACK, 
TS, MSS and Wscale) and you'll have to send it 1 RTT later. (In fact, 
not even the TFO option will fit if the cookie is large.) OTOH, there is 
on such pressure oh the SOCKS option space; you've got 16K to play with.