Computer Networks

15129145

BEIJING JIAOTONG
UNIVERSITY

Qos in Internet for Media

Streaming by UDP
Submitted To:
Professor:

Zhang Jinyu
Submitted By:

Name:
Muhammad Waqas Moin Sheikh
Student Id: 15129145
University: Beijing Jiaotong University
Department: Computer Application Technology
1
BJTU

Computer Networks

15129145

1. Abstracts

Delivering real-time video over the Internet is an important issue for many Internet multimedia
applications. Transmission of real-time video has bandwidth, delay, and loss requirements. The
application-level quality for video streaming relies on continuous playback, which means that
neither buffer underflow nor buffer overflow should occur. Since the Best Effort network such as the
Internet does not provide any Quality of Service (QoS) guarantees to video transmission over the
Internet. Thus, mapping the application-level QoS requirements into network-level requirements,
namely, limited delay jitters. End-to-end application level QoS has to be achieved through
adaptation. Since the QoS of video streams over IP networks depends on several factors such as
video transmission rate, packet loss rate, and end-to-end transmission delay. The objectives is to
simulate an adaptation scheme to include the effect of User Datagram Protocol (UDP) parameters
on delay jitter and datagram loss values to increase the efficiency of UDP protocol to prevent the
network congestion and increase the adaptively.

2. Introduction

Multimedia is any combination of text, graphics, audio, video, animation and data. Multimedia
applications over the Internet include Video on Demand (VoD), interactive video, and
videoconferencing. However there are limitations to these applications, as it is often required that a
multimedia file be completely downloaded before it can be played or viewed. Streaming is the ability
to start processing data before all of it has arrived, thus making delivery in real-time or near realtime possible. Streaming technologies are designed to overcome the problem of limited bandwidth.
The implication of this is that multimedia files of any size can be played/displayed over the Internet
in real-time or near real-time. To date, there has been no definitive way to transmit streamed
MPEG-4 files across the Internet with an associated Quality of Service. One possibility is to write a
control protocol on top of TCP/IP, which manages the flow of multimedia data [1]. In this report, an
alternative approach using a protocol stack comprising a Real-time Transport Protocol (RTP) layer
over a User Datagram Protocol (UDP)/Internet Protocol (IP) layer is described. Providing QoS
guarantees is difficult or impossible in networks that offer "best effort" service, such as the
Internet's IP layer. Therefore a lot of work has been carried out recently on how to add QoS support
to the Internet service model. Examples of this include the intserv (Integrated Services) and diffserv
(Differentiated Services) approaches. The RTP/RTCP approach is an attempt to add QoS support
mechanisms above the Transport layer (TCP or UDP). However the use of RTCP messages to provide
and maintain QoS guarantees to multimedia streams.

2
BJTU

Computer Networks

15129145

3. RTP/RTCP (Real time Transport Protocol/ RTP Control Protocol)

Usually RTP (Real time transport protocol) runs on top of another transport layer protocol - most
often the User Datagram Protocol (UDP). RTP is used in conjunction with the Real-time Transport
Control Protocol (RTCP). While RTP carries the media streams (audio or video), RTCP monitor
transmission statistics and quality of service information, that is Real-Time Control Protocol (RTCP)
provides feedback on the transmission and reception quality of data carried by RTP.

4. Extension to the RTP/RTCP payload format type enabling Qos.

The main objective to adapt RTP is to lower delay requirements for streaming applications by making
RTP more reliable, in a sense emulating TCP through selective re-transmissions. In order to realise
the existing RTP/RTCP payload format must be modified slightly. The underlying transport protocol
chosen is UDP/IP (user datagram protocol/internet protocol) which is extremely unreliable and is
susceptible to severe packet loss when transmitting compressed MPEG video streams in congested
networks. One simple solution is to use increased redundancy by sending multiple copies of data
packets; however this adds an extra load on the network. Another solution using retransmission of
all lost packets is unsuitable for real-time or near real-time streams, as retransmitting causes
additional propagation delays and also increases the load on the network.

5. Using RTP as a transport mechanism for MPEG-4 FlexMux stream

MPEG-4 applications can involve a large number of ESs and thus a large number of RTP sessions.
Allowing a selective bundling scheme or multiplexing of ESs may be necessary for certain MPEG-4
applications. MPEG-4 FlexMux streams can be synchronised with other RTP payloads. MPEG-4
FlexMux streams and other real-time data streams can be combined into a set of consolidated
streams through the use of RTP mixers and translators. The delivery performance of the MPEG-4
stream can be monitored via the RTCP control channel. An MPEG-4 FlexMux stream is mapped
directly to the RTP payload without any addition of extra header fields or the removal of any
FlexMux packet header. Each RTP packet contains a sender clock reference timestamp that is used to
synchronise the FlexMux clock. On the client side, the Flex DE multiplexor does not make use of the
RTP timestamp. The purpose of the RTP timestamp is to determine the network jitter, and
propagation delay between server and client. An RTP packet should begin with an integer number of
FlexMux packets.

3
BJTU

Computer Networks

15129145

6. Conclusion

The current version of the system is capable of creating and transmitting the MPEG-4 stream file
using a RTP/UDP/IP transport stack to a client. The next stage is to harness and exploit the
characteristics of both the transport media and MPEG-4 so as to implement QoS parameters. The
extensions to the RTP and RTCP packets have yet to be implemented with the intended purpose of
implementing selective retransmission into the system [9]. The extended RTP and RTCP packets are
to be used to monitor that the client receives all essential packets i.e. the PR bit is set to one.
Currently, the server assumes that the marker bit and the priority bits are equal. The server can
transmit according to different transmission profiles as defined by the status variable; however it is
unable to dynamically change the transmission profile dynamically within the session. Also, research
must be done to identify what characterises and constitutes a change in transmission profile. For
example, when should the server resort to prioritised transmission of high priority packets, or when
should it adopt transmission redundancy to send high priority packets? Ideally, prioritised encoding
transmission (PET) should be adopted when the MPEG-4 file is encoded in real-time; however, in the
system implemented, encoding of the MPEG-4 file is offline.

7. References

[1] Nicola Cranley*, Ludovic Fiard, Liam, Quality of Service for Streamed Multimedia the Internet
[2] G. Muntean and L. Murphy, An Object-Oriented Prototype System for Feedback
Controlled Multimedia Networking, submitted to ISSC 2000
[3] http://datatracker.ietf.org/wg/payload/documents/
[4] RFC 1889: RTP: A transport protocol for Real Time Applications
[5] RFC 1890: RTP profile for Audio and Video Conference with Minimal Control
[6] Internet draft: draft-podolsky-avt-rtprx-00.txt
A RTCP based Retransmission Protocol for Unicast RTP Streaming Multimedia

4
BJTU