Network performance

Network performance refers to the service quality of a telecommunications product as seen by the customer. It should not be seen merely as an attempt to get "more through" the network.

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

• Circuit-switched networks: In circuit switched networks, network performance is synonymous with the grade of service. The number of rejected calls is a measure of how well the network is performing under heavy traffic loads.^[1] Other types of performance measures can include noise, echo and so on.

• ATM: In an Asynchronous Transfer Mode (ATM) network, performance can be measured by line rate, quality of service (QoS), data throughput, connect time, stability, technology, modulation technique and modem enhancements.^[2]

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]

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.^[4]

The 8-second rule is an old (by Internet standards) way of measuring 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.^[5]

It is generally believed that this rule no longer applies, since a much higher percentage of Internet users now have broadband available, making almost every website load up much faster, in some cases in less than a second. However, the rule has remained as a rough unit to measure the performance of a webserver.

Relationship between latency and throughput

A common concern in the development or procurement of a telecommunications system is a simple question: "will my data arrive fast enough?". This question in fact contains many subtle parts, based on the interplay of several factors. The perceived 'fastness' (speed being a scientific quantity related to propagation and so is not used in this context) is highly dependent on user requirements and measurement technique. 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.

Terms

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.

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.

Physical limitations

• The speed of light imposes a minimum propagation time on all electromagnetic signals. It is not possible to reduce the latency below t=(distance)/(speed of light).

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

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.

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. ^[6] 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. ^[7] Several different methods have been proposed to handle the intermittent connectivity and long delays between packets, such as delay-tolerant networking ^[8].

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

Web surfing

Users browsing the Internet feel that responses are "instant" when delays are less than 100 ms from click to response^[9]. 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^[10]. 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 kbit/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.

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.^[11][12] 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.^[13]

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

• Bandwidth-delay product
• Bitrate
• Digital bandwidth
• Goodput
• Grade of service
• Ideal Web response time
• Lag
• Measuring network throughput
• Network traffic measurement
• Response time

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". http://cne.gmu.edu/modules/os_perf/std.t.html. Retrieved 2003-07-13. 
4. ^ "The Need for Speed II". Zona Research. http://www.keynote.com/downloads/Zona_Need_For_Speed.pdf. Retrieved 2008-07-24. 
5. ^ "The 8-Second Rule". Submit Corner. http://www.submitcorner.com/Guide/Bandwidth/001.shtml. Retrieved 2008-07-24. 
6. ^ Roddy, 2001, 67 - 90
7. ^ U.S. Government Accounting Office (GAO), 2006
8. ^ Kevin Fall, 2003
9. ^ Millar, R.B. (1968), Response in man-machine conversational transactions, Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277.
10. ^ H. K. Choi, J. O. Limb, "A Behavioral Model of Web Traffic", Proceedings of the 7th International Conference on Network Protocols, 1999 [ICNP '99], pages 327-334.
11. ^ "D8 Video:OnLive demoed on iPad, PC, Mac, Console, iPhone". Wall Street Journal. 2010-08-09. http://video.allthingsd.com/video/d8-video-onlive-demo/9D57A2C6-24ED-4351-8266-F3F7BA0C4D18/. Retrieved 2010-08-19. 
12. ^ "The Process of Invention: OnLive Video Game Service". The FU Foundation School of Engineering & Applied Science (Columbia University). http://tv.seas.columbia.edu/videos/545/60/79. Retrieved 2010-01-23. 
13. ^ "Beta Testing at the Speed of Light". OnLive. 2010-01-21. http://blog.onlive.com/2010/01/21/beta-testing-at-the-speed-of-light/. Retrieved 2010-01-23. 

References

• Rappaport, Theodore S. Wireless Communications, Principles and Practice second edition, Prentice Hall, 2002, ISBN 0130422320

• Roddy, Dennis, Satellite Communications third edition, McGraw-Hill, 2001, ISBN 0071371761

• Fall, Kevin, "A Delay-Tolerant Network Architecture for Challenged Internets", Intel Corporation, February, 2003, Doc No: IRB-TR-03-003 The File

• Government Accountability Office (GAO) report 06-445, NASA'S DEEP SPACE NETWORK: Current Management Structure is Not Conducive to Effectively Matching Resources with Future Requirements, April 27, 2006

External links

• Nasa's Deep Space Network Website
• It's the Latency, Stupid
• more formal paper by same author
• A technical article on techniques for reducing web latency