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

Christoph Paasch <> Tue, 15 November 2016 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A304E129471 for <>; Tue, 15 Nov 2016 09:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.799
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VKW5rV6rDy5r for <>; Tue, 15 Nov 2016 09:43:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E06D128E19 for <>; Tue, 15 Nov 2016 09:43:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1479231779; 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=Ds6TDCQwGfFjAbXqg79QQcFA1SHazRRafLAX891ZF14=; b=0nE1QOzKjC2Burd0pXHftmLjbEU8DuftiRtIwXHyFNdN1Ep0khE5MNTbBs113f2d retTRlS6CpMfq4zZP6Sam8EaOkgkB/FJ6DC5oomD4xhKC9c/DJyFD9pXx0MaZcXB AaKMkSnH0xSvavYgYBw/mZPNXyRp0OE0uAeChIk8TImUpqIdhe+0CKgskDp9fzeN TngXID1aKfBDTPxJNVyDau4Ao/Npt8bQyr/MbcpHVrKqZtKmPtNXfnjcanDXF9ZL gwIOwzO6a3ukOHiaAUrFFvNE2Gco/l74oo/3f4gKHvINu6mQXMH+RNRGrdTOA1Rn tK1+4BSJ+jvTtYmmlAUlYQ==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 84.2E.18952.3294B285; Tue, 15 Nov 2016 09:42:59 -0800 (PST)
X-AuditID: 11973e12-7490c9a000004a08-ce-582b4923cf74
Received: from ( []) by (Apple SCV relay) with SMTP id C0.6E.23613.3294B285; Tue, 15 Nov 2016 09:42:59 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-disposition: inline
Content-type: text/plain; charset="utf-8"
Received: from localhost ([]) by (Oracle Communications Messaging Server 64bit (built Jun 15 2016)) with ESMTPSA id <>; Tue, 15 Nov 2016 09:42:59 -0800 (PST)
Date: Tue, 15 Nov 2016 09:42:59 -0800
From: Christoph Paasch <>
To: Alan Ford <>
Message-id: <20161115174259.GY4269@Chimay.local>
References: <> <20161113075145.GH4269@Chimay.local> <> <> <20161115071909.GV4269@Chimay.local> <>
In-reply-to: <>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FAYpavsqR1hcHu3ucXKcyuYLe59mMZo 8Xn1dTYHZo+ds+6yeyxZ8pPJ49Wx7ywBzFFcNimpOZllqUX6dglcGZ2TTzIXfJGrOLb6B2MD 4xSJLkZODgkBE4mzZ3vZuhi5OIQE9jJK/Nv/gB0m0fDqEQtE4hCjxJdNU1lBErwCghI/Jt8D SnBwMAvISxy5lA0SZhaQlnj0dwY7RFhdYsqUXIjWX4wSbz+dYwapERaQlOi+cwfMZhFQldj/ +w8LiM0moCXx9nY7K0iviICyxPJZrBAjyyT+/+5ngWgNkFjx/ikLxAUGEluvdzKC2EICU5kk 5izhArE5BWwlvqycDFYjCjTm7+F7YOdLCKxgkzj5+gTzBEaRWUg+mIXwwSwkH8xC+GABI8sq RqHcxMwc3cw8E73EgoKcVL3k/NxNjKDImG4ntIPx1CqrQ4wCHIxKPLweqtoRQqyJZcWVuYcY pTlYlMR531oChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDyzph6N6NcZsISHeMP+ce8jspv Vvc9yKVscpar61d4bxHb3O1rl/PvOc429+2f1eJVtU16IokLf70Ln2v4OKB5rkR95cTnGtPj ex9EswedEfuQMtdx3Vx3lnV7lz03K9UUFpI6cfatEItal7zJRobsZ1JnSxWXrr7wv8BEI/SJ jant/qAlh5uUWIozEg21mIuKEwExL3aHbQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUi2FB8Q1fZUzvC4NoKfYuV51YwW9z7MI3R 4vPq62wOzB47Z91l91iy5CeTx6tj31kCmKO4bFJSczLLUov07RK4Mjonn2Qu+CJXcWz1D8YG xikSXYycHBICJhINrx6xQNhiEhfurWfrYuTiEBI4xCjxZdNUVpAEr4CgxI/J94CKODiYBeQl jlzKBgkzC0hLPPo7gx0irC4xZUouROsvRom3n84xg9QIC0hKdN+5A2azCKhK7P/9B2wXm4CW xNvb7awgvSICyhLLZ7FCjCyT+P+7nwWiNUBixfunLBAXGEhsvd7JCGILCUxlkpizhAvE5hSw lfiycjJYjSjQmL+H77FMYBSaheToWQhHz0Jy9CyEoxcwsqxiFChKzUmsNNNLLCjISdVLzs/d xAgO8MKoHYwNy60OMQpwMCrx8HqoakcIsSaWFVfmAgOIg1lJhJffEijEm5JYWZValB9fVJqT WnyIUZqDRUmc11xUK0JIID2xJDU7NbUgtQgmy8TBKdXAGL9LQ/yCutCEF9OX7jGU7A+6ty/u itrEc6aMirtcZ7HeN1d71Wjlxrei3nn2uQzFy8dSb3jwbCmQbZWemF/9mfOf3MnbATcfa0fH 122aKlBgLjGPc0VGVxGvHH+loQfzJt2SqUJLBUozHL8cypoT9b5HZZ6Y94yCU48MmaTaj5g+ lj66Im2aEktxRqKhFnNRcSIAdHRMo2wCAAA=
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 4/5 - Priorities
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Nov 2016 17:43:01 -0000

Hello Alan,

On 15/11/16 - 09:36:48, Alan Ford wrote:
> > On 15 Nov 2016, at 07:19, Christoph Paasch <> wrote:
> > On 14/11/16 - 06:14:17, Alan Ford wrote:
> >> 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.
> So what semantics would you assign to the priorities? Or are you saying we should leave that up to implementors"

Just to make sure that there isn't a misunderstanding: I think we need a
richer signaling than priority-bits.

Personally, I would know what kind of semantics I would assign to each bit,
because I control both client and server. But that's the model I believe we
should not target for.

> “This defines the priority of each subflow with relation to each other; how a receiver of this option translates this into the scheduling is implementation-specific."
> Is that useful to you as an implementor, do you feel?

This depends. If the implementor has a very specific use-case and client in
mind, it will be useful.
For someone who wants to implement a generic-purpose implementation it will
be hard to decide.

> For interop, when you don’t know what the far end will do with this information, would it be useful?

Yes, that's my point. I don't think it will be useful for interop.

> Are there any fundamentals we could/should specify?

I think there are a few use-cases (there are probably many more and it would
be good to complete the list):

1. Thin-streams that require low latency:

   Here a client would like to tell the server what threshold (in terms of
   delay) should trigger use of the secondary subflow. This threshold could
   be expressed in milliseconds or relative to the RTT of the primary

2. Bulk-transfers that have a certain bitrate requirement:

   Here a host would like to the tell the peer this bitrate. The peer will
   then only use the secondary subflow if it can't satisfy the bitrate on
   the primary subflow.

   Instead of expressing this as a bitrate, expressing it as a "deadline"
   might be good as well. For example when streaming a video over HTTP, each
   chunk has a certain deadline at which point it should reach the receiver
   to avoid rebuffering of the video.

3. Transfers (thin and/or bulk) that just require reliability:

   The backup-bit does its job here in this scenario.