Concurrency & conforming
Sep 1, 2010 12:00 PM, By Brian Stevenson and Mike Nann
Mesh topologies and rewrapping media essence at the receiver can increase efficiency.
In part one of this look at distributing digital media files, we discussed overcoming impediments inherent in the TCP/IP protocol to improve the performance of individual file transfers. (See “Efficient digital distribution of media” in the July issue.) With improved performance for any given transfer between two points achieved, we must now extend this into real-world applications, where content is distributed to many — even hundreds — of destinations. We will look next at optimizing distribution architectures for delivery concurrency and addressing recipients' differing media format requirements.
The second stage — concurrency
Figure 1. Scenario 2 uses a central server in a star configuration.
Ideally, multicast could be used to significantly reduce the total amount of data transferred. While multicast is viable on private terrestrial IP or satellite networks, it is not practical over the public Internet. As a result, delivery to multiple recipients reachable only over the public Internet generally involves multiple IP unicast transfers.
For a content owner or provider delivering content to large numbers of distribution partners, the next best thing to the ideal of multicast is a hybrid model — multicast over satellite to those who can receive it, multicast over IP networks where possible (such as private networks) and multiple IP unicast transfers to the remaining recipients. The transfer application should dynamically acquire information about the receiving capabilities of each destination point or user and concurrently manage a hybrid mix of transfer types to reach all destinations optimally.
With multiple IP unicast transfers almost inevitable in broad distribution schemes, optimizing transfer concurrency is a key to efficiency. It is also significant that a location that typically functions as a receiver may also sometimes function as a sender. For example, a local broadcast television affiliate receiving national network content may also be a contributor of local news coverage to other affiliated stations in the region. In this case, while multiple stations receive content from a central point, there are also transfers directly between some of these stations.
To demonstrate ways in which transfer concurrency can be made more efficient, consider a number of different scenarios for multiple unicast transfers. All of the below scenarios involve a source location, A, delivering a file to three destinations: B, C and D. Assume that the outgoing available bandwidth at A is at least as great as the incoming bandwidth of each receiver, as this is typically the case for senders that frequently distribute large amounts of content. For simplicity, assume that connections between any of these points share the same characteristics for packet loss and that an optimized transfer system is being used to overcome latency and achieve high utilization on the network.
Scenario 1: Consecutive (nonconcurrent) transfers
Figure 2. Scenario 3 uses a mesh topology.
In this scenario, content is first transferred from A to B, then A to C and finally A to D. This is clearly the least efficient, as there is no concurrency. Such an approach could be acceptable if all points have equivalent bandwidth or if the sender's outgoing bandwidth is lower than the incoming bandwidth of each recipient. In such cases, the sender's outgoing bandwidth is the constraint on overall performance. This is unlikely when content is regularly distributed from a centralized source, however, as the sender will typically have considerable bandwidth dedicated to distribution.
As such, transfer rates are typically limited by receiver bandwidths; if the sender has 45Mb/s outgoing bandwidth and a receiver only 10Mb/s, utilization of the sender's outgoing bandwidth can be less than 25 percent during that transfer. Another problem is that the total time before all destinations have received the file increases with the number of recipients, irrespective of the available bandwidth at the sender. Requirements for timeliness of content may make this impractical.
Scenario 2: Star (central server)
In this architecture, similar to a star network topology, all senders and receivers access a central server. A content file is uploaded to the server and is distributed to all destinations. (See Figure 1.)
Figure 3. Scenario 3 can use a star topology within the mesh.
In this example, the file would be first transmitted from A to the server; the server then delivers the file to the three recipients. This may be advantageous from the perspective of the sender, as the total amount of “good” data(ignoring overhead, resends of lost packets, etc.) transmitted from A is the size of the file, similar to a multicast transmission. From the overall system perspective, however, the transfer to the server increases (by the size of the file) the total amount of good data transferred. This could be negligible overall if there are a large number of unicast recipients (with more than 100 recipients, the extra transmission adds less than 1 percent overall), but it will be significant with a small number (33 percent additional overhead in this example).
This still could be beneficial if the bandwidth of sender A is the overall bottleneck, as it only delivers the file to one recipient directly. Again, though, where A is a common distribution source, it will likely have considerable dedicated bandwidth. Another scenario in which this topology may be beneficial is if the link from A has high transit costs (such as a private network link) or unreliable performance. In such cases, minimizing the transfer from A can result in cost savings or increased overall throughput. Also note that as the central server is linked to all senders and recipients, it can work to optimize the overall throughput of the system.
Continue to next page
| Want to use this article? Click here for options! |  |
