A-TDD on
Congestion Control
                       Raj Mudhar - raj@ripnet.com


 This work is licensed under the Creative...
Example
Using a typical Congestion Control
requirement, common in telecom and
networking applications.
Show how to get fro...
Congestion Control
              Redundant messaging paths for payload



 NE a                                           ...
Acceptance Criteria
User Story: As a Network Operator, I want to automatically control the
throughput between network elem...
Think “Black Box”

Acceptance Criteria should be:
  Customer visible
  If the criteria is “internal” then it is not
  acce...
Acceptance Criteria
Are the Acceptance Criteria below “black box”?
Acceptance criteria (Second Pass):
   NE can detect con...
SMART AC
Acceptance Criteria should be:
  Specific - definite and explicit
  Measurable - quantifiable, observable
  Achievab...
SMART AC Applied
          Acceptance                   Specific            Measurable           Achievable         Relev  ...
Acceptance Criteria
Are the Acceptance Criteria below “black box”?

Acceptance criteria (Third Pass):

   NE informs conne...
SMART AC Applied
          Acceptance                  Specific            Measurable             Achievable         Relev ...
Updated User Stories
 As a Network Operator, I want to automatically control the throughput between network
 elements so t...
Acceptance Test Format
 Use the BDD format:

   Narrative:

      As a [role] I want [feature] so that [benefit]

   Follow...
Acceptance Tests
The SMART table on slide 10 gives us what we need to write Acceptance tests for
our first User Story.
    ...
A-TDD as a design tool
 ATs help us uncover architectural and design
 considerations.
 Provides a customer-centric structu...
Ask Yourself
Did defining Acceptance Tests make you think about:
  Engineering Guidelines for Network Topology?
  The messa...
What if...?
You could learn and apply A-TDD in your team FAST?
How could this help you deliver higher quality features
mor...
About
Raj Mudhar is currently leading the Agile transition in the W-CDMA business at
Alcatel-Lucent, serving a population ...
Upcoming SlideShare
Loading in …5
×

A-TDD Applied To A Telecom Congestion Control Feature

1,320 views

Published on

Congestion Control is a common telecom and network application to manage overload of data traffic through high-traffic Network Elements (NEs). These slides offer an example of how to use A-TDD to decompose the requirements into User Stories, and develop scenarios using BDD-format for Acceptance Test in large, complex product development.

Published in: Technology
  • Be the first to comment

A-TDD Applied To A Telecom Congestion Control Feature

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. Think “Black Box” Acceptance Criteria should be: Customer visible If the criteria is “internal” then it is not acceptance criteria rajile.com
  6. 6. 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 reconfigured 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
  7. 7. 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
  8. 8. 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
  9. 9. 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 traffic too. - Take it out. Overloaded NE’s congestion level is reduced to “normal” below 80% capacity within 200 ms. rajile.com
  10. 10. 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
  11. 11. 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
  12. 12. Acceptance Test Format Use the BDD format: Narrative: As a [role] I want [feature] so that [benefit] 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
  13. 13. 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
  14. 14. A-TDD as a design tool ATs help us uncover architectural and design considerations. Provides a customer-centric structure to define feature behaviour Is a tool for requirements decomposition Aligns customers and developers to a common language rajile.com
  15. 15. Ask Yourself Did defining 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
  16. 16. 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 find 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
  17. 17. 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

×