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

Christoph Paasch <> Sun, 13 November 2016 07:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14484129410 for <>; Sat, 12 Nov 2016 23:51:48 -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 0jQ2FF_7QDJC for <>; Sat, 12 Nov 2016 23:51:47 -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 1E18D128B38 for <>; Sat, 12 Nov 2016 23:51:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1479023507; 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=oLvPtt4zs65TQPGUl1Qfd5DcUejAknZ5H2fRV4SI44M=; b=VEZT5Uvv7R5sKM7FL0bDEjEhc/4k0vePKSL55qLlRZVhMsgkIzgWf5CA8i4WqVku VELB8xRoqSyHjbQ09Ys+IqMKcZEFCB8Ap63d6fXGUSbbAs479O/pes4ZfwlMUoJE zFmWT3XF38QUN7C4+brSM3MLuHTM3p6JpLb9BHbmlkXyWoZ3fTUO5ciwXAUFE8tZ D2tBFyhtdx0S0slMRKjBYeTgVUBN7Tc69KRV2STFAFfpNMhsH8eJLYvoJE4VOWqp H4Odyrr4bCoN6mACq17BFc6Uibp+2dGMUozU2MBsue9j8LP2sdhqYlOWRX9nCx2V UemTI91DL/PTF8cvNRrqaA==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 5B.BC.09085.19B18285; Sat, 12 Nov 2016 23:51:46 -0800 (PST)
X-AuditID: 11973e11-b3dff7000000237d-2d-58281b91b86d
Received: from ( []) by (Apple SCV relay) with SMTP id 2C.16.23613.19B18285; Sat, 12 Nov 2016 23:51:45 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-disposition: inline
Content-type: text/plain; charset="iso-8859-1"
Received: from localhost ([]) by (Oracle Communications Messaging Server 64bit (built Jun 15 2016)) with ESMTPSA id <>; Sat, 12 Nov 2016 23:51:45 -0800 (PST)
Date: Sat, 12 Nov 2016 23:51:45 -0800
From: Christoph Paasch <>
To: Fabien Duchêne <>
Message-id: <20161113075145.GH4269@Chimay.local>
References: <>
In-reply-to: <>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FAYpTtJWiPCYM02a4t7H6YxWnxefZ3N gcljyZKfTB6vjn1nCWCK4rJJSc3JLEst0rdL4Mq4+/gwe8EUwYrWz7OYGhgv8XYxcnJICJhI /H7RydrFyMUhJLCXUeL2/GPMMIl7N06xQSQ2MkpMmfKZHSTBKyAo8WPyPZYuRg4OZgF5iSOX skHCzALSEo/+zmCHsHUker9/Y4bofcUosePvXjaQhLCApET3nTtgC1gEVCWW9pxmArHZBLQk 3t5uZwWxRQScJWZ8+sUMMchY4vCG21C9ARIr3j9lgbjBQOLon31gy4QEtCU2n+8Eq+cEWvx9 Vj+YLSqgLPH3MMidXEDPHGGTePZ1DtsERpFZSH6YhfDDLCQ/zELywwJGllWMQrmJmTm6mXlG eokFBTmpesn5uZsYQbEw3U5wB+PxVVaHGAU4GJV4eDky1SOEWBPLiitzDzFKc7AoifOGe6lF CAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamD0ePr3uIH4F9NmZc7AzTO9Jafd+RayRe2+66rX yi37zRel30+SKa3ovjC59/btlVeUL++L01mpbXX7tH71FKfNFjd2M0eUfU/S388+/7LAzPg5 PS+L5JnZnczyI7PtovTlX6xea3qn9UGwwp7KlbfiX54O/Zj/yzRz3sMt/qxKncE1mr+lOTYo sRRnJBpqMRcVJwIA7iMXkWYCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUi2FDMrztRWiPCYNFSY4t7H6YxWnxefZ3N gcljyZKfTB6vjn1nCWCK4rJJSc3JLEst0rdL4Mq4+/gwe8EUwYrWz7OYGhgv8XYxcnJICJhI 3Ltxig3CFpO4cG89kM3FISSwkVFiypTP7CAJXgFBiR+T77F0MXJwMAvISxy5lA0SZhaQlnj0 dwY7hK0j0fv9GzNE7ytGiR1/94INFRaQlOi+c4cZxGYRUJVY2nOaCcRmE9CSeHu7nRXEFhFw lpjx6RczxCBjicMbbkP1BkiseP+UBeIGA4mjf/aBLRMS0JbYfL4TrJ4TaPH3Wf1gtqiAssTf w/dYJjAKzUJy9iyEs2chOXsWkrMXMLKsYhQoSs1JrDTTSywoyEnVS87P3cQIDunCqB2MDcut DjEKcDAq8fBuSFOPEGJNLCuuzD3EKMHBrCTCayehESHEm5JYWZValB9fVJqTWnyIMRno34nM UqLJ+cB4yyuJNzQxMTAxNjYzNjY3MSdNWEmc91qHfISQQHpiSWp2ampBahHMFiYOTqkGxtZn ZfNmtH39ssXS8YrKl7ITFQJ6om73l4fsa01pl1Qs0Vn1mGn/fG4Lw9jkzLJihS99B0MStthI xr95OenlsTXz3084ahj83+LK1p3PH5twfZTp9dGxPyYtJ71K8tDXYx5CMjHXY5vNFkusOn9y btgakYU2c43+7G/gnxe/V167yGvinAPnZyixFGckGmoxFxUnAgDi5Xm3rQIAAA==
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: Sun, 13 Nov 2016 07:51:48 -0000


On 06/11/16 - 13:33:56, Fabien Duchêne wrote:
> Hello,
> As we agreed in Berlin during IETF96, here are a few email to discuss
> the contributions proposed in
> The backup mode defined in RC6824 only supports an "all-or- nothing"
> mode in the usage of
> the subflows, where an host might just prefer to use certain subflow 
> over others.
> To allow an host to inform the receving host about its preference in
> terms of subflow usage, we propose to modify the ADD_ADDR option by
> adding 3 "priority" bits.
> A host receving a priority for a sub MAY use this information in it's
> scheduling decisions.
> To allow the priority of an already established subflow to be modified,
> we propose to modify the MP_PRIO option by adding the 3 priority bits
> next to the "B" flag.
> For the moment, the priority field is interpreted as an unsigned integer
> with the highest numerical value being the most preferred one, but this
> is up to discussions, but this point is up to discussion.

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.

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.