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

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 <justin.iurman@uliege.be>
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, internet-drafts@ietf.org
> >> <mailto:internet-drafts@ietf.org> 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
> >
> >> Status:
> >> 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>
> >>
> >>
> >> 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
> > ippm@ietf.org
> > https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>