Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07

From: Greg Mirsky <[email-masked]>
Date: Thu, 13 Apr 2017 09:53:59 -0700

Dear All,
the new update of the TWAMP-Light YANG model
<https://tools.ietf.org/html/draft-mirsky-ippm-twamp-light-yang-08> has
been published. It includes the following:

   - packet loss ratio as decimal64 type with fraction-size 5;
   - session-reflector state parameter in session-sender container;
   - defined continuous and periodic modes to execute a test session and
   how performance metrics are calculated in each of the modes;
   - reporting of one-way packet loss metrics, both near-end and far-end,
   has dependency of reflector's mode.

Some questions still being discussed and we greatly appreciate suggestions,
comments:

   - include percentile in delay and delay-variation containers?
   - default value for session-timeout in session-sender container is 900
   seconds. Seems too big. What may be practical? Change units from seconds to
   centiseconds or milliseconds?

Regards,
Greg

On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell <[email-masked]> wrote:

> Some comments from the "field" as Accedian has several hundred thousand
> TWAMP sessions running (continously) at numerous Tier one mobile/fixed
> operators globally.
>
> On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S <[email-masked]>
> wrote:
>
>> Hi Greg,
>>
>>
>>
>> Thanks a lot for your response. Please see my reply inline tagged [WEI>>].
>>
>>
>>
>> Regards,
>>
>> Wei Luo
>>
>>
>>
>> *From:* Greg Mirsky [mailto:[email-masked]]
>> *Sent:* Tuesday, March 21, 2017 1:16 AM
>> *To:* Wei Luo S <[email-masked]>
>> *Cc:* [email-masked]; [email-masked]
>> *Subject:* Re: Some though on draft-mirsky-ippm-twamp-light-yang-07
>>
>>
>>
>> Hi Wei Luo,
>>
>> many thanks for your thorough review and the most helpful comments to the
>> TWAMP Light(Test) model. Please find my answers, notes in-line tagged GIM>>.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <[email-masked]>
>> wrote:
>>
>> Hi Greg & Adrian,
>>
>>
>>
>> This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson.
>> The current TWAMP Light YANG model is well defined. Thanks for your great
>> job.
>>
>> But by working closely with our customers, we got some new user cases on
>> TWAMP light. I believe these user cases are valuable and popular enough to
>> be modeled in TWAMP Light YANG. I hope I can be a contributor  and co-work
>> with you move this draft forward.
>>
>> I  drafted a new version of the TWAMP light YANG model based on version
>> [email-masked]. Could you please comments on it? Any
>> discussion is welcome.
>>
>> The draft yang model and tree is attached. To make you find the updates
>> quickly, I highlighted all the updates in file
>> ietf-twamp-light-weiluo.pdf.
>>
>>
>>
>> The following are the list of main updates:
>>
>> *1. Add a new typedef: percent. This is a new type defined for packet
>> loss ratio.*
>>
>> Consideration:
>>
>> 1). From the customer perspective, packet loss ratio is a more meaningful
>> data. In most of the time, the absolute number is meaningless to user,
>> especially they do the TWAMP test continuously. They are more care about
>> the ratio than the absolute number. So adding it makes this model more
>> friendly to customer;
>>
>> 2). From the service layer assurance(SLA) perspective, the packet loss
>> ratio is a major measures. So with adding packet loss ratio in model, the
>> TWAMP can work in SLA framework more smoothly.
>>
>> 3). It seems some similar protocol’s YANG model has the same definition,
>> e.g. ‘Service OAM Performance Monitoring YANG Module’,
>> https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf.
>>
>> Agreed packet loss is important, however another important loss metric is
> loss burst size (max/min) and number of loss bursts. A loss burst of 10
> consecutive TWAMP-test packets can be deemed more serious than 10 lost
> packets spread evenly over the report interval.
>
>> GIM>> Indeed, packet loss more often expressed as packet loss ratio
>> rather than as the absolute number. It would be most helpful to hear from
>> network operators if they see introduction of Packet Loss Ratio into the
>> TWAMP model helpful.
>>
>> *2. Add a new typedef: state-mode. It defines a common type for
>> stateful/stateless reflector. This type will be used in both sender session
>> and reflector session.*
>>
>> Consideration:
>>
>> If the reflector is stateful, the TWAMP light can measure more items,
>> e.g. one way packet loss. So for sender, the stats calculation and show is
>> different. When the reflector is stateless, it doesn’t need to calculate
>> the one way packet loss. The one way packet loss is invalid and shouldn’t
>> be presented to customer. When the reflector is stateless, the sender needs
>> to calculate the one way packet loss. And the data should be present to
>> customer. So this is used as a ‘when’ condition in the model’s RO tree.
>>
>> GIM>> Yes, if Session-Sender is aware of the mode corresponding
>> Session-Reflector operates, the sender may avoid calculation of some
>> performance metrics, e.g., one-way packet loss. On the other hand, the
>> orchestrator is aware of the state-mode and should be capable to properly
>> use metrics reported by the Session-Sender.
>>
>> [WEI>>] Yes, the orchestrator could know that. But from the model side,
>> this is not correct.  The model should represent the right behavior and
>> shouldn’t do assumption on orchestrator.
>>
> I agree the model should describe both one-way loss metrics and roundtrip
> loss metrics, and the sender should be able to use either mode when
> calculating, potentially also populating the roundtrip delay values with
> proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that
> would indicate buffer load/CPU load in the TWAMP responders processing time.
>
>> *3. Add a new typedef: send-mode. This is a new type for sender session.
>> It makes the sender session can send packet continuously and monitor the
>> network all the time.*
>>
>> Consideration:
>>
>> The user case is that: the user runs TWAMP light sessions to watch links
>> quality continuously. The session number could be very big. These TWAMP
>> sessions are managed by SLA framework or similar. SLA retrieves the stats
>> from TWAMP periodically, e.g. 15mins. In other words, all the performance
>> metrics are calculated based on the packets sent/received within 15mins.
>> This makes the calculation become possible. With the periodical stats data,
>> the Network Management software can do further actions if some abnormal
>> stats observed.  This is a more general user case in customer site. While
>> the non-continuous TWAMP sender session is generally used for debugging
>> purpose on a link.
>>
>> GIM>> I think that support of continuous measurement is in LMAP domain,
>> not for TWAMP Test data model. To conduct continuous measurement he LMAP
>> Controller, in my opinion, programs the Measurement Agent to perform TWAMP
>> Test session with certain set of parameters and repeat it without any
>> interval (interval = 0).
>>
>
> Many operators use TWAMP in continous mode, not only with Accedian test
> points and report at fixed intervals, typically ranging from 5s to 5 or 15
> minutes, with 1-minute being the most popular granularity currently. The
> advantage is that the result calculation can be handled separately from the
> TWAMP-test sending/recieving, so that there is no parallelism required to
> monitor 24/7. If a start-stop-based methodology is used, the sender needs
> to start up the new test session even before the previous one has ended,
> since the previous session needs to wait X seconds (or at least Y 100s of
> milliseconds) before it stops waiting for packets to come back. And this
> new session needs to have a different signature in order for the sender to
> discern which packets belong to the previous interval and which belong to
> the current.
>
> In a continous test-model, the sender can just simply record the sequence
> number of the last packet transmitted in the interval to be reported, wait
> for it to come back, or a MAXTIME, then report that result, while
> continuing to transmit for the next interval.
>
> If the "interval==0" parameter is intended to be used for continous type
> tests, then what parameter should indicate to the sender at what intervals
> to produce results?
>
>> *4. Add a new group: packet-loss-statistics. It grouping two packet loss
>> statistics: loss-count and loss-ratio. This group will be used in RO stats
>> tree.*
>>
>> GIM>> I'd like to continue discussion.
>>
>> [WEI>>] OK.
>>
>> *5. Move leaf dscp out from grouping session-light-parameters. The leaf
>> dscp is only valid when the dscp-handling-mode is use-configured-value. A
>> when condition shall be added to it. So it can’t be in this group.*
>>
>> GIM>> I'm concerned that then the model will not be able to support
>> concurrent TWAMP Test sessions between the same pair of Test Points (IP
>> address+port number) at different CoS markings.
>>
>> [WEI>>] Actually, I have concern on using five tuple(IP address+port
>> number+dscp) to identify a TWAMP test session. The DSCP is not a constant
>> value in packet. It could be modified by the routers in the path. For
>> example, the sender has two sessions: session A’s five tuple is:
>> Sip=1.1.1.1, Dip=2.2.2.2, Sport=50000, Dport=50001, DSCP=cs2. Session B’s
>> five tuple is: Sip=1.1.1.1, Dip=2.2.2.2, Sport=50000, Dport=50001,
>> DSCP=cs3. The only difference between session A and session B is DSCP. If
>> the test packet’s DSCP of session B is modified to cs2 by a router in the
>> path. The five tuples are exactly the same for reflector. It can’t
>> differentiate which packet is from session A, which packet is from session
>> B. It could mess the reflector’s session sequence number. And also, the
>> sender will be messed because the received reply packet’s five tuple are
>> exactly the same.
>>
>> So I think it’s more reasonable to use four tuple to identify a session.
>>
>
> Yes, this would be appreciated by users. Changes in DSCP is a reasonably
> common network error that users can detect with continous TWAMP monitoring,
> thus it is good to not include the DSCP value as part of the "session
> identifiier" but instead use 4-tuple with UDP source port to identify
> several parallel flows between the same sender and responder.
>
>> *6. Add leaf 'session-packet-send-mode' to
>> /twamp-light/twamp-light-session-sender/test-session*. This leaf specifies
>> the sender session's packet send mode: continuous or non-continuous.*
>>
>> GIM>> As discussed in #3, I think that it is already part of LMAP YANG
>> model.
>>
>> *7. Add leaf 'reflector-light-mode-state' to
>> /twamp-light/twamp-light-session-sender/test-session*. This leaf indicates
>> the the reflector's mode: stateful or stateless. If the reflector's mode is
>> stateful. Two one way packet loss statistics can be got:
>> one-way-packet-loss-far-end, one-way-packet-loss-near-end.*
>>
>> Consideration:
>>
>> Only valid data should be presented to user. Otherwise it could
>> misleading user in some cases.
>>
>> GIM>> A in response to #2.
>>
>> *8. Modify leaf
>> /twamp-light/twamp-light-session-sender/test-session*/number-of-packets.
>> Add a 'when' condition to this leaf. When send-mode is 'continuous', the
>> leaf number-of-packets is meaningless. So add a 'when' condition to limit
>> it.  Besides, added a default value ‘10’ to it. When the send-mode is
>> 'non-continuous', the session can't work with an empty number-of-packets.*
>>
>> GIM>> As I've noted in #3. Will add default.
>>
>> *9. Add leaf time out to
>> /twamp-light/twamp-light-session-sender/test-session*. A timeout mechanism
>> is needed when the sender session can't get all the reply packets for a
>> long time.*
>>
>> GIM>> Thank you, will add in the next update.
>>
>> *10. Modify leaf
>> /twamp-light/twamp-light-session-sender/test-session*/interval. Change the
>> units from ‘microseconds’ to ‘milliseconds’. Add a default value 1000. *
>>
>> Consideration:
>>
>>     1). The aim of TWAMP is to measure network quality, but not fast
>> failure detection. So a millisecond packet interval is enough.
>>
>>     2). Interval is a necessary parameter for a session. A sender session
>> can't work with an empty packet send interval. So added a default value to
>> it.
>>
>> GIM>> Thank you. We've made units of interval microseconds in the last
>> update already. I think that changing to milliseconds may be too
>> restrictive, limit use cases for TWAMP Test. Will add default value with
>> the next update.
>>
>> [WEI>>] Sorry, I do not see the reason. Are there any user cases to use
>> microseconds?
>>
>> *11. Add leaf 'dscp' to
>> /twamp-light/twamp-light-session-sender/test-session*. This is the leaf
>> moved out from grouping session-light-parameters.*
>>
>> GIM>> As noted in response #5, the change may limit ability to run
>> concurrent TWAMP Test sessions per CoS. I consider that to be valuable mode
>> but would like to hear from network operators if that is indeed useful
>> information.
>>
>
> See my comment above. I argue that it is useful to keep track of changing
> DSCP values, and treating DSCP as a metric of the TWAMP Session just like
> loss and delay
>
>> *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and
>> 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to
>> /twamp-light/twamp-light-session-reflector/test-session*. These three
>> attributes should be session specific. Different session could have
>> different values. They are not common attributes.*
>>
>> GIM>> Agree, will make it in the next update.
>>
>> *13. Add leaf 'dscp' to
>> /twamp-light/twamp-light-session-reflector/test-session*. This is the leaf
>> moved out from grouping session-light-parameters. Besides the movement,
>> added a 'when' condition to the leaf 'dscp'. This leaf is only valid when
>> the dscp-handling-mode is 'use-configured-value'.*
>>
>> GIM>> As response to #5.
>>
>> *14. Modify leaf
>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/number-of-packets.
>> Add a 'when' condition to this leaf. When send-mode is 'continuous', the
>> leaf number-of-packets is meaningless.*
>>
>> GIM>> Similar to #3.
>>
>> *15. Modify leaf
>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/interval.
>> Change the units from microseconds to milliseconds.*
>>
>> GIM>> I think that microseconds is reasonable.
>>
>> *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and
>> 'one-way-packet-loss-near-end' to
>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/.
>> These are the new statistics for stateful reflector.*
>>
>> GIM>> Thank you, will be coming in the next update.
>>
>> *17. Remove leaf loss-packet in
>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats.
>> The loss packeted is replaced with 'two-way-packet-loss' stated above.*
>>
>> GIM>> Agree.
>>
>> *18. Modify leaf to
>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/history-stats*/interval.
>> Change the units from microseconds to milliseconds.*
>>
>> GIM>> I think that will limit applicability of TWAMP Test.
>>
>> *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and
>> 'one-way-packet-loss-near-end' to
>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/history-stats*/.
>> These are the new statistics for stateful reflector.*
>>
>> GIM>> Agree.
>>
>>
>>
>> Thanks,
>>
>> Wei Luo
>>
>>
>>
>> _______________________________________________
>> ippm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>>
>
>
> --
>
>
>
> Henrik Nydell
>
> Sr Manager Global Strategy & Solutions
>
> Cell
>
> Email
>
> Skype
>
> +46 709845992 <+46%2070%20984%2059%2092>
>
> [email-masked] <[email-masked]>
>
> h <http://linkedin.com/in/maekowalk>nydell
>
>
> <http://accedian.com/> <http://blog.accedian.com/>
> <https://www.linkedin.com/company/accedian-networks>
> <https://twitter.com/Accedian>   <https://www.facebook.com/accedian>
> <http://www.youtube.com/user/accedian>
>
>
>
> 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.
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>
>

