[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
- [multipathtcp] Multipath TCP Address advertisemen… Fabien Duchêne
- Re: [multipathtcp] Multipath TCP Address advertis… Christoph Paasch
- Re: [multipathtcp] Multipath TCP Address advertis… Fabien Duchêne
- Re: [multipathtcp] Multipath TCP Address advertis… Alan Ford
- Re: [multipathtcp] Multipath TCP Address advertis… Olivier Bonaventure
- Re: [multipathtcp] Multipath TCP Address advertis… Fabien Duchêne
- Re: [multipathtcp] Multipath TCP Address advertis… Christoph Paasch
- Re: [multipathtcp] Multipath TCP Address advertis… Markus.Brunner3
- Re: [multipathtcp] Multipath TCP Address advertis… philip.eardley
- Re: [multipathtcp] Multipath TCP Address advertis… Martyn Russell
- Re: [multipathtcp] Multipath TCP Address advertis… Alan Ford
- Re: [multipathtcp] Multipath TCP Address advertis… Christoph Paasch
- Re: [multipathtcp] Multipath TCP Address advertis… Christoph Paasch