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

Christoph Paasch <cpaasch@apple.com> Tue, 15 November 2016 07:19 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 4CC8B1295DD for <multipathtcp@ietfa.amsl.com>; Mon, 14 Nov 2016 23:19:12 -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 DnZvYuICG4vG for <multipathtcp@ietfa.amsl.com>; Mon, 14 Nov 2016 23:19:10 -0800 (PST)
Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 9C485129516 for <multipathtcp@ietf.org>; Mon, 14 Nov 2016 23:19:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1479194350; 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=I3UQHyor9UdqDvK7/0Gs1TRO5L9npOMgFihBjrCHJwY=; b=WGcXiViGJbApuXg0HvsH7iEMlnsLEMg6J0EIx6R3n9+L3ingjzc042oE2R+2ouRD BhJaL2OrNYgnO9S1ZiUdFTjsjhiDAilKcHKuCFmEsNiHBcC+39nkhyFfWAgR/tb5 9Gy23cCHqo0tIVKcMeQNAMh0pO11QN3/DD2YCSuREvAzSN8q+Lxp4W1ZujI7Nnh8 AweObW6qat1oWhoN6clXoJRP54HpmFdAUuxim0tIqzLf7Hp5Cgg/pIJHVcaYFDbG i/lmw2LGExiwsKKU7ccXxotVf7Jld812jLRSXjNDqwq8gur3sC0Xr+5bRqQ5Z5Eu zvIj3T4FVa4IpuCiNCfIhA==;
Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 22.97.12011.EE6BA285; Mon, 14 Nov 2016 23:19:10 -0800 (PST)
X-AuditID: 11973e13-68e279a000002eeb-ba-582ab6eefa23
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay5.apple.com (Apple SCV relay) with SMTP id AD.9F.27929.DE6BA285; Mon, 14 Nov 2016 23:19:10 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-disposition: inline
Content-type: text/plain; charset=utf-8
Received: from localhost ([17.150.212.34]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OGO00CI39NXSGD0@nwk-mmpp-sz09.apple.com>; Mon, 14 Nov 2016 23:19:09 -0800 (PST)
Sender: cpaasch@apple.com
Date: Mon, 14 Nov 2016 23:19:09 -0800
From: Christoph Paasch <cpaasch@apple.com>
To: Alan Ford <alan.ford@gmail.com>
Message-id: <20161115071909.GV4269@Chimay.local>
References: <581F2334.8010403@uclouvain.be> <20161113075145.GH4269@Chimay.local> <826bf9ab-e9b7-a89b-28de-676deece8a4b@uclouvain.be> <D0FA35FF-B17F-4F7F-92E1-D9FBB6E735A7@gmail.com>
In-reply-to: <D0FA35FF-B17F-4F7F-92E1-D9FBB6E735A7@gmail.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FAYoftum1aEwdJT/BYrz61gtrj3YRqj xefV19kcmD12zrrL7rFkyU8mj1fHvrMEMEdx2aSk5mSWpRbp2yVwZXxa3MhW8EejYnrvL6YG xl0KXYycHBICJhLnW6+wdDFycQgJ7GWUuNp7lrWLkQMssfYHE0T8IKPE4r8rWEEaeAUEJX5M vscCUsMsIC9x5FI2SJhZQFri0d8Z7BBhdYkpU3IhWn8xSpzsewvWKiwgKdF95w4ziM0ioCpx 599ZMJtNQEvi7e12sLUiAsoSy2exQowsk/j/u58FojVAYsX7pywQFxhIvL9+mRFi/m5GiT2/ b4ElOAVsJU7v+cwEYosCzfl7+B7YXxICl9kkOj/PZJzAKDILyQuzEF6YheSFWQgvLGBkWcUo lJuYmaObmWeql1hQkJOql5yfu4kRFBnT7YR3MJ5eZXWIUYCDUYmHd8dRzQgh1sSy4srcQ4zS HCxK4rwcXFoRQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhZ/ItKSrmbFzycd0rn0b+HC00v S4Ydy6vqe9saWvFTrN5e5G3Apti3pWEbZ5ub/H2ZnT37yey3t95tW/d1XkF6asqco6dWbDyi M/mJb1LMnQsH75r8jRAuOrlEI+7I/YBvr8pMRdaWM5zl1Ns5SaBAm01S3l5OreGA8EEpsaTZ PSGe5+7mrhNXYinOSDTUYi4qTgQAUUJFOG0CAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUi2FAcoPtum1aEwe99bBYrz61gtrj3YRqj xefV19kcmD12zrrL7rFkyU8mj1fHvrMEMEdx2aSk5mSWpRbp2yVwZXxa3MhW8EejYnrvL6YG xl0KXYwcHBICJhJrfzB1MXICmWISF+6tZ+ti5OIQEjjIKLH47wpWkASvgKDEj8n3WEDqmQXk JY5cygYJMwtISzz6O4MdIqwuMWVKLkTrL0aJk31vwVqFBSQluu/cYQaxWQRUJe78Owtmswlo Sby93c4K0isioCyxfBYrxMgyif+/+1kgWgMkVrx/ygJxgYHE++uXGSHm72aU2PP7FliCU8BW 4vSez2D3iwLN+Xv4HssERqFZSK6ehXD1LCRXz0K4egEjyypGgaLUnMRKU73EgoKcVL3k/NxN jOAAL4zYwfh/mdUhRgEORiUeXoETmhFCrIllxZW5hxglOJiVRHhltmpFCPGmJFZWpRblxxeV 5qQWH2JMBnp3IrOUaHI+MPrySuINTUwMTIyNzYyNzU3MSRNWEuc1FwVaIZCeWJKanZpakFoE s4WJg1OqgZEpoK72wqZy5zvZL5lz/4nVCPnUbmspmG2g7XHw17YVrk8TvjaWP/mgIy6x3cp5 x0fV+F9cypfOahkJ7/F/NnvfmWsCU93NLvNzzLhU8OMYZ/jxhYXLjvsxM0xbdq/N9lmhdZ3M Te6woqmblrrfYbEw55rX6DbtX9LhjZtkkr72XvxpoHfSvUOJpTgj0VCLuag4EQDrMPtBtAIA AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/PDPIlyz3o18YklezAx4_hmBL_h8>
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: Tue, 15 Nov 2016 07:19:12 -0000

Hello,

On 14/11/16 - 06:14:17, Alan Ford wrote:
> Hi all,
> 
> After discussion at IETF97, I think it’s clear that this proposal - the
> idea of “priority” - means different things to different people. For
> example:
> 
> a) A percentage split - but would that only kick in when one link is full?
> Or would all traffic always be split?
> b) Prioritising subflows, overflowing only when one is full
> c) QoS (latency, bandwidth, etc) values
> d) etc etc
> 
> Personally I think only (b) makes sense at the subflow level, everything
> else is far too complex to signal in a few bits. Whether it is of use to
> people in the real world, however, I don’t know, however!

