Re: [ippm] RFC 8972, STAMP Optional Extensions Question, RFC 8762 stateless detection

I agree with Henrik that's a practical method to discover the stateless/stateful mode of the reflector.

Cheers,
Xiao Min
------------------Original------------------
From: HenrikNydell <hnydell@accedian.com>
To: 肖敏10093570;
Cc: rick.ringel@spirent.com <rick.ringel@spirent.com>;IETF IPPM WG <ippm@ietf.org>;
Date: 2022年08月18日 18:44
Subject: Re: [ippm] RFC 8972, STAMP Optional Extensions Question, RFC 8762 stateless detection

Just a minor comment.
It is easy for a TWAMP-light / STAMP sender to determine if the responder is a stateless or stateful one by sending a couple of packets with random sequence numbers. The TWAMP/STAMP replies will clearly tell if the reflector is stateless and merely copying received sequence number, or of it is stateful and generating a nice incremental sequence number on the return path.

This maybe didnt address your initial question, but it at leasts helps a sender that for some reason is unaware of reflector capabilities, to probe for statefulness.

On Thu, Aug 18, 2022 at 3:56 AM <xiao.min2@zte.com.cn> wrote:
Hi Rick,
Glad to know you're implementing STAMP.
As a proponent of STAMP and a co-author of RFC 8972 and draft-ietf-ippm-stamp-yang, I have some add-on to what Greg has responded.
Please see inline my responses with [XM]>>>. Hope it helps.
Best Regards,
Xiao Min
------------------Original------------------
From: Ringel,Rick <rick.ringel@spirent.com>
To: ippm@ietf.org <ippm@ietf.org>;
Date: 2022年08月18日 00:40
Subject: [ippm] RFC 8972, STAMP Optional Extensions Question, RFC 8762 stateless detection
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
I’m working to implement the DirectMeasurement TLV as described in RFC 8972.  There is a scenario where the reflector cannot give a correct response, but the available TLV flags don’t allow the reflector to signal this to the sender.
A STAMP reflector can be started in stateless mode, in which case the reflector has no tx/rx counters to use in the DirectMeasurement TLV response.
[XM]>>> Note that in section 4 of RFC 8762 it says "only round-trip packet loss can be calculated while the reflector is operating in stateless mode".
I am currently setting the ‘Unrecognized’ flag so the sender doesn’t try to interpret the results, but this seems inconsistent with the intent of the flag.
What should the reflector’s response be in this situation?
[XM]>>> I expect that the behavior of the reflector in stateless mode is to remain the received counters as is and send them back to the sender.
I have played with algorithms on the sender side to determine if the reflector is stateful or stateless, as described in RFC 8762.  The best I have come up with is seeding the sender sequence number with a non-zero value on the first transmission.   If the reflector responds with a matching sequence number, it is stateless.  The sender can then inhibit transmission of the DirectMeasurement TLV.   Have I missed something in the RFC regarding the sender’s method for determining stateful/stateless reflectors?   The RFC says the sender sequence number should start at zero, so this is a bit of a hack.
[XM]>>> As you may know, a big difference between STAMP and TWAMP is that STAMP removes TWAMP-Control which achieves mode/parameter negotiation between the sender and reflector. The alternative to TWAMP-Control in STAMP is a centralized configuration on the sender and reflector, so I believe draft-ietf-ippm-stamp-yang can make sure the sender knows the stateless mode of the reflector.
I look forward to your response.
Rick Ringel
Senior Software Engineer
Rick.Ringel@spirent.com | www.spirent.com
5280 Corporate Drive, Suite A100, Frederick, MD 21703
Spirent Communications e-mail confidentiality.
This email and the information contained therein may contain private, confidential or privileged material solely meant for the intended recipient. If you are not the intended  recipient review, copying or distribution is forbidden. Further, if you are not the intended recipient, please contact the sender immediately and permanently delete this email and any copies or attachments.
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

--

Henrik Nydell
Sr Product Manager
1.866.685.8181
hnydell@accedian.com
accedian.com

Avis de confidentialité
Les  informations contenues dans le présent message et dans toute pièce qui  lui est jointe sont confidentielles et peuvent être protégées par le  secret professionnel. Ces informations sont à l’usage exclusif de son ou  de ses destinataires. Si vous recevez ce message par erreur, veuillez  s’il vous plait communiquer immédiatement avec l’expéditeur et en  détruire tout exemplaire. De plus, il vous est strictement interdit de  le divulguer, de le distribuer ou de le reproduire sans l’autorisation  de l’expéditeur. Merci.
Confidentiality notice
This  e-mail message and any attachment hereto contain confidential  information which may be privileged and which is intended for the  exclusive use of its addressee(s). If you receive this message in error,  please inform sender immediately and destroy any copy thereof.  Furthermore, any disclosure, distribution or copying of this message  and/or any attachment hereto without the consent of the sender is  strictly prohibited. Thank you.