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

[Greg Mirsky <[e-mail]>]

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