I agree with you that signalling priorities in the sense of (b) is not
necessarily useful. Because, at the end it is then still left to the
decision of the implementer on how he translates the priorities into
scheduling.

I think that one missing piece in MPTCP today is the lack of control a
host can exercise on how the peer should schedule its traffic.

The backup-bit only enables seamless handover. But MPTCP's benefits go
beyond that. Especially for applications sending a thin stream, the delay
benefits can be huge (as has been mentioned in the IETF journal article), if
the scheduling takes RTT into account (while minimizing cell usage for power
& cost reasons).

Allowing to signal this will be a bigger exercise, but I believe
that it is necessary if we want longterm to go to a world where a client can
connect to any webserver (of any implementation) and use MPTCP.

> 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.

Ignoring potential issues with changing the window-sizes or using ECN for a
moment. Using such tricks would only work for bulk transfers. Thin streams
won't be able to reduce/increase the amount of traffic on the secondary subflow.


Cheers,
Christoph

> 
> This proposal needs a much clearer idea of what it’s trying to achieve
> before we could consider it for merging.
> 
> Regards, Alan
> 
> > On 14 Nov 2016, at 01:58, Fabien Duchêne <fabien.duchene@uclouvain.be>
> > wrote:
> > 
> > Hello,
> > 
> > Inline,
> > 
> > On 11/13/2016 08:51 AM, Christoph Paasch wrote:
> >> Hello, 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.
> > The way I wrote the draft was more like "ok, let's tell the server that,
> > if possible, I'd like to receive most on the trafic on this subflow,
> > then this one, then this one".  This is why I wrote
> > 
> > "The priority field MUST be interpreted as an unsigned integer value
> > with the highest numerical value being the most preferred one."
> > 
> > While I agree that we should be as specific as possible, I wonder how we
> > could be more explicit about this. Any idea?  If we are too specific,
> > like saying "always schedule on the highest priority subflow, until the
> > windows is full, then skip to the next one" we are actually writing a
> > strict priority scheduler, and I was hoping that we could leave the
> > priority open to more creative ways of handling the priorities.  It's a
> > MAY because I'm not sure that making the respect of the priority a MUST
> > would be interesting, for backward compatibility, but also because the
> > priorities of one host could clash with the other's own interest.
> > 
> >> 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
> >> 
> > Cheers!
> > 
> > Fabien
> > 
> > _______________________________________________ multipathtcp mailing
> > list multipathtcp@ietf.org <mailto:multipathtcp@ietf.org>
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> > <https://www.ietf.org/mailman/listinfo/multipathtcp>

> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp