Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00

Hello,

as an overall comment, I agree that one of the difficulties around multipath
is how the hosts can communicate to the peers the desired scheduling
mechanisms. Currently there is no reliable way besides backup-bits which is
a "hard" switch. However, often scheduling is much more fine-grained as
shown in a number of the schedulers described in
https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-00.

It's a bit similar to TCP which can't pick the peer's congestion-control and
for example if one wants the peer to use a background-CC the host needs to
resort to tuning the receive-window a la draft-bagnulo-iccrg-rledbat-00.

So, having a way to communicate the scheduling "requirements" to the peer
(and let the peer match these requirements with its local policies), would
be good!

One more comment inline:

On 07/20/20 - 03:54, Kangjiao wrote:
> Hi Yoshi,
> 
> Thanks for your suggestions. We clarify the issues as below:
> 
> 1: One thing I'm not very clear is why we cannot use MP_PRIO for the use
> cases described in the draft. I believe the draft should describe the
> cases where existing features cannot fulfill the requirements more
> specifically.
> 
> KJ: The new MP_Navigation Option is used for the server to indicate
> destination network interface to client for which server wants to use for
> traffic switching. For my understanding, MP_PRIO is used to signal a
> change in priority of subflows to the peer. In application, MP_PRIO can
> reduce the chance of data transmission on a specific subflow but it cannot
> tell its peer which network interface is the destination from server side.
> For example, if there are multiple subflows with high priority from
> difference network interfaces, client receiving MP_PRIO does not know
> which is the target one.

For this particular scenario the server could send the MP_PRIO with backup-bit
set on all subflows that the client should not use. Thus implicitly the
high-priority network-interfaces can then be used by the client, right?

Christoph

> 2: Clients also have their own constraints. (e.g. policy or routing) So,
> even though servers send a navigation request, they might not follow it. I
> think this point should be clarified.
> 
> KJ: If the mechanism of accurate-data-scheduling-by-server is deployed,
> the principle is that the server takes precedence.
> 
> 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1?
> 
> KJ:  For the protocol design, the definition of ’r’, ‘E’ and ’B’ are as
> following: Flag ‘r’: reserved for future usage.  Flag ‘E’: exists to
> provide reliability for this option (like that in ”ADD_ADDR”).  Flag ’B’:
> indicates whether the subflow over which the option is received is a
> backup one (that is compatiable with the value by MP_PRIO).
> 
> But we are thinking whether these fields are necessary and should be set
> as mandatory.
> 
> Sincerely, Jiao From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Yoshifumi Nishida Sent: Sunday, July 19, 2020 7:26 PM To: tcpm@ietf.org
> Extensions <tcpm@ietf.org> Subject: [tcpm] comments on
> draft-kang-tcpm-accurate-data-scheduling-by-server-00
> 
> Hi, I've read draft-kang-tcpm-accurate-data-scheduling-by-server-00.  I
> think this is an interesting topic for mptcp, but I think it would be
> better to clarify the following points.
> 
> 1: One thing I'm not very clear is why we cannot use MP_PRIO for the use
> cases described in the draft. I believe the draft should describe the
> cases where existing features cannot fulfill the requirements more
> specifically.
> 
> 2: Clients also have their own constraints. (e.g. policy or routing) So,
> even though servers send a navigation request, they might not follow it. I
> think this point should be clarified.
> 
> 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1?
> 
> Thanks, -- Yoshi

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