Maxwell now supports pre-written impairment patterns, scenarios.

A scenario is a collection of impairment settings designed to reflect anything from observed real-life network behavior to a hypothetical network link.

A scenario can also invoke a user or IWL written Maxwell plug in.

Scenarios define more than just impairments; a scenario may also define address and protocol filters.

Scenarios can also be used as a template; the user uses the template as a base and makes small modifications to tailor the impairments as desired.

Writing a scenario is as simple as building a set of desired impairments through the Maxwell graphical user interface and then saving a snapshot

The following is a list of some of the available scenarios.  Additional scenarios will be added over time.  And, of course, a user may write his/her own scenarios.

1. Asymmetrical DSL Link

   • Up-link: 384 kbs (kilobits per second)
   • Down-link: 4096 kbs

   This scenario assumes a PPPoA-like frame format with a 6 byte header, 8 byte trailer, a minimum 48 byte payload cell, and a 1500 octet MTU size.  Each endpoint is assumed to be able to queue up 4500 bytes before incoming Ethernet frames must be dropped.

   A user could supplement this scenario with automation of the up-link and down-link rates to emulate the kind of dynamic rate adjustment that some ISPs do on their ADSL offerings.

2. Trans-Oceanic Terrestrial Link

   This scenario emulates an ATM-based T-1 link running over a terrestrial trans-oceanic cable between New York and London.

   ATM uses 53 byte fixed size cells, of which 5 bytes are header and 48 bytes are payload.  The T1 rate is 1536 kbps.  Transmission queues on each end are assumed to hold up to 8 packets of 1500 bytes each.  This ATM packet framing, rate, and queue length information is automatically entered into the Rate Limiter panels when the scenario is loaded.

   The great circle distance between New York and London is approximately 5600 km.  A speed of light transit time of approximately 19 msec is entered into the Delay panels.  The user may chose to adjust this value to reflect the typically lower propagation rate of a fiber optical link, about 0.6c to 0.7c c being the speed of light in a vacuum.)

   The rate and delay values yield about 30,000 bits in transit (1536 kbps times 0.019 sec) or 3750 bytes.  If minimum sized packets of only one data byte arrive on the ethernet interfaces, the worst-case maximum number of packet buffers needed to store in-transit packets is 3750 packets each direction, or 7500 total.  Since some control overhead packets may also need to be in transit, the value was rounded to the next power of two (8192) and entered into the Buffer Count field in the Flow Edit dialog.

