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

[Justin Iurman <[e-mail]>]

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>
>>
>