[Detnet] Validity of Deadline based forwarding

Jinoo Joung <jjoung@smu.ac.kr> Mon, 13 November 2023 11:21 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 48534C14CE33 for <detnet@ietfa.amsl.com>; Mon, 13 Nov 2023 03:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 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] 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 cKDgp9b6xBOL for <detnet@ietfa.amsl.com>; Mon, 13 Nov 2023 03:20:58 -0800 (PST)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 BC0C7C14CE2B for <detnet@ietf.org>; Mon, 13 Nov 2023 03:20:57 -0800 (PST)
Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-1cc131e52f1so38880635ad.0 for <detnet@ietf.org>; Mon, 13 Nov 2023 03:20:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smu-ac-kr.20230601.gappssmtp.com; s=20230601; t=1699874457; x=1700479257; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=fWmdbWpnsHKOtf6ZeTcOX3fVNK8lxhxHU2l1yIDMpl4=; b=w5JrpoDBAXPojw0CsC/EWXy/ccbKjRxsHkft/MTqaiumAkjCmcBHwcI/KYcURi1MOh 4z6NMneGRm8UWJeadi2aYui1qlNa5Ejm8LC6IJDa0VUVTPLMHBoXRjdQHe9GkiM69ngh xbiykEUFdEkzCmyN+KorGPYaut3yXVLplgMlYjpYSzo8bYLjhpBVDMHKzkWP0g5kss8t bPeIAmSkFx+sRHrsgwDqQRMqqFiw0sSfWgyirSvGhw6XBm0FZijftkBn8Ju5+tntYdpM 3tm6knU0OyAbCxmUU4jgNIf2kV38/WDo8RvrrC5Qq4Go81jlWrYDoeFxk5iG9U7o3P2F s+KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699874457; x=1700479257; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fWmdbWpnsHKOtf6ZeTcOX3fVNK8lxhxHU2l1yIDMpl4=; b=QTYkAgANc4ajMUYnviScvoNv7yENP/ffeMjZO9ToSl+RshkDLinQjPiFL0pbEgpWaw nkkZUUbJFuSvYOisAiPJDXJjXUIcFzBECESna9zi0j2eqcXe9XvA+lzL4K0g/ElfzFzk GTFUIwhlOm737TTcb3455crH+Mqev7B5syIsw/VHRAkjbVVJWm3bE8EjPapKITxrZy+K aLlwJt0L5xm295imeBjz2gNLaCRvMRhvarQBqDfeFRcCffIXX3OR+Dz+lPphgHj02YPi Xuq+2GbcOhNet02wM/BOxAjZQAa7SyynNxql7CYXfjPYdbAvJSD4K4TfUofWryAs9/dH Ai7A==
X-Gm-Message-State: AOJu0YxOhL+oiYNTokkWm/Op98LOKacyUmFAK4cibi4/4EMLGIdjHs73 hO0iE7Zr55/iDXPbMQumFSagvKLvjOC0J9c0WS8mAG/TT8fs9C5Lv5c=
X-Google-Smtp-Source: AGHT+IFt5brw/c6UivOQlBoiMai37jv5rZ9C6lcrBOQJP9I1Pu/Qw/gMZcdci6gH1z1U7zcKJsDCk0d8LsKz1YaF7DA=
X-Received: by 2002:a17:90b:4b04:b0:280:735:bece with SMTP id lx4-20020a17090b4b0400b002800735becemr9028127pjb.16.1699874456728; Mon, 13 Nov 2023 03:20:56 -0800 (PST)
MIME-Version: 1.0
From: Jinoo Joung <jjoung@smu.ac.kr>
Date: Mon, 13 Nov 2023 20:20:45 +0900
Message-ID: <CA+8ZkcQnv7tYJMwtJsNzJCSy1WCUtbVtFzdEPsnEaBGARC0cTg@mail.gmail.com>
To: DetNet WG <detnet@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002815a1060a06dd38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/wcBzfEKFVGboOxnHmXw7G-75tBY>
Subject: [Detnet] Validity of Deadline based forwarding
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, 13 Nov 2023 11:21:03 -0000

Hello Shaofu,

I have a question for clarification on the admission criteria (or the
schedulability condition) of the Deadline based forwarding.
Let's consider only the In-time mode operation with PIFO implementation,
for simplicity.

According to your draft, the admission is decided based on Equation 1,
which is
sum{A_i(t-d_i) for all i} <= C*t,
where A_i(t) is the arrival constraint function of the flow i.
In the flow entrance node, this A_i(t) can be obtained from the flow
specification (with max burst and arrival rate).

However, A_i(t) changes as the flow traverses hops, because of the burst
accumulation.
How it will change is difficult to know, since it is a function of other
flows' parameters as well.
Thus, in Options 1 and 2, you suggested the shaping (or regulation)
function to be used in core nodes,
to enforce A_i(t) to become the initial arrival process,
so that we can test the admission condition (Equation 1) even in core nodes.

Unfortunately, this approach needs per-flow state maintenance, therefore
not scalable.
So, in Options 3 and 4 you suggested the "Latency compensation", as an
alternative solution to the shaping.

How can this latency compensation apply to Equation 1, or
how do you check the admission condition in Option 3 or 4?

I suspect that the latency compensation does not make Equation 1 to be
usable in core nodes.
By utilizing the delay budget obtained from the previous nodes,
the latency compensation can only make more packets "eligible".
It is also unclear how to distinguish eligible and ineligible packets, but
it is not important to me.

As you have specified in the presentation slides,
if some of the packets become ineligible with Option 3 or 4,
then these packets will be served later than the eligible packets,
and are not guaranteed latency bounds.
But it is not the packets' faults to become ineligible.

Can you still say Option 3 or 4 is a suitable solution?

Best regards,
Jinoo