Whatever the situation may be, one of Maxwell's pre-defined scenarios can address it. What is a scenario? A scenario is any type of real-world, real-life situation that can occur in a mobile, cloud or wide area network:
- Check out performance under limited bandwidth conditions
- Emulate a legacy protocol
- Determine application performance for branch office users
- Evaluate a video conferencing system under typical satellite conditions
- Determine application performance over wireless
Maxwell does the work; you point and click
Scenarios work in one of two ways --
1Select one that best fits your application requirements, and you're ready to go.
Don't see exactly what you need? No problem...
2Maxwell engineers create the scenario for you:
Describe what you need. Maxwell engineers configure the correct settings for you and add the new scenario to the graphical user interface -- in a few minutes for simple scenarios, and less than one day for a more complex emulation.
Want to do the work yourself? No problem!
Scenarios can also be used as a template; use the template as a base and makes small modifications to tailor the impairments as desired.
Or, you can build a set of desired impairments though the Maxwell graphical interface, save a snapshot, define addresses and protocol filters.
Or, you can create a plugin in C or C++.
Scenarios available with Maxwell
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.
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.7cc 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.
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.
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
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:
The first piece is set to a fixed delay of 20ms with a width of 70.
The second is set with a fixed delay of 50ms with a width of 20.
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.
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.)
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.
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.
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.
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.
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.
Noisy Factor Floor
This scenario demonstrates one way to model a wired electrical LAN that is operating in an environment with a great deal of electrical and vibrational noise. While short runs of Ethernet cable rarely show measurable loss rates, long cable lengths can become measurably lossy. In an industrial setting with vibrations, connectors that are not firmly seated can also cause packet loss.
Packet Resequencing - User Control
This plugin permits user controlled resequencing of packets.
The default settings do not do any resequencing. Rather, the user controls everything.
Radio Communication Handoff
This scenario is intended for testing the robustness of devices that employ IP over radio links (e.g. mobile phone or WiFi handset) that are moving constantly from one cell site or access point to another.
As a device moves along, the signal strength will vary and the number of corrupted packets will vary. It is also assumed that the hand-off between the stationary sites is not "clean:." That is, both sites may put the same packet onto the net. Additionally, the devices will be subject to varying delays, jitter, and rate limitations. This scenario also assumes the bit rate varies with time as link layer algorithms attempt to adjust to the varying signal strength.
Home Network Access
This scenario emulates a network connection over the public Internet between a user at a home or residence and a network service such as a storage site.
The network parameters are based on data provided in the ITU-T G.1050 Recommendation.
G.1050 (03/2011) Impairment Tests
This scenario loads the G.1050 (03/2011) Impairment plugin and allows the user to select the impairment test case that is to be run. To activate a test, click on the "Plugin: G.1050 Impairments" row (under the Statistics row). When you wish to start an impairment, click on the Activate G.1050 impairments check box. Enter the test case number you wish to activate. The impairment changes are applied as soon as your cursor focus leaves the input fields.
G.1050 (11/2007) Impairment Tests
This scenario loads the G.1050 (11/2007) Impairment plugin and allows the user to select the impairment test case and severity that is to be run. To activate a test, click on the "Plugin: G.1050 Impairments" row (under the Statistics row). When you wish to start an impairment, click on the Activate G.1050 impairments check box. Enter the rate combination number and severity number corresponding to the severity letter you wish to activate. The impairment changes are applied as soon as your cursor focus leaves the input fields.
Low Earth Orbit Polar Satellite Link
This scenario emulates a communications link between a ground station and an aircraft in flight via two satellites in low earth polar orbit. The scenario parameters were determined using the following simplified model:
The two satellites (indicated by the orange marks on the figure) orbit in the same direction but in different planes. The distance between the satellites is assumed to remain constant in this simple model at 3000 km (indicated by the horizontal yellow line). The altitude of the orbits is assumed to be 800 km and circular. The aircraft and ground stations (indicated by the two green crosses) are assumed to be at latitudes such that they each acquire and lose contact with their corresponding in-sight satellite at the same time. Assuming an earth radius of 6367 km, each satellite appears to the stations to rise above the horizon (marked by the red plus signs) at a distance of about 3300 km (indicated by the vertical yellow line), coming to within 800 km, and setting below the horizon when 3300 km distant. Assuming an orbital period of 100 minutes, transit from horizon to horizon is about 800 seconds. Applying the Pythagorean equation and some trigonometry yields these equations (note variable 'd' is multiplied by 2 since two satellite/ground link distances are changing at the same time):
theta = 0.4769 - t*0.001192
R = 7167
d = sqrt((R*sin(theta))**2 + (R*cos(theta) - 6367)**2)
y = (2*d + 3000)/300000.0
Total link distance then varies from about 9,600 km to 4,600 km. The speed of light delay then varies from approximately 32 msec to approximately 15 msec and then increasing back to 32 msec. For this scenario the default rate is set to 10 kbps, Ethernet framing assumed, and transmission queues on both ends sufficient to hold at least three 1500 bytes packets.