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

[Yoshifumi Nishida <[e-mail]>]

Hi Kangjiao,

Thanks for the response.
I put my comments in lines.

On Sun, Jul 19, 2020 at 8:54 PM Kangjiao <[e-mail]> 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.
>

I think It would be better if you can show more concrete examples for the
scenario in the draft.
I would like to use the example in Section 3.2 of the draft for this. (BTW,
I personally prefer to use IP_C1 or IP_S1 or C1, S1 rather than IP1, IP2 so
that it will be easy to understand which address belongs to client or
server)
If the server sends MP_PRIO with B flag to the client by using <IP1, IP3>
and <IP2, IP3>, I think the client will send traffic to IP4. Isn't this
what the server wants?

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

Well, let's say the server wants to use 5G because it's beneficial for
them, but the client doesn't want to use it because it's costly.
The client still should follow the server's request?

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

Got it. Thanks for clarification. I think you'd better put these info into
the draft later.

Thanks,
--
Yoshi


>