Subject: Re: [ippm] Questions about STAMP Extensions 答复: WGLC for STAMP Extensions

From: wangyali <[email-masked]>
Date: Tue, 9 Jun 2020 12:37:17 +0000

Hi Greg,

Going over your discussion which is a good inspiration for me. And may I ask some questions as follows? Please see inline <Yali>.

From: ippm [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, June 3, 2020 3:49 AM
To: Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]>
Cc: IETF IPPM WG ([email-masked]) <[email-masked]>; Ian Swett <ianswett=[email-masked]>
Subject: Re: [ippm] 答复: WGLC for STAMP Extensions

Hi Yuezhong,
great, let us connect off-list to share ideas about a new STAMP application document.
On your other questions (I brought it to the front) I've added my notes under GIM2>> tag below:

And another question is how to use Class of Service TLV to find the misconfigure problem, is it enough?
GIM>> One of the possible scenarios could be as follows:

STAMP Sender sets DSCP1 to value A
STAMP packet is transmitted with DSCP set to A
STAMP Reflector copies DSCP value into DSCP2 field
reflected STAMP packet is transmitted with DSCP set to A (as requested by the STAMP Sender)
STAMP Sender receives the STAMP packet with DSCP A but DSCP2 value is B not as expected.
I hope this little example helps. Obviously, there are many ways to use the CoS TLV to test CoS mappings.

song>> the CoS mappings happened in Sender or other places, if DSCP value is not same with DSCP2 value, it means a error in which place?
GIM2>> Let us assume that no CoS re-mapping expected along a path between the Sender and the Reflector. If the value in the DSCP2 field is different from the value set in the DSCP field by the Sender at the transmission, then the error is on the downstream leg of the path. If the value in the DSCP1 field is different from the value in the DSCP field of the reflected packet received by the Sender, then the error is on the upstream leg of the path. I'll note that CoS re-mapping may be used and then the determination of the error condition should be based on the expected behavior. I hope that helps..

<Yali> how does the using CoS TLV in STAMP test help to diagnose the root cause of the problem that an excessive packet drop of higher level service while packet drop for lower service packets is at a normal level？Could you give some details about this?

song>> and for Access Report TLV, can you explain more, for example the location of sender and reflector both in user side, and how to find the reflector status changed, very thanks!
GIM2>> As noted in the last paragraph in Section 4.6:
   The Access Report TLV is used by the Performance Measurement Function
   (PMF) components of the Access Steering, Switching and Splitting
   feature for 5G networks [TS23501].  The PMF component in the User
   Equipment acts as the STAMP Session-Sender, and the PMF component in
   the User Plane Function acts as the STAMP Session-Reflector.
UE acts as Session-Sender and UPF - Session-Reflector.

<Yali> As the value of the Access ID field and the Return Code field are set at the Session-Sender, e.g. UE, and the Session-Reflector sets the Access Report TLV having the same value of the Access ID and Return Code from the test packet it has received, so as my understand, the Session-Reflector can take use of the Access Report TLV to indicate changes to the access network status. But what is the application of the Access Report TLV in the reflected packet received by Session-Sender except disarming the timer?

Why does it suggest the value of retransmission times to be four and the value of the retransmission timer to be three seconds? Are they experimental results or else?

Thanks,
Yali

Regards,
Greg

On Mon, Jun 1, 2020 at 8:59 PM Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
thanks for the reply from you and Ian, some of my questions have been answered, and there are still a few problems I don't understand,
I will use the way you use with song>> tag for my reply

Regards,
Yuezhong

发件人: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2020年6月2日 0:03
收件人: Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]<mailto:[email-masked]>>
抄送: Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
主题: Re: [ippm] 答复: WGLC for STAMP Extensions

Hi Yuezhong,
thank you for your comments and suggestions. Please find my notes and answers in-line under the GIM>> tag.

Regards,
Greg

On Sat, May 30, 2020 at 4:56 AM Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ian，

I have read the latest version of this draft，and have some small suggestions, hope it is helpful for you.

