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

[Greg Mirsky <[e-mail]>]

Hi Justin,
thank you for sharing your thoughts. Although IOAM documents don't specify
how and when an implementation should/must obtain the wall clock value, we
know of several documents, including IETF-published, that have helpful
guidance. As for the performance impact of measuring the residence time, I
believe that the impact is lower for IOAM-DEX compared with other IOAM
trace options, e.g., preallocated. Also, IOAM-DEX can produce more accurate
measurement results.

Regards,
Greg

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

> Hi Greg,
>
> On 3/3/23 22:17, Greg Mirsky 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
>
> True, "the time at which the packet was received by the node"
> ([RFC9197]) can be vague, although all devices of an IOAM-Domain are
> expected to follow the same definition. But, then...
>
> >     [...] Have you
> >     considered using Bit 4 Transit delay as defined in RFC 9197?
>
> ... bit 4 Transit Delay has the same issue, i.e., RFC 9197 does not
> specify exactly when the ingress/egress timestamps SHOULD/MUST be taken.
> Besides, this data field is quite often hard to retrieve (and by "hard",
> I mean from a performance point of view).
>
> Thanks,
> Justin
>
> > 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>
> >
>