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

[Kangjiao <[e-mail]>]

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.

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:[e-mail]] On Behalf Of Yoshifumi Nishida
Sent: Sunday, July 19, 2020 7:26 PM
To: [e-mail] Extensions <[e-mail]>
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