Re: [multipathtcp] Multipath TCP Address advertisement 4/5 - Priorities

Christoph Paasch <> Tue, 15 November 2016 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECFDF129471 for <>; Tue, 15 Nov 2016 09:43:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QpLgd40RdET6 for <>; Tue, 15 Nov 2016 09:43:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F694128E19 for <>; Tue, 15 Nov 2016 09:43:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1479231837; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0gV2Dm8g5sf/HT9fhwZB6WDUbt2sEdEgpUKOvqsGL0g=; b=2iZIHg9Dl/dUtvBmG1siwPrKknp4qY+dGOSEePVyz+jqgy2XUGziBxRhx1rtJ9Xm j5+5we4XqgV8ayWybq83pQAYA+YkEsPRn3IicLEjDYkt9j34srhcjsX8VZ7ULAU/ 7qtMxJSkanyiP31s8g23ZcjxWyerVVMBeBMfOJ6/YjAH6k7cTEavedx+UbWY2ljK Vgtbq16gaW1TIbJUZxnqLxcviGdtMrqqEADFd3aWOYsdqSLBx5PzvkYqzs20sMp1 11cwh7wV8Lnw574ipCYcx5bLJiGFdzf/K0tcP7UC4MfO8983uehop1pD9bYFvl43 X61ZNWaXxclZY6ITGVu3yw==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id A9.9C.09085.D594B285; Tue, 15 Nov 2016 09:43:57 -0800 (PST)
X-AuditID: 11973e11-0d5e19a00000237d-94-582b495d368a
Received: from ( []) by (Apple SCV relay) with SMTP id 91.7F.23613.C594B285; Tue, 15 Nov 2016 09:43:56 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-disposition: inline
Content-type: text/plain; charset="utf-8"
Received: from localhost ([]) by (Oracle Communications Messaging Server 64bit (built Jun 15 2016)) with ESMTPSA id <>; Tue, 15 Nov 2016 09:43:56 -0800 (PST)
Date: Tue, 15 Nov 2016 09:43:56 -0800
From: Christoph Paasch <>
Message-id: <20161115174356.GZ4269@Chimay.local>
References: <> <20161113075145.GH4269@Chimay.local> <> <> <>
In-reply-to: <>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUi2FAYpRvrqR1hMP0Qq8XKcyuYLe59mMZo 8bbhHpPF59XX2RxYPHbOusvusWTJTyaPu10zmT1eHfvOEsASxWWTkpqTWZZapG+XwJUxacJ+ toLpKhX75jxnbGBsl+1i5OSQEDCRWLruGTuILSSwl1HixYIimPiO15fZuhi5gOKHGCW2nvrP BpLgFRCU+DH5HksXIwcHs4C8xJFL2SBhZgFpiUd/Z7BDhNUlpkzJhWj9xShx9udUJpAaYQFJ ie47d5hBbBYBVYmziz6xgNhsAloSb2+3s4LYIgIKEh2b30DN8ZZ4OkUDojVAYsX7p2BbeQUM JJb36ENc/JFR4tNWsOmcAg4SLzd+BpsiKqAs8fcwyJFcQJ/cZ5PYdWIj8wRGkVlIHpiF8MAs JA/MQnhgASPLKkah3MTMHN3MPCO9xIKCnFS95PzcTYygSJluJ7iD8fgqq0OMAhyMSjy8Hqra EUKsiWXFlbmHGKU5WJTEed9ZAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwMr34xdb/jmVS evTMDcti4j/4e14VaXxZF2DzbG9Ps6Fx9fTiJsOo0zxGV3VnczefK38387RHm8CPBddyWx41 Ta08v3Sb2q9mQ0e7h20H6sXaTKU/Pp3cWhN0RvdFguu+hqAnhTFrla9n/6hZ55zeoCuz4krL oe3BiaGNR3Me/9TaFtQY9TVDiaU4I9FQi7moOBEAsh6ynXUCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUi2FB8QzfGUzvC4PRlG4uV51YwW9z7MI3R 4m3DPSaLz6uvszmweOycdZfdY8mSn0wed7tmMnu8OvadJYAlissmJTUnsyy1SN8ugStj0oT9 bAXTVSr2zXnO2MDYLtvFyMkhIWAiseP1ZTYIW0ziwr31QDYXh5DAIUaJraf+gyV4BQQlfky+ x9LFyMHBLCAvceRSNkiYWUBa4tHfGewQYXWJKVNyIVp/MUqc/TmVCaRGWEBSovvOHWYQm0VA VeLsok8sIDabgJbE29vtrCC2iICCRMfmN1BzvCWeTtGAaA2QWPH+KdhWXgEDieU9+iBhIYGP jBKftoJN5xRwkHi58TPYFFEBZYm/h++xTGAUmoXk5lkIN89CcvMshJsXMLKsYhQoSs1JrDTT SywoyEnVS87P3cQIDvnCqB2MDcutDjEKcDAq8fB6qGpHCLEmlhVX5gLDh4NZSYSX3xIoxJuS WFmVWpQfX1Sak1p8iDEZ6NmJzFKiyfnAeMwriTc0MTEwMTY2MzY2NzEnTVhJnNdcVCtCSCA9 sSQ1OzW1ILUIZgsTB6dUA6O3mNXfyV+svKdu85uaa2n+qDj5z1OPykzWvcYvZjYaXA/ueJ4+ +cB06wWPDa/HMHUWTLPl6zsgtv2W3rzXKVxhAp93BP9dcuzVsazPHyepPH6hk3u2+NZrF7nO CFebpWrv6g/EZPXdbA78GCrN6hm04on2Xs6FSot1ly323fjt8VfjJVK/7zgrsRRnJBpqMRcV JwIAMVU4n70CAAA=
Archived-At: <>
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 4/5 - Priorities
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Nov 2016 17:44:00 -0000

