A proxy caching scheme for continuous media streams on the Internet

Author(s):  
Eun-Ji Lim ◽  
Seong-Ho Park ◽  
Hyeon-Ok Hong ◽  
Ki-Dong Chung
2002 ◽  
Vol 9B (3) ◽  
pp. 303-310
Author(s):  
Hyeon-Ok Hong ◽  
Eun-Ji Im ◽  
Gi-Dong Jeong

2016 ◽  
Vol 2016 ◽  
pp. 1-9
Author(s):  
DaeYoub Kim

To solve various problems of the Internet, content centric networking (CCN), one of information centric networking architectures (ICN), provides both an in-network content caching scheme and a built-in content verification scheme. However, a user is still asked to generate many request messages when retrieving fragmented content through CCN. This model can seriously increase the amount of network traffic. Furthermore, when receiving content, a user is asked to verify the received content before using it. This verification process can cause a serious service delay. To improve such inefficiencies, this paper proposes a transmission process to handle request messages at one time. Also, it suggests an efficient content verification method using both hash chains and Merkel-hash tree.


Author(s):  
Dimitris Kanellopoulos ◽  
Sotiris Kotsiantis ◽  
Panayotis Pintelas

Multimedia communications involve digital audio and video and impose new quality of service (QoS) requirements on the Internet (Lu, 2000). Different multimedia applications have different QoS requirements. For example, continuous media types such as audio and video require hard or soft bounds on the end-to-end delay, while discrete media such as text and images do not have any strict delay constrains. In addition, video applications require more bandwidth than audio applications. QoS requirements are specified by the following four closely related parameters: (1) bandwidth on demand; (2) low end-to-end delay; (3) low delay variation (or delay jitter); and (4) acceptable error or loss rate without retransmission, as the delay would be intolerable with retransmission. Multimedia applications are classified into the following three categories: • Two-way conversational applications, which are characterized by their stringent requirement on endto- end delay that includes total time taken to capture, digitize, encode/compress audio/video data, transport them from the source to the destination, and decode and display them to the user. • Broadcasting services where the source is live. The main dissimilarity from the conversational applications is that it is one-way communication and it can stand more delay. • On-demand applications (e.g., video on demand) where the user requests some stored items and the server delivers them to the user. In designing and implementing multimedia applications, the characteristics of these application types should be used to provide required QoS, but using network and system resources efficiently. Even though we say that QoS should be guaranteed, the user states the degree of guarantees. Usually, there are three levels of guarantees: • Hard guarantee, where user-specified QoS should be met absolutely. Reserving network and system resources based on the peak-bit rate of a stream achieves hard guarantees. • Soft guarantee, where user-specified QoS is supposed to be met to a certain precise percentage. This is suitable for continuous media, as they usually do not need 100% accuracy in playback. This type of guarantee uses system resources more efficiently. • Best effort, where no guarantee is given and the multimedia application is executed with whatever resources are available. More networks function in this mode. These different types of guarantees may all be needed in a multimedia session established using proper association control protocols such as C_MACSE (Kanellopoulos & Kotsiantis, 2006). Different levels of guarantee are used for different types of traffic and the user determines which type of guarantee to use. Besides, the charging policy is related to the level of guarantee and the most expensive is the hard guarantee, while the best effort is the cheapest. At the source, multimedia data are either captured live or retrieved from storage devices. The transport module accepts these data, packetizes and passed them on to the Internet. At the destination (sink), multimedia data are reassembled and passed to the application for playback of audio/video. Packet processing time differences, network access time differences, and queuing delay difference can cause delay jitter, which has to be removed at the destination before data being played out.


Sign in / Sign up

Export Citation Format

Share Document