Re: [Detnet] Validity of Deadline based forwarding Tue, 14 November 2023 03:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2782C15198F for <>; Mon, 13 Nov 2023 19:25:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y7W7jqYZjrcP for <>; Mon, 13 Nov 2023 19:25:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7C5FC1516F8 for <>; Mon, 13 Nov 2023 19:25:14 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4STs9y0mLNz8XrRJ; Tue, 14 Nov 2023 11:25:10 +0800 (CST)
Received: from ([]) by with SMTP id 3AE3P2FF021183; Tue, 14 Nov 2023 11:25:02 +0800 (+08) (envelope-from
Received: from mapi (njy2app03[null]) by mapi (Zmail) with MAPI id mid201; Tue, 14 Nov 2023 11:25:03 +0800 (CST)
Date: Tue, 14 Nov 2023 11:25:03 +0800
X-Zmail-TransId: 2afb6552e88f3bb-9a07e
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 3AE3P2FF021183
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6552E896.000/4STs9y0mLNz8XrRJ
Archived-At: <>
Subject: Re: [Detnet] Validity of Deadline based forwarding
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Nov 2023 03:25:20 -0000

Hi Jinoo,

Thanks for your reviews and questions. 
Please see inline #PSF.



From: JinooJoung <>
To: DetNet WG <>;
Date: 2023年11月13日 19:21
Subject: [Detnet] Validity of Deadline based forwarding

detnet mailing list

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.
#PSF: In the case of in-time mode, packets may be sent before its deadline, but never exceed its deadline. I know you suspect that this conclusion may not hold true on the intermediate nodes, that's okay. Let's consider this conclusion on the flow entrance node first. I will further explain the behavior on the intermediate nodes later.

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).
#PSF: Yes.

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.
#PSF: Yes. But one thing to note is that the purpose of the re-shaping for a specific flow is to avoid accumulation between multiple bursts of that flow itself, rather than avoiding aggregation from other flows. Burst aggregation (i.e., flow aggregation) is natural, and we need to consider the demand for burst aggregation in the resource reservation process. 

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?
#PSF: In the case of latency compenstation (option 3/4), there is no maintenance of admission conditions for each flow, and also no admission condition check, on the intermediate node. Packets are automatically sorted according to "rank = arrival time + planned residence time (D) + latency deviation (E)" when PIFO used. 

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.
#PSF: As mentioned above, in the case of in-time mode, most arrivals may be ineligible (due to sending before their deadline), so they may have a positive E, and latency compensation will punish the packet to maintain a virtual time interval with the previous packet belonging to the same flow (as the evenly distributed result on the flow entrance node). For example, packet-1 and packet-2 belongs to the same flow, on the flow entrance node, packet-1 sent first, and 100us later packet-2 sent. So the virtual time interval between packet-1 and packet-2 is 100 us. Ideally, packet-1 arrived at a core node, and 100us later packet-2 arrived that core node. However, due to in-time scheduling behavior, packet-2 may imediately arrive when packet-1 arrived (e.g, on all upstream nodes, packet-1 always sent just at its deadline, while packet-2 is lucky to send without queueing delay), in this case, E of packet-2 = E of packet-1 + 100us. Packet-2 will be automatically sorted after packet-1, with a virtual distance of 100us.

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. 
#PSF: An ineligible packet (see the packet-2 in the above example) will certainly be served later than the eligible packet (see the packet-1 in the above example) that belongs to the same flow. However, it is not true between flows, e.g, packet-2 may still be served before the eligible packet-x from other flows because packet-x may have a large planned residence time (D). Note that the relationship between multiple flows is the relationship of burst aggregation, that is to say, we assume that all flows arrived asynchronously, and based on the resource reservation, <packet-1, packet-2, ...> of a specific flow belongs to a specific delay level may reserve its dedicated resources. Packet-1 may be conflict with other eligible packets from the same delay level, but all of them will be sent before the deadline related with that delay level; Packet-2 (even if it arrived back-to-back with packet-1 to cause burst accumulation) will not affect the scheduling of packet-1 and other eligible packets from other flows belongs to the same delay level. After 100us, packet-2 became the eligible protagonist of the party, however, it may send before that time (due to in-time scheduling behavior).
Now, back to your statement "are not guaranteed latency bounds. But it is not the packets' faults to become ineligible. ", do you think that the punish time of 100us that may be expienced by packet-2 will cause packet-2 exceed its deadline ? My answer is NO. The reason is similar to "the re-shaping delay will not cause a packet to violate its latency bounds".  

Can you still say Option 3 or 4 is a suitable solution?
#PSF: There are many respected predecessors in the academic community who have conducted extensive research in this direction. : ) 
Please see similar idea of latency compensation in this paper:

Best regards,