Example of Internet Radio/Video
Internet radio/video is an example of a new long-session application. Essentially, it is a plain old-fashioned TCP session with a twist: you download a media file of streamed content and watch it at the same time. Playback buffering solves possible reordering and jitter issues, and the user is not aware of the download time because viewing and listening occur at the same time that the content continues to download. The usage of buffers can be very beneficial in terms of jitter reduction. Their only drawback is usually a minor delay between the time the user clicks a button and the time that the contents reproduction starts. These buffers make the video/radio service over TCP very smooth and transparent for the viewer. Once the session is established, an HTTP Get request results in a TCP transfer of the music, which most often is some form of MP3 media content, as illustrated in Figure 4.18.
How about packet drops and reordering? Is the user aware of any retransmissions or jitter? In most cases, not really, because what is happening is just a file transfer with TCP managing the delivery, at worse, the user may see a pause in the playback until the TCP download catches up. To handle this, the receiver needs to supply some buffering for the application to allow for retransmission and limited reordering. Figure 4.19 shows a reordering scenario with Internet radio, which involves the TCP guaranteed delivery mechanism.
Figure 4.18 TCP push model for Internet radio
Figure 4.19 Re-ordering situation with Internet Radio
To some degree, the answer depends on how you define "real time." If the definition is unidirectional broadcasting of streaming media. meaning that there is no user interaction, then you are describing simply an evolution of the basic TCP file transfer concept. Perhaps the term to use here is a "webcasting" or "one-way" real-time application. At the same time, however, the fact is that traffic to sites similar to YouTube accounts for an impressive amount of bandwidth consumed daily on the public Internet. The consistent low delay and jitter demands that exist for real-time look-alike applications loosen up a little with webcasting services in favor of providing raw bandwidth to allow TCP to ramp up the size of the congestion window.
Example of Peer-to-Peer (P2P) Applications
Until recently, many Internet service operators used traffic engineering to exchange the bulk of traffic for content providers. With traffic engineering, the traffic flows to web-hosting content sites or to any content-rich provider are very predictable, and there is very little or no direct communication between end users. This predictability was very helpful for dimensioning links and allowed the focus to be on links towards the content sites. An example of this traffic pattern was that North American operators regularly upgraded their cross-Atlantic links to adjust for the constant increase of traffic being pulled by Europe. Another example was the content provider America Online (AOL), which built up content sites overseas to engineer the load of traffic pulled to the US. Many operators with high volumes of traffic exchanges used traffic engineering to establish private peering with each other to control the load, instead of exchanging traffic at peering exchanges.
The emergence of peer-t o-peer (P2P) applications has caused the biggest changes in traffic patterns in the history of the Internet. With P2P, suddenly traffic paths changed and, worse, they keep on changing, over the course of day or even on an hourly basis due to the invincible matrix network that P2P applications create. Traffic can suddenly be local, or between users, and without a central location or hub providing the content. Users sharing file contents with each other require long-lasting sessions with appropriate bandwidth, resulting in a brand new pattern not seen earlier with HTTP and web hosts. In earlier traffic-engineering planning, the Provider Edge (PE) and distribution router uplink traffic usage would be similar to the summary of Customer Premises Edge (CPE)-facing interfaces, as illustrated in Figure 4.20 .
With P2P traffic, the usage and path can change very rapidly from uplinks to downlink, downlink to downlink, and so forth, as illustrated in Figure 4.21.
Figure 4.20 Uplink traffic-engineering planning
Figure 4.21 P2P traffic-shifting scenario
P2P networking is often referred to as a "network." It is not a physical network in the sense that it has dedicated routers and resources, such as servers with terabytes of disk space. Instead, the network is a logical overlay network at the application layer, lying over existing Internet architecture, with indexing and peer discovery creating a system of hosts that file share to share content for an application. There are several different architectures for P2P networking models and system: centralized, distributed, hybrid, structured, and non-structured.
The first implementations of P2P networks used a centralized model that contained a host responsible for the indexing and to be the go-to system for queries from the users, thus creating a hub point but only for queries, an example being the Napster system. Because a centralized index was maintained, the search engines were fairly advanced and the hit rate for finding the desired content was fairly reliable. This model, however, ran into legal issues because Napster was accused of violating copyright laws, but for our discussion, the index service was a single point of failure, so, for example, denial-of-service attacks could easily take down the whole service.
The P2P application that started the P2P file-sharing boom was Kazaa. Its P2P service model, called a hybrid model, is decentralized, with nodes performing the functions. The Kazaa network consists of supernodes and nodes. The supernodes, which may be more available than other nodes and have publicly available addresses, are elected without users been aware of it. The Kazaa network is an aggregated model called fast-track. in which users query supernodes from a list of nodes, and supernodes relay the query to other supernodes and to users in its domain area. When a content owner receives a query, they unicast the desired files to the node that originated the query. To limit the query, a Time To Live (TTL) is added to it to avoid too much flooding.
An example of the fully distributed model is the Gnutella network, with applications such as Limewire and Frostwire. In its native format, there are no differences between nodes in the network. The indexing is local and queries are flooded with TTL restrictions, as illustrated in Figure 4.22.
Figure 4.22 Gnutella distributed P2P model
While the Gnutella design results in a fully distributed model, it too has some possible bottlenecks, such as when nodes connect and disconnect, the result being unreliable services for the overlay network.
To solve this, Gnutella has introduced something of hybrid model, adding concepts like ultra-peers and leaf nodes which allow nodes that enter the network as leafs to connect to nodes selected to be ultra-peers. The selection of a node to become an ultra-peer is similar to the Kazaa concept: these are nodes that are not powered down frequently, or that have public IP addressing and therefore are not behind a firewall and connect via Network Address Translation (NAT) . Adding ultra- peers and leaf nodes offers a more stable layer of application routing for the flooded requests and request hits. To create this logical overlay network, Gnutella and other distributed P2P models use five packet types:
• Ping – Discover hosts on network.
• Pong – Reply to ping.
• Query – Search for a file.
• Query hit – Reply to query.
• Push – Download request.
When a new user connects to the Gnutella network for the first time, an application ping message is broadcast to the network, announcing the presence of the user on the network. Nodes that receive this ping message send a pong message back to the originator to acknowledge that they have received the ping. The node can later establish sessions within the Gnutella network with those nodes that replied with pongs. The P2P software’s cache keeps track of the Gnutella hosts that send the pongs, resulting in a list of active Gnutella hosts (hosts that have established a TCP connection). With the enhanced version of Gnutella, a leaf node connects only to ultra-peers, because they are the only nodes that respond with pongs. The pong contains the ultra-peer’s cache, thus allowing the leaf node to establish TCP connections to other ultra-peers. The number of TCP sessions can vary over time depending on the availability of ultra-peers. The Gnutella traffic itself follows the TCP mechanism, establishing a congestion window to optimize the file transfer performance.
P2P application downloads have evolved from allowing just a single established TCP session to allowing several sessions simultaneously, increasing the data push rate and creating a traffic matrix that can make it difficult to discern where certain content originated.
Discovering P2P on the Network
Discovering P2P traffic on the network is not that easy, because it cannot be mapped to fixed port numbers or well-known protocols. However, the traffic trends themselves are relative easy to discover. First, a large amount of TCP download traffic is sent to one or a few subscribers. This traffic follows the normal push and pull model. Then, however, there is a sudden shifting of traffic from local traffic between subscribers in a certain area, or even between ports on the router itself, to traffic from outside the area and the router uplinks. In these situations, the rapid change in traffic patterns is probably related to P2P and file – sharing scenarios.
Many studies have been done and papers written about how to discover P2P file-sharing traffic, but so far no one has developed a process on how to easily identify file – sharing and P2P traffic. Because there are no well-known centralized indexing servers or port numbers, the only visible proof is the volume of traffic, relatively, long-lasting TCP sessions and the size of the data packets. Even if one could filter and look further into the packets beyond the IP and TCP headers, the traffic is often encapsulated with Secure Socket Layer (SSL), making it more difficult to examine the data content.
Illegal File Sharing and Copyright Violation
While this topic is about QOS and this topic examines applications that exist in today’s IP networks, it is not possible to discuss P2P applications without mentioning that it has intensified the debate about copyright material. As users share content with each other, it is possible (and to be frank, highly likely) that some of the content is regulated by copyright laws. Needless to say, there is a debate about P2P and its file-sharing capabilities, and the evolution of P2P applications has been influenced by this debate, and the architecture has moved from centralized indexing to a decentralized or hybrid version, with many nodes. A centralized indexing function is easier and more stable, but the result of the Napster lawsuit is that the P2P community has moved to a more decentralized model. Like a Rolling Stone, by Bob Dylan, might be copyrighted, but P2P applications sure keep it rolling.
QOS Conclusions for New Internet Applications
This topic has touched on the evolution of the Internet and its applications in an effort to help QOS designers, who are constantly playing a catch-up game when it comes to providing support for these applications. Service providers have generally viewed the downloading of web- based movie clips and streaming media in terms of the TCP best- effort model used for HTTP and SMTP, rather than trying to optimize services for these types of Internet applications. With the growing acceptance of web-based radio and sites for downloading movies and movie clips, operators now recognize webcasting as a common Internet application. However, the operators still see them as best-effort types of applications and services. Because TCP is robust in its delivery, acceptable services can be delivered and maintained without much path and traffic control.
Service providers have looked upon peer-to-peer (P2P) and file - sharing applications as a plague, because the constantly changing traffic patterns of file transfer sessions, often changing hourly, create unexpected congestion points on unexpected links. One specific example occurs in shared areas such as DSL environments, in which the congestion arising from a single user performing massive file transfers affects the shared bandwidth among all subscribers on a DSLAM. QOS can help mitigate the deleterious effects of P2P traffic by treating it as Less than Best-Effort (LBE) traffic. Towards this goal, the only good QOS model is to classify and protect real-.ime applications and to treat all remaining TCP- based traffic purely as best-effort traffic. This model, in combination with policing and shaping end-user bandwidth, creates a worst-case but predictable volume of traffic entering the network. The issue with this model is that it is very ingress-egress centric model. The only QOS choice available is to manipulate the transit path with legacy functions such as RED in an attempt to shorten the long-lasting sessions and to possibly reduce the congestion window size.
If the goal is to classify and support P2P traffic, the QOS design needs to follow "the bigger, the better" rule to be able to optimize the TCP mechanism. However, the issue with P2P traffic is the unpredictable behavior of its traffic paths. Because end users are rapidly exchanging data between each other, the traffic paths can be very hard to predict and to engineer in advance.