For part 4,there list 8 new TLVs, but it seems not detailed enough for each TLV about the application scenario and some terms in it, we need guess to understand the whole plan.
GIM>> We have tried to provide a clear technical description of extensions to help implementers produce interoperable implementations. Describing various scenarios an extension may be used in was not our main objective. There are other SDOs that reference STAMP and STAMP TLVs in their documents. I can mention BBF's WT-390.2 IP Performance Measurement from IP Edge to Customer Equipment using STAMP, and MEF's MEF-w66 Service OAM for IP Services. Both documents are in advanced phase and will be published later this year.

Especially for the people who have no background knowledge of each application scenario, maybe it is more hard for them to understand.
GIM>> Yes, you are correct. Standard documents require a certain level of knowledge in the particular area of the technology.

So I suggest for each TLV, there should have some pictures and background content to help people understand the TLV’s meaning and using method，it will be better.
GIM>> That is very helpful suggestion and I think that it can be a basis for the Applicability of STAMP document. Would you be interested in working on the new document together?

song>>We would like to work on the new document you mentioned，if there have some plan，we can discuss together.

By the way, I have some doubt about the Location TLV, which is the last-hop router, the reflector or the router before it? And how to indicate if the STAMP packets are send to the wrong Session-Reflector from this TLV?
GIM>> I hope that Henrik's response clarified one of the use case scenarios.

And another question is how to use Class of Service TLV to find the misconfigure problem, is it enough?
GIM>> One of the possible scenarios could be as follows:

  *   STAMP Sender sets DSCP1 to value A
  *   STAMP packet is transmitted with DSCP set to A
  *   STAMP Reflector copies DSCP value into DSCP2 field
  *   reflected STAMP packet is transmitted with DSCP set to A (as requested by the STAMP Sender)
  *   STAMP Sender receives the STAMP packet with DSCP A but DSCP2 value is B not as expected.
I hope this little example helps. Obviously, there are many ways to use the CoS TLV to test CoS mappings.
song>> the CoS mappings happened in Sender or other places, if DSCP value is not same with DSCP2 value, it means a error in which place?
song>> and for Access Report TLV, can you explain more, for example the location of sender and reflector both in user side, and how to find the reflector status changed, very thanks!

Thanks,
Yuezhong

发件人: ippm [mailto:[email-masked]<mailto:[email-masked]>] 代表 Ian Swett
发送时间: 2020年5月23日 5:26
收件人: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
主题: [ippm] WGLC for STAMP Extensions

Hi IPPM,

At our virtual interim meeting, we decided draft-ietf-ippm-stamp-option-tlv was ready for last call. This email starts a two-week WGLC for this draft.

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04

This last call will end on Monday, June 8th. Please reply to [email-masked]<mailto:[email-masked]> with your reviews and comments.

Thanks,
Ian & Tommy
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 11 Jun 2020 12:37:03 -0700

Hi Yali,
thank you for your questions. Please find my answers and notes below tagger
by GIM>>.

Regards,
Greg

On Tue, Jun 9, 2020 at 5:37 AM wangyali <[email-masked]> wrote:

> Hi Greg,
>
>
>
> Going over your discussion which is a good inspiration for me. And may I
> ask some questions as follows? Please see inline <Yali>.
>
>
>
> *From:* ippm [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Wednesday, June 3, 2020 3:49 AM
> *To:* Songyuezhong (songyuezhong, IP technology Research Dept) <
> [email-masked]>
> *Cc:* IETF IPPM WG ([email-masked]) <[email-masked]>; Ian Swett <ianswett=
> [email-masked]>
> *Subject:* Re: [ippm] 答复: WGLC for STAMP Extensions
>
>
>
> Hi Yuezhong,
>
> song>> the CoS mappings happened in Sender or other places, if DSCP value
> is not same with DSCP2 value, it means a error in which place?
>
> GIM2>> Let us assume that no CoS re-mapping expected along a path between
> the Sender and the Reflector. If the value in the DSCP2 field is different
> from the value set in the DSCP field by the Sender at the transmission,
> then the error is on the downstream leg of the path. If the value in the
> DSCP1 field is different from the value in the DSCP field of the reflected
> packet received by the Sender, then the error is on the upstream leg of the
> path. I'll note that CoS re-mapping may be used and then the determination
> of the error condition should be based on the expected behavior. I hope
> that helps..
>
> <Yali> how does the using CoS TLV in STAMP test help to diagnose the root
> cause of the problem that an excessive packet drop of higher level service
> while packet drop for lower service packets is at a normal level？Could
> you give some details about this?
>
GIM>> I think that the primary use case for the CoS extension is to verify,
for example, as part of the service activation testing, whether CoS marking
along the path is handled as expected. Also, CoS TLV can be used to monitor
the consistency of CoS mapping. The symptom that you've mentioned is very
typical in mobile multi-service backhaul when 2G, 3G, LTE, and now, 5G
services carried over the same path. Using the CoS extension, in our view,
would help an operator to perform the root cause analysis faster and be
more effective in localizing and repairing the problem.

>
> song>> and for Access Report TLV, can you explain more, for example the
> location of sender and reflector both in user side, and how to find the
> reflector status changed, very thanks!
>
> <Yali> As the value of the Access ID field and the Return Code field are
> set at the Session-Sender, e.g. UE, and the Session-Reflector sets the
> Access Report TLV having the same value of the Access ID and Return Code
> from the test packet it has received, so as my understand, the
> Session-Reflector can take use of the Access Report TLV to indicate changes
> to the access network status. But what is the application of the Access
> Report TLV in the reflected packet received by Session-Sender except
> disarming the timer?
>
>
>
> Why does it suggest the value of retransmission times to be four and the
> value of the retransmission timer to be three seconds? Are they
> experimental results or else?
>
GIM>> The Access Report TLV reflects the current 3GPP specification
(Rel.16). Other use cases for the Access Report TLV, in my opinion, could
be discussed and the required modifications specified in a new document. I
will be glad to discuss your ideas and suggestions.

>
>
> Thanks,
>
> Yali
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Jun 1, 2020 at 8:59 PM Songyuezhong (songyuezhong, IP technology
> Research Dept) <[email-masked]> wrote:
>
> Hi Greg,
>
> thanks for the reply from you and Ian, some of my questions have been
> answered, and there are still a few problems I don't understand,
>
> *发件人**:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2020年6月2日 0:03
> *收件人:* Songyuezhong (songyuezhong, IP technology Research Dept) <
> [email-masked]>
> *抄送:* Ian Swett <ianswett=[email-masked]>; IETF IPPM WG (
> [email-masked]) <[email-masked]>
> *主题:* Re: [ippm] 答复: WGLC for STAMP Extensions
>
>
>
> Hi Yuezhong,
>
> On Sat, May 30, 2020 at 4:56 AM Songyuezhong (songyuezhong, IP technology
> Research Dept) <[email-masked]> wrote:
>
> Hi Ian，
>
>
>
> For part 4,there list 8 new TLVs, but it seems not detailed enough for
> each TLV about the application scenario and some terms in it, we need guess
> to understand the whole plan.
>
> GIM>> We have tried to provide a clear technical description of extensions
> to help implementers produce interoperable implementations. Describing
> various scenarios an extension may be used in was not our main objective.
> There are other SDOs that reference STAMP and STAMP TLVs in their
> documents. I can mention BBF's WT-390.2 IP Performance Measurement from IP
> Edge to Customer Equipment using STAMP, and MEF's MEF-w66 Service OAM for
> IP Services. Both documents are in advanced phase and will be published
> later this year.
>
>
>
> Especially for the people who have no background knowledge of each
> application scenario, maybe it is more hard for them to understand.
>
> GIM>> Yes, you are correct. Standard documents require a certain level of
> knowledge in the particular area of the technology.
>
>
>
> So I suggest for each TLV, there should have some pictures and background
> content to help people understand the TLV’s meaning and using method，it
> will be better.
>
> GIM>> That is very helpful suggestion and I think that it can be a basis
> for the Applicability of STAMP document. Would you be interested in working
> on the new document together?
>
>
>
>    - STAMP Sender sets DSCP1 to value A
>    - STAMP packet is transmitted with DSCP set to A
>    - STAMP Reflector copies DSCP value into DSCP2 field
>    - reflected STAMP packet is transmitted with DSCP set to A (as
>    requested by the STAMP Sender)
>    - STAMP Sender receives the STAMP packet with DSCP A but DSCP2 value
>    is B not as expected.
>
> song>> the CoS mappings happened in Sender or other places, if DSCP value
> is not same with DSCP2 value, it means a error in which place?
>
> song>> and for Access Report TLV, can you explain more, for example the
> location of sender and reflector both in user side, and how to find the
> reflector status changed, very thanks!
>
>
>
> Thanks,
> Yuezhong
>
>
>
> *发件人**:* ippm [mailto:[email-masked]] *代表 *Ian Swett
> *发送时间:* 2020年5月23日 5:26
> *收件人:* IETF IPPM WG ([email-masked]) <[email-masked]>
> *主题:* [ippm] WGLC for STAMP Extensions
>
>
>
> Hi IPPM,
>
> At our virtual interim meeting, we decided
> draft-ietf-ippm-stamp-option-tlv was ready for last call. This email starts
> a two-week WGLC for this draft.
>
> The latest version can be found here:
> https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04
>
> This last call will end on *Monday, June 8th*. Please reply to
> [email-masked] with your reviews and comments.
>
> Thanks,
> Ian & Tommy
>
> [email-masked]

---

From: wangyali <[email-masked]>
Date: Fri, 12 Jun 2020 06:29:27 +0000

Hi Greg,
Thanks for your responses. I’m glad to join in the further discussion.

Best regards,
Yali

From: Greg Mirsky [mailto:[email-masked]]
Sent: Friday, June 12, 2020 3:37 AM
To: wangyali <[email-masked]>
Cc: Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>; Ian Swett <ianswett=[email-masked]>
Subject: Re: [ippm] Questions about STAMP Extensions 答复: WGLC for STAMP Extensions

Hi Yali,
thank you for your questions. Please find my answers and notes below tagger by GIM>>.

Regards,
Greg

On Tue, Jun 9, 2020 at 5:37 AM wangyali <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

From: ippm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Wednesday, June 3, 2020 3:49 AM
To: Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]<mailto:[email-masked]>>
Cc: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] 答复: WGLC for STAMP Extensions

