Network performance

Network performance refers to measures of service quality of a telecommunications product as seen by the customer.

The following list gives examples of network performance measures for a circuit-switched network and one type of packet-switched network, viz. ATM:

There are many different ways to measure the performance of a network, as each network is different in nature and design. Performance can also be modelled instead of measured; one example of this is using state transition diagrams to model queuing performance in a circuit-switched network. These diagrams allow the network planner to analyze how the network will perform in each state, ensuring that the network will be optimally designed.[3]

Performance measures

The following measures are often considered important:

A common misunderstanding is that having greater throughput means a "faster" connection. However, throughput, latency, the type of information transmitted, and the way that information is applied all affect the perceived speed of a connection.

Bandwidth

Main article: Bandwidth (computing)

The available channel bandwidth and achievable signal-to-noise ratio determine the maximum possible throughput. It is not generally possible to send more data than dictated by the Shannon-Hartley Theorem.

Throughput

Main article: throughput

Throughput is the number of messages successfully delivered per unit time. Throughput is controlled by available bandwidth, as well as the available signal-to-noise ratio and hardware limitations. Throughput for the purpose of this article will be understood to be measured from the arrival of the first bit of data at the receiver, to decouple the concept of throughput from the concept of latency. For discussions of this type the terms 'throughput' and 'bandwidth' are often used interchangeably.

The Time Window is the period over which the throughput is measured. Choice of an appropriate time window will often dominate calculations of throughput, and whether latency is taken into account or not will determine whether the latency affects the throughput or not.

Latency

Main article: Latency (engineering)

The speed of light imposes a minimum propagation time on all electromagnetic signals. It is not possible to reduce the latency below

t=s/c_m

where s is the distance and cm is the speed of light in the medium

Other delays also occur in intermediate nodes. In packet switched networks delays can occur due to queueing.

Jitter

Main article: Jitter

Jitter is the undesired deviation from true periodicity of an assumed periodic signal in electronics and telecommunications, often in relation to a reference clock source. Jitter may be observed in characteristics such as the frequency of successive pulses, the signal amplitude, or phase of periodic signals. Jitter is a significant, and usually undesired, factor in the design of almost all communications links (e.g., USB, PCI-e, SATA, OC-48). In clock recovery applications it is called timing jitter.[4]

Error rate

Main article: Bit error rate

In digital transmission, the number of bit errors is the number of received bits of a data stream over a communication channel that have been altered due to noise, interference, distortion or bit synchronization errors.

The bit error rate or bit error ratio (BER) is the number of bit errors divided by the total number of transferred bits during a studied time interval. BER is a unitless performance measure, often expressed as a percentage.

The bit error probability pe is the expectation value of the BER. The BER can be considered as an approximate estimate of the bit error probability. This estimate is accurate for a long time interval and a high number of bit errors.

Interplay of factors

All of the factors above, coupled with user requirements and user perceptions, play a role in determining the perceived 'fastness' or utility, of a network connection. The relationship between throughput, latency, and user experience is most aptly understood in the context of a shared network medium, and as a scheduling problem. For systems that are heavily dominated by either latency or throughput considerations.

Algorithms and protocols

For some systems, latency and throughput are coupled entities. In TCP/IP, latency can also directly affect throughput. In TCP connections, the large bandwidth-delay product of high latency connections, combined with relatively small TCP window sizes on many devices, effectively causes the throughput of a high latency connection to drop sharply with latency. This can be remedied with various techniques, such as increasing the TCP congestion window size, or more drastic solutions, such as packet coalescing, TCP acceleration, and forward error correction, all of which are commonly used for high latency satellite links.

TCP acceleration converts the TCP packets into a stream that is similar to UDP. Because of this, the TCP acceleration software must provide its own mechanisms to ensure the reliability of the link, taking the latency and bandwidth of the link into account, and both ends of the high latency link must support the method used.

In Media access control (MAC) layer, performance issues such as throughput and end-to-end delay are also addressed. Different performance models have been developed and applied for performance analysis.[5][6]

Examples of latency or throughput dominated systems

Many systems can be characterized as dominated either by throughput limitations or by latency limitations in terms of end-user utility or experience. In some cases, hard limits such as the speed of light present unique problems to such systems and nothing can be done to correct this. Other systems allow for significant balancing and optimization for best user experience.

