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

[Alan Ford <[e-mail]>]

Hi Christoph,

> On 15 Nov 2016, at 07:19, Christoph Paasch <[e-mail]> wrote:
> 
> 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.

So what semantics would you assign to the priorities? Or are you saying we should leave that up to implementors"

“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? For interop, when you don’t know what the far end will do with this information, would it be useful?

Are there any fundamentals we could/should specify?

Regards,
Alan