3. VoIP Testing - Bursts of Packet Drop

   This scenario emulates a link in which small bursts of packets are lost.

   The drop probability is set at 3%.  This will initiate approximately bursts of lost packets out of every 100.

   The coupling probability is set to 50% with an interval of 100 milliseconds.  This means that a second packet that follows within 100 milliseconds of a previously dropped first packet has a 1 in 2 chance of being dropped itself.  It is this elevated probability of the successor packet being dropped that forms the burst.

   The burst will continue as long as packets continue to arrive within the coupling interval and are selected (using this scenario's 50% coupled drop probability) for dropping.

   When the burst is over, the basic drop probability (3% in this scenario) is resumed.

4. VoIP Testing - Phone Having Variable Delays in its Encoding Processing

   This combination of traffic flow and impairments emulates a sending VoIP phone that has variable delays in its encoding and transmission.

   Some of the traffic originating from the designated source will be delayed between 20 and 50 milliseconds without causing packet reordering.

   In this case the source and destination IPv4 addresses are set to the IP address of the VoIP phones (the Maxwell user will have to update these with addresses appropriate for his/her network.)  The IPv4 protocol is set to 17 which corresponds to UDP which all the voice packets will be using.  The source and destination ports are set to match the ports on which the phones send and receive.

   In addition to the above criteria for the predefined fields, this scenario uses expression matching to catch only packets containing DVI4 encoded data by examining the payload type in the RTP header

5. Router Suffering from Intermittent Congestion Without Packet Loss

   This scenario emulates a very common network condition - a router at which traffic sometimes arriving faster than it can be forwarded.  Internal queues build up inside the router and packets delayed by variable amounts.  This scenario envisions a router with so much internal memory that the queues never overflow and that no packets are lost.  In other words, this hypothetical router only causes jitter, not loss.

   Setting the jitter probability to 100% ensures that all packets will be subjected to the jitter impairment.

   This scenario uses a Piecewise function to describe the distribution of jitter packet delays.  In this scenario three pieces are defined:

   1. The first piece is set to a fixed delay of 20ms with a width of 70.

   2. The second is set with a fixed delay of 50ms with a width of 20.

   3. The third is set with a fixed delay of 1000ms with a width of 10.

   Note that the widths have been set so that they sum to 100.  Although this is not necessary, it is a convenient method to assure that the widths represent the percentage that each piece will contribute to the piecewise function as a whole.

   These settings imitate an intermittently congested router sending traffic 70% of the time with a 20ms delay, 20% of the time with a 50ms delay and 10% of the time with a 1000ms delay.

6. DNS Name Resolution Delays

   Domain Name System response time often plays a major role in how a user perceives internet response.  This scenario introduces a delay of about 150ms to 4% of the DNS queries and response packets.  (This means that about 7.8% of the DNS queries will be delayed by 150ms and about 0.2% by 300ms.)

   All other packets will transit Maxwell without impairment (unless the user has added an impairment or scenario to another flow.)

7. Effect of Impairments on CIFS Services (including Samba)

   Here the drop probability is set to 5%.  Duplication is added with its probability being 7% and the probability of coupling at 50%.  Constant delay is set at 100ms.

8. Geosynchronous Satellite Link

   This scenario emulates a communication link via a satellite in geosynchronous orbit.  The values used in the scenario were computed using the following assumptions:

   • Geosynchronous orbit is approximately 36,000 km altitude.  Total distance from ground transmitter to satellite transceiver and then to ground receiver would be no less that 72,000 km.  At the speed of light with no time lost at the transceiver, that makes for an approximately 240 msec delay - which is entered into Constant Delay.

   • The transmission rate is set to 1544 kbps, which is similar to the U.S. military's Milstar satellites.  That value is entered into the Rate field of the Rate Limiter.  The rate and distance yield about 370,000 bits in transit (1544 kbps times 0.24 sec).  If the average packet contains 500 bytes, Maxwell needs room to queue 93 packet buffers traveling in each direction.  Each endpoint is assumed to have transmission queues that can store 32 packets before drops occur, so the total number of packet buffers Maxwell needs to run this scenario is 250 (125 each way).

   This scenario makes some simplifying assumptions:

   • Ethernet-like packet format.

   • The satelite link is open for immediate use without first going through a contention resolution mechanism.

9. Periodic Link Congestion

   This scenario emulates a link experiencing traffic congestion such that packet delay increases from 0 to 250 msec over a period of 6 seconds and back down to 0 over another period of 6 seconds.  Packet drop probability increases in phase and with the same period from 0 to 35% and back down to 0%.

   You may change the values of the periods by clicking on the Drop and Delay rows to the left and then clicking on the Options button to the right of the Drop Probability and Constant Delay fields.  Be sure when you do this you do it for both Interface 1 and 2.

10. Periodic Link Failure

    This scenario emulates a network experiencing deterministic periodic link failures.  It does this by having 5 seconds of unhindered flow (i.e. 0% drop probability) followed by 0.5 seconds in which all packets in both directions are dropped (i.e. 100% drop probability).

    You may change the values of the periods by clicking on the Drop row to the left and then clicking on the Options button to the right of the Drop Probability field.  Be sure when you do this you do it for Interface 1 and 2.

11. Periodic Link Rate Change

    This scenario emulates a link running at full line speed for 10 seconds.  It then experiences a sudden change to 100 kbps for 10 seconds, after which it resumes full line rate and the cycle repeats.

    You may change the values of the periods by clicking on the Rate Limiter row to the left and then clicking on the Options button to the right of the Link Rate field.  Please note that a link rate of 0 (zero) kbps is equivalent to turning the rate limiter off (i.e. resumes full line speed).  Be sure when you change any impairment values that you do it for both Interface 1 and 2 if you wish to maintain symmetrical impairment.

12. TCP/IP Test Suite

    See the note on the TCP/IP Test Suite for details.

13. SIP Test Suite

    See the note on the SIP Test Suite for details.