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

[Greg Mirsky <[e-mail]>]

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