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

[Greg Mirsky <[e-mail]>]

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