[ippm] Re: Call for adoption for draft-mirsky-ippm-hybrid-two-step

[Greg Mirsky <[e-mail]>]

Thank you, Martin and Bjørn. Your comments and feedback help improve this
draft.

Regards,
Greg

On Fri, Jul 19, 2024 at 2:10 PM Bjørn Ivar Teigen <[e-mail]> wrote:

> Same here, looks good!
>
> - Bjørn
>
> On Fri, 19 Jul 2024 at 21:03, Martin Duke <[e-mail]> wrote:
>
>> SGTM. No further comments.
>>
>> On Fri, Jul 5, 2024 at 1:46 PM Greg Mirsky <[e-mail]> wrote:
>>
>>> Hi, Bjørn and Martin,
>>> I thank you for the discussion. Bjørn's thoughtful questions made me
>>> revisit the question raised by Martin:
>>>
>>> It's also disturbing to me that there doesn't seem to be strong
>>> wire-image synchronization between the trigger packet and followon packet
>>> via a common sequence number or something else. This could lead to
>>> confusion at the egress.
>>>
>>> After considering your questions, I propose the following updates:
>>>
>>>    - re-name Considerations for HTS Timers into Operational
>>>    Considerations
>>>    - move Deploying HTS in a Multicast Network into the new section
>>>    - update text as below:
>>>
>>> OLD TEXT:
>>>    This specification defines two timers - HTS Follow-up and HTS
>>>    Collection.  For the particular flow, there MUST be no more than one
>>>    HTS Trigger, values of HTS timers bounded by the rate of the trigger
>>>    generation for that flow.
>>> NEW TEXT:
>>>    Correctly attributing information originated by the particular
>>>    trigger packet to the proper HTS Follow-up packet is essential for
>>>    the HTS protocol.  That can be achieved using characteristic
>>>    information that uniquely indetifies the trigger packet within given
>>>    HTS domain.  For example, a combination of the flow identifier and
>>>    packet's sequence number within that flow, as Flow ID and Sequence
>>>    Number in IOAM Direct Export [RFC9326], can be used to correlate
>>>    between stored telemetry information and the appropriate HTS Follow-
>>>    up packet.  In case the trigger packet doesn't include data that
>>>    distinguish it from other trigger packets in the HTS domain, then for
>>>    the particular flow, there MUST be no more than one HTS Trigger,
>>>    values of HTS timers bounded by the rate of the trigger generation
>>>    for that flow.  In practice, the minimal interval between HTS Trigger
>>>    packets SHOULD be selected from the range determined by the round-
>>>    trip time (RTT) between HTS Ingress and HTS Egress nodes as [RTT/2,
>>>    RTT].
>>>
>>> Attached, please find the updated working version of the draft and diff
>>> that highlights all updates.
>>> Appreciate your comments, questions, and suggestions.
>>>
>>> Regards,
>>> Greg
>>>
>>>
>>> On Fri, Jul 5, 2024 at 2:11 AM Bjørn Ivar Teigen <[e-mail]> wrote:
>>>
>>>> Ok, thanks for the clarification.
>>>>
>>>> I still think selecting RTT/2 risks there being two active trigger
>>>> packets at once. Imagine a sudden queue forming on the path so that the RTT
>>>> grows by a factor of 2. Then there will be two active trigger packets at
>>>> the same time.
>>>>
>>>> That might not pose a problem, in which case I'm fine with it. However,
>>>> if the requirement to have only 1 active trigger packet at any given time
>>>> is crucial for the operation of the protocol, it might cause unexpected
>>>> issues. To say it in fewer words: Selecting RTT/2 means there MAY be more
>>>> than one active trigger packet at any given time.
>>>>
>>>> Is the single trigger packet requirement there simply to limit the
>>>> network load from HTS measurements or does it affect the operation of the
>>>> protocol itself?
>>>>
>>>> Regards,
>>>> Bjørn
>>>>
>>>> On Thu, 4 Jul 2024 at 18:45, Greg Mirsky <[e-mail]> wrote:
>>>>
>>>>> Hi Bjørn,
>>>>> top-posting the remaining issue:
>>>>>
>>>>>>
>>>>>>>    - If I understand correctly there can only be one trigger packet
>>>>>>>    active at a time. That limits the measurement rate to one measurement per
>>>>>>>    round-trip. Is that correct? If so, this limitation should be more clearly
>>>>>>>    stated.
>>>>>>>
>>>>>>> GIM>> Your understanding of the requirement in Section 4.4 is
>>>>>> correct. But I am not sure that the interval between trigger packets is
>>>>>> bound by the RTT. I think that it is closer to RTT/2, as the measurement
>>>>>> conducted are one-way. WDYT?
>>>>>>
>>>>> Bjørn: If the next trigger packet can only be sent once a response has
>>>>> been received, then there will be a minimum interval of 1 RTT between
>>>>> trigger packets, no? Am I misunderstanding something?
>>>>>
>>>>> GIM2>> HTS doesn't use request-reply mechanism, but follows the
>>>>> unidirectional path of an on-path telemetry packet. RTT measurement may be
>>>>> used to tune transmission of trigger packets. I'd suggest using RTT/2,
>>>>> rather than RTT (although that would also work).
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Thu, Jul 4, 2024 at 1:43 AM Bjørn Ivar Teigen <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> On Thu, 4 Jul 2024 at 04:27, Greg Mirsky <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Bjørn,
>>>>>>> my apologies for procrastinating to respond. Thank you for
>>>>>>> your comments and questions. Please find my notes below tagged GIM>>.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Greg
>>>>>>>
>>>>>>> On Fri, Sep 22, 2023 at 6:52 AM Bjørn Ivar Teigen <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> IPPM WG,
>>>>>>>>
>>>>>>>> I support adopting this document.
>>>>>>>> I do think it is a bit challenging to understand the motivations
>>>>>>>> for the mechanism, but that can probably be easily fixed by adding some
>>>>>>>> clarifying text and/or diagrams.
>>>>>>>>
>>>>>>>> Here are my comments on the draft:
>>>>>>>>
>>>>>>>>    - Is one of the purposes of the two-packet approach to separate
>>>>>>>>    measurements from different domains from each other? (I.e. by having one
>>>>>>>>    ingress and egress node for each domain, but one trigger packet that
>>>>>>>>    triggers measurements at all of the domains) If so, perhaps adding a
>>>>>>>>    diagram will make that more clear.
>>>>>>>>
>>>>>>>> GIM>> That is an interesting idea, thank you. I imagine that an
>>>>>>> on-path telemetry protocol is applied whithin a single domain because
>>>>>>> revealing information about the operational state of the network is very
>>>>>>> sensitive and proprietary from the standpoint of an operator.
>>>>>>>
>>>>>>>>
>>>>>>>>    - Is the purpose of the trigger packet to signal each
>>>>>>>>    intermediate node to take a measurement immediately? The list of things for
>>>>>>>>    the intermediate node to do upon receiving a trigger packet does not
>>>>>>>>    include taking a measurement. Is that an oversight?
>>>>>>>>
>>>>>>>> GIM>> A trigger packet is the packet of the hybrid measurement
>>>>>>> protocol, e.g., IOAM-DEX or the Alternate Marking method. As I understand
>>>>>>> it, such measurement protocols reflect the network conditions as
>>>>>>> experienced by the trigger packet. In that sense, HTS is based on the
>>>>>>> assumption that the measurements and operational state information are
>>>>>>> obtained as that packet traverses the intermediate node.
>>>>>>>
>>>>>>
>>>>>>>>    - If I understand correctly there can only be one
>>>>>>>>    trigger packet active at a time. That limits the measurement rate to one
>>>>>>>>    measurement per round-trip. Is that correct? If so, this limitation should
>>>>>>>>    be more clearly stated.
>>>>>>>>
>>>>>>>> GIM>> Your understanding of the requirement in Section 4.4 is
>>>>>>> correct. But I am not sure that the interval between trigger packets is
>>>>>>> bound by the RTT. I think that it is closer to RTT/2, as the measurement
>>>>>>> conducted are one-way. WDYT?
>>>>>>>
>>>>>> Bjørn: If the next trigger packet can only be sent once a response
>>>>>> has been received, then there will be a minimum interval of 1 RTT between
>>>>>> trigger packets, no? Am I misunderstanding something?
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Bjørn Ivar Teigen
>>>>>>>>
>>>>>>>> On Fri, 22 Sept 2023 at 12:54, Martin Duke <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I agree that this type of work is in-charter.
>>>>>>>>>
>>>>>>>>> I can't speak to whether this answers a big need or anyone would
>>>>>>>>> deploy it, but I don't see a fundamental problem with adoption, assuming
>>>>>>>>> there are satisfactory answers to the questions below.
>>>>>>>>>
>>>>>>>>> I can see how something like this could go haywire, with followon
>>>>>>>>> packets getting misrouted, reordered, or lost, and wonder if we have enough
>>>>>>>>> experience with it to be a standard, or if we should instead aim for
>>>>>>>>> experimental.
>>>>>>>>>
>>>>>>>>> Some more minor comments:
>>>>>>>>>
>>>>>>>>> I found the motivation in the introduction to be a bit hard to
>>>>>>>>> understand, and the abstract could use a sentence or two explaining what
>>>>>>>>> this protocol specifically does.
>>>>>>>>>
>>>>>>>>> IIUC since the last major presentation @IETF 113, the model seems
>>>>>>>>> to have evolved from each intermediate node generating its own
>>>>>>>>> followon packet, instead the ingress node generates one and each
>>>>>>>>> intermediate node appends to the followup. I hope that's right?
>>>>>>>>>
>>>>>>>>> It's also disturbing to me that there doesn't seem to be strong
>>>>>>>>> wire-image synchronization between the trigger packet and followon packet
>>>>>>>>> via a common sequence number or something else. This could lead to
>>>>>>>>> confusion at the egress.
>>>>>>>>>
>>>>>>>>> What assurances are there that the followon packet followed the
>>>>>>>>> same path from ingress to egress as the trigger packet? What are the
>>>>>>>>> consequences of this not happening and remaining undetected?
>>>>>>>>>
>>>>>>>>> This is not very important, but I find "hybrid two-step" to be a
>>>>>>>>> nondescriptive name, and might prefer something like "IOAM Followon".
>>>>>>>>>
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Sep 19, 2023 at 11:28 AM Haoyu Song <
>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>
>>>>>>>>>> IPPM WG,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As a coauthor, I support the adoption of the draft as the WG
>>>>>>>>>> document. The hybrid approach complements with the other IOAM approaches
>>>>>>>>>> well and has its own merits.  Thanks!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>
>>>>>>>>>> Haoyu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *From:* ippm <[e-mail]> *On Behalf Of * Tommy Pauly
>>>>>>>>>> *Sent:* Wednesday, September 13, 2023 9:22 AM
>>>>>>>>>> *To:* IETF IPPM WG <[e-mail]>
>>>>>>>>>> *Subject:* [ippm] Call for adoption for
>>>>>>>>>> draft-mirsky-ippm-hybrid-two-step
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello IPPM,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This email starts a call for adoption for
>>>>>>>>>> draft-mirsky-ippm-hybrid-two-step. This draft has been around for a while
>>>>>>>>>> and discussed several times on list and in WG meetings.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-two-step-15.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please review the document and email the list with your comments,
>>>>>>>>>> and if you think IPPM should adopt this work.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This call for adoption will last three weeks and end on *October
>>>>>>>>>> 4th*.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>
>>>>>>>>>> Tommy
>>>>>>>>>> _______________________________________________
>>>>>>>>>> ippm mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ippm mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bjørn Ivar Teigen, Ph.D.
>>>>>>>> Head of Research
>>>>>>>> [phone] | [e-mail] | www.domos.ai
>>>>>>>> _______________________________________________
>>>>>>>> ippm mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bjørn Ivar Teigen, Ph.D.
>>>>>> Head of Research
>>>>>> [phone] | [e-mail] | www.domos.ai
>>>>>> [image: https://understandingnetworkapis.com/]
>>>>>> <https://understandingnetworkapis.com/>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Bjørn Ivar Teigen, Ph.D.
>>>> Head of Research
>>>> [phone] | [e-mail] | www.domos.ai
>>>> [image: https://understandingnetworkapis.com/]
>>>> <https://understandingnetworkapis.com/>
>>>>
>>>
>
> --
> Bjørn Ivar Teigen, Ph.D.
> Head of Research
> [phone] | [e-mail] | www.domos.ai
> [image: https://understandingnetworkapis.com/]
> <https://understandingnetworkapis.com/>
>