Satellite telephony

A telecom satellite in geosynchronous orbit imposes a path length of at least 71000 km between transmitter and receiver.[7] which means a minimum delay between message request and message receipt, or latency of 473 ms. This delay can be very noticeable and affects satellite phone service regardless of available throughput capacity.

Deep space communication

These long path length considerations are exacerbated when communicating with space probes and other long-range targets beyond Earth's atmosphere. The Deep Space Network implemented by NASA is one such system that must cope with these problems. Largely latency driven, the GAO has criticized the current architecture.[8] Several different methods have been proposed to handle the intermittent connectivity and long delays between packets, such as delay-tolerant networking.[9]

Even deeper space communication

At interstellar distances, the difficulties in designing radio systems that can achieve any throughput at all are massive. In these cases, maintaining communication is a bigger issue than how long that communication takes.

Offline data transport

Transportation is concerned almost entirely with throughput, which is why physical deliveries of backup tape archives are still largely done by vehicle.

Optimized systems

World wide web

Users on the Internet feel that responses are "instant" when delays are less than 100 ms from click to response.[10] Latency and throughput together affect the perceived speed of a connection. However, the perceived performance of a connection can still vary widely, depending in part on the type of information transmitted and how it is used.

In a 2001 study, it was found that a typical web page was 53,400 bytes in size.[11]

[12] Round-trip packet latency over the Internet is fairly low – typically less than a tenth of a second across North America – and an average web page of 30-100 kilobytes would normally transfer fully in 10–30 seconds, over a 56-kbit/s modem, which yields a 3 KB/s transfer rate. If a user had to wait 10–30 seconds to see anything, after every web-page click, it would be intolerable.

Because latency is so important, the HTTP protocol and HTML markup language were invented to reduce the rendering time of hypertext over the internet. These protocols allow incremental rendering, meaning that page text can begin display after the first packet arrives. HTTP and nearly all browsers support gzip (compressed) transfer encoding, which can typically compress text by 2x. Moreover, HTTP 1.0 and later protocols support a rich set of caching primitives, allowing content to be stored closer to the user, in both browser-caches and ISP proxy-caches, all to reduce latency. And finally, in the early days of HTTP, interlaced photos were transmitted via GIF, which allowed a rough version of an embedded picture to appear when only half the scan lines had arrived. A few years later JPEG was invented, allowing an almost arbitrary tradeoff between latency and image quality. These optimizations of HTTP and HTML, GIF, and JPEG were crucial to reducing latency and improving the perceived performance of the World Wide Web.

Hence, when a user clicks on a web page, there is a delay of 500-550 milliseconds to transfer a 1500-byte packet over a 56 kbit/s modem, before the user can begin to see up to 3,000 bytes (uncompressed) of text. A DSL line with a throughput of 256kbit/s would produce a delay of roughly 60-110 ms, which would be perceived as an "instant" response.

By comparison, to transfer the contents of a DVD over a modem could take a week or more at a 56 kbit/s modem rate. Simply packing the DVD into an envelope and mailing it could be faster.

8-second rule

A June 2001 Zona Research report entitled "The Need for Speed II" found that the average web user will wait about eight seconds for a page to download, but that current average download time across backbone connection on most web sites is almost ten seconds.[13]

The 8-second rule is an old (by Internet standards) way of determining the adequate response time of a webserver through different bandwidth connections. It specified that if the load-time of a web page exceeds eight seconds, users are unlikely to wait, or "stick around", for its completion. In order to increase the "stickiness" of a website, faster ways to deliver the content to the user needed to be devised. These included stripping away unnecessary HTML code and using fewer images.[14]

