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

[Justin Iurman <[e-mail]>]

Hi Alex,

Please see inline.

On 3/10/23 17:42, Alex Huang Feng wrote:
> 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.

I agree. Unfortunately, I just don't think it's the right approach (at 
least for the IOAM-Trace-Type).

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

Using 1 bit for two 4-byte fields would break existing implementations 
(see my reply to Haoyu about this). And I feel like it would make sense 
to have the base timestamps available with new IOAM DEX extension-flags. 
But, then, you'd need to allocate 2 bits for that, which is a real 
concern. On the other hand, there is more "free" room in the 
IOAM-Trace-Type but, here, the problem is to kind of "duplicate" 
existing data fields (i.e., bits 2 and 3).

I also have a question. Let's say these 2 bits are allocated in the IOAM 
DEX extension-flags. How would the transit nodes know what to export 
(i.e., on-path delay, computed between current timestamp on the node and 
the base timestamp from the encap node), without having a dedicated bit 
in the IOAM-Trace-Type? All you have right now is bit 2 and bit 3.

Thanks,
Justin

> Regards,
> Alex
> 
>> On 7 Mar 2023, at 21:02, Greg Mirsky <[e-mail] 
>> <mailto:[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>>
>>     >>
>>     >
>>
>