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
<http://accedian.com>
<https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
<https://ca.linkedin.com/company/accedian>
<http://www.accedian.com>
*accedian.com <http://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.