A-TDD Applied To A Telecom Congestion Control Feature

A-TDD on Congestion Control Raj Mudhar - raj@ripnet.com This work is licensed under the Creative Commons Attribution-Share Alike 2.5 Canada License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ca/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. rajile.com

Example Using a typical Congestion Control requirement, common in telecom and networking applications. Show how to get from Epic to appropriately sized User Stories and how A-TDD can be used rajile.com

Congestion Control Redundant messaging paths for payload NE a NE b Redundant messaging paths for signalling Consider two network elements (NE), “NE a” and “NE b”. Data traffic flows between these two elements, also to and from each NE. (Over-simplified example!) NEs can be connected 1:1, 1:n, or m:n. (one or more a’s to one or more b’s) Our customer wants Congestion Control capability to ensure that any one NE cannot overload another, causing it to drop messages and degrade service. The User Story reads: As a Network Operator, I want to automatically control the throughput between network elements so that I can avoid overloading any single NE causing it to drop messages and degrade service level. rajile.com

Acceptance Criteria User Story: As a Network Operator, I want to automatically control the throughput between network elements so that I can avoid overloading any single NE causing it to drop messages and degrade service level. Acceptance criteria (First Pass): NE can detect congestion NE can inform connected NEs it is experiencing congestion NE can be informed that the receiver of its data stream is experiencing congestion NE can request other NEs to reduce transmission rate Overloaded NE’s congestion level is reduced to “normal” rajile.com

Think “Black Box” Acceptance Criteria should be: Customer visible If the criteria is “internal” then it is not acceptance criteria rajile.com

Acceptance Criteria Are the Acceptance Criteria below “black box”? Acceptance criteria (Second Pass): NE can detect congestion - detection is internal to the NE and therefore NOT acceptance criteria. It gets removed. This could be a User Story in itself, a customer may want to track congestion detection so that the network can be reconﬁgured in a highly congested cluster of NEs. NE can inform connected NEs it is experiencing congestion NE can be informed that the receiver of its data stream is experiencing congestion NE can request other NEs to reduce transmission rate - what about this one? Is this acceptance criteria or a design detail? Overloaded NE’s congestion level is reduced to “normal” rajile.com

SMART AC Acceptance Criteria should be: Specific - definite and explicit Measurable - quantifiable, observable Achievable - can exist, can be done Relevant - appropriate for the Story Time bound - when is outcome observed? rajile.com

SMART AC Applied Acceptance Specific Measurable Achievable Relev Time bound ant NE can inform connected NEs it "I'm Congested" Detect message on Push traffic up to an Yes From the time we hit the is experiencing congestion message to all the NE interface unreasonably high threshold on receiving NE connected NEs through the amount to trigger the to the time the message signalling channel message. (What is received on the sending amount?) NE - latency should be ??? NE can be informed that the Receive “I’m Detect message on Push traffic up to an Yes From the time we hit the receiver of its data stream is Congested” the NE interface unreasonably high threshold on receiving NE experiencing congestion message from through the amount to trigger the to the time the message connected NEs signalling channel message. (What is received on the sending amount?) NE - latency should be ??? NE can request other NEs to Hmmm... this is two- ? ? ? ? reduce transmission rate sided and redundant with the “I’m Not good acceptance Congested” message. criteria Overloaded NE’s congestion Not specific enough ? ? ? ? level is reduced to “Normal” - what is normal? We discover missing What is the information congestion threshold? rajile.com

Acceptance Criteria Are the Acceptance Criteria below “black box”? Acceptance criteria (Third Pass): NE informs connected neighbour NEs it is experiencing congestion once messaging queue reaches 80% of capacity NE can be informed that the receiver of its data stream is experiencing congestion within 100 ms of exceeding 80% capacity NE can request other NEs to reduce transmission rate - This is redundant and changing transmission rate is not the only or right way to reduce congestion - could re-route trafﬁc too. - Take it out. Overloaded NE’s congestion level is reduced to “normal” below 80% capacity within 200 ms. rajile.com

SMART AC Applied Acceptance Specific Measurable Achievable Relev Time bound ant NE can inform connected NEs it "I'm Congested" Detect message on Increase traffic until Yes “I’m Congested” is experiencing congestion message to all the NE interface receiving NE’s input message to be sent out connected NEs through the queue exceeds 80% the signalling channel signalling channel occupancy within 5 ms. NE can be informed that the Receive “I’m Detect message on Increase traffic until Yes “I’m Congested” receiver of its data stream is Congested” the NE interface receiving NE’s input message to be received experiencing congestion message from through the queue exceeds 80% within 100 ms of queue connected NEs signalling channel occupancy overload. Overloaded NE’s congestion Threshold is defined. NEs Txing to NE Decrease traffic until Yes Within 200 ms of sending level is reduced to below 80% under test - receiving NE’s input a “I’m Congested” “Congestion queue drops below message. Cleared” message 80% occupancy sent to neighbouring NE We cycle back to our customer and PO and define new User Stories. Customers want to be able to log overload events and generate a message through the network back to the Network Operations Centre and count events over a 30 day rolling window. Event notification should happen in real time. (Detection - slide 6). The overload threshold should be configurable on an NE by NE basis. rajile.com