---

From: Henrik Nydell <[email-masked]>
Date: Tue, 18 Apr 2017 13:58:42 +0200

I would ask you to consider adding some more valuable metrics
1) Loss burst size max

        leaf loss-burst-max {
                type int32;
                description
                "Highest number of lost packets back-to-back during interval.";
        }

2) Loss burst count (tells how many instances there was of packet loss
during an interval, one "instance" means one or more consecutive packets
lost.

        leaf loss-burst-count {
                type int32;
                description
                "Number of occasions with packet loss during interval.";
        }

To further explain the above metrics, consider 60-second interval below
with 1 packet per second monitoring, where x means lost packet and o means
recieved.

0                                                           60s
oooXooXooooXXXXooooooooooXXoooooXoooXooooooooXXXXXXXXXXXXooo

This 60s-interval has 22 lost packets ( 22/60 =36.67% loss)
Loss burst max is 12 packets, number of loss instances are 7

3) Percentiles are very useful and important. If they cannot be
"configurable" in the Yang model I would suggest you to consider adding at
least the 95th, 99th and 99.9th percentiles for all delay type metrics.

On Thu, Apr 13, 2017 at 6:53 PM, Greg Mirsky <[email-masked]> wrote:

> Some questions still being discussed and we greatly appreciate
> suggestions, comments:
>
>>> many thanks for your thorough review and the most helpful comments to
>>> the TWAMP Light(Test) model. Please find my answers, notes in-line tagged
>>> GIM>>.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> 1). From the customer perspective, packet loss ratio is a more
>>> meaningful data. In most of the time, the absolute number is meaningless to
>>> user, especially they do the TWAMP test continuously. They are more care
>>> about the ratio than the absolute number. So adding it makes this model
>>> more friendly to customer;
>>>
>>> Agreed packet loss is important, however another important loss metric
>> is loss burst size (max/min) and number of loss bursts. A loss burst of 10
>>>     2). Interval is a necessary parameter for a session. A sender
>>> session can't work with an empty packet send interval. So added a default
>>> value to it.
>>>
>> 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

