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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> wrote:
>
>> Hi Greg,
>>
>>
>>
>> Thanks a lot for your response. Please see my reply inline tagged [WEI>>].
>>
>>
>>
>> Regards,
>>
>> Wei Luo
>>
>>
>>
>> *From:* Greg Mirsky [mailto:[e-mail]]
>> *Sent:* Tuesday, March 21, 2017 1:16 AM
>> *To:* Wei Luo S <[e-mail]>
>> *Cc:* [e-mail]; [e-mail]
>> *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 <[e-mail]>
>> 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
>> [e-mail]. 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>>
>
>
> --
>
>
> [image: Accedian.com]
>
> Henrik Nydell
>
> Sr Manager Global Strategy & Solutions
>
> Cell
>
> Email
>
> Skype
>
> [phone] <+46%2070%20984%2059%2092>
>
> [e-mail] <[e-mail]>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>
>