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

[Martin Duke <[e-mail]>]

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