Updated User Stories As a Network Operator, I want to automatically control the throughput between network elements so that I can avoid overloading any single NE causing it to drop messages and degrade service level. (Epic) As a Network Operator, I want NEs to automatically maintain traffic at a default value of below 80% of capacity so that I can avoid overloading any single NE causing it to drop messages and degrade service level. As a Network Operations Engineer, I want to be able to receive notifications of congestion events in real time at the Network Operations Center, so that I can rapidly reconfigure my network. As a Network Operator, I want to track congestion events on a 30-day rolling window so that I can monitor network congestion trends. As a Network Operations Engineer, I want to be able to configure the congestion threshold on a per-NE basis, so that I can optimize my network performance. By using A-TDD we elaborated on the single User Story and generated more. rajile.com

Acceptance Test Format Use the BDD format: Narrative: As a [role] I want [feature] so that [beneﬁt] Followed by Acceptance Criteria as scenarios: Given [Precondition/Context] and [more context] When [Actor + Action] Then [Observable result] and [other outcome or result] rajile.com

Acceptance Tests The SMART table on slide 10 gives us what we need to write Acceptance tests for our first User Story. traffic at a default value of nt NEs to automatically maintain Story: As a Network Operator, I wa it to drop messages and avoid overloading any single NE causing below 80% of capacity so that I can degrade service level. to neighbouring NEs Can you th Scenario 1: Congestion Notification Given that an NEa is < 80% Rx queue capacity ink of And it is connected to one or more nei ghbouring NE s other scen arios? And neighbouring NEs are Txing data to NEa There are And neighbouring NE Tx rate is inc reasing many! y When its queue hits >=80% occupanc Then the event is logged And an alarm is raised Are the 3 signalling channel in <= 5 ms And an “I’m Congested” message is sent out the scenarios ouring NEs And the “I’m Conges ted” message is replicated to all neighb tied to the righ es notification that a neighbouring NE is congested Story? May t sub- Scenario 2: Transmitting NE receiv be not! Given NEb is Tx ing to NEa ” message out its signalling channel When NEa sends an “I’m Congested 0 ms ge on its signalling channel within 10 Then NEb receives the “I’m Congested” messa ssage response to an “I’m Congested” Me Scenario 3: Reducin g messaging to Neighbouring NE in Given NEb is Txing to NEa ” message on its signalling channel When NEb receives an “I’m Congested a within 100 ms Then NEb reduces message flow to NE of receiving the “I’m Congested” me ssage. And NEb receives a “Conge stion Cleared” message within 200 ms rajile.com

A-TDD as a design tool ATs help us uncover architectural and design considerations. Provides a customer-centric structure to deﬁne feature behaviour Is a tool for requirements decomposition Aligns customers and developers to a common language rajile.com

Ask Yourself Did deﬁning Acceptance Tests make you think about: Engineering Guidelines for Network Topology? The message sequence chart modelling the congestion control dialogue? Ideas for parametric modelling of the congestion control algorithm? Additional high-value Stories a customer would pay for? Automation of ATs to assess “level of feature completion” as Stories are implemented? Further decomposition of User Stories using SMART ATs AND INVEST criteria for User Stories? What developers can start working on NOW and what needs to be further elaborated before work can begin? rajile.com

What if...? You could learn and apply A-TDD in your team FAST? How could this help you deliver higher quality features more rapidly? If you want to ﬁnd out, a new Collaborative A-TDD Research Study is being launched in April 2010 and you can take part. Details here: http://wp.me/pHeMM-5Z And Research Intro slides available here: http://timy.in/?eDRno Or join us at the 1st International Workshop on Test-driven Development (TDD 2010) - http://agile.csc.ncsu.edu/tdd/ rajile.com

About Raj Mudhar is currently leading the Agile transition in the W-CDMA business at Alcatel-Lucent, serving a population of 3000 as transformation servant-leader. Contact Raj: E-mail: raj@ripnet.com / raj.mudhar@alcatel-lucent.com LinkedIn: http://ca.linkedin.com/in/rajmudhar Twitter: http://twitter.com/rmudhar @rmudhar Web: http://rajile.com rajile.com

A-TDD Applied To A Telecom Congestion Control Feature

by Raj Mudhar on Apr 03, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 8

Statistics

A-TDD Applied To A Telecom Congestion Control Feature — Presentation Transcript