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

[Christoph Paasch <[e-mail]>]

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 <[e-mail]>
> > 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 [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> > <https://www.ietf.org/mailman/listinfo/multipathtcp>

> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp