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

Alan Ford <> Tue, 15 November 2016 09:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEAD412979D for <>; Tue, 15 Nov 2016 01:36:56 -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 z2ou6l2A747Q for <>; Tue, 15 Nov 2016 01:36:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D4E1129537 for <>; Tue, 15 Nov 2016 01:36:55 -0800 (PST)
Received: by with SMTP id c4so23575535pfb.1 for <>; Tue, 15 Nov 2016 01:36:55 -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=1Q3wil9rEVaEDFuZ+Ni0KiCOxd43w4LxYUsjwz0MlC4=; b=YTp9iJ0rLGnDX8AHyAZkRu30X71A9rKVfDxi+1d3cyIAgsln36nOUh09VPi1m5K8gc P13IqWB06MQvX2qhw85icLmnOfc27GB/z5h2VY61uo91ypacmiUsuszzGx6q/tLWiJ+v cKoJB8As8xt/c+5DFdvSxp5/CIQEJC54zp7+OITm/8z/N9xvDrm1naDFqNqz8dBrZ0rY 74RZy2TK5FJyA3D01EzPt1jbfrOIoOeTwYM55GMwlzvoG1qMZrXW3uSuhFgLoixPj3OY uXtpKxtLfIeJ3U9WDGx/HgXIoX/nDxOWrFxObHhD2rSSpEgNEBnZqikHpDZKSNMoRbe2 qh3w==
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=1Q3wil9rEVaEDFuZ+Ni0KiCOxd43w4LxYUsjwz0MlC4=; b=VlCno4yE2rEDlGOuzewSY2p2TC9dbYT+T4bRPoP/NS/jLY6CDxDeLy/J0cm9g0iFdi aKuyt/6wimnzOpCN/Tws8UMco7FTYliSx35Xwp1HIGU0+kJYjirMQM0Ou/Cx7riyAxWp CtTZbWRUIZps+Wu8qRb7qHhN9yaLcsDShQnQ13zqnrvSZ7yoF7aiewKqZUif3FmxiZyf xKbbaHTeNnzuPjyYDLBmrO1uWczl31f/MmUDGyE2pVfn6EhPVpf2JI2r3qtHx8d5ZiOv qNCTIFRSszJ3kGNodTYZAV81qDnBYTtMcfdrTRNmYUqJCnpJMqm3FPc9nHpe8mYF5NTj APwA==
X-Gm-Message-State: ABUngvf0fgYRV/Of3oBOqPMmcoq+M06QZHjxssmOS9kZ28lswrnOLhaYGpAR7MO+6+Bx5g==
X-Received: by with SMTP id p67mr45575899pfg.15.1479202614754; Tue, 15 Nov 2016 01:36:54 -0800 (PST)
Received: from ([2001:67c:370:128:250d:3916:5032:5af6]) by with ESMTPSA id b126sm41274071pfg.90.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Nov 2016 01:36:53 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_590C9D45-E430-4C20-BA50-426BD49D62FD"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <20161115071909.GV4269@Chimay.local>
Date: Tue, 15 Nov 2016 09:36:48 +0000
Message-Id: <>
References: <> <20161113075145.GH4269@Chimay.local> <> <> <20161115071909.GV4269@Chimay.local>
To: Christoph Paasch <>
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: Tue, 15 Nov 2016 09:36:57 -0000

Hi Christoph,

> On 15 Nov 2016, at 07:19, Christoph Paasch <> wrote:
> Hello,
> On 14/11/16 - 06:14:17, Alan Ford wrote:
>> 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 agree with you that signalling priorities in the sense of (b) is not
> necessarily useful. Because, at the end it is then still left to the
> decision of the implementer on how he translates the priorities into
> scheduling.
> I think that one missing piece in MPTCP today is the lack of control a
> host can exercise on how the peer should schedule its traffic.
> The backup-bit only enables seamless handover. But MPTCP's benefits go
> beyond that. Especially for applications sending a thin stream, the delay
> benefits can be huge (as has been mentioned in the IETF journal article), if
> the scheduling takes RTT into account (while minimizing cell usage for power
> & cost reasons).
> Allowing to signal this will be a bigger exercise, but I believe
> that it is necessary if we want longterm to go to a world where a client can
> connect to any webserver (of any implementation) and use MPTCP.

So what semantics would you assign to the priorities? Or are you saying we should leave that up to implementors"

“This defines the priority of each subflow with relation to each other; how a receiver of this option translates this into the scheduling is implementation-specific."

Is that useful to you as an implementor, do you feel? For interop, when you don’t know what the far end will do with this information, would it be useful?

Are there any fundamentals we could/should specify?