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

Christoph Paasch <cpaasch@apple.com> Sun, 13 November 2016 07:51 UTC

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14484129410 for <multipathtcp@ietfa.amsl.com>; Sat, 12 Nov 2016 23:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jQ2FF_7QDJC for <multipathtcp@ietfa.amsl.com>; Sat, 12 Nov 2016 23:51:47 -0800 (PST)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E18D128B38 for <multipathtcp@ietf.org>; Sat, 12 Nov 2016 23:51:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; 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 relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in2.apple.com (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 chive.apple.com (chive.apple.com [17.128.115.15]) by relay6.apple.com (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 ([17.150.210.10]) by chive.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OGK00IZPLU9W960@chive.apple.com>; Sat, 12 Nov 2016 23:51:45 -0800 (PST)
Sender: cpaasch@apple.com
Date: Sat, 12 Nov 2016 23:51:45 -0800
From: Christoph Paasch <cpaasch@apple.com>
To: Fabien =?iso-8859-1?Q?Duch=EAne?= <fabien.duchene@uclouvain.be>
Message-id: <20161113075145.GH4269@Chimay.local>
References: <581F2334.8010403@uclouvain.be>
In-reply-to: <581F2334.8010403@uclouvain.be>
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: <https://mailarchive.ietf.org/arch/msg/multipathtcp/yPxUxYfe1Y3SC3lgVS-V1iwWULQ>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 4/5 - Priorities
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Nov 2016 07:51:48 -0000

Hello,

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
> https://datatracker.ietf.org/doc/draft-duchene-mptcp-add-addr/
> 
> 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.


Thoughts?



Cheers,
Christoph