Internet congestion is originated in the Internet protocol, known as TCP/IP, that delivers data at network addresses thus transmitting a separate stream of data packets to each client computer even when many clients are requesting the same web content. The one-to-one delivery model provides interactivity and an obvious way of error handling but it wastes bandwidth whenever a high-demand content is transmitted. Bandwidth determines the network throughput and is the most limited network resource. When there is not enough bandwidth, traffic congestion causes delays in content delivery. The more Internet users are trying to access the same content, the more chance they experience delays in content presentation. The growing demand of bandwidth-hungry video over the Internet is putting a strain on Internet service providers (ISPs) who are fighting back by limiting access and/or interfering in Internet traffic.
This problem is not known in radio and television because in a broadcast system multiple receivers are tuned to the same channel, receive the same signal and thus get the same “copy” of content. In digital radio and television, audio and video is transmitted as a stream of data packets and a channel identifier is included in the packet header. Bandwidth is reserved for each channel and user's choice is limited to what is scheduled for transmission on the channels. Like dedicated phone lines, which waste bandwidth when not used, dedicated channels waste bandwidth when a content in low or no demand is transmitted.
IP multicasting is a technique for conserving bandwidth by sending packets from one Internet location to many others without unnecessary packet duplication. According to this technique, one packet stream, which could be audio or video or other type of data, is sent from a source to many locations on the Internet and is replicated in the network as needed to reach simultaneously as many end-users as necessary. Multicast commercial applications include webcasting, multiparty computer games and conference calls.
In order to take advantage of one-to-many delivery provided by IP multicasting, user computers join a “multicast group”. The group is created by a multicast application that runs multicast protocols for a specific source and specific destinations over “multicast enabled” routers. If a group for delivery of a desired content has not been created, there is nothing to join. A multicast group is not created dynamically in response to a sudden and temporary demand for a particular content. Moreover a group often cannot be created because of lack of multicast enabled routers between source and destination. This limits choice of content delivered in one-to-many manner by sources of already existing multicast groups. As a result, the contribution of IP multicast to reducing Internet congestion is limited respectively.
Another multicast problem is handling transmission errors. The guaranteed error-free data delivery over the Internet is provided by an acknowledgement mechanism of TCP protocol. According to the protocol, the sender retransmits a packet if the receiver does not acknowledge the reception of the error-free packet. The positive acknowledgement or ACK provides for both packets recovery and congestion control: the sender slows down if ACKs are delayed. A “negative acknowledgement” or NAK, which is a request for retransmission of a lost or corrupted packet, is used for packet recovery only. In a multicast application, many client computers receive the same packet stream and therefore the same corrupted packet, which is a problem if a guaranteed error-free data delivery is required. On one hand, if each client submits a retransmission request it would essentially reduce bandwidth savings provided by multicast. On the other hand, it would be wrong to designate a particular client computer in a multicast group as a retransmission requester on behalf of all clients because the group formation is out of control: any client can join or leave the group at any time. Errors in audio and video, although annoying, can be localized but software with errors does not work. That is why IP multicasting, which incorporates UDP instead of TCP in the transport layer, is mainly used for transmission of audio/video streams and does not fit for distribution of software, thereby further limiting contribution of IP multicast to reducing Internet congestion.
More practical method of bandwidth saving is web caching. Many ISPs, universities and corporations are using proxy caches to store copies of frequently accessed web content so that subsequent requests may be satisfied from the cache if certain conditions are met. Web caching provides essential bandwidth savings because a single copy of content is delivered from its origin server located anywhere in the world to a proxy cache positioned closer to users. But the savings are partial because locally i.e., from the proxy server to client computers the content is still distributed as separate streams of packets. It is therefore desirable to have a way of one-to-many data delivery that is free from IP multicast limitations.
U.S. Pat. No. 7,240,105 to Satran et al. discloses a method and system that combines content caching with multicast data delivery. The cache is formed as a multilevel hierarchical tree so that requests for content by end-user clients are received by the lowest level cache and forwarded as necessary to higher levels in the hierarchy.
U.S. Pat. No. 7,133,928 to McCanne discusses advantages of an application-level overlay routing protocol. Exploiting multicasting in a singly administered regional domain, as opposite to disjoint multicast networks that span multiple administrative domains with heterogeneous equipment and different multicast implementations, the protocol allows data distribution and bandwidth management to be handled in a more cohesive and intelligent fashion.
U.S. Pat. No. 6,374,303 to Armitage et al. discloses a multicast adaptation of Internet MPLS protocol. MPLS, which stands for Multi-Protocol Label Switching, provides for explicit routing and as a result, more efficient data forwarding based on the use of fixed size labels attached to packets.
U.S. Pat. No. 6,061,738 to Osaku et al. teaches using numbers as URL aliases and thereby avoiding the need to know and input URLs, which are long strings of characters.
U.S. Pat. No. 6,973,050 to Birdwell et al. discloses a transmission announcement system for use in conjunction with a unidirectional data broadcast system in which data is served simultaneously to multiple clients. The system sends out announcements of upcoming broadcast transmissions thereby enabling clients to select and receive transmissions of interest.
U.S. Pat. No. 7,590,245 to the same applicant discloses a system providing anonymity of communications by transmitting information in packets that do not contain source and destination addresses included in a packet header or anywhere in the packet. The anonymous packets are forwarded from a source host to a destination host by a randomly chosen flow number over a sequence of flow routers.
U.S. patent application Ser. No. 12/291,522 of the same applicant discloses a method and system for reducing Internet congestion by transmitting popular content in a broadcast manner. In the system, a single copy of content is delivered from its origin server located anywhere in the world to a broadcast server according to the standard Internet protocol. From the server, that serves an Internet regional domain, the content is transmitted as a flow of packets with a flow number placed in the packet's header. Clients, that have requested the same content, simultaneously download packets with the flow number thereby avoiding congestion and delays in content delivery. However the two-step delivery has a limitation: only one at a time content can be directed at the broadcast server address and that does not work well for live media streams concurrently transmitted to the regional domain. Therefore it is desirable to remove this “bottleneck”—the broadcast server—from a flow routing system.