-- 

Henrik Nydell

Cell

Email

Skype

+46 709845992

-- 

Avis de confidentialité

Confidentiality notice

---

From: Wei Luo S <[email-masked]>
Date: Wed, 19 Apr 2017 01:24:58 +0000

Please see my comments inline.

Thanks,
Wei Luo

From: Henrik Nydell [mailto:[email-masked]]
Sent: Tuesday, April 18, 2017 7:59 PM
To: Greg Mirsky <[email-masked]>
Cc: Wei Luo S <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07

        leaf loss-burst-max {

                type int32;

                description

        }
[WEI] Agree, it’s valuable, I think we should add it. Besides, I suggest to add one more metrics: loss-burst-min, which is the minimum  number of lost packets back-to-back during interval.

2) Loss burst count (tells how many instances there was of packet loss during an interval, one "instance" means one or more consecutive packets lost.

        leaf loss-burst-count {

                type int32;

                description

        }

To further explain the above metrics, consider 60-second interval below with 1 packet per second monitoring, where x means lost packet and o means recieved.

0                                                           60s

[WEI] Agree. It should be added. For stateful reflector, two more metrics can be added: loss-burst-count-far-end, loss-burst-count-near-end.

3) Percentiles are very useful and important. If they cannot be "configurable" in the Yang model I would suggest you to consider adding at least the 95th, 99th and 99.9th percentiles for all delay type metrics.
[WEI] Could you explain the meaning of “percentile” here?

