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

[Martyn Russell <[e-mail]>]

Hi all,

On 15/11/2016 16:19, Christoph Paasch 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

>From my understanding of RFC6824 in it's current form, the priority does depend on different use cases of the subflows, which is why it will mean different things to people using the MP_PRIO API. The spec currently talks about 2 such cases. The default case being simultaneously sending data over all subflows, but goes on to talk about an "all-or-nothing" failover subflows.

I think if these use cases are all we care about then that's fine and sufficient. But the spec does suggest possible line prioritisation by cost too. In that situation, I believe the spec needs improving because often you don't want all or nothing on subflows which has a premium/cost attached to it.

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, but I think there will be an appetite for more use cases than the priority is currently sufficient for.


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

--
Regards,
Martyn

-- SHAREDBAND EMAIL DISCLAIMER --
Email Disclaimer: http://sharedband.com/email-disclaimer<http://sharedband.com/email-disclaimer/>

Shared Band Ltd T/A Sharedband
Registered in England No 04861356, VAT No GB822654826
Registered Office: 40 Princes St, Ipswich, Suffolk, IP1 1RJ UK