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

[Christoph Paasch <[e-mail]>]

Hello,

On 06/11/16 - 13:33:56, Fabien Duchêne wrote:
> Hello,
> 
> As we agreed in Berlin during IETF96, here are a few email to discuss
> the contributions proposed in
> https://datatracker.ietf.org/doc/draft-duchene-mptcp-add-addr/
> 
> The backup mode defined in RC6824 only supports an "all-or- nothing"
> mode in the usage of
> the subflows, where an host might just prefer to use certain subflow 
> over others.
> To allow an host to inform the receving host about its preference in
> terms of subflow usage, we propose to modify the ADD_ADDR option by
> adding 3 "priority" bits.
> A host receving a priority for a sub MAY use this information in it's
> scheduling decisions.
> 
> To allow the priority of an already established subflow to be modified,
> we propose to modify the MP_PRIO option by adding the 3 priority bits
> next to the "B" flag.
> 
> For the moment, the priority field is interpreted as an unsigned integer
> with the highest numerical value being the most preferred one, but this
> is up to discussions, but this point is up to discussion.

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.

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