[ippm] Re: comments on draft-shi-ippm-congestion-measurement-data
"Shihang(Vincent)" <shihang9@huawei.com> Wed, 16 October 2024 11:25 UTC
Return-Path: <shihang9@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B504CC15107F; Wed, 16 Oct 2024 04:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkTJPo1HOeWD; Wed, 16 Oct 2024 04:25:08 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF6DC14F71D; Wed, 16 Oct 2024 04:25:08 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XT7rD609Lz6GBxs; Wed, 16 Oct 2024 19:23:24 +0800 (CST)
Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 4F8CF1400D9; Wed, 16 Oct 2024 19:25:05 +0800 (CST)
Received: from kwepemf100011.china.huawei.com (7.202.181.225) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 16 Oct 2024 12:25:04 +0100
Received: from kwepemf100010.china.huawei.com (7.202.181.224) by kwepemf100011.china.huawei.com (7.202.181.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 16 Oct 2024 19:25:02 +0800
Received: from kwepemf100010.china.huawei.com ([7.202.181.224]) by kwepemf100010.china.huawei.com ([7.202.181.224]) with mapi id 15.02.1544.011; Wed, 16 Oct 2024 19:25:02 +0800
From: "Shihang(Vincent)" <shihang9@huawei.com>
To: 赵广宇 <zhaoguangyu@chinamobile.com>, draft-shi-ippm-congestion-measurement-data <draft-shi-ippm-congestion-measurement-data@ietf.org>
Thread-Topic: RE: [ippm] comments on draft-shi-ippm-congestion-measurement-data
Thread-Index: AQHbH6u7I0q9dJRTcEu1KUctiV4p0bKJPEzA
Date: Wed, 16 Oct 2024 11:25:02 +0000
Message-ID: <e1e3533a82904b798c6498218799ee62@huawei.com>
References: <20241016171343564759296@chinamobile.com>
In-Reply-To: <20241016171343564759296@chinamobile.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.41.128]
Content-Type: multipart/alternative; boundary="_000_e1e3533a82904b798c6498218799ee62huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: D5D67Z5WTOAJJ2NBOBSHZ2AZ2J6PBFH2
X-Message-ID-Hash: D5D67Z5WTOAJJ2NBOBSHZ2AZ2J6PBFH2
X-MailFrom: shihang9@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ippm <ippm@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [ippm] Re: comments on draft-shi-ippm-congestion-measurement-data
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/LDVDKRM6_BJ8hNAUUDChNEgdUuA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Owner: <mailto:ippm-owner@ietf.org>
List-Post: <mailto:ippm@ietf.org>
List-Subscribe: <mailto:ippm-join@ietf.org>
List-Unsubscribe: <mailto:ippm-leave@ietf.org>
Hi Guangyu, You formula looks good to me. I have incorporated your suggestion into the revised document. https://datatracker.ietf.org/doc/draft-shi-ippm-congestion-measurement-data/ Please take a look at it. Thanks, Hang From: 赵广宇 <zhaoguangyu@chinamobile.com> Sent: Wednesday, October 16, 2024 5:14 PM To: Shihang(Vincent) <shihang9@huawei.com>; draft-shi-ippm-congestion-measurement-data <draft-shi-ippm-congestion-measurement-data@ietf.org> Cc: ippm <ippm@ietf.org> Subject: Re: RE: [ippm] comments on draft-shi-ippm-congestion-measurement-data Hi Vincent, I aggree with your point, available bandwith can be used many scenarios. It's very nice that the firmula ABW = B - T - R*B changes to ABW = B - T - R. That way, it has greater applicability. The explanation for B can also be explanded, " In some cases, B can represent the bandwidth that is reserved or allocated for specific services or tenants." Thanks ——————————————— zhaoguangyu@chinamobile.com<mailto:zhaoguangyu@chinamobile.com> 发件人: Shihang(Vincent)<mailto:shihang9@huawei.com> 时间: 2024/10/16(星期三)16:46 收件人: 赵广宇<mailto:zhaoguangyu@chinamobile.com>;draft-shi-ippm-congestion-measurement-data<mailto:draft-shi-ippm-congestion-measurement-data@ietf.org>; 抄送人: ippm<mailto:ippm@ietf.org>;刘鹏<mailto:liupengyjy@chinamobile.com>;李志强<mailto:lizhiqiangyjy@chinamobile.com>; 主题: RE: [ippm] congestion measurement data's comments Hi Guangyu, Thanks for your comment. Available bandwidth is a useful metric. I can see its value not only in congestion control, but also in load balancing etc. Regarding the calculation of ABW, the formula you proposed(ABW = B - T - R*B) seems like to assume that the reserved bandwidth is proportional to the total bandwidth. However, in some cases, it is desired to be more flexible for bandwidth reservation. How about change it to ABW = B – T – R? In which R is reserved. Or even further, ABW = B – T. in which B is the allocated bandwidth for this service/tenant. Thanks, Hang From: 赵广宇 <zhaoguangyu@chinamobile.com<mailto:zhaoguangyu@chinamobile.com>> Sent: Monday, October 14, 2024 2:53 PM To: draft-shi-ippm-congestion-measurement-data <draft-shi-ippm-congestion-measurement-data@ietf.org<mailto:draft-shi-ippm-congestion-measurement-data@ietf.org>> Cc: ippm <ippm@ietf.org<mailto:ippm@ietf.org>>; 刘鹏 <liupengyjy@chinamobile.com<mailto:liupengyjy@chinamobile.com>>; 李志强 <lizhiqiangyjy@chinamobile.com<mailto:lizhiqiangyjy@chinamobile.com>> Subject: [ippm] congestion measurement data's comments Dear all, I am glad to read the document draft-shi-ippm-congestion-measurement-data(https://datatracker.ietf.org/doc/draft-shi-ippm-congestion-measurement-data/). Measuring congestion information facilitates better network congestion control, and available bandwidth information serves as a crucial congestion signal for network links. It is proposed to add the capability to collect available bandwidth information in the document draft-shi-ippm-congestion-measurement-data. The specific content is as follows: Add the congestion control information - available bandwidth information in table 1. +=====+=========================+========+===========+ | Bit | Congestion Info Data | Length | Operation | +=====+=========================+========+===========+ | 5 | Available Bandwidth | 8 | Min | +-----+-------------------------+--------+-----------+ Add the example: Using available bandwidth in CC The ABW(available bandwidth) of links can be applied in existing CC algorithms to optimize their throughput performance, such as TCP Reno and CUBIC. The sending rate and congestion window can be dynamically adjusted during the CC's slow-start and loss recovery phases.The BBR algorithm, which detects link bottleneck bandwidth based on rate and round-trip time (RTT), can utilize the ABW in AECN to obtain the bottleneck bandwidth of the link and optimize data throughput efficiency. Alternatively, a completely new CC algorithm can be designed based on ABW to predict and avoid congestion in advance. The method for obtaining the ABW of a link can be referenced as follows: a. The sending node can obtain the ABW of its egress port, mark the packet with data fields for ABW Measurement, and then send the packet to the Receiving node. b. Transit Node identify the ABW probe action based on the AECN header, compare the ABW of their egress port with the ABW in the packet. If the ABW of the current node is smaller than that in the packet, it updates to the link's ABW and forwards the packet; otherwise, it directly forwards the packet. c. After receiving the ABW packet, the receiving node parses the link's ABW, constructs an ABW response packet, and sends it back to the sending node. The calculation of the current node's ABW can be referenced as follows: ABW = B - T - R*B where B is the bandwidth of the egress port where the flow passes, T is the traffic size of that egress port, and R is the reserved bandwidth ratio. The reserved bandwidth takes into account the fairness of the CC algorithm, facilitating the entry of newly added flow. The value of R can be set according to the specific circumstances of each node, allowing TOR switches and backbone routers to reserve different percentages of bandwidth. Regards ——————————————— zhaoguangyu@chinamobile.com<mailto:zhaoguangyu@chinamobile.com>