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

[Christoph Paasch <[e-mail]>]

Hello Alan,

On 15/11/16 - 09:36:48, Alan Ford wrote:
> > On 15 Nov 2016, at 07:19, Christoph Paasch <[e-mail]> 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
   subflow.


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.



Christoph