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

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Mon, 14 November 2016 06:18 UTC

Return-Path: <olivier.bonaventure@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 365F81294DC for <multipathtcp@ietfa.amsl.com>; Sun, 13 Nov 2016 22:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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, 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 Vg38JHJ1MslX for <multipathtcp@ietfa.amsl.com>; Sun, 13 Nov 2016 22:17:59 -0800 (PST)
Received: from smtp2.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 90515127077 for <multipathtcp@ietf.org>; Sun, 13 Nov 2016 22:17:59 -0800 (PST)
Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 2F48167D9F0; Mon, 14 Nov 2016 07:17:44 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be 2F48167D9F0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1479104264; bh=TJOjeKPZFT6TJNOSwBLzCDwyxjMvBQJh6pyWq/WVOFI=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=zsyjRnYQCrB+uG2paBzmypLkeZE1pYihlsAP3Xq1GrTcd1yI3KhNWH+c4l9Nfl8l+ seBg3KCFEe/fgiUnpLPmWG9TYYzwte0zJ1QtMwV/feHo/MpViQfZpfMMDRb3Y+X2bt zQY9z8azh+DiufFNRMSp4xKHMhh5Ng5IS+EOGrOI=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2
References: <581F2334.8010403@uclouvain.be> <20161113075145.GH4269@Chimay.local> <826bf9ab-e9b7-a89b-28de-676deece8a4b@uclouvain.be> <D0FA35FF-B17F-4F7F-92E1-D9FBB6E735A7@gmail.com>
To: Alan Ford <alan.ford@gmail.com>, =?UTF-8?Q?Fabien_Duch=c3=aane?= <fabien.duchene@uclouvain.be>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <15e6fed0-b6f0-1303-4511-2f686d4eb0ae@uclouvain.be>
Date: Mon, 14 Nov 2016 07:17:43 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <D0FA35FF-B17F-4F7F-92E1-D9FBB6E735A7@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: 2F48167D9F0.A1F8E
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/v_cYrxkRnV1BYMhKrydcqhbwWm4>
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
Reply-To: Olivier.Bonaventure@uclouvain.be
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: Mon, 14 Nov 2016 06:18:01 -0000

Alan,

> I also think it’s entirely feasible to achieve a lot of the traffic
> engineering here by using TCP control signals - ACKs and window size -
> to slow down communications. As a sender you can already control rate
> based on your local policy, and at the receiving end you could use ACKs,
> ECN, window, etc.

Announcing different receive windows on different subflows is not a good 
idea. RFC6824 notes in section 2.4

    With MPTCP, all subflows share the same receive buffer and advertise
    the same receive window.

This is a safe principle that hosts should respect.


Olivier