Re: [Detnet] About the E2E latency of C-SCORE

peng.shaofu@zte.com.cn Mon, 25 March 2024 02:14 UTC

Return-Path: <peng.shaofu@zte.com.cn>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5224BC14F70C for <detnet@ietfa.amsl.com>; Sun, 24 Mar 2024 19:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, 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 WsJjV9N-khOR for <detnet@ietfa.amsl.com>; Sun, 24 Mar 2024 19:13:58 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8E2C14F70B for <detnet@ietf.org>; Sun, 24 Mar 2024 19:13:55 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4V2xLl1DjSz8XrRP; Mon, 25 Mar 2024 10:13:51 +0800 (CST)
Received: from njy2app03.zte.com.cn ([10.40.13.14]) by mse-fl1.zte.com.cn with SMTP id 42P2Dhnh002763; Mon, 25 Mar 2024 10:13:43 +0800 (+08) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njb2app06[null]) by mapi (Zmail) with MAPI id mid201; Mon, 25 Mar 2024 10:13:44 +0800 (CST)
Date: Mon, 25 Mar 2024 10:13:44 +0800
X-Zmail-TransId: 2afe6600ddd8ffffffff863-9c0ce
X-Mailer: Zmail v1.0
Message-ID: <20240325101344631CGIqDQaKtgM0U_AobPGAi@zte.com.cn>
In-Reply-To: <CA+8ZkcTdyx7cC5G3EFwbKDH6zioStk8=Ynd7Sb7CCAHHsQYUmg@mail.gmail.com>
References: 202403221535396660460@zte.com.cn, CA+8ZkcTdyx7cC5G3EFwbKDH6zioStk8=Ynd7Sb7CCAHHsQYUmg@mail.gmail.com
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: jjoung@smu.ac.kr
Cc: detnet@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 42P2Dhnh002763
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6600DDDF.000/4V2xLl1DjSz8XrRP
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/tF31losHQenjJa8jOXE0WX9nEtw>
Subject: Re: [Detnet] About the E2E latency of C-SCORE
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2024 02:14:02 -0000

Hi Jinoo,

Thanks for your confirmation.
We have reached the consensus for this point, i.e.,  worst-case per-hop latency is L/r.

Based on that, perhaps I can further understand worst-case per-hop latency as packet interval.
For example, considering a flow with TSpec: packet size L and sending a packet per time duration d.
It will consume the bandwidth: r = L/d. 
Thus, L/r = d, that is the flow's packet interval and the delay level treatment enjoyed by that flow. 
Here, d seems not be explicitly affected or determined by the network. In other words, it may be challenge for the network to explicitly provide different delay level treatment for different flow, e.g, n flows each with the same TSpec: packet size L and rate r, where n*r = C, and C is the link capacity. In this example, C-SCORE will provide the same worst-case latency L/r = n*L/C for each flow, but that treatment may not be the expected RSpec of the individual flow. 
However, C-SCORE may meet the case that application has not the requirement of customized E2E delay.  : )

Regards,
PSF


Original


From: JinooJoung <jjoung@smu.ac.kr>
To: 彭少富10053815;
Cc: detnet@ietf.org <detnet@ietf.org>;
Date: 2024年03月24日 09:41
Subject: Re: [Detnet] About the E2E latency of C-SCORE

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet


Hello Shaofu,
Yes, you are correct.
The SLi is the decisive factor in node i.

However,
SLi = Lmax_i/Ri + L/r.

And L/r is much larger than Lmax_i/Ri.
Thus, according to the definition of "per-hope dominant factor", which is the largest sum term,
the per-hop dominant factor is L/r.

Best,
Jinoo




On Fri, Mar 22, 2024 at 4:35 PM <peng.shaofu@zte.com.cn> wrote:



Hi Jinoo,

Thank you for patiently explaining the latency of C-SCORE during the meeting. 
I just check the E2E latency equation provided in draft-joung-detnet-stateless-fair-queuing-02, it is:
    Dh(p) <= (B-L)/r + SL0 + SL1 + ... + SLh,     (5)

Now I realize that we are talking about different things.
The PBOO (pay bursts only once) you mentioned is actually (B-L)/r, right ?
But I (and maybe there are other people who also pay more attention to the worst-case latency per-hop), am more concerned about SL0 + SL1 + ... + SLh, that is actually an evaluation formula based on the worst-case latency per-hop multiplied by the number of hops.

IMO, (B-L)/r is negligible, especially when the flow is policing on the network entrance node and B = L.
That is, the worst-case per-hop latency SLi on each node i is the dominator factor.

Please correct me if I have any misunderstanding.

Regards,
PSF