[ippm] Re: draft-mirsky-ippm-stamp-cos-ext

[[e-mail]]

Hi Greg,

Thank you for the prompt response.
Please see inline.

Original


From: GregWhite <[e-mail]>
To: 肖敏10093570;[e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2025年06月04日 07:15
Subject: Re: [ippm] Re: draft-mirsky-ippm-stamp-cos-ext



Hi Xiao Min,
 
That case actually is handled in the text.  
“Furthermore, if the value of the REC field is non-zero, a system that
   supports this specification MUST add 0b10 to the value of the RP
   field in the CoSTLV in the reflected test packet.”
 
So, the SS compliant with 8972 will send 0b00000000 in the Reserved field.  The SR compliant with the new definition will interpret this as REC=0b00, Reserved=0b000000, and it will send an RP field of 0b00 or 0b01.  The SS then will never see an RP value that is unexpected.
[XM]>>> Thank you for the clear explanation. Then I see an inconsistency between your explanation and the following text
"In the former case, .... Furthermore, B adds 0b10 to the value of the RP field in the reflected STAMP packet,..."
Please handle the inconsistency in the next revision.

But, this isn’t an ideal protocol, because it means that there is no way for a SS compliant with this draft to set REC=0b00 and be able to determine whether the SR implements this draft or implements 8972, so it cannot usefully detect manipulation of the ECN value 0b00 on the return path without previously having tested other REC values with the same SR and storing state regarding the SR’s implementation of this draft.  
 
I agree that moving the new RP bit to a new RP2 field would solve that problem.
[XM]>>> OK, thanks.
 
Greg M. & I are working on a joint draft to replace our two individual drafts, I will include this change in that document unless others see an issue with it.
[XM]>>> Glad to know you're merging your two individual drafts. :-)


Cheers,
Xiao Min


-Greg
 
 

From: "[e-mail]" <[e-mail]>
 Date: Tuesday, June 3, 2025 at 1:59 AM
 To: "[e-mail]" <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
 Subject: [ippm] Re: draft-mirsky-ippm-stamp-cos-ext


 
Hi Greg,

 Thanks for updating the working version of the draft.
While reviewing the diff, I found there is an issue with the former case "A Session-Sender uses A and Session-Reflector uses B". When a Session-Sender complied with RFC8972 receives the STAMP packet reflected by a Session-Reflector complied with this draft, the value of the RP field in the reflected STAMP packet is 0b10, however RFC8972 doesn't define the behavior of Session-Sender when it receives an RP value of 0b10.
So, a question came into my mind, why not introduce a new RP2 field following the newly introduced REC field? The RP2 field may have the similar definition with the existing RP field but only apply to ECN, while RP field applies only to DSCP.
 
Cheers,
Xiao Min

Original

From: GregMirsky <[e-mail]>



To: 肖敏10093570;



Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;



Date: 2025年06月02日 08:39



Subject: Re: [ippm] Re: draft-mirsky-ippm-stamp-cos-ext




Hi Xiao Min and Will,

Thank you for your comments and the discussion. I've worked on the updates to address your suggestions. Please review the diff, which highlights the updates, and the working version of the draft. Please let me know if you find that your comments have been addressed.


 

Best regards,



Greg



 

On Thu, May 29, 2025 at 10:14 AM <[e-mail]> wrote:


Hi Will,
 
Thank you for your comments.
Your two suggestions make sense to me.
Also note that there is an open question on why in the latter case ECN value in the IP header of the reflected STAMP test packet will be set to 0b00.
 
Cheers,
Xiao Min

Original

From: WillHawkins <[e-mail]>



To: Greg Mirsky <[e-mail]>;



Cc: 肖敏10093570;[e-mail] <[e-mail]>;



Date: 2025年05月28日 19:20



Subject: Re: [ippm] Re: draft-mirsky-ippm-stamp-cos-ext




Xiao and Greg,
 
 Thank you for the excellent discussion! I have a few _very_ minor
 suggestions that I will offer below. Again, they are only suggestions!
 Feel free to take them or leave them!
 
 
 On Tue, May 27, 2025 at 8:28 PM Greg Mirsky <[e-mail]> wrote:
 > 
 > Hi Xiao Min,
 > thank you for pointing that out to me. I'll work on how the modified use of the RP field affects the interworking between the RFC8972-conforming implementation and the one supporting the new proposal.
 > 
 > Regards,
 > Greg
 > 
 > On Sun, May 25, 2025 at 7:47 PM <[e-mail]> wrote:
 >> 
 >> Hi Greg,
 >> 
 >> 
 >> Thank you for the thoughtful reply.
 >> 
 >> Please see inline.
 >> 
 >> Original
 >> From: GregMirsky <[e-mail]> 
 >> To: 肖敏10093570;
 >> Cc: [e-mail] <[e-mail]>;
 >> Date: 2025年05月24日 07:06
 >> Subject: Re: draft-mirsky-ippm-stamp-cos-ext
 >> Hi Xiao Min,
 >> apologies for the delay to respond and thank you for your comments. I agree that explanation of interworking between CoS TLV as defined in Section 4.4 of RFC 8792 and the extended CoS is helpful. I propose adding a new section:
 >> NEW TEXT:
 >> 3.1.  Interoperability with RFC 8972
 >> 
 >>    Consider two scenarios of interoperability between an implementation
 >>    that supports the CoS TLV as defined in Section 4.4 of [RFC8972]
 >>    (referred to as A) and the implementation that supports it as defined
 >>    in this specification (referred to as B):
 >> 
 >>    *  A Session-Sender uses A and Session-Reflector - B.
 >> 
 >>    *  A Session-Sender uses B and Session-Reflector - A.
 
 As usual, really nicely written! I only have two minor suggestions.
 First, above, do we want the - B and - A to be uses B and uses A? Or
 am I simply too stupid to understand the meaning of your use of the
 dashes there?
 
 
 >> 
 >>    In the former case, if A includes CoS TLV in the STAMP test packet,
 >>    it zeroes the Reserved field.  When B receives the packet with CoS
 >>    TLV, it uses the value of the REC field, which is 0b00, to set the
 >>    ECN value in the IP header of the reflected STAMP test packet.
 
 On Fri, May 23, 2025 at 7:07 PM Greg Mirsky <[e-mail]> wrote:
 > 
 > Hi Xiao Min,
 > apologies for the delay to respond and thank you for your comments. I agree that explanation of interworking between CoS TLV as defined in Section 4..4 of RFC 8792 and the extended CoS is helpful. I propose adding a new section:
 > NEW TEXT:
 > 3.1.  Interoperability with RFC 8972
 > 
 >    Consider two scenarios of interoperability between an implementation
 >    that supports the CoS TLV as defined in Section 4.4 of [RFC8972]
 >    (referred to as A) and the implementation that supports it as defined
 >    in this specification (referred to as B):
 > 
 >    *  A Session-Sender uses A and Session-Reflector - B.
 > 
 >    *  A Session-Sender uses B and Session-Reflector - A.
 
 As usual, really nicely written! I only have tw minor suggestions.
 First, above, do we want the - B and - A to be uses B and uses A? Or
 am I simply too stupid to understand the meaning of your use of the
 dashes there?
 
 > 
 >    In the former case, if A includes CoS TLV in the STAMP test packet,
 >    it zeroes the Reserved field.  When B receives the packet with CoS
 >    TLV, it uses the value of the REC field, which is 0b00, to set the
 >    ECN value in the IP header of the reflected STAMP test packet.
 
 Second, if you change the last two lines of the previous paragraph to
 
 TLV, it uses the value of the REC field and will set the
 ECN value in the IP header of the reflected STAMP test packet to 0b00.
 
 there is parallel sentence structure with the end of the next
 paragraph. That may draw the readers eyes more quickly to the way
 that, in both cases, the ECN value set in the IP header of the
 reflected STAMP test packet is the same (and really hammer home the
 fact that there is compatibility). Again, that is only a suggestion!
 
 Thank you both, again and as usual, for the great work! I hope that everyone
 had a great weekend!!
 
 Will
 
 
 >> 
 >>    In the latter case, regardless of the value set by B in the STAMP
 >>    test packet, A, acting as Session-Reflector, will interpret it as
 >>    part of the Reserved field and ignore the value according to
 >>    Section 4.4 of [RFC8972].  Thus, A will set ECN in the IP header of
 >>    the reflected STAMP test packet to 0b00.
 >> 
 >> What are your thoughts about the new section?
 >> 
 >> [XM]>>> Thanks for proposing the new section. To the processing of new added REC field, I think it's clear, just wonder why "Thus, A will set ECN in the IP header of the reflected STAMP test packet to 0b00", would not A set ECN at its own option? And I noticed that this specification updates the definition of RP field, would you like to mention the processing of RP field too in the new section?
 >> 
 >> 
 >> Cheers,
 >> 
 >> Xiao Min
 >> 
 >> 
 >> Regards,
 >> Greg
 >> 
 >> On Tue, Apr 8, 2025 at 7:45 PM <[e-mail]> wrote:
 >>> 
 >>> Hi Greg,
 >>> 
 >>> 
 >>> Thank you for the concise and well-written draft.
 >>> 
 >>> I like the idea of making the new CoS TLV backward compatible with the existing CoS TLV defined in Section 4.4 of RFC 8972.
 >>> 
 >>> While reading the substantial part on the new definition of existing RP field and the new added REC field, I believe it's helpful to explain the existing definition of RP field here, in addition to the new definition. Furthermore, a new section explaining the backward compatibility, like Section 4.6 of RFC 8762, may make the advantages of this kind design more clear.
 >>> 
 >>> 
 >>> Best Regards,
 >>> 
 >>> Xiao Min
 >> 
 >> 
 > _______________________________________________
 > ippm mailing list -- [e-mail]
 > To unsubscribe send an email to [e-mail]