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

Kangjiao <kangjiao@huawei.com> Thu, 23 July 2020 02:00 UTC

Return-Path: <kangjiao@huawei.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885E63A0B26 for <tcpm@ietfa.amsl.com>; Wed, 22 Jul 2020 19:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhKSOPUADSm2 for <tcpm@ietfa.amsl.com>; Wed, 22 Jul 2020 19:00:56 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E453A0B23 for <tcpm@ietf.org>; Wed, 22 Jul 2020 19:00:55 -0700 (PDT)
Received: from lhreml732-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4FD19C581BA8D79C568B; Thu, 23 Jul 2020 03:00:54 +0100 (IST)
Received: from lhreml732-chm.china.huawei.com (10.201.108.83) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 23 Jul 2020 03:00:54 +0100
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 23 Jul 2020 03:00:53 +0100
Received: from DGGEMM534-MBS.china.huawei.com ([169.254.7.122]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0487.000; Thu, 23 Jul 2020 10:00:41 +0800
From: Kangjiao <kangjiao@huawei.com>
To: Christoph Paasch <cpaasch@apple.com>, Yoshifumi Nishida <nsd.ietf@gmail.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
CC: Liangqiandeng <liangqiandeng@huawei.com>
Thread-Topic: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00
Thread-Index: AQHWXb+HJHOpbU0oSkKL2jMMYvRPV6kP1fbAgAHYVoCAAryHoA==
Date: Thu, 23 Jul 2020 02:00:41 +0000
Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com>
References: <CAAK044TfEz73MohX3hMBPSqqB9gGHvh6FtCdh8NykbLMHDsDmA@mail.gmail.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2C@dggemm534-mbs.china.huawei.com> <20200721155945.GA93692@MacBook-Pro-64.local>
In-Reply-To: <20200721155945.GA93692@MacBook-Pro-64.local>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.67.102.89]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/yvcT9GnEjRWhO1ehltmSny06EMs>
Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2020 02:00:58 -0000

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.

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>om>; tcpm@ietf.org Extensions <tcpm@ietf.org>rg>; 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