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

Fabien Duchêne <fabien.duchene@uclouvain.be> Sun, 06 November 2016 12:27 UTC

Return-Path: <fabien.duchene@uclouvain.be>
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 48FFD1297CE for <multipathtcp@ietfa.amsl.com>; Sun, 6 Nov 2016 04:27:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 3smfXEGbM1iJ for <multipathtcp@ietfa.amsl.com>; Sun, 6 Nov 2016 04:27:34 -0800 (PST)
Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1606A1297CD for <multipathtcp@ietf.org>; Sun, 6 Nov 2016 04:27:34 -0800 (PST)
Received: from [130.104.228.52] (marguerite.dhcp.info.ucl.ac.be [130.104.228.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: duchenef@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id AC1EC67DA0D for <multipathtcp@ietf.org>; Sun, 6 Nov 2016 13:27:25 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be AC1EC67DA0D
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1478435245; bh=hDHbwgzbFk3wJHK60Jw6sA5EKO+Dvz9v6l2xuL9a0yk=; h=To:From:Subject:Date; b=jRWa5bWQU4m94/50IAwa+qnRYyPv31td8JocsUT6uvEKpeA4ECcWZjU2xx8L7Ia7K DHkbPX1tsIFMHQD4vFUC2tgRAE69AtLSqBii6HDbDZHiqf6gNLCbGV2KRjroX90Uxn Z7XZgQgYYit/UP7LRqLYygHsz1pux4NgYxEfM5wA=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-3
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
From: Fabien Duchêne <fabien.duchene@uclouvain.be>
Message-ID: <581F2334.8010403@uclouvain.be>
Date: Sun, 06 Nov 2016 13:33:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: AC1EC67DA0D.A0285
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: fabien.duchene@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/yKe1DqJJZWpypL9wBVVob7l8PVw>
Subject: [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, 06 Nov 2016 12:27:37 -0000

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.

Fabien