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

Fabien Duchêne <> Mon, 14 November 2016 02:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED422127058 for <>; Sun, 13 Nov 2016 18:07:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NLtHkAoh-GsN for <>; Sun, 13 Nov 2016 18:07:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1F81129474 for <>; Sun, 13 Nov 2016 17:58:59 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id BB18667DA44 for <>; Mon, 14 Nov 2016 02:58:51 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 BB18667DA44
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1479088732; bh=PW4o6ZzNRZ0Qqs3xf8dQsWtIfZgMWqvZoMh5IgBpIuE=; h=Subject:To:References:From:Date:In-Reply-To; b=0djJOrQ56+8q/7HOWohbpEPMHIDnzVJdZbFrPX+zfzNkKsH7XCXAnuDAkOet+O6YK lcRDFOTjUq6g7XDC+yT7uva5XYlonR2Z2hL7Yr1k2UAVChhu7IwO4/gOWQ/8WgSm5m 2Iiku1DfFQLT/b0T1CnOr+nmZw0UCLdiG/yASo1g=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3
To: "" <>
References: <> <20161113075145.GH4269@Chimay.local>
From: Fabien Duchêne <>
Message-ID: <>
Date: Mon, 14 Nov 2016 02:58:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0
MIME-Version: 1.0
In-Reply-To: <20161113075145.GH4269@Chimay.local>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: BB18667DA44.AF2B9
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
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: Mon, 14 Nov 2016 02:07:51 -0000



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