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

Alan Ford <> Mon, 14 November 2016 06:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1F531294E4 for <>; Sun, 13 Nov 2016 22:14:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 j87M13xPijjU for <>; Sun, 13 Nov 2016 22:14:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED8BA1294DC for <>; Sun, 13 Nov 2016 22:14:20 -0800 (PST)
Received: by with SMTP id 189so27602778pfz.3 for <>; Sun, 13 Nov 2016 22:14:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=RO2lpgUUbotTFOSwnJdnqMW33BD91UZ+4p3V13qbLPs=; b=r2xOrnDQpISkfdlkNTH/qoKIxGDSGU/c94mJWGPY4bYByjgfh3jXIFwE3C6EypRKh+ KwccSOaMcjVqAc8/COttcb5sw59FF8rIR/Hg3tZ6F2PE2Nk4e6jnOmkwJ++hGBOsFIUF nbt7T03PtOrfKRY3HihGae9GCD8E/gc3d/VoEM8F2oshUWg6c2qTANS0GyqM9kiTOBGw Zs4aSIF8JhAUfjvmW6PEq2SaPGBI/O/x7fN5XZz2ZuQHrtVNkdKZaMChYCwBISKIFw3Y zWU7x0MCx8/V5dP0JSq+MEYTVD4gTTi+5QL3Da5grEIsMB87UhMRo4mxkOCSidAdJEKt ULxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RO2lpgUUbotTFOSwnJdnqMW33BD91UZ+4p3V13qbLPs=; b=dNVKw9hTMxmPIsGoCxb6bTGsO2lxDq6n+n+kpZiiZI8QKeCd63fugLskEPokTAqNCr i+N9vZ9Q289kwUJvLHCobBFs45hRPmElAv5TV9/MUAg7Ya/d2oX/I90EcTarl5JUmXaM /20jXaD9p7FXfmpYW5habCyLZ7Z9fndcvutbudJWUyqZX9NxBr5s+22BlLtocp8jFB4+ T4RJRTqFTL+eGWRDAqRjDHEZxLDifMMKyTw87NMYGnUhQPhO6NLekIYMyfdMl4y0vd3f cp6WFqWUXsLOb6PhzSEMH5uffvCQ0o9+3vazUG6iXJPT3x2YnG5nvHlcWpGeX03wyMpi n6Tg==
X-Gm-Message-State: ABUngvcxQ2ROvxg5pmnmbF7U5/QUrapZsTCvKIiYCAPTF4QUhzkDSVZWhBl2vHiQxEb97Q==
X-Received: by with SMTP id i68mr33585028pfj.18.1479104060536; Sun, 13 Nov 2016 22:14:20 -0800 (PST)
Received: from ( []) by with ESMTPSA id vz6sm32088573pab.15.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 22:14:19 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_ED6C2EA0-73C8-493B-95A0-AF18B898D619"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Mon, 14 Nov 2016 06:14:17 +0000
Message-Id: <>
References: <> <20161113075145.GH4269@Chimay.local> <>
To: Fabien Duchêne <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
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 06:14:23 -0000

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.


> 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
> <>
> <>