Computer Networks

15129145

BEIJING JIAOTONG
UNIVERSITY

Qos in Internet for

Media Streaming by
UDP
Submitted To:
Professor:

Zhang Jinyu

Submitted By:
Name:
Sheikh

Muhammad Waqas Moin

1
BJTU

Computer Networks
15129145

Student Id:
15129145
University:
Beijing Jiaotong University
Department:
Computer
Application
Technology
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 real-time 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.
2
BJTU

Computer Networks
15129145

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.

3.

RTP/RTCP

Control

(Real
Protocol)

time Transport Protocol/ RTP

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

3
BJTU

Computer Networks
15129145

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.

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 realtime; 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

4
BJTU

Computer Networks
15129145

[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

5
BJTU