Re: [ippm] New Version Notification for draft-ahuang-ioam-on-path-delay-00.txt

[Alex Huang Feng <[e-mail]>]

Hi Justin and Greg,

Thanks for your comments. All of them valid.

In practice, with only draft-ahuang-ippm-dex-timestamp-ext, we can already export an aggregated on-path delay, but this second draft asking for a bit in the IOAM architecture is for IOAM consistency. Let me explain.

As Justin said, having the timestamp reference in the IOAM DEX header already allows the node to compute the on-path delay.
However, how IOAM DEX was designed is having a bit-field referenced to IOAM Trace-Type registry telling the current node (transit and decap nodes) which metrics “should” be aggregated and/or exported (Section 3.2 of RFC9326).
Nothing in this RFC prevents us to export more metrics than the specified in this registry (IOAM Trace-Type).
For example, using draft-ietf-opsawg-ipfix-on-path-telemetry, the node can also export flow-related metrics which are not specified in the registry.
Yet, to remain consistent to the design of IOAM DEX, I felt that this on-path delay metric should be specified in the bit-field present in the header.
Of course, adding this bit for IOAM DEX impacts the IOAM architecture since the same registry was used.

The motivation of these two drafts is to export the computed delay in postcard mode directly from the monitored node.
Bit 2 and 3 from IOAM Trace-Type registry allow the export of the timestamps meaning the computation of the delay is pushed to the collector. Moreover, no aggregation is possible in the node since they are timestamps.

About using Bit 4 Transit delay, I believe we are trying to solve different problems.
The on-path delay defined in draft-ietf-opsawg-ipfix-on-path-telemetry covers also the link delay, which is really useful for anomaly detection.

Hoping this answer your questions.

Regards,
Alex

> On 3 Mar 2023, at 22:17, Greg Mirsky <[e-mail]> wrote:
> 
> Hi, Alex, Justin et al.,
> I read the draft and have some notes to share with you:
> I think that I understand the motivation of the authors of the draft. RFC 9197 does not specify when the timestamp SHOULD (less, MUST) be taken. As a result, it is challenging to extract variable delay caused by processing in a node from fixed propagation delay determined by the laws of physics. (We've discussed that in RFC 8169 Residence Time Measurement in MPLS Networks <https://datatracker.ietf.org/doc/rfc8169/>). Thus, in my opinion, another method other than using Bit 2 and Bit 3 in the IOAM Trace-Type registry is needed.
> Said that I have a question for the authors of the draft. Have you considered using Bit 4 Transit delay as defined in RFC 9197 <https://datatracker.ietf.org/doc/rfc9197/>? I believe that the transit delay is precisely the residence time a data packet spends in a node, which you are intended to measure using your proposal. I agree with you that IOAM-DEX can provide more accurate measurements of the transit delay benefiting from the separation of the reading of the wall clock value and calculating from the transmitting the trigger data packet.
> Regards,
> Greg
> 
> On Fri, Mar 3, 2023 at 10:52 AM Justin Iurman <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Alex,
> 
> I don't understand why bits 2 and 3 (i.e., timestamp seconds & fraction) 
> are not enough. If each node on the path timestamps its data part in the 
> trace, then based on the entire trace you're able to recompute on-path 
> delays by simply substracting a node's timestamp by the one of the 
> encapsulating node. You can actually compute the on-path delay between 
> any node. Did I miss something?
> 
> Thanks,
> Justin
> 
> On 3/3/23 17:54, Alex Huang Feng wrote:
> > Dear IPPM WG,
> > 
> > Some time ago I submitted draft-ahuang-ippm-dex-timestamp-ext that 
> > allows IOAM DEX to add a timestamp in the header.
> > This allows IOAM in postcard mode to compute the on-path delay at each node.
> > 
> > To export the on-path delay in the IOAM architecture, a bit-field is used.
> > This new draft adds a new 32bit Data-field in the "IOAM Trace-Type” 
> > registry allowing the export of the On-path delay in the IOAM architecture.
> > 
> > I would like to request feedback from the WG on this draft.
> > 
> > Cheers,
> > Alex
> > 
> >> On 3 Mar 2023, at 17:40, [e-mail] <mailto:[e-mail]> 
> >> <mailto:[e-mail] <mailto:[e-mail]>> wrote:
> >>
> >>
> >> A new version of I-D, draft-ahuang-ioam-on-path-delay-00.txt
> >> has been successfully submitted by Alex Huang Feng and posted to the
> >> IETF repository.
> >>
> >> Name:draft-ahuang-ioam-on-path-delay
> >> Revision:00
> >> Title:On-Path delay Data Field for In Situ Operations, Administration, 
> >> and Maintenance (IOAM)
> >> Document date:2023-03-03
> >> Group:Individual Submission
> >> Pages:7
> >> URL: 
> >> https://www.ietf.org/archive/id/draft-ahuang-ioam-on-path-delay-00.txt <https://www.ietf.org/archive/id/draft-ahuang-ioam-on-path-delay-00.txt> 
> >> <https://www.ietf.org/archive/id/draft-ahuang-ioam-on-path-delay-00.txt <https://www.ietf.org/archive/id/draft-ahuang-ioam-on-path-delay-00.txt>>
> >> Status: 
> >> https://datatracker.ietf.org/doc/draft-ahuang-ioam-on-path-delay/ <https://datatracker.ietf.org/doc/draft-ahuang-ioam-on-path-delay/> 
> >> <https://datatracker.ietf.org/doc/draft-ahuang-ioam-on-path-delay/ <https://datatracker.ietf.org/doc/draft-ahuang-ioam-on-path-delay/>>
> >> Htmlized: 
> >> https://datatracker.ietf.org/doc/html/draft-ahuang-ioam-on-path-delay <https://datatracker.ietf.org/doc/html/draft-ahuang-ioam-on-path-delay> 
> >> <https://datatracker.ietf.org/doc/html/draft-ahuang-ioam-on-path-delay <https://datatracker.ietf.org/doc/html/draft-ahuang-ioam-on-path-delay>>
> >>
> >>
> >> Abstract:
> >>   This document defines a Data Field In Situ Operations,
> >>   Administration, and Maintenance (IOAM) architecture for on-path delay
> >>   information.  This data field is registered as a new entry in the
> >>   "IOAM Trace-Type" registry.
> >>
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >>
> > 
> > 
> > _______________________________________________
> > ippm mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>
> 
> _______________________________________________
> ippm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>