A more recent 2012 study[15] finds that (by that time's data) viewers of online video streams start to abandon viewing the video when its startup delay reaches 2 seconds. Progressively more viewers abandon viewing as the startup delay increases (roughly 5.8% for each additional second of delay). 10 second startup delay causes about 40% of viewers to give up viewing a video.

Online gaming

Some online games utilize the Internet and/or a Local Area Network to coordinate a multiplayer game experience among two or more players, each of whom is running a copy of the game on a local game system (typically a video game console or gaming computer), with messages sent among the multiple game systems (either directly or through a game server reporting the actions of each player so that all the game systems stay synchronized). If the nature of the game is such that the game's local action cannot proceed until it synchronizes with one or more remote game systems, then the latency of the Internet and/or LAN will accordingly delay the responsiveness of a game system. Although such systems may only require very low throughput (e.g. messages of game controller actions may be only a few kilobits per second), the latency of the Internet and/or LAN must be low enough to meet the requirements of the game.

The maximum acceptable latency is game-type dependent. For example, generally, twitch gameplay games such as a first-person shooter like Quake 3 require lower latency for the best experience, while generally, a turn-based game such as chess can tolerate higher latency. But, it entirely depends on the specifics of each game. For example, fast chess is a turn-based game that may have low latency requirements. And, in the case of twitch games, some games can be designed such that only events that impact the outcome of the game are subject to synchronization latency, allowing for fast local response time most of the time.

Cloud gaming is a type of online gaming where the entire game is hosted on a game server in a data center, and the user is only running a thin client locally that forwards game controller upstream to the game server. The game server then renders the next frame of the game video which is compressed using low-latency video compression and is sent downstream and decompressed by the thin client. For the cloud gaming experience to be acceptable, the round-trip latency of all elements of the cloud gaming system (the thin client, the Internet and/or LAN connection the game server, the game execution on the game server, the video and audio compression and decompression, and the display of the video on a display device) must be low enough that the user perception is that the game is running locally.[12][16] Because of such tight latency requirements, distance considerations of the speed of light through optical fiber come into play, currently limiting the distance between a user and a cloud gaming game server to approximately 1000 miles, according to OnLive, the only company thus far operating a cloud gaming service.[17]

Online game systems utilizing a wireless network may be subject to significant latency, depending on the architecture of the wireless network and local electromagnetic interference impacting that network. Although radio propagation through air is faster than light through optical fiber, wireless systems are often shared among many users and may suffer from latency incurred due to network congestion which can trigger bufferbloat related issues, or due to network protocols that introduce latency. And, in the event of electromagnetic interference, transmitted packets may be lost, requiring a retransmission which also incurs latency.

See also

Notes

  1. ITU-T Study Group 2, Teletraffic Engineering Handbook (PDF), Retrieved on 2005-02-13.
  2. Telecommunications Magazine Online, Americas January 2003, Issue Highlights, Online Exclusive: Broadband Access Maximum Performance, Retrieved on 2005-02-13.
  3. "State Transition Diagrams". Retrieved 2003-07-13.
  4. Wolaver, 1991, p.211
  5. Bianchi, G. (2000). "Performance analysis of the IEEE 802.11 distributed coordination function". IEEE Journal on Selected Areas in Communications 18 (3): 535–547. doi:10.1109/49.840210.
  6. Shi, Zhefu; Beard, C.; Mitchell, K. (16–19 Nov 2008). "Tunable traffic control for multihop CSMA networks". IEEE Military Communications Conference, 2008. MILCOM 2008: 1–7.
  7. Roddy, 2001, 67 - 90
  8. U.S. Government Accounting Office (GAO), 2006
  9. Kevin Fall, 2003
  10. Millar, R.B. (1968), Response in man-machine conversational transactions, Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277.
  11. Choi, H.K.; Limb, J. O. (1999). "A Behavioral Model of Web Traffic". Proceedings of the 7th International Conference on Network Protocols: 327–334.
  12. 12.0 12.1 "D8 Video:OnLive demoed on iPad, PC, Mac, Console, iPhone". Wall Street Journal. 2010-08-09. Retrieved 2010-08-19.
  13. "The Need for Speed II". Zona Research. Retrieved 2008-07-24.
  14. "The 8-Second Rule". Submit Corner. Retrieved 2008-07-24.
  15. "Video Stream Quality Impacts Viewer Behavior: Inferring Causality Using Quasi-Experimental Designs". Retrieved 2014-10-06.
  16. "The Process of Invention: OnLive Video Game Service". The FU Foundation School of Engineering & Applied Science (Columbia University). Retrieved 2010-01-23.
  17. "Beta Testing at the Speed of Light". OnLive. 2010-01-21. Retrieved 2010-01-23.

References

External links