[ippm] Re: Working group last call for draft-ietf-ippm-asymmetrical-pkts

[Will Hawkins <[e-mail]>]

On Thu, Apr 24, 2025 at 2:04 PM Greg Mirsky <[e-mail]> wrote:

> Hi Henrik and Will,
> thank you for the discussion and a great idea to signal truncated packet.
> Thinking outloud, Do you foresee a case other then Reflected Test Packet
> Control TLV when Session-Reflector will need to truncate reflected packet?
> If that is a plausible case, then using TLV flags seems reasonable.
> Otherwise, if this is specific to the Reflected Test Packet Control TLV,
> then we can define the Truncated flag as part of the new TLV (adding one or
> two reserved bits). What do you think?
>

I really like that ... could we make it slightly more broad:

C: A flag indicating whether the Reflector was able to comply with a
request implied in the test packet received from the Session Sender, where
the definition of compliance is set according to the TLV specification.

Thoughts?


>
> Regards,
> Greg
>
> On Thu, Apr 24, 2025 at 9:25 AM Will Hawkins <[e-mail]> wrote:
>
>>
>>
>> On Thu, Apr 24, 2025 at 6:35 AM Henrik Nydell (hnydell) <
>> [e-mail]> wrote:
>>
>>> I agree with Greg keeping the interval between packets as 32-bit (max
>>> 4.29 seconds) is sufficient.
>>>
>>>
>>>
>>> Regarding path MTU discovery, I like Will’s idea, I do however think it
>>> would be best to still get a response from the session-reflector, but mark
>>> with a new flag on that sending MTU was reached and packet has been
>>> truncated to MTU
>>>
>>
>> Great idea!
>>
>>
>>> max of the link. (if the session-reflector can detect this before
>>> sending the packet). I don’t think we want UDP fragmentation to occur at
>>> either the session-sender nor the session-reflector?
>>>
>>>
>>>
>>> The M (Malformed) flag in the Stamp TLV flags field could possibly be
>>> used for this purpose, or we look at introducing a new flag for MTU overflow
>>>
>>
>> Would it be possible to specify that the Reflector simply change the
>> length field in the reflected packet from its original value to indicate
>> that it had to take a special measure to make the packet fit? I get the
>> sense (although I do not know) that adding semantics to the Flags could be
>> disruptive given that they are limited in quantity and defined "at a higher
>> level"?
>>
>> That's just a brainstorm!
>> Will
>>
>>
>>
>>>
>>>
>>> Regards
>>>
>>> Henrik
>>>
>>>
>>>
>>> *From: *Greg Mirsky <[e-mail]>
>>> *Date: *Thursday, 24 April 2025 at 01:03
>>> *To: *Will Hawkins <[e-mail]>
>>> *Cc: *Marcus Ihlar <marcus.ihlar=[e-mail]>, IETF
>>> IPPM WG ([e-mail]) <[e-mail]>
>>> *Subject: *[ippm] Re: Working group last call for
>>> draft-ietf-ippm-asymmetrical-pkts
>>>
>>> That's a very good question, Will! I can't come up with a practical case
>>> for rate measurement at a 5+ second interpacket interval (I'm not sure
>>> anything above a decisecond is useful). Perhaps someone with more
>>> operational experience will help us here.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Wed, Apr 23, 2025 at 8:50 AM Will Hawkins <[e-mail]> wrote:
>>>
>>> Sorry for the late reply! I think that Rakesh's suggestion re: the size
>>> of the interval field is interesting. Do we "lose" anything as a result of
>>> making in 64 bits? In other words, it seems like supporting intervals > 5
>>> seconds is something that a user might reasonably want and if we could
>>> support that without too much effort, maybe it is a good idea?
>>>
>>>
>>>
>>> Also, as an FYI: I have updated the implementation to match the new TLV
>>> format.
>>>
>>>
>>>
>>> Will
>>>
>>>
>>>
>>> On Tue, Apr 22, 2025 at 8:49 PM Greg Mirsky <[e-mail]>
>>> wrote:
>>>
>>> Hi Rakesh,
>>>
>>> thank you for excellent questions. Please find my notes below tagged
>>> GIM>>. Based on your questions, the updated Reflected Packet Control TLV
>>> may look like:
>>>
>>> Dear All,
>>>
>>> please share your comments about the proposed update.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 22, 2025 at 1:49 PM Rakesh Gandhi <[e-mail]>
>>> wrote:
>>>
>>> Hi Marcus, WG,
>>>
>>>
>>>
>>> I have reviewed the document and I believe it is ready for the next
>>> steps.
>>>
>>> I have following review comments that authors may consider:
>>>
>>> Section 2:
>>>
>>> Figure 1:
>>>
>>> (1) Length of the reflected packet is 4-byte field - maximum 4 Billion
>>> octets. Do we expect the length of the reflected packet to be that big?
>>>
>>> Note that Extra padding TLV has a length of 2-byte field in RFC 8972.
>>>
>>> GIM>> Good point! I think that two-byte field is sufficient for a
>>> reflected STAMP packet (besides, it will be limited by MTU).
>>>
>>>
>>>
>>> (2) Number of reflected packets is 4-byte field - maximum 4 Billion
>>> packets reflected. Do we expect as many packets reflected in a response?
>>>
>>> GIM>> Consider scenario when an operator is interested in measuring
>>> packet loss and packet delay only in the upstream direction. It seems like
>>> ratio 1:64K is reasonable, so we can make this field also two-byte long.
>>>
>>>
>>>
>>> (3) Interval Between the Reflected Packets is a 4-byte field - maximum
>>> interval between packets would be 4.29 seconds. Do we expect that packets
>>> can not have more than this interval?
>>>
>>> GIM>> I think that this field can remain unchanged.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Rakesh
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Apr 10, 2025 at 5:06 AM Marcus Ihlar <marcus.ihlar=
>>> [e-mail]> wrote:
>>>
>>> Hello IPPM,
>>>
>>>
>>>
>>> This email initiates the working group last call for Performance
>>> Measurement with Asymmetrical Traffic Using STAMP
>>> (draft-ietf-ippm-asymmetrical-pkts).
>>>
>>>
>>>
>>> The current version of the document can be found here:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/
>>>
>>> https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-05.html
>>>
>>>
>>>
>>> Please review the document and reply to this email with any comments and
>>> indicate whether you believe it is ready for publication. This WGLC will
>>> last for three weeks and end on *May 1, 2025*.
>>>
>>>
>>>
>>> BR,
>>>
>>> Marcus and Thomas
>>>
>>>
>>>
>>> _______________________________________________
>>> ippm mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> ippm mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> ippm mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>>