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

Hello Markus,

On 15/11/16 - 07:49:45, Markus.Brunner3@swisscom.com wrote:
> we are happy with a solution with the characteristics of (b) for the moment, not sure whether other use cases would need something else.

can you give an example of how you would translate the priority-bits into
scheduling decisions?

Thanks,
Christoph

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

> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp