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 you insights.
I understand your concerns but the authors believe without the aggregation at the node level, the overhead and complexity to monitor the delay in large scale networks is great.

Using IOAM-DEX with draft-ietf-opsawg-ipfix-on-path-telemetry, the monitoring of the delay would only mean an extension to the IPFIX exporter.
Therefore, besides the IPFIX counters, we would also have the aggregated delay metrics per flow.

On the other hand, using Bit 2,3 of IOAM Trace-type, every node would have to send all the sampled packets with their timestamp to the collector and the collector would still need to correlate the data to the flow, compute the diff with each message and then aggregate.

Haoyu proposed to reduce the requested bits to one in the draft-ahuang-ippm-dex-timestamp-ext and I wrote the second draft to remain consistent within the IOAM architecture, but if IPPM WG feels the bits allocated in draft-ahuang-ioam-on-path-delay are not necessary, I am ok with it. Without this second draft, we would only request one bit for the timestamp extension in IOAM-DEX.

Regards,
Alex

> On 7 Mar 2023, at 21:02, Greg Mirsky <[e-mail]> wrote:
> 
> 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] <mailto:[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]> 
> >> <mailto:[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/ <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/ <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]> 
> >> <mailto:[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]>>
> >>     >> <mailto:[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>>
> >>     >>
> >>     <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/>>
> >>     >>
> >>     <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>>
> >>     >>
> >>     <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]> <mailto:[e-mail] <mailto:[e-mail]>>
> >>     > https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>
> >>     <https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>>
> >>
> >>     _______________________________________________
> >>     ippm mailing list
> >>     [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >>     https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>
> >>     <https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>>
> >>
> >