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

On 07/23/20 - 04:38, Kangjiao wrote:
> Hi Christoph,
> 
> From my perspective, I think following are two different requirements:
>  
> 1. Making all the traffic towards S2 (for this case, MP_PRIO may be enough)
> 
> 2. Making traffic only from <IP_C1, IP_S1> to the destination IP_S2, which means diverting traffic that should be scheduled to <IP_C1, IP_S1> to one subflow belonging to the target network interface (it is "on-demand scheduling", for this case, MP_PRIO is not enough)

What is the use-case for such a scheme?

I don't see how a multipath scheduler could assign the traffic that "would"
have been sent to <C1,S1> to a different subflow. Because for that he would
need to know what *would* have been sent on <C1,S1> which he can only know
once he actually sends traffic on that subflow as that will be driving the
congestion-window which will allow to send more (or less) traffic on <C1,S1>.

Christoph

> 
> What do you think?
> 
> Sincerely
> Jiao
> 
> -----Original Message-----
> From: Christoph Paasch [mailto:cpaasch@apple.com] 
> Sent: Thursday, July 23, 2020 11:11 AM
> To: Kangjiao <kangjiao@huawei.com>
> Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>; tcpm@ietf.org Extensions <tcpm@ietf.org>; Liangqiandeng <liangqiandeng@huawei.com>
> Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00
> 
> Hello,
> 
> > On Jul 22, 2020, at 7:01 PM, Kangjiao <kangjiao@huawei.com> wrote:
> > 
> > Hi Christoph and Yoshi,
> > 
> > If I understand right, you both point to the same question whether reusing the MP_PRIO can finish accurate data scheduling for server. I think MP_PRIO may be not enough even if setting all the "non-target" subflows to backup ones. I can give a scenario:
> > 
> > Six subflows have been established between client and server that are <IP_C1, IP_S1>, <IP_C2, IP_S1>, <IP_C1, IP_S2>, <IP_C2, IP_S2>, <IP_C1, IP_S3> and <IP_C2, IP_S3>. The client has IP_C1 and IP_C2. The server has IP_S1, IP_S2 and IP_S3.
> > 
> > Server tool detects that KPI of IP_S2 is better now so the server wants to switch data traffic from <IP_C1, IP_S1> to the destination IP_S2. If we set <IP_C1, IP_S1> as "backup", it is not guaranteed that all the load over <IP_C1, IP_S1> can be diverted to IP_S2 because of the ongoing suflows towards IP_S3.
> 
> But we could simply also set <IP_C1,IP_S3> ans <IP_C2,IP_S3> as backup as well, no?
> 
> Now, all the traffic will be steered towards S2.
> 
> Christoph
> 
> 
> > 
> > So I think MP_PRIO can reduce the chance of data transmission on a specific subflow but it cannot convey the info of target network interface from server to client.
> > 
> > Thanks
> > Jiao
> > 
> > -----Original Message-----
> > From: Christoph Paasch [mailto:cpaasch@apple.com]
> > Sent: Wednesday, July 22, 2020 12:00 AM
> > To: Kangjiao <kangjiao@huawei.com>
> > Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>; tcpm@ietf.org Extensions 
> > <tcpm@ietf.org>; Liangqiandeng <liangqiandeng@huawei.com>
> > Subject: 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
> > 