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

Hi,

we are happy with a solution with the characteristics of (b) for the moment, not sure whether other use cases would need something else. Plus we had a lot of discussions on what „full“ would mean spcifically.

Marcus

Von: multipathtcp <multipathtcp-bounces@ietf.org> im Auftrag von Alan Ford <alan.ford@gmail.com>
Datum: Montag, 14. November 2016 um 07:14
An: Fabien Duchêne <fabien.duchene@uclouvain.be>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Betreff: Re: [multipathtcp] Multipath TCP Address advertisement 4/5 - Priorities

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

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 <fabien.duchene@uclouvain.be<mailto:fabien.duchene@uclouvain.be>> 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
multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
https://www.ietf.org/mailman/listinfo/multipathtcp