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

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

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