On Thu, Apr 13, 2017 at 6:53 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Dear All,
the new update of the TWAMP-Light YANG model<https://tools.ietf.org/html/draft-mirsky-ippm-twamp-light-yang-08> has been published. It includes the following:

  *   packet loss ratio as decimal64 type with fraction-size 5;
  *   session-reflector state parameter in session-sender container;
  *   defined continuous and periodic modes to execute a test session and how performance metrics are calculated in each of the modes;
  *   reporting of one-way packet loss metrics, both near-end and far-end, has dependency of reflector's mode.
Some questions still being discussed and we greatly appreciate suggestions, comments:

  *   include percentile in delay and delay-variation containers?
  *   default value for session-timeout in session-sender container is 900 seconds. Seems too big. What may be practical? Change units from seconds to centiseconds or milliseconds?
Regards,
Greg

On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell <[email-masked]<mailto:[email-masked]>> wrote:
Some comments from the "field" as Accedian has several hundred thousand TWAMP sessions running (continously) at numerous Tier one mobile/fixed operators globally.

On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Regards,
Wei Luo

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 21, 2017 1:16 AM
To: Wei Luo S <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Some though on draft-mirsky-ippm-twamp-light-yang-07

Hi Wei Luo,
many thanks for your thorough review and the most helpful comments to the TWAMP Light(Test) model. Please find my answers, notes in-line tagged GIM>>.

Regards,
Greg

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg & Adrian,

This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. The current TWAMP Light YANG model is well defined. Thanks for your great job.
But by working closely with our customers, we got some new user cases on TWAMP light. I believe these user cases are valuable and popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor  and co-work with you move this draft forward.
I  drafted a new version of the TWAMP light YANG model based on version [email-masked]<mailto:[email-masked]>. Could you please comments on it? Any discussion is welcome.
The draft yang model and tree is attached. To make you find the updates quickly, I highlighted all the updates in file ietf-twamp-light-weiluo.pdf.

The following are the list of main updates:
1. Add a new typedef: percent. This is a new type defined for packet loss ratio.
Consideration:
1). From the customer perspective, packet loss ratio is a more meaningful data. In most of the time, the absolute number is meaningless to user, especially they do the TWAMP test continuously. They are more care about the ratio than the absolute number. So adding it makes this model more friendly to customer;
2). From the service layer assurance(SLA) perspective, the packet loss ratio is a major measures. So with adding packet loss ratio in model, the TWAMP can work in SLA framework more smoothly.
3). It seems some similar protocol’s YANG model has the same definition, e.g. ‘Service OAM Performance Monitoring YANG Module’, https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf.
Agreed packet loss is important, however another important loss metric is loss burst size (max/min) and number of loss bursts. A loss burst of 10 consecutive TWAMP-test packets can be deemed more serious than 10 lost packets spread evenly over the report interval.
GIM>> Indeed, packet loss more often expressed as packet loss ratio rather than as the absolute number. It would be most helpful to hear from network operators if they see introduction of Packet Loss Ratio into the TWAMP model helpful.
2. Add a new typedef: state-mode. It defines a common type for stateful/stateless reflector. This type will be used in both sender session and reflector session.
Consideration:
If the reflector is stateful, the TWAMP light can measure more items, e.g. one way packet loss. So for sender, the stats calculation and show is different. When the reflector is stateless, it doesn’t need to calculate the one way packet loss. The one way packet loss is invalid and shouldn’t be presented to customer. When the reflector is stateless, the sender needs to calculate the one way packet loss. And the data should be present to customer. So this is used as a ‘when’ condition in the model’s RO tree.
GIM>> Yes, if Session-Sender is aware of the mode corresponding Session-Reflector operates, the sender may avoid calculation of some performance metrics, e.g., one-way packet loss. On the other hand, the orchestrator is aware of the state-mode and should be capable to properly use metrics reported by the Session-Sender.
[WEI>>] Yes, the orchestrator could know that. But from the model side, this is not correct.  The model should represent the right behavior and shouldn’t do assumption on orchestrator.
I agree the model should describe both one-way loss metrics and roundtrip loss metrics, and the sender should be able to use either mode when calculating, potentially also populating the roundtrip delay values with proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that would indicate buffer load/CPU load in the TWAMP responders processing time.
3. Add a new typedef: send-mode. This is a new type for sender session. It makes the sender session can send packet continuously and monitor the network all the time.
Consideration:
The user case is that: the user runs TWAMP light sessions to watch links quality continuously. The session number could be very big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. In other words, all the performance metrics are calculated based on the packets sent/received within 15mins. This makes the calculation become possible. With the periodical stats data, the Network Management software can do further actions if some abnormal stats observed.  This is a more general user case in customer site. While the non-continuous TWAMP sender session is generally used for debugging purpose on a link.
GIM>> I think that support of continuous measurement is in LMAP domain, not for TWAMP Test data model. To conduct continuous measurement he LMAP Controller, in my opinion, programs the Measurement Agent to perform TWAMP Test session with certain set of parameters and repeat it without any interval (interval = 0).

