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

Jinoo Joung <jjoung@smu.ac.kr> Mon, 25 March 2024 08:47 UTC

Return-Path: <jjoung@smu.ac.kr>
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 6A912C14F693 for <detnet@ietfa.amsl.com>; Mon, 25 Mar 2024 01:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smu-ac-kr.20230601.gappssmtp.com
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 MElkcXq91O_k for <detnet@ietfa.amsl.com>; Mon, 25 Mar 2024 01:47:15 -0700 (PDT)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC96EC14F696 for <detnet@ietf.org>; Mon, 25 Mar 2024 01:47:14 -0700 (PDT)
Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-29fb12a22afso2734032a91.3 for <detnet@ietf.org>; Mon, 25 Mar 2024 01:47:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smu-ac-kr.20230601.gappssmtp.com; s=20230601; t=1711356434; x=1711961234; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=e8myKg6N4qI4HKtQ0GjbeDq8nX3pAjWcQ8X2t1Rn+OI=; b=VT1ECJC+1oXq82cUAwxoy8jBLmENigHEHgBI4I/88xoCZskFa7cLL3yNEUp/KfV3l2 4TALTMHq4SqHWSqxW0xjmBYkocsFGxrJWzNe/uOjH0C70mtocgIYqKNqR4S5rB1UgIn1 epQHkmtZWHz+yLJEZ7r4FzHIvxZkdbBMTzWnhRw2xSBhiy7/2qr8buXBTT5x+LqPxVY/ q96jbh9dSyPPoJT1gSAYhPIcnaR/c6uC33+AjYs7hPqDfrB7SEMYL6IPsPPtt2gFkY8A 8hNPmfbUAtjgcgZQVXbxgBGJRaIiYe97BYuOdT+ebEwveqaJ86puluFSLMsi5xrFJVlF T+zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711356434; x=1711961234; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=e8myKg6N4qI4HKtQ0GjbeDq8nX3pAjWcQ8X2t1Rn+OI=; b=Y6QO32JarpegJonf9PIQuS7iLKFRdbRIvLZCLcIRuFgvC0Ro9mrVDB2EmPJCs1mw/x 4D7Fe/VUP7JtpN2cPkdN379U6ymj0XreRw/rnRVqogDXdiIcZtcZp56+cbIiI7HbzvAC AnFIpkjzz4M5eMxJ0Lt6ymB0HeoKWY/2G5NYRBJzdzLMq3V+2qcV0KItZr90n8mTP+7l eJjpkmRfjweKyv1pPYJMoENvfC90B+5syEtoJ15MdklTokQfXBxcFdMNpePD/I68wedZ ECJ8e4/tZfbtrahwhtFW3JLkBUz0ajCtXj17x5I2RE4ZTQ9zifzmc2VYMy7oMwl8CiGD MqZA==
X-Gm-Message-State: AOJu0YyMmuSAHK4r9wlxo/WePnZSC0OuCB3z3EQOF7C+1gHdpr6U9uEx 1wY1lMAw/lWO4P0hnYFD6neQtrKsvRAuEEkXO5QH8V4RQluhmwA4mzW96tq/nXqjc3M3WhhMSxa VTywSydRnDBfCyJRYzQJ5bu+iZnE5u7FZu0lbew==
X-Google-Smtp-Source: AGHT+IHb4p1UNnxDyWirX47Xp0gJHhy+f9uemmiZ4cNY6mKRkOpvhcFxtmmySkr+raB7+RIQTEGXoAIGNLWjA/uXJMg=
X-Received: by 2002:a17:90a:dc0c:b0:29a:729a:be2c with SMTP id i12-20020a17090adc0c00b0029a729abe2cmr4323431pjv.21.1711356434094; Mon, 25 Mar 2024 01:47:14 -0700 (PDT)
MIME-Version: 1.0
References: <CA+8ZkcTdyx7cC5G3EFwbKDH6zioStk8=Ynd7Sb7CCAHHsQYUmg@mail.gmail.com> <20240325101344631CGIqDQaKtgM0U_AobPGAi@zte.com.cn>
In-Reply-To: <20240325101344631CGIqDQaKtgM0U_AobPGAi@zte.com.cn>
From: Jinoo Joung <jjoung@smu.ac.kr>
Date: Mon, 25 Mar 2024 17:47:02 +0900
Message-ID: <CA+8ZkcS+eJYXk8Y88dhHQpVUiQMkcit_k3zk4pJkYX=-UMUJbg@mail.gmail.com>
To: peng.shaofu@zte.com.cn
Cc: detnet@ietf.org
Content-Type: multipart/alternative; boundary="00000000000056bd6406147838df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/PMspGIjVZf34LI4Lfgi_E_DqU00>
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 08:47:18 -0000

Hello Shaofu,

As I answered to you during the 119 meeting session,
the latencies can be differentiated by allocating different service rates
(r) to the flows.

Best,
Jinoo

On Mon, Mar 25, 2024 at 11:13 AM <peng.shaofu@zte.com.cn> wrote:

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