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

[Greg Mirsky <[e-mail]>]

Dear All,
I share Justin's concerns and agree with his recommendation to be more
conservative with using the available space.

Regards,
Greg

On Tue, Mar 7, 2023 at 3:55 AM Justin Iurman <[e-mail]>
wrote:

> Hi Alex,
>
> I understand the motivation behind [I-D.draft-ahuang-ioam-on-path-delay]
> and [I-D.draft-ahuang-ippm-dex-timestamp-ext]. My main concern is about
> wasting a data field bit for something that can already be retrieved
> based on existing/similar data fields (which, of course, means
> delegating the aggregation work to the collector). Feels like a
> "duplicate" data field bit somehow.
>
> [RFC9326] says "an IOAM encapsulating node [...] MAY export the
> requested IOAM data immediately". Did you consider using bits 2,3 and
> delegate the aggregation work to the collector? Might not be as perfect
> as you'd want, but this wouldn't require to define a new bit in the IOAM
> Trace-Type registry, nor would it require to define new flags in the
> IOAM DEX Extension-Flags registry.
>
> Thanks,
> Justin
>
> On 3/6/23 11:37, Alex Huang Feng wrote:
> > 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]
> >> <mailto:[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>
> >>
> >
>