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

[Bjørn Ivar Teigen <[e-mail]>]

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