Hello Markus,

On 15/11/16 - 07:49:45, wrote:
> we are happy with a solution with the characteristics of (b) for the moment, not sure whether other use cases would need something else.

can you give an example of how you would translate the priority-bits into
scheduling decisions?


> Plus we had a lot of discussions on what „full“ would mean spcifically.
> Marcus
> Von: multipathtcp <> im Auftrag von Alan Ford <>
> Datum: Montag, 14. November 2016 um 07:14
> An: Fabien Duchêne <>
> Cc: "" <>
> Betreff: Re: [multipathtcp] Multipath TCP Address advertisement 4/5 - Priorities
> Hi all,
> After discussion at IETF97, I think it’s clear that this proposal - the idea of “priority” - means different things to different people. For example:
> a) A percentage split - but would that only kick in when one link is full? Or would all traffic always be split?
> b) Prioritising subflows, overflowing only when one is full
> c) QoS (latency, bandwidth, etc) values
> d) etc etc
> Personally I think only (b) makes sense at the subflow level, everything else is far too complex to signal in a few bits. Whether it is of use to people in the real world, however, I don’t know, however!
> I also think it’s entirely feasible to achieve a lot of the traffic engineering here by using TCP control signals - ACKs and window size - to slow down communications. As a sender you can already control rate based on your local policy, and at the receiving end you could use ACKs, ECN, window, etc.
> This proposal needs a much clearer idea of what it’s trying to achieve before we could consider it for merging.
> Regards,
> Alan
> On 14 Nov 2016, at 01:58, Fabien Duchêne <<>> wrote:
> Hello,
> Inline,
> On 11/13/2016 08:51 AM, Christoph Paasch wrote:
> Hello,
> while I support adding more info to MPTCP to allow a finer-grained control
> of the peer's scheduling, I think the priority-bits should be defined in a
> more precise way.
> I see the this work here as a way to allow for a more deterministic behavior
> when an MPTCP-client connects to a MPTCP-server. As of today, when I on my
> mobile device connect to a server that is outside of my control, the only
> way I can tell the server to schedule traffic in a certain way is by using
> the backup-bit. Upon which I can expect the server to not send traffic on
> this subflow unless the primary subflow is broken.
> This kind of "configuration" is not sufficient for most use-cases.
> I see the priorities as a way for the client to tell the server exactly
> what kind of scheduling it expects to meet a certain "QoS-requirement".
> So, we should clearly specify what each priority means.
> The way I wrote the draft was more like "ok, let's tell the server that, if possible,
> I'd like to receive most on the trafic on this subflow, then this one, then this one".
> This is why I wrote
> "The priority field MUST be interpreted as an unsigned integer value with the highest
> numerical value being the most preferred one."
> While I agree that we should be as specific as possible, I wonder how we could be more
> explicit about this. Any idea?
> If we are too specific, like saying "always schedule on the highest priority subflow,
> until the windows is full, then skip to the next one" we are actually writing a strict priority
> scheduler, and I was hoping that we could leave the priority open to more creative ways
> of handling the priorities.
> It's a MAY because I'm not sure that making the respect of the priority a MUST would
> be interesting, for backward compatibility, but also because the priorities of one host
> could clash with the other's own interest.
> If we leave the interpretation of the priority-bits open to the
> implementation, hosts still cannot rely on getting a certain service by
> the peer when set the priority bits.
> Thoughts?
> Cheers,
> Christoph
> Cheers!
> Fabien
> _______________________________________________
> multipathtcp mailing list

> _______________________________________________
> multipathtcp mailing list