Hi Yuezhong,

song>> the CoS mappings happened in Sender or other places, if DSCP value is not same with DSCP2 value, it means a error in which place?
GIM2>> Let us assume that no CoS re-mapping expected along a path between the Sender and the Reflector. If the value in the DSCP2 field is different from the value set in the DSCP field by the Sender at the transmission, then the error is on the downstream leg of the path. If the value in the DSCP1 field is different from the value in the DSCP field of the reflected packet received by the Sender, then the error is on the upstream leg of the path. I'll note that CoS re-mapping may be used and then the determination of the error condition should be based on the expected behavior. I hope that helps..
<Yali> how does the using CoS TLV in STAMP test help to diagnose the root cause of the problem that an excessive packet drop of higher level service while packet drop for lower service packets is at a normal level？Could you give some details about this?
GIM>> I think that the primary use case for the CoS extension is to verify, for example, as part of the service activation testing, whether CoS marking along the path is handled as expected. Also, CoS TLV can be used to monitor the consistency of CoS mapping. The symptom that you've mentioned is very typical in mobile multi-service backhaul when 2G, 3G, LTE, and now, 5G services carried over the same path. Using the CoS extension, in our view, would help an operator to perform the root cause analysis faster and be more effective in localizing and repairing the problem.

Why does it suggest the value of retransmission times to be four and the value of the retransmission timer to be three seconds? Are they experimental results or else?
GIM>> The Access Report TLV reflects the current 3GPP specification (Rel.16). Other use cases for the Access Report TLV, in my opinion, could be discussed and the required modifications specified in a new document. I will be glad to discuss your ideas and suggestions.

Thanks,
Yali

Regards,
Greg

Regards,
Yuezhong

Hi Yuezhong,

Regards,
Greg

Thanks,
Yuezhong

Hi IPPM,

Thanks,
Ian & Tommy