Many operators use TWAMP in continous mode, not only with Accedian test points and report at fixed intervals, typically ranging from 5s to 5 or 15 minutes, with 1-minute being the most popular granularity currently. The advantage is that the result calculation can be handled separately from the TWAMP-test sending/recieving, so that there is no parallelism required to monitor 24/7. If a start-stop-based methodology is used, the sender needs to start up the new test session even before the previous one has ended, since the previous session needs to wait X seconds (or at least Y 100s of milliseconds) before it stops waiting for packets to come back. And this new session needs to have a different signature in order for the sender to discern which packets belong to the previous interval and which belong to the current.

In a continous test-model, the sender can just simply record the sequence number of the last packet transmitted in the interval to be reported, wait for it to come back, or a MAXTIME, then report that result, while continuing to transmit for the next interval.

If the "interval==0" parameter is intended to be used for continous type tests, then what parameter should indicate to the sender at what intervals to produce results?
4. Add a new group: packet-loss-statistics. It grouping two packet loss statistics: loss-count and loss-ratio. This group will be used in RO stats tree.
GIM>> I'd like to continue discussion.
[WEI>>] OK.
5. Move leaf dscp out from grouping session-light-parameters. The leaf dscp is only valid when the dscp-handling-mode is use-configured-value. A when condition shall be added to it. So it can’t be in this group.
GIM>> I'm concerned that then the model will not be able to support concurrent TWAMP Test sessions between the same pair of Test Points (IP address+port number) at different CoS markings.
[WEI>>] Actually, I have concern on using five tuple(IP address+port number+dscp) to identify a TWAMP test session. The DSCP is not a constant value in packet. It could be modified by the routers in the path. For example, the sender has two sessions: session A’s five tuple is: Sip=1.1.1.1, Dip=2.2.2.2, Sport=50000, Dport=50001, DSCP=cs2. Session B’s five tuple is: Sip=1.1.1.1, Dip=2.2.2.2, Sport=50000, Dport=50001, DSCP=cs3. The only difference between session A and session B is DSCP. If the test packet’s DSCP of session B is modified to cs2 by a router in the path. The five tuples are exactly the same for reflector. It can’t differentiate which packet is from session A, which packet is from session B. It could mess the reflector’s session sequence number. And also, the sender will be messed because the received reply packet’s five tuple are exactly the same.
So I think it’s more reasonable to use four tuple to identify a session.

Yes, this would be appreciated by users. Changes in DSCP is a reasonably common network error that users can detect with continous TWAMP monitoring, thus it is good to not include the DSCP value as part of the "session identifiier" but instead use 4-tuple with UDP source port to identify several parallel flows between the same sender and responder.
6. Add leaf 'session-packet-send-mode' to /twamp-light/twamp-light-session-sender/test-session*. This leaf specifies the sender session's packet send mode: continuous or non-continuous.
GIM>> As discussed in #3, I think that it is already part of LMAP YANG model.
7. Add leaf 'reflector-light-mode-state' to /twamp-light/twamp-light-session-sender/test-session*. This leaf indicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can be got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.
Consideration:
Only valid data should be presented to user. Otherwise it could misleading user in some cases.
GIM>> A in response to #2.
8. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless. So add a 'when' condition to limit it.  Besides, added a default value ‘10’ to it. When the send-mode is 'non-continuous', the session can't work with an empty number-of-packets.
GIM>> As I've noted in #3. Will add default.
9. Add leaf time out to /twamp-light/twamp-light-session-sender/test-session*. A timeout mechanism is needed when the sender session can't get all the reply packets for a long time.
GIM>> Thank you, will add in the next update.
10. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/interval. Change the units from ‘microseconds’ to ‘milliseconds’. Add a default value 1000.
Consideration:
    1). The aim of TWAMP is to measure network quality, but not fast failure detection. So a millisecond packet interval is enough.
    2). Interval is a necessary parameter for a session. A sender session can't work with an empty packet send interval. So added a default value to it.
GIM>> Thank you. We've made units of interval microseconds in the last update already. I think that changing to milliseconds may be too restrictive, limit use cases for TWAMP Test. Will add default value with the next update.
[WEI>>] Sorry, I do not see the reason. Are there any user cases to use microseconds?
11. Add leaf 'dscp' to /twamp-light/twamp-light-session-sender/test-session*. This is the leaf moved out from grouping session-light-parameters.
GIM>> As noted in response #5, the change may limit ability to run concurrent TWAMP Test sessions per CoS. I consider that to be valuable mode but would like to hear from network operators if that is indeed useful information.

See my comment above. I argue that it is useful to keep track of changing DSCP values, and treating DSCP as a metric of the TWAMP Session just like loss and delay
12. Move leaves 'ref-wait', 'reflector-light-mode-state' and 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to /twamp-light/twamp-light-session-reflector/test-session*. These three attributes should be session specific. Different session could have different values. They are not common attributes.
GIM>> Agree, will make it in the next update.
13. Add leaf 'dscp' to /twamp-light/twamp-light-session-reflector/test-session*. This is the leaf moved out from grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only valid when the dscp-handling-mode is 'use-configured-value'.
GIM>> As response to #5.
14. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/number-of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.
GIM>> Similar to #3.
15. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/interval. Change the units from microseconds to milliseconds.
GIM>> I think that microseconds is reasonable.
16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end' to /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/. These are the new statistics for stateful reflector.
GIM>> Thank you, will be coming in the next update.
17. Remove leaf loss-packet in /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats. The loss packeted is replaced with 'two-way-packet-loss' stated above.
GIM>> Agree.
18. Modify leaf to /twamp-light-state/twamp-light-session-sender-state/test-session-state*/history-stats*/interval. Change the units from microseconds to milliseconds.
GIM>> I think that will limit applicability of TWAMP Test.
19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end' to /twamp-light-state/twamp-light-session-sender-state/test-session-state*/history-stats*/. These are the new statistics for stateful reflector.
GIM>> Agree.

Thanks,
Wei Luo

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

--

[Accedian.com]

Henrik Nydell

Cell

Email

Skype

+46 709845992<tel:+46%2070%20984%2059%2092>

[email-masked]<mailto:[email-masked]>

h<http://linkedin.com/in/maekowalk>nydell

[https://lh4.googleusercontent.com/rYMX9Bq5MSwpoyECOyWeco2zNSgmt33L2eLHGPWzUUnvV2lcQtl3wsUpSHtIUoxrBVhzCK-eNko_EFvLFDuJ_SXNwH8umjesy5j08yPYyp1KPTmDevyFKE7gvsbR_1n_CWH57gLm]<http://accedian.com/>[https://lh6.googleusercontent.com/RrCnBjHMnhWiVkDeACpl0c-565qL0yGzH6-FxUlWY2ewsaIxucUfv8XDIfZMscTMjLz5ruS1n8nYCrYo5vj0W5sxPk_1MovBbUdnxki5KV8O63nf6NQ5KoWwMVZEYo4KaJMxzlqg]<http://blog.accedian.com/> [https://lh4.googleusercontent.com/A9cPy0TEBII_Fq9KzCqQlaAN36OMh8pi-sDbkVeaLUtYblIV0rlANVxzcGxBx8D0oAjqvbBYbl7D3UhFnlk8OlClv0-dihI2wQi-fsxPBPL7rbdjnvuyuDNwjzVkEzq7kFkPeSZS] <https://www.linkedin.com/company/accedian-networks>   [https://lh4.googleusercontent.com/MD1lal7Io30a7lK8WUlYG2y6fsndCmkksiJ1vWb4QSGftTDxTsuLDIGRIknkI7fgpFs6G0PaPvx9ol6kBChgFSgxQBOgXlwFDp3cqxoc3EXO7vVBqeZCl60DUz6o-_H4jeAjmN5n] <https://twitter.com/Accedian>   [https://lh6.googleusercontent.com/j9J6FxGoe-UQmEU-2TYHtV2bHwn5bWBQVJ4E9Xxx8e-x3Ao-xknZJbXR1dPfeVAt7WIzbtl27yXn3bXlauF-cJGcOT0OLotU-X0mMp79pVv8CZZm_DuyKzRvEWvahie2Lbd9n0YJ] <https://www.facebook.com/accedian>   [https://lh5.googleusercontent.com/IJmGWXmmsC0zkQZN1tS7AUNQ0Qudhdwf60t6wLg_qvCl4d5mSjzSAouTcCEl7lRjNESieG6ZiGhgQnFXHpdvzTYNNTUOqfUWD-6KbGwGxm2jM0KqQoMKO6vkcQ5iKQ2cpJ79y84G] <http://www.youtube.com/user/accedian>

[https://lh4.googleusercontent.com/SF6ptcTujM24g-7TL3cL5CMFHqwgFi2kSFnZl6OS6Ha_eW6f8zP27iyCTL7o5b5vlb5p433wGrDkZkbBFaXAFjxlMgncOla9ET7v-771Evv4s58B9D6PGjAUDO9dZZ8laKI081Ur]

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.

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

--

[Accedian.com]

Henrik Nydell

Cell

Email

Skype

+46 709845992

[email-masked]<mailto:[email-masked]>

h<http://linkedin.com/in/maekowalk>nydell

[https://lh4.googleusercontent.com/rYMX9Bq5MSwpoyECOyWeco2zNSgmt33L2eLHGPWzUUnvV2lcQtl3wsUpSHtIUoxrBVhzCK-eNko_EFvLFDuJ_SXNwH8umjesy5j08yPYyp1KPTmDevyFKE7gvsbR_1n_CWH57gLm]<http://accedian.com/>[https://lh6.googleusercontent.com/RrCnBjHMnhWiVkDeACpl0c-565qL0yGzH6-FxUlWY2ewsaIxucUfv8XDIfZMscTMjLz5ruS1n8nYCrYo5vj0W5sxPk_1MovBbUdnxki5KV8O63nf6NQ5KoWwMVZEYo4KaJMxzlqg]<http://blog.accedian.com/> [https://lh4.googleusercontent.com/A9cPy0TEBII_Fq9KzCqQlaAN36OMh8pi-sDbkVeaLUtYblIV0rlANVxzcGxBx8D0oAjqvbBYbl7D3UhFnlk8OlClv0-dihI2wQi-fsxPBPL7rbdjnvuyuDNwjzVkEzq7kFkPeSZS] <https://www.linkedin.com/company/accedian-networks>   [https://lh4.googleusercontent.com/MD1lal7Io30a7lK8WUlYG2y6fsndCmkksiJ1vWb4QSGftTDxTsuLDIGRIknkI7fgpFs6G0PaPvx9ol6kBChgFSgxQBOgXlwFDp3cqxoc3EXO7vVBqeZCl60DUz6o-_H4jeAjmN5n] <https://twitter.com/Accedian>   [https://lh6.googleusercontent.com/j9J6FxGoe-UQmEU-2TYHtV2bHwn5bWBQVJ4E9Xxx8e-x3Ao-xknZJbXR1dPfeVAt7WIzbtl27yXn3bXlauF-cJGcOT0OLotU-X0mMp79pVv8CZZm_DuyKzRvEWvahie2Lbd9n0YJ] <https://www.facebook.com/accedian>   [https://lh5.googleusercontent.com/IJmGWXmmsC0zkQZN1tS7AUNQ0Qudhdwf60t6wLg_qvCl4d5mSjzSAouTcCEl7lRjNESieG6ZiGhgQnFXHpdvzTYNNTUOqfUWD-6KbGwGxm2jM0KqQoMKO6vkcQ5iKQ2cpJ79y84G] <http://www.youtube.com/user/accedian>

[https://lh4.googleusercontent.com/SF6ptcTujM24g-7TL3cL5CMFHqwgFi2kSFnZl6OS6Ha_eW6f8zP27iyCTL7o5b5vlb5p433wGrDkZkbBFaXAFjxlMgncOla9ET7v-771Evv4s58B9D6PGjAUDO9dZZ8laKI081Ur]

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.

---

From: Henrik Nydell <[email-masked]>
Date: Wed, 19 Apr 2017 09:43:08 +0200

Please see my clarifications inline

Thanks
Henrik

On Wed, Apr 19, 2017 at 3:24 AM, Wei Luo S <[email-masked]> wrote:

> *From:* Henrik Nydell [mailto:[email-masked]]
> *Sent:* Tuesday, April 18, 2017 7:59 PM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* Wei Luo S <[email-masked]>; draft-mirsky-ippm-twamp-light-
> [email-masked]; [email-masked]
> *Subject:* Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07
>
>
>
> [WEI] Agree, it’s valuable, I think we should add it. Besides, I suggest
> to add one more metrics: loss-burst-min, which is the minimum  number of
> lost packets back-to-back during interval.
>

 [HN] I Agree loss-burst-min is also an important metric for gap analysis

> [WEI] Agree. It should be added. For stateful reflector, two more metrics
> can be added: loss-burst-count-far-end, loss-burst-count-near-end.
>
>
>

[HN] Instead of just reporting the min/max/avg values;

+--ro one-way-delay-far-end
       |     |  |  +--ro delay
       |     |  |  |  +--ro min?   yang:gauge32
       |     |  |  |  +--ro max?   yang:gauge32
       |     |  |  |  +--ro avg?   yang:gauge32
       |     |  |  +--ro delay-variation
       |     |  |     +--ro min?   uint32
       |     |  |     +--ro max?   uint32
       |     |  |     +--ro avg?   uint32

A percentile gives more granularity. Percentile 95 for delay means that out
of all samples in the interval, if you remove the 5% highest, then the next
largest delay value is p95. So a delay value of 23.412ms at p95 means that
95% of the delay samples during the interval were lower than or equal to
23.412ms.

Using percentiles allows for filtering out spikes, instead reporting on
"bulk" delay during an interval. Especcially useful for SLA/SLO-based
monitoring where you do not necessarily want to raise an alarm on a max
spike that was caused by a single packet being delayed, but instead look at
percentile 95 or 99 or 99.5 depending on what resolution you want.

Many protocols and functions use a percentile so define in which range the
protocol or function operates well. One example is from the mobile world,
where Ericsson and others define the RAN requirements in terms of delay and
delay variation with percentiles. I.e it is OK that a few packets break the
delay limit, as long as 99% don't (p99).

Many operators use continous TWAMP monitoring with quite high packet rates,
like 50 packets per second. With 60 second interval reporting, this means
3,000 samples per interval, giving plenty of room to calculate 99.9
percentile (removing 3 highest samples out of the 3,000)

For a standardized Yang model the best would of course be if these
percentiles were not statically defined, but could be configurable
depending on what the user wants to see. For sake of simpicity I think
three definable percentiles would be sufficient.
percentile-a [0.1 .. 99.9]
percentile-b [0.1 .. 99.9]
percentile-c [0.1 .. 99.9]

And these three then reported (if implemented by the TWAMP sender) for both
roundtrip, far-end and near-end. and for both delay and delay-variation
metrics.

> On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <[email-masked]> wrote:
>
> Hi Greg & Adrian,
>
>
>
> This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. The
> current TWAMP Light YANG model is well defined. Thanks for your great job.
>
> *1. Add a new typedef: percent. This is a new type defined for packet loss
> ratio.*
>
> Consideration:
>
> GIM>> Indeed, packet loss more often expressed as packet loss ratio rather
> than as the absolute number. It would be most helpful to hear from network
> operators if they see introduction of Packet Loss Ratio into the TWAMP
> model helpful.
>
> If the reflector is stateful, the TWAMP light can measure more items, e.g.
> one way packet loss. So for sender, the stats calculation and show is
> *Henrik Nydell*
> *Cell*
> *Email*
> *Skype*
> *+46 709845992 <+46%2070%20984%2059%2092>*
>
> [email-masked] <[email-masked]>*
>
> *h <http://linkedin.com/in/maekowalk>nydell*
>
>
>
> *Henrik Nydell*
> *Cell*
> *Email*
> *Skype*
> *+46 709845992 <+46%2070%20984%2059%2092>*
>
> [email-masked] <[email-masked]>*
>
> *h <http://linkedin.com/in/maekowalk>nydell*
>
>
>

-- 

Henrik Nydell

Cell

Email

Skype

+46 709845992

-- 

Avis de confidentialité

Confidentiality notice

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 Apr 2017 20:36:05 -0700

Hi Henrik,
your comments and suggestions that reflect practical experience of TWAMP
deployment in network operation is the most valuable, thank you.
We need to take a closer look at how to support the percentile. As you've
suggested, operator may have option to configure percentile for each
performance metric you've listed with default values for the set being 95,
99, and 99.9. That might give the flexibility and avoid extra configuration
if the default values are acceptable. What do you think? And I wonder
whether very low percentile levels have any practical use. Consider the
following:
   typedef percentile {
    type decimal64 {
    fraction-digits 1;
    }
    description "Percentile";
   }

grouping twamp-session-percentile {
   description "Percentile grouping";
   leaf first-percentile {
      type percentile {
          range "90.0 ... 99.9";
      }
      default 95.0;
      description "";
   }
   leaf second-percentile {
      type percentile {
          range "90.0 ... 99.9";
      }
      default 99.0;
      description "";
   }
   leaf third-percentile {
      type percentile {
          range "90.0 ... 99.9";
      }
      default 99.9;
      description "";
   }
}

Best regards,
Greg

On Wed, Apr 19, 2017 at 12:43 AM, Henrik Nydell <[email-masked]>
wrote:

> A percentile gives more granularity. Percentile 95 for delay means that
> out of all samples in the interval, if you remove the 5% highest, then the
> next largest delay value is p95. So a delay value of 23.412ms at p95 means
> that 95% of the delay samples during the interval were lower than or equal
> to 23.412ms.
>
> Many operators use continous TWAMP monitoring with quite high packet
> rates, like 50 packets per second. With 60 second interval reporting, this
> means 3,000 samples per interval, giving plenty of room to calculate 99.9
> And these three then reported (if implemented by the TWAMP sender) for
> both roundtrip, far-end and near-end. and for both delay and
> delay-variation metrics.
>
>
>
>
>>
>>
>>
>>
>>    - reporting of one-way packet loss metrics, both near-end and
>>    far-end, has dependency of reflector's mode.
>>
>>    - default value for session-timeout in session-sender container is
>>    900 seconds. Seems too big. What may be practical? Change units from
>>    seconds to centiseconds or milliseconds?
>>
>> Regards,
>>
>> Greg
>>
>>
>>

---

From: Henrik Nydell <[email-masked]>
Date: Fri, 21 Apr 2017 16:18:03 +0200

Sorry for a late reply Greg, see my comments inline below

On Thu, Apr 20, 2017 at 5:36 AM, Greg Mirsky <[email-masked]> wrote:

> [HN] I think the model could allow two decimal points, even if it (today)
is unlikely that you have so many samples in an interval that it makes
sense to calculate the such values (99.99%-ile)

As for low percentiles, I see no reason to limit the Yang model to 90 ...
99, even though those are the by far most common ones in use. For
synchronization protocols (like NTP) for example, there is often a
requirement that the "lucky packets" i.e the ones with the fastest
roundtrip time through the network are the ones that are important, and a
specific algorithm may work properly as long as at least one out of ten
packets arrive with the lowest possible roundtrip latency. To set an
service level objective (threshold) for such a requirement one could use a
low percentile like delay 10%, and chose to alert if the current interval
is very different from the previous interval.

The default values of 95, 99 and 99.9 I think makes sense.

>>> [WEI] Agree. It should be added. For stateful reflector, two more
>>> metrics can be added: loss-burst-count-far-end, loss-burst-count-near-end.
>>>
>>>
>>>
>> Many protocols and functions use a percentile so define in which range
>> the protocol or function operates well. One example is from the mobile
>> world, where Ericsson and others define the RAN requirements in terms of
>> delay and delay variation with percentiles. I.e it is OK that a few packets
>> break the delay limit, as long as 99% don't (p99).
>>
>>>    - defined continuous and periodic modes to execute a test session
>>>    and how performance metrics are calculated in each of the modes;
>>> I agree the model should describe both one-way loss metrics and
>>> roundtrip loss metrics, and the sender should be able to use either mode
>>> when calculating, potentially also populating the roundtrip delay values
>>> with proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values
>>> that would indicate buffer load/CPU load in the TWAMP responders processing
>>> time.
>>>
>>> In a continous test-model, the sender can just simply record the
>>> sequence number of the last packet transmitted in the interval to be
>>> reported, wait for it to come back, or a MAXTIME, then report that result,
>>> while continuing to transmit for the next interval.
>>>
>>>
>>>
>>> See my comment above. I argue that it is useful to keep track of
>>> changing DSCP values, and treating DSCP as a metric of the TWAMP Session
>>> just like loss and delay
>>>

-- 

Henrik Nydell

Cell

Email

Skype

+46 709845992

-- 

Avis de confidentialité

Confidentiality notice