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

[Greg Mirsky <[e-mail]>]

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