Hello Max:
Thank you for the presentation.
BLUF: I have revised your latency and delay definition as outlined below and invite debate:
Latency: The total delay experienced by a frame in the course of its transmission between two points in a network, measured from the time
that the first bit in the frame passes the first point (P1) to the time that
that the last bit in the frame passes the second point (P2). Refer to 3.120 of 802.1Q-2022
- First bit in the frame: The first bit of the MPDU, immediately after the SFD Refer to 3.1.1 Packet format of 802.3-2022
- Last bit in the frame: The last bit of the MPDU, which includes the FCS. Refer to 3.1.1 Packet format of 802.3-2022
- First point (P1): The MAC service interface on the talker Refer to 6. Support of the MAC Service of 802.1Q-2022
- Second point (P2): The MAC service interface on the listener. Refer to 6. Support of the MAC Service of 802.1Q-2022
- Network: The Bridged Local Area Network Refer to 802.1Q-2022
Delay: a component of the latency that measures the time for a specific transmission, include:
- propagation delay(PD): delay along the network media (e.g., cable) for a frame transmitted from the specified Port of this station to the neighboring Port on a different station
=distance(between peer MDIs)/propagation speed
(refer to 12.32.2 Propagation Delay 802.1Q-2022)
- bridge delay(BD): delay of frames as they pass through the Bridge’s relay = independentDelay + dependentDelay (refer to 12.32.1 Bridge Delay, 802.1Q-2022 )
independentDelay= Delay independent of frame length (e.g., MAC address lookup, switching logic).
dependentDelay = delay for transferring a frame across the MAC Service interfaces from ingress to egress port =frame length/bridge internal transferring rate
- transmission delay(TD): queuing delay(time waiting for the frame becomes first in line for transmission on the Port) + access delay(time for transmission of the frame) (refer
to 6.5.9 Priority, 802.1Q-2022)
- Transmit data delay(TDD): delay from the input of frame at the XGMII to the presentation of the same frame by the PHY to the MDI.
- Receive data delay(RDD): delay from the input of frame at the MDI to the presentation of the same frame by the PHY to the XGMII. ( Refer to 149.10 Delay constraints, 802.3-2022)
- Transit delay: the elapsed time between an MA_UNITDATA.request primitive and the corresponding MA_UNITDATA.indication
primitive. (refer to 6.5.5 Transit delay, 802.1Q-2022)
e.x: for an n hop the latency from talker to listener = (n+1)x(PD+TD)+nxBD+TDD+RDD = transit delay
Background:
- I assume you aimed to define the sematic of the ISAAC system ontology, specifically the sematic of latency and delay.
And I assume you assumed the ontology of ISAAC=subset of {802.1Q-2022, 802.3-2022}
- Your original latency and delay definition:
‘something’Latency: ”first bit to last bit”
• Time interval between the (first bit of the) SFD and the (last bit of the) FCS of a certain packet to pass a certain reference plane
• Time interval between the (first bit of the) SFD of one packet and the (last bit of the) FCS of a response packet to pass a certain reference plane
• Depends on packet length! i.e. dominated by line rate at least for large packets
‘something’Delay: “first bit to first bit”
• Time interval between the (first bit of the) SFD (or any other defined bit) of two packets to pass a certain reference plane
• Time interval for a certain specified bit within a packet to pass from one reference plane to another reference plane
• Does NOT depend on packet length! i.e. not dominated by line rate
- I revised “Time interval between the (first bit of the) SFD…” to “first bit in the frame passes” to align with 802.1Q-2022, Section 3.120, emphasizing frame or MPDU latency, not packet
latency
- I overloaded your “certain reference plane” to “the MAC service interface on the talker/listener” to align on 802.1-2002 and emphasize frame latency at the Data Link layer
- I removed the round-trip latency for request/response, as it is outside the scope of this ontology.
- I revised your delay definitions to align with 802.1Q and 802.3.
Thanks
V/r
Mark Hu
Best regards
Mobile: +1 586 879 4375
From: Max Turner <max.turner@xxxxxxxx>
Sent: Monday, August 5, 2024 6:44 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] Agenda of the IEEE802.3dm Use Case AdHoc to be held on 2024-08-07
|
CAUTION: This email comes from a non Aptiv email account |
Dear all!
Please find the tentative agenda attached.
Presentations are posted:
https://ieee802.org/3/dm/public/adhoc/080724/index.html
Please provide any new contributions to Jon Lewis and to the ad hoc chair by end of day Monday, August 5th, AoE.
All attendees are expected to familiarize themselves with the Working Group Policies and Procedures at
http://1.ieee802.org/rules/ before participating in the meeting (or meetings) to be held based on the present notice, and to act accordingly. By participating in this meeting (or meetings), attendees
agree to comply with all applicable laws and with the IEEE Codes of Ethics and Conduct and all IEEE policies and procedures including, but not limited to, the IEEE Patent Policy and IEEE SA Copyright and Participation Policies as provided in
https://ieee802.org/1/files/public/templates/admin-TG-intro-0324-v01.pdf.
Best
Max Turner
(Ad Hoc Chair)
--
Max Turner, Dipl.Phys.
Automotive
Network Architect
Ethernovia BV
Utrechtseweg 75
3702AA Zeist
The Netherlands
c-de: +49 177 863 7804
c-nl: +31 685 386 449
To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1