congestion control and fairness for real-time media ... · congestion control and fairness for ......

Master Thesis

Congestion Control andFairness for Real-time Media

Transmission

Submitted by

Juhi Kulshrestha

Submitted on

June 29, 2011

Supervisor

Prof. Dr.- Ing. Thorsten Herfet

Advisor

Manuel Gorius, M.Sc.

Reviewers

Prof. Dr.- Ing. Thorsten HerfetProf. Dr. Holger Hermanns

Saarland University

Faculty of Natural Sciences and Technology I

Department of Computer Science

Universität des Saarlandes

Postfach 15 11 50, 66041 Saarbrücken

UNIVERSITÄT DES SAARLANDES

Lehrstuhl für Nachrichtentechnik

FR Informatik

Prof. Dr. Th. Herfet

Universität des Saarlandes Campus Saarbrücken C6 3, 10. OG 66123 Saarbrücken

Telefon (0681) 302-6541 Telefax (0681) 302-6542

www.nt.uni-saarland.de

Master’s Thesis for Juhi Kulshrestha

Congestion Control and Fairness for Real-time Media Transmission

Audiovisual content generates the major part of the traffic in the Future Internet. Currently the Transmission Control Protocol (TCP) is the prevalent protocol for web-based audio and video distribution. It provides flow and congestion control, as well as perfect reliability. These features are essential for error-free file transfer and ensure fairness between concurrent transmissions over the Internet. However, without modification they reasonably affect the Quality of Experience (QoE) for real-time media streams, especially if they are transmitted over wireless networks.

Audiovisual applications require a predictable delivery time but can tolerate a specific residual error. With the generalized architecture on adaptive hybrid error correction1, the Telecommunications Lab has developed a versatile basis for efficient error correction on packet level. Coding parameters are determined analytically based on a statistical model in order to serve predictable transmission delay as well as predictable residual loss to the application.

The scope of this master's thesis is the design of a congestion control mechanism with respect to real-time media transmission that operates on top of the available error correction architecture. In particular, the tasks to be solved are the following:

• Introduce into available policies for congestion control and discuss their usability for real-time media. Consider scalability issues of those schemes for large receiver groups.

• The literature presents ideas based on predictive estimation of the available channel bandwidth for a smoother congestion control in TCP. Discuss those approaches for a potential solution.

• Develop a congestion control mechanism suitable for real-time media transmission on top of the generalized architecture on adaptive hybrid error correction.

• Demonstrate the solution in a suitable environment. An implementation of a media-oriented transport protocol is available at the Telecommunications Lab and should be the basis for practical demonstrations. Erroneous network behavior might be emulated via the netem2 network emulator on top of a physical IP network.

Tutor: Supervisor:

Manuel Gorius Prof. Dr.-Ing. Th. Herfet

1 http://www.nt.uni-saarland.de/publications/ 2 http://www.linuxfoundation.org/en/Net:Netem

—

–

Eidesstattliche Erklärung Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.

Statement in Lieu of an Oath

I hereby confirm that I have written this thesis on my own and that I have not used any other media or materials than the ones referred to in this thesis.

Einverständniserklärung Ich bin damit einverstanden, dass meine (bestandene) Arbeit in beiden Versionen in die Bibliothek der Informatik aufgenommen und damit veröffentlicht wird.

Declaration of Consent I agree to make both versions of my thesis (with a passing grade) accessible to the public by having them added to the library of the Computer Science Department. Saarbrücken,…………………………….. …………………………………………. (Datum / Date) (Unterschrift / Signature)

ACKNOWLEDGEMENTS

First and foremost I would like to thank Prof. Dr.-Ing. Thorsten Herfet for his guidance

throughout our association. He always gave me invaluable advice and provided the best

work atmosphere one could possibly want.

Manuel Gorius is another person who played a significant role in shaping this work. I am

grateful for his much appreciated ideas, patience and constant support. This thesis wouldn’t

have been possible without the many discussions and brainstorming sessions that we had.

I would further like to thank all the people at the Telecommunications Lab at Saarland

University for being helpful and providing a conducive environment for doing research.

And last but not the least, I would like to thank my family for supporting me and being

there for me in every imaginable way.

ABSTRACT

Real-time media already comprises of a large chunk of the Internet traffic, and its amount

is expected to increase even further in the coming years. In such a situation, where there

exist multiple simultaneous media streams, the questions of congestion control and fairness

gain even greater significance. In this Master thesis, these questions have been targeted and

the use of adaptive bandwidth estimation in ensuring fairness and controlling congestion

has been explored. By incorporating the estimate of the bandwidth in the network into the

parameter calculation for the Adaptive Hybrid Error Correction (AHEC) architecture, along

with the already existing delay and residual loss constraints, we propose to control the con-

gestion in the network. A differentiation between losses due to congestion and corruption

is expected to lead to a better bandwidth estimation in heterogeneous networks.

Keywords

Adaptive Hybrid Error Correction (AHEC), congestion control, bandwidth estimation, fair-

ness, future media internet

TABLE OF CONTENTS

ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

I INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

II ADAPTIVE HYBRID ERROR CORRECTION SCHEME . . . . . . . 13

2.1 Adaptive Hybrid Error Correction Architecture . . . . . . . . . . . . . . . 13

2.2 Analytical Design of Coding Parameters . . . . . . . . . . . . . . . . . . . 15

2.3 PRRT Prototype Implementation . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Evaluation of AHEC Architecture under Limited Bandwidth . . . . . . . 19

2.4.1 Evaluation of Original AHEC Architecture . . . . . . . . . . . . . . 20

2.4.2 Evaluation of Revised AHEC Architecture . . . . . . . . . . . . . . 20

III BANDWIDTH ESTIMATION & CONGESTION CONTROL . . . . . 23

3.1 Bandwidth Estimation Techniques . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Packet Pair/Train Dispersion (PPTD) . . . . . . . . . . . . . . . . 23

3.1.2 Variable Packet Size (VPS) probing . . . . . . . . . . . . . . . . . . 24

3.1.3 Self-Loading Periodic streams (SLoPS) . . . . . . . . . . . . . . . . 24

3.1.4 Trains of Packet Pairs (TOPP) . . . . . . . . . . . . . . . . . . . . 24

3.2 Congestion Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 Window-based congestion control protocols . . . . . . . . . . . . . 25

3.2.2 TCP - like congestion control protocols . . . . . . . . . . . . . . . . 28

3.2.3 Equation based congestion control protocols . . . . . . . . . . . . . 29

3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 TCP Friendly Rate Control (TFRC) Protocol . . . . . . . . . . . . . . . . 31

3.4.1 Loss Event Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1

3.4.2 Model for TCP Throughput . . . . . . . . . . . . . . . . . . . . . . 31

3.4.3 Estimation of round-trip time and timeout value . . . . . . . . . . 33

3.4.4 Estimation of loss event rate . . . . . . . . . . . . . . . . . . . . . 33

3.4.5 Bandwidth Estimation using TFRC . . . . . . . . . . . . . . . . . . 35

3.4.6 TCP Friendly Multicast Congestion Control (TFMCC) Protocol . . 35

IV PROPOSED SOLUTION FOR INCLUSION OF BANDWIDTH LIMI-TATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 Analytical Solution for Optimizing under Limited Bandwidth . . . . . . . 37

4.1.1 Adjusting channel coding rate . . . . . . . . . . . . . . . . . . . . . 38

4.1.2 Adjusting source coding rate . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Proposed Architecture for Bandwidth Estimation using TFRC . . . . . . 41

4.2.1 Sender Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.2 Receiver Functionalities . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.1 Sender Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.2 Receiver Implementation . . . . . . . . . . . . . . . . . . . . . . . . 53

V EVALUATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2 Results & Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

VI DIFFERENTIATING CONGESTION AND CORRUPTION LOSSES 69

6.1 Need for loss differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.2 Available Loss Differentiation Techniques . . . . . . . . . . . . . . . . . . . 70

6.3 Integration with our solution - A Hint . . . . . . . . . . . . . . . . . . . . 70

VII CONCLUSION AND OUTLOOK . . . . . . . . . . . . . . . . . . . . . . . 73

7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

2

LIST OF TABLES

1 Parameters of AHEC Scheme [13] . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Optimum Parameter Sets for different values of Target Packet Loss Rate . . 39

3 Estimated Bandwidth: Comparison of results . . . . . . . . . . . . . . . . . 65

3

LIST OF FIGURES

1 AHEC Architecture [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 PRRT module in Kernel User space1 . . . . . . . . . . . . . . . . . . . . . . 18

3 Queue structure of AHEC protocol stack[1] . . . . . . . . . . . . . . . . . . 18

4 Bandwidth peaks in throughput for pure FEC configuration . . . . . . . . . 21

5 Bandwidth peaks in throughput for HEC configuration . . . . . . . . . . . . 21

6 Data and Acknowledgement transmission of a TCP connection [6] . . . . . 26

7 An example of loss events and loss intervals . . . . . . . . . . . . . . . . . . 32

8 Residual loss as an objective function to be minimized under delay and band-width constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

9 Bandwidth (Residual RI) vs Reliability (Target PLR) . . . . . . . . . . . . 39

10 Functionalities of the sender and receiver in bandwidth estimation . . . . . 42

11 Measurement of Round Trip Time . . . . . . . . . . . . . . . . . . . . . . . 43

12 Token Bucket Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

13 Bottleneck Bandwidth Estimation . . . . . . . . . . . . . . . . . . . . . . . 48

14 Transition from Slow Start to Normal Operation Phase . . . . . . . . . . . 48

15 RTT averaging using EWMA factor of 0.1 . . . . . . . . . . . . . . . . . . . 49

16 RTT averaging using EWMA factor of 0.05 . . . . . . . . . . . . . . . . . . 50

17 RTT averaging using EWMA factor of 0.01 . . . . . . . . . . . . . . . . . . 50

18 Bandwidth Estimation using TCP Response Equation . . . . . . . . . . . . 51

19 Sender Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

20 Receiver Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

21 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

22 Experimental Setup with the bottleneck at the router . . . . . . . . . . . . 59

23 Observation Interval = 1 x RTT . . . . . . . . . . . . . . . . . . . . . . . . 60

24 Observation Interval = 1.5 x RTT . . . . . . . . . . . . . . . . . . . . . . . 61



27 Impact of retransmissions for error correction on sending rate . . . . . . . . 63

28 Experimental Setup with concurrent TCP streams . . . . . . . . . . . . . . 65

5

29 Impact of 1 competing TCP stream on sending rate . . . . . . . . . . . . . 66

30 Impact of 2 competing TCP streams on sending rate . . . . . . . . . . . . . 66

31 Impact of 5 competing TCP streams on sending rate . . . . . . . . . . . . . 67

32 Impact of 10 competing TCP streams on sending rate . . . . . . . . . . . . 67

33 Impact of 15 competing TCP streams on sending rate . . . . . . . . . . . . 68

34 Inclusion of Loss Differentiation into our Bandwidth Estimation Solution . 71

6

CHAPTER I

INTRODUCTION

The Internet today sees a huge traffic of multimedia transmission, and this has been a

compelling factor in the recent evolution of the Internet. The Cisco VNI Forecast [15]

predicts that by the year 2014, the various forms of video (TV, VoD, Internet Video and

P2P) will exceed 91% of the global consumer traffic. According to their Usage Study,

the subset of online video that includes streaming video, flash and Internet TV, already

comprises of 26% of the traffic today. Also the voice and video communication traffic is

now 6 times higher than the data communication traffic. With the advent of 3D video

and HD video, the bandwidth demands are expected to rise even further. It is thus, an

undeniable fact that the Internet is fast converging towards a Media Internet. And this

rapidly increasing demand of real time media services over Internet has led to the creation

of the Future Media Internet [16] concept.

Once dominated by text based data applications, currently the Internet has a major

part of its traffic occupied by the various types of audio-video media. The real time media

traffic on the Internet has different requirements as compared to the data traffic, even

though both rely on the underlying Internet Protocol (whether in its current version IPv4

or in the upcoming IPv6) encapsulation for the digital data transmission. Generally the

audio-visual applications and multimedia data impose certain constraints on delivery time

but can at the same time tolerate some losses, and this is not sufficiently made available

by the current protocols. ITU-T Y.1541 [17] is the most widely agreed recommendation

specifying the objectives of end-to-end network performance for IP based services and it

relates subjective QoS descriptions with IP network attributes like packet transfer delay,

delay variation, packet loss and error ratios and captures the results into a set of Network

QoS classes.

1.1 Motivation

With the definite shift in paradigm that can be seen on the Internet, and the multitude

of media streams being transmitted over it, congestion is a very real problem in today’s

Internet. And with the increasing amount of media content being transmitted, the situation

is expected to get even worse in the future. It is therefore extremely important to identify

the situation when the network is in a congested state. A general practice to over come

transmission losses is to add redundancy to the data being transmitted. But in a situation

where there is congestion developing in the network, the losses can not be reduced by

7

adding redundancy. In fact in congestion scenarios, adding redundancy would degrade the

performance further. Therefore to handle the congestion, we first need to recognize such a

situation and then accordingly take some action, for example, to notify the application of

the congestion and let it decide how to deal with it.

The stability of the Internet today is generally attributed to the fairness inherent to the

TCP protocol. But at the same time there are some applications like the real-time media

applications, which make use of UDP based protocols, which have no notion of fairness. The

UDP-based media streaming applications can be for both stored media content as well as

real time content. The technique for streaming the stored content is progressive download,

where the digital media content is downloaded and stored on the client side device before

being played, while for real time streaming applications a small buffer is used in order to

initiate playback, but at no point the entire media file is stored locally.

All the real time media applications that we are addressing in this thesis have a mini-

mum bandwidth requirement which is essential for its correct behavior, and talking about

fairness towards others while it can not satisfy its own requirements is not feasible. Above

this minimum required bandwidth, the proposed scheme must ensure that friendliness to-

wards other simultaneous streams is maintained. This fairness towards other protocols, for

example TCP, is a big point for public interest because its widely believed that today’s

Internet works because of the fairness introduced due to the pessimistic behavior of TCP.

To handle the congestion situations and to still maintain fairness towards other proto-

cols, an estimate of the available bandwidth in the network is required. Another aspect

to respond better to congestion is the differentiation between losses due to congestion and

losses due to corruption. In case of corruption losses, increasing the redundancy is a good

solution, whereas in case of congestion losses increasing the redundancy would be counter

productive.

Reliable transport protocols like TCP are tuned for good performance in traditional

networks comprising of wired links and stationary hosts, where the packet losses happen

mostly because of congestion. But with the advent and large scale acceptance of wireless

networks, this is no longer true. These wireless links in the heterogeneous networks suffer

from a significant amount of losses which are not due to congestion but due to corruption.

These corruption losses could stem from bit error rate and handoffs etc. TCP invokes its

congestion control and avoidance mechanism in response to all the losses, and this in turn

leads to end-to-end performance degradation in wireless lossy environments.

1.2 State of the Art

Before delving into what our solution for the congestion control mechanism for multicast

real-time media transmission is, let us first take a quick look at how congestion control is

done in the current scenario.

8

TCP, which is considered state of the art, provides a simple interface to establish a fully

reliable end-to-end connection with flow and congestion control, which makes it currently

the preferred protocol for Internet media streaming. Audiovisual applications, however,

prefer timeliness over reliability. This fact clearly contradicts the policy of TCP. It is not

suitable for real time media transmission because it guarantees delivery of every byte by re-

peated retransmissions. If the network quality is bad, this can lead to lots of retransmissions

and delay, which is unacceptable for real time media applications. It is also not scalable

as it doesn’t support multicast. But the major problem, as far as congestion handling is

concerned, is that it assumes every packet loss to be due to congestion, and on detect-

ing congestion it reduces its window size leading to a lower throughput in heterogeneous

networks.

On the other hand, UDP implements only error detection without any correction capa-

bilities and simply sends as fast as possible. It is obvious that neither TCP nor UDP are

able to handle the requirements for a sufficiently reliable multimedia transmission within

an IP based network and therefore new approaches have to be investigated.

A discussion about congestion control or handling in IP networks would be incomplete

without talking about Datagram Congestion Control Protocol (DCCP) [31], which is a

protocol built specifically to be usable like UDP, but with built in congestion control. It

streams datagrams over unreliable unicast connections, though there is a mechanism for

reliable setup/teardown of connections. Negotiating the congestion control mechanism,

which could be TCP like congestion control or TCP friendly rate control, is also possible.

The acknowledgements are only used for implementing congestion control and not to provide

reliability, which remains the task of higher layer protocols. But the main drawback of

DCCP is that it is not scalable to multicast networks. It essentially requires a unicast

connection to each client and therefore is not a very useful approach for the purpose of

multicast transmission of media streams.

In unmanaged IP networks, partial reliability is basically the only option to deal with the

strict time constraints imposed by media applications. There is a partial reliability extension

available for the aforementioned DCCP protocol, PR-DCCP [32]. It can retransmit lost

packets as needed. Since DCCP uses an incremental sequence number, the retransmitted

packets cannot utilize their original sequence number. To solve this problem, PR-DCCP

adopts sequence number compensation, which appends an offset to the retransmitted packet;

thus the receiver can use the sequence number of this retransmitted packet and the attached

offset so as to re-obtain the original sequence number. Furthermore, PR-DCCP utilizes a

DCCP option to record information regarding whether the packet requires reliable delivery.

None of the available transport protocols fulfill the delay and reliability requirements of

the real time media applications described earlier. Therefore future transport protocols for

unmanaged delivery networks have to support a “Predictable Reliability under Predictable

9

Delay” (PRPD) paradigm [1] in order to serve the QoS requirements of audio-visual appli-

cations and to minimize the amount of allocated network bandwidth at the same time.

1.3 Thesis Outline

As mentioned previously, the real time media applications require a predictable deliv-

ery time, but at the same time they can tolerate some residual error. The Telecommu-

nications Lab has developed a media oriented Predictably Reliable Real-time Transport

(PRRT)1protocol stack, which has the Adaptive Hybrid Error Correction (AHEC) mech-

anism at its core, for near optimal error correction at packet level. Within the scope of

this Master’s thesis, we want to design a congestion control mechanism for real time media

transmission which works on top of the available AHEC architecture.

The main goals of this thesis include:

• Introduction to available policies for congestion control and their suitability for real

time media transmission, including exploration of scalability issues for large receiver

groups.

• Evaluation of techniques for estimation of available channel bandwidth for enabling

smoother congestion control in TCP for a potential solution for real time media trans-

mission.

• Development of a congestion control mechanism to operate on top of the AHEC

architecture for real time media transmission, which ensures fairness towards other

protocols.

• Demonstration of the proposed solution in a suitable environment.

The second chapter describes the Adaptive Hybrid Error Correction scheme, in particu-

lar the AHEC architecture, analytical design of coding parameters and the PRRT protocol

stack’s prototype implementation. In addition to these, the AHEC architecture’s perfor-

mance is evaluated under limited bandwidth. The third chapter discusses bandwidth esti-

mation and congestion control. Various kinds of bandwidth estimation techniques and con-

gestion control mechanisms are delineated, and their suitability for our purpose of real-time

media transmission is discussed. We conclude the chapter by elaborating on the working of

TFRC protocol, which is our chosen option for congestion control using bandwidth estima-

tion. In the fourth chapter, we describe our proposed solution for inclusion of bandwidth

limit in AHEC scheme, giving both the analytical background as well as the architecture

design and implementation details. In chapter 5, we present our results and furthermore

sketch a critique for them. We discuss some of the shortcomings of our solution, the reasons

1http://www.nt.uni-saarland.de/projects/prrt

10

for those, and possible solutions for them. In chapter 6, we give a brief introduction into

methodologies for differentiating between congestion and wireless corruption losses and also

the need for them in our scenario of real-time media transmission. We also present a way

of plugging it in with our solution of congestion control which operates over the AHEC

mechanism. In the final chapter, we summarize the findings of this thesis, and conclude

with the open problems that should be addressed in the future.

11

CHAPTER II

ADAPTIVE HYBRID ERROR CORRECTION SCHEME

Audio-visual applications impose strict requirements on the transmission protocols, such

as delay constraints [1] and residual error rates. As discussed in the previous section 1.2,

the available protocols are either not able to guarantee timely delivery or do not provide

enough reliability. Mostly the audio-visual applications prefer timeliness over reliability.

The Telecommunications Lab has proposed a novel PRRT (Predictably Reliable Real-

time Transport) protocol stack which fills the gap between the available transport layer

protocols like TCP and UDP. It strikes a balance between reliability and timely deliv-

ery. At the heart of the Media oriented protocol is the Adaptive Hybrid Error Correction

(AHEC) scheme [1] [10]. It is a versatile scheme which flexibly combines together Negative

Acknowledgment (NACK) based Automatic Repeat reQuest (ARQ), and adaptive packet

based Forward Error Correction (FEC). Inclusion of FEC improves the scalability of the

scheme in the multicast scenarios, and ARQ provides adaptivity. This leads to a near-

optimal coding efficiency which is controlled by the analytical parameter derivation based

on a statistical channel prediction model, which is fed with the receiver feedback. Extensive

experiments [26] have shown that this approach outperforms current transport protocols,

like UDP and TCP, if both reliability and consumed transmission bandwidth are considered.

Several rounds of request and retransmission are allowed as long as the target delay

of the application is not exceeded. The Gilbert-Elliot model is used to model the packet

losses, which has been shown to be a good approximation for the packet loss model in the

wireless channel.

2.1 Adaptive Hybrid Error Correction Architecture

The AHEC scheme, by applying systematic block coding on packet level, generates n code

symbols out of k < n information symbols. The scheme splits the n−k parity symbols of the

systematic code, or packets in this case, according to the vector Np = (np,0, np,1, ..., np,r).

Np vector defines the allocation of redundancy packets per round, where Np[0] = np,0 is the

redundancy sent a priori with the original transmission and np,i are the number of parity

packets sent in the ith retransmission round.

The detailed working of the AHEC scheme is as follows:

1. Encoding and Sending

At the sender side, packet level encoding is applied using virtual interleaving of the

13

Figure 1: AHEC Architecture [1]

packets. Packets from the real-time data source are fed into the interleaver and

then immediately sent on the network. The sender maintains a packet cache for

retransmissions, whose size is determined according to the delay constraint of the

application. k +Np[0] packets are sent immediately after encoding a block.

2. Erasure Detection and Feedback

After receiving a block of packets, the receiver first determines whether it received

enough packets to decode the current block, i.e. at least k packets arrived out of the

n packet block that was sent. Packet erasures are determined by gap detection in the

sequence numbers. If it is unable to decode, then it sends a NACK which identifies

the missing packets to the sender.

3. Feedback Analysis and Updating the Coding Parameters

The sender evaluates the received feedback and determines the current system param-

eters like Group RTT and Group PLR for the receivers, and uses these to update the

AHEC coding parameters to adapt to the variable network conditions. (The PLR can

be estimated by the receiver and then sent to the sender inside the feedback header.)

4. Retransmission and Repetition

In case of k = 1, the original packets are retransmitted, otherwise parity packets gen-

erated by packet-level encoding are sent. Depending on the current AHEC parameters

applied by the sender, steps 1 to 4 are performed r = length(Np)−1 times within the

delay constraint.

14

The receiver feedback is used by the sender to analytically calculate the parameters

based on a statistical channel model in order to predict the reliability and the redundancy

produced by a certain coding parameter set. The parameter set that satisfies the application

constraints (target delivery time DTarget and reliability) with the lowest amount of redun-

dancy added is chosen. Therefore the receiver gets the quality of service it requires, at the

time it requires it in, assuming that channel capacity is sufficient. This will be an important

point for the use of bandwidth estimation techniques, as described in later chapters.

Table 1: Parameters of AHEC Scheme [13]

Symbol Definition

System Parameters

R Multimedia data rateL Packet lengthSimplified GE Packet loss modelRTT Round trip timePe Original link packet loss rateTs Packet interval

ConstraintsPLRtarget Packet loss rate requirement of applicationDtarget Delay constraint of application

Coding Parameters

Np Vector Np = (np,0, np,1, ..., np,r) defines the allocation of re-dundancy packets per round, where Np[0] = np,0 is the re-dundancy sent a priori with the original transmission andnp,i are the number of parity packets sent in the ith retrans-mission round.

k Number of data packets per block, i.e message lengthn Code word length

2.2 Analytical Design of Coding Parameters

Since the proposed protocol is supposed to adapt to the temporally changing network condi-

tions, we achieve adaptivity by analytical parameterization. Additional degrees of freedom

are available due to the combination of FEC and ARQ. Therefore, we can look at the

parameter search as an optimal distribution of the target delay budget by finding a good

trade-off between the number of retransmission rounds r = length(Np)− 1 and the coding

block length k. As presented by the authors in [1], we give a short description of the simple

analysis for the optimal coding parameters under the observed network state and the given

constraints for delay and residual error rate. The optimization target is - with minimum

redundancy RI - to guarantee a certain target packet loss rate (PLR) requirement under a

strict delay constraint.

By adjusting the block length k and number of retransmission rounds r = length(Np)−1,

15

according to the real-time stream’s average packet interval Ts and the observed round trip

time RTT , we can achieve a predictable and upper-bounded target coding delay DTarget.

For a chosen r we get,

k(r) =

⌊DTarget − (12 + r) ·RTT

Ts

⌋, (1)

where we have also included the transmission delay for the original transmission.

The authors of [18], apply the sequence analysis on the Gilbert-Elliot model, which repre-

sents a two state Markov chain, so as to estimate the residual erasure rate of a C(n, k) MDS

(Maximum Distance Separable) code, over a channel with erasure rate Pe and correlation

coefficient ρ for the state transitions. For a simplified analysis here, we choose the Gilbert -

Elliot model with zero correlation coefficient, equivalent to the binomial distribution. Then

the probability of d erasures in a sequence of n packets is given by,

Pdist(d, n) =(nd

)P de (1− Pe)

n−d. (2)

Let i denote the number of lost data packets in case of j packets being lost in one

encoding block of n packets. Since it is a systematic code, this means that amongst all of

the j lost packets in the block, there are i data packets lost from the k data packets and

there are j − i parity packets lost from n− k parity packets. Since all of the packets in one

encoding block have the same loss probability, the probability that j erasures in the block

of length n, hits i out of the k data packets is given by,

Pd(n, k, i, j) =

(ki

) (n−kj−i

)(nj

) . (3)

Then the residual loss rate of the C(n, k) code corresponds to the expected number of

unrecovered data packets per block divided by k,

Pres =1

k

k∑i=1

n−k+i∑j=max(n−k+1,i)

i · Pd(n, k, i, j) · Pdist(j, n). (4)

We choose a large enough n such that the residual erasure rate satisfies the PLR con-

straint and remains lower than PTarget.

16

The overall redundancy added on to the channel depends on the distribution of the

parity packets across the r retransmission cycles. By the wth round the number of packets

the sender has already sent are

−→n [w] = k +

w∑s=1

−→Np[s]. (5)

The retransmission round w is triggered by the loss notification in the previous round,

i.e. with the probability of decoding failure in the w − 1th round. Let Rw be the random

variable denoting the number of packets collected at the receiver at the end of the wth

round, then it is less than k with the probability,

Pr(Rw < k) =

−→n [w]∑j=−→n [w]−k+1

Pdist(j,−→n [w]). (6)

Then the overall redundancy is given by

RI =1

k

(−→Np[1] +

r∑w=2

Pr(Rw−1 < k).−→Np[w]

), (7)

where−→Np[1] is included because these parity packets are sent without receiver request.

The AHEC coding parameter set (k,−→Np) is iteratively adjusted between k and r, while

finding the optimal distribution of parity among the available retransmission rounds. Be-

sides just this naive long full search, a greedy algorithm to solve this optimization problem

also exists. Since this search of the optimal parameters is computationally quite intensive,

devices with limited processing capabilities should have pre-calculated tables of parameters

under typical scenarios, stored on them before hand.

2.3 PRRT Prototype Implementation

The prototype implementation of PRRT or Predictably Reliable Real-time Transport pro-

tocol suite is an enhanced version of the prevalent UDP stack to incorporate the above

described AHEC scheme that forms its core. In this thesis we will just give a brief outline,

for more details please refer to [12] and [13].

It is integrated as a kernel module into the Linux kernel, such that the AHEC function-

ality is encapsulated into a runtime-loadable kernel module. The inclusion of the prototype

1PRRT Project webpage : www.nt.uni-saarland.de/projects/prrt

17

Figure 2: PRRT module in Kernel User space1

implementation into the kernel has several advantages such as lower overhead of system

calls, lower maintenance effort, and support for run time loading. The application instan-

tiates a network socket that communicates via the kernel module providing predictable

reliability under predictable delay. Since the socket handling for PRRT is very similar to

the UDP socket, it provides a simple way for the programmers to implement PRRT into

existing softwares and thus provides a lot of flexibility.

Figure 3: Queue structure of AHEC protocol stack[1]

A number of FIFO queues with parallel access underly the operation of the PRRT

18

protocol:

• Outgoing Packet Queue

Packets scheduled to be transmitted are put here. When they are put on to the

physical network to be transmitted the packets are also moved to retransmission

queue immediately.

• Retransmission Queue

The sender retains the transmitted packets in the retransmission queue to serve the

repetition requests for at least the target delay time.

• Incoming Packet Queue

At the receiver, gap detection, packet reordering and insertion of retransmitted packets

happens at the incoming packet queue. Also the parity packets are demultiplexed and

moved to parity queue.

• Re-request Queue

The information of the incomplete blocks from the gap detection is maintained in the

re-request queue. The feedbacks are sent periodically with the loss notifications.

• Parity Queue

Both the sender and the receiver maintain parity queues . At the sender, the packet

level encoder fills it and the retransmission requests are answered from the parity

queue. And at the receiver, the redundancy packets are supplied by the parity queue

to the packet level decoder.

The protocol stack provides a C/C++ socket library similar to the UDP socket API, to

make it more easy and familiar for the application programmers. The AHEC is configured

using socket options. The interface provides access to the channel state information and

the coding parameters, therefore an external application can perform parameter adaptation.

These coding parameters can either be obtained from pre-computed parameter tables, or

analytically as described in the previous section 2.2.

The prototype implementation inherits the multicast support and connectionless packet

delivery from the UDP stack.

2.4 Evaluation of AHEC Architecture under Limited Bandwidth

In the previous sections, we have introduced and elaborated on the media oriented PRRT

protocol and the AHEC mechanism that forms it’s core. It can be seen that there are a few

open issues in the current AHEC scheme. As of now, there is no upper limit to the amount

of redundancy that can be added to correct erasures. Therefore, in principle, we can correct

any error rate just because there is no upper limit to the amount of redundancy that can

19

be added. Also currently, the stream under consideration is assumed to be the only stream

and there is no mechanism to implement fairness amongst multiple simultaneous streams.

We address these issues of limited channel bandwidth and fairness towards other media

streams in this thesis.

Before discussing the solution for the functioning of AHEC under bandwidth constraint,

let us first evaluate how the AHEC architecture behaves under limited bandwidth.

2.4.1 Evaluation of Original AHEC Architecture

In the original formulation of the AHEC Architecture [18], the author had used Nrr which

gives the number of retransmission rounds and Nrt vector which defines the number of

redundancy packets retransmitted in one retransmission round for each lost packet, to

characterize the error correction mechanism. To satisfy the delay budget the trade off was

between the number of retransmission rounds and the coding block length. This could

therefore lead to a peak in the bandwidth requirement, because even though the elements

of the Nrt vector might be small individually, but they are still multiplied by the number

of NACKs received for a particular retransmission round. For example, if Nrr = 3, and

Nrt = {1, 1, 3} and 5 NACKs are received in the third retransmission round, then 5×3 = 15

packets would need to be retransmitted in a burst which would correspond to a peak in

the bandwidth requirement. Therefore even though this configuration could be sufficient to

reach some residual loss under certain network conditions, this came at the price of a very

large bandwidth requirement in the last retransmission round. This kind of bursty behavior

produced by redundancy transmissions was unwanted for the real time media applications.

2.4.2 Evaluation of Revised AHEC Architecture

In the revised architecture [1], the authors do not use the Nrt vector anymore, but instead

make use of the Np vector which defines how the n−k parity packets are distributed amongst

the different transmission rounds, where Np[0] gives the number of parity packets which are

sent a priori with the original transmission. Again in case any of the elements of the Np

vector become too large, then a burst of parity packets would be sent together and this can

lead to a bandwidth peak in the transmission. The queues on the routers do not distinguish

between the data packets and the parity packets, therefore with a sudden influx of large

number of parity packets, they may drop packets and there may even be congestion losses

due to queue overflows.

To exemplify this bursty behavior, we ran a short evaluation experiment over the

100Mbps network without any bottleneck bandwidth. Our sender and receiver were both

equipped with our PRRT protocol stack. We transmitted a high data rate stream from the

sender to the receiver, under the pure FEC configuration as well as the HEC configuration.

We then plotted the transmission bandwidth by using the throughput analysis feature of

20

the Wireshark1tool. The resulting plots of throughput against the transmission time are

shown in the diagrams 4 and 5.

Figure 4: Bandwidth peaks in throughput for pure FEC configuration

The plot shown in the diagram 4 shows the variation of the throughput along time for

a pure FEC case, with k = 50 and n = 80. As can be seen in the diagram, there are clear

bandwidth peaks in the throughput, and these are present throughout the transmission

time.

Figure 5: Bandwidth peaks in throughput for HEC configuration

1http://www.wireshark.org/

21

The plot shown in the diagram 5 shows the variation of the throughput along time for a

HEC case, with k = 50, n = 80 and parity packet distribution over the transmission rounds

given by Np = (5, 10, 15). Again it can be seen in the diagram that there are clear bandwidth

peaks in the throughput, and these are again present throughout the transmission time.

Therefore under a bottleneck bandwidth, these bandwidth peaks in the transmission

where longer bursts of parity are sent at once, can exceed the available bandwidth and lead

to congestion losses. Thus a pure FEC or a stronger HEC configuration is not possible

under bottleneck bandwidth in the current architecture.

22

CHAPTER III

BANDWIDTH ESTIMATION & CONGESTION CONTROL

Congestion occurs when the amount of data being transmitted through a network begins

to approach the data carrying capacity of the network. The objective of the congestion

control mechanisms is to maintain the amount of data in the network below the level at

which the performance drops off significantly. Consequently congestion control is a research

area where there has been extensive work in the past. In this chapter we will take a look

at the different classes of congestion control protocols and discuss their suitability for our

purpose of congestion control for media transmission.

For the multimedia transmission over a network, bandwidth is a key factor that affects

the packet loss rate. The packet loss rate may be severe if the sending rate is not adaptively

adjusted according to the network conditions, in turn, leading to congestion losses. There-

fore we will also take a look at the available techniques for bandwidth estimation, which as

stated, is closely related to the congestion control and adaptive rate adjustment.

3.1 Bandwidth Estimation Techniques

Knowing the bandwidth of the channel in an adaptive manner is crucial for ensuring that we

utilize the bandwidth using the most optimum codes, and without giving rise to congestion.

In the following sub-sections we present a brief overview of these bandwidth estimation

techniques for the purpose of congestion control and discuss their suitability for our pur-

pose of realtime media transmission.

Let us first take a quick look at the array of techniques available for estimating the

bandwidth on the channel. Though there can also be passive measurements [19] techniques

where we have a trace of the network conditions collected before hand. These are not of

interest to us, but we are interested in the active probing techniques. The typical active

probing techniques are packet pair/train dispersion (PPTD), variable packet size (VPS)

probing, Self-Loading Periodic streams (SLoPS) and Trains of Packet Pairs (TOPP).

3.1.1 Packet Pair/Train Dispersion (PPTD)

In packet pair probing technique [20], [21], the source sends multiple packet pairs to the

receiver. The receiver computes the end-to-end capacity by observing the delay between

the packets of the packet pairs, or in other words the dispersion which is experienced by

the packet pairs. Since the method is susceptible to the influence of cross traffic, therefore

23

a number of packet pairs are sent and filtering is done using statistical methods.

3.1.2 Variable Packet Size (VPS) probing

VPS probing [22], [23] measures the capacity of each hop along a transmission path. The

key element of the technique is to measure the RTT from the source to each hop of the path

as a function of the probing packet size. It sends multiple probing packets of a given size.

VPS makes use of the Time to Live (TTL) field of the IP header to force probing packets

to expire at a particular hop. The router at that hop then discards the probing packets,

and returns an ICMP “Time-exceeded” error message back to the source. The source uses

the received ICMP packets to measure the RTT to that hop. The RTTs for different packet

sizes are plotted, and the inverse of the slope of the graph gives the capacity of the link.

Unfortunately, the capacity estimates produced by VPS are often wrong. In the presence

of store-and-forward layer 2 devices like switches and hubs, they add extra transmission

latency and this leads to underestimation of the link capacity. Several tools like pathchar

[22], clink [28], and pchar [29] work on this principle.

3.1.3 Self-Loading Periodic streams (SLoPS)

In SLoPS [24], a sequence of packet probe trains is sent at a specific rate, where each of the

packet trains is of the same size. The sender tries to modify its sending rate such that it can

bring the stream rate close to the available bandwidth of the path. The sender varies its

sending rate by observing the variations in the one-way delays which are seen by the stream.

If the streaming rate is greater than the available bandwidth on the path, there will be a

short term overload in the bottleneck link’s queue, leading to an increase in the one way

delay of the probing packet trains. And inversely, when the streaming rate is less than the

available bandwidth, the one way delays of the packet train will not increase. Even though

SLoPS does overcome the inaccuracies in the existing probing techniques, it still can not

be used for real-time applications because it requires very large number of packet streams,

and also very long measurement periods. Pathload [27] is a tool based on this technique.

3.1.4 Trains of Packet Pairs (TOPP)

TOPP [25] sends many packet pairs at gradually increasing rates from the source to the

sink. This basic idea is very similar to SLoPS. In fact most of the differences between the

two methods are related to the statistical processing of the measurements. Also, TOPP

increases the offered rate linearly, while SLoPS uses a binary search to adjust the offered

rate. An important difference between TOPP and SLoPS is that TOPP can also estimate

the capacity of the tight link of the path. This capacity may be higher than the capacity

of the path, if the narrow and tight links are different. Here tight link refers to the link in

the path with the lowest available bandwidth, while the narrow link is the bottleneck link.

24

This methodology is not able to capture the fine grained interaction between the probes and

the competing flows and this temporal queuing behavior is useful for available bandwidth

estimation.

[30] provides a very comprehensive comparison study of the different bandwidth estima-

tion methodologies and tools.

3.2 Congestion Control Mechanisms

Next we take a look at the different kinds of congestion control mechanisms. They can

be broadly classified into three categories, the window based congestion control, TCP-like

congestion control protocols and the equation based congestion control mechanisms. We

will next describe each of these briefly, and give an example of each.

3.2.1 Window-based congestion control protocols

Window-based congestion control protocols, as the name suggests make use of a congestion

window just like TCP, and therefore portray a similar behavior. They vary the size of their

windows in order to regulate the amount of information being injected into the network,

based on the network conditions. TCP, in particular, makes use of Additive Increase, Multi-

plicative Decrease (AIMD) mechanism, such that it linearly increases the congestion window

size to probe the available bandwidth, and when it encounters congestion it decreases its

window size multiplicatively (by halving it).

3.2.1.1 LIAD for TCP Congestion Control

Here the TCP congestion control mechanism has been modified to fit the requirements of

heterogeneous wireless networks by making use of an adaptive window congestion control

mechanism, LIAD or Logarithmic Increase and Adaptive Decrease. The analysis of the

adaptive bandwidth prediction based LIAD for TCP congestion control scheme [6] is based

on the RTT. In the slow start phase, LIAD adopts the same exponential increase mechanism

with the available bandwidth prediction for determining the ideal slow start threshold. The

logarithmic increase takes place to increase the cwnd every time an ACK is received in

the congestion avoidance phase. And the adaptive decrease is based on an adaptive shrink

factor based on an adaptive bandwidth prediction. This is used to dynamically shrink the

cwnd in the congestion avoidance phase.

Figure 6 shows the transmission of data and acknowledgment segments in a TCP con-

nection, where S is the maximum segment size and R is the data rate of the connection. The

round trip time is RTTmin, when the network is not saturated. In a light traffic network,

the total time for sending a segment is therefore SR +RTTmin. And in a light traffic network,

25

Figure 6: Data and Acknowledgement transmission of a TCP connection [6]

increasing the cwnd does not increase the round trip time and the total time for sending

cwnd segments should be less than SR +RTTmin,

cwnd.(MSS

Rate) < (

MSS

Rate) +RTTmin. (8)

In the increasing cwnd phase, while the expected bandwidth is sufficient, the cwnd is

constrained by

cwnd <RTTmin

MSSRate

+ 1 (9)

which is derived by rearranging the terms of the inequality 8.

The optimal cwnd size is given by the right hand side of the inequality 9 .This is the cwnd

beyond which the network traffic is saturated, and the RTT progressively keeps increasing

till congestion occurs finally. In this expression, the RTTmin is the minimum RTT of the

connection when the network traffic is not yet saturated, MSS is the maximum segment

size and the Rate is the data rate of the connection.

The RTT is used as a measure of the traffic load in the network. The RTT value

based on the ACKs is used to determine the slow start threshold, ssthresh adaptively. The

ssthreshideal is given by

ssthreshideal =RTTmin

InterACK+ 1, (10)

which is basically the optimal cwnd for the current traffic load on the network. Here,

a modified - EWMA value of InterACK period is used as the parameter to represent the

26

current traffic load. Modified Exponentially Weighted Moving Average (M - EWMA) model

is used to compute the new expected smooth InterACK (InterACKnew) given by,

InterACKnew = α · InterACKcurrent + (1− α) · InterACKDiff, (11)

InterACKDiff = InterACKcurrent − InterACKold. (12)

Here, InterACKcurrent is the current inter-ACK time, InterACKDiff is the difference be-

tween the current and previous ACKs, and α is a constant value in the range (0,1). Thus

both in the case of a wireless link with non-consecutive packet loss (i.e. receiving non

consecutive duplicate ACKs), and in a wired network with consecutive loss of packets (i.e.

receiving consecutive duplicate ACKs), M-EWMA supports a fast response and thus has the

inherent capability to differentiate between these two types of packet losses (wired link’s

consecutive congestion losses and wireless link’s non-consecutive corruption losses) for a

better estimate of the available network bandwidth. The adaptive Network Bandwidth is

estimated using RTT of the last received ACK :

Adaptive Network Bandwidth =ssthreshideal

RTT. (13)

Under the estimated bandwidth, cwnd increases exponentially until the cwnd exceeds

the ssthreshnet in the slow start phase and then enters into the congestion avoidance phase.

ssthreshnet is given by

ssthreshnet = (Adaptive Network Bandwidth)×RTTmin (14)

= ssthreshideal ×RTTmin

RTT. (15)

This implies that ssthreshideal of the estimated network bandwidth occurs when the

RTT for the network is same as RTTmin. The term RTTminRTT is called the shrink factor of

the ssthreshideal. When the network becomes congested, the RTT increases and the shrink

factor decreases and the optimal cwnd shrinks. If the DUPACK is due to packet loss in a

wireless link, RTT is not affected and the shrink factor is not updated, therefore the cwnd

remains unchanged.

3.2.1.2 TCP Emulation at Receiver (TEAR)

Another approach in this category of window based congestion control protocols is TEAR

[5]. In this approach a congestion window is maintained and the sending rate is set using

the size of the congestion window. The congestion window or cwnd is located at the receiver

instead of being maintained at the sender to make the protocol suitable also for multicast,

in addition to unicast transmissions. Its size is manipulated similar to as is done for TCP,

27

by emulation of the timeouts and triple DUPACKs by the receiver. The RTT is measured

at the receiver, and the sending rate is maintained as cwnd/RTT .

3.2.2 TCP - like congestion control protocols

These congestion control protocols adjust their sending rate according to TCP’s Additive

Increase Multiplicative Decrease (AIMD) mechanism, but do not make use of a congestion

window.

3.2.2.1 Loss Delay based Adjustment Algorithm

Loss Delay based Adjustment Algorithm [8] is a TCP friendly adaptation scheme, in which

the transmission rate of the media applications adapts to the congestion level of the network

in a TCP friendly manner. It is a sender based adaptation scheme that relies on the

RTP/RTCP for feedback information about the losses and RTT. During periods without

losses, the sender increases its transmission rate by an Adaptive Increase Rate (AIR), which

is estimated using the loss, delay and bottleneck bandwidth values reported in the RTCP

feedback reports. During under load periods, the transmission rate is increased by AIR,

and it is multiplicatively decreased during congestion periods.

In RTP, each session member periodically sends RTCP reports to all other session mem-

bers. The sender reports contain the amount of data sent and the timestamp of when the

report was generated. The receiver report includes the fraction of lost data, timestamp of

last received sender report, tLSR, for a stream and the time elapsed between receiving last

sender report and sending the receiver report, tDLSR. The RTT can then be determined by

RTT = RRrecvd − tDLSR − tLSR. (16)

The propagation delay for the connection is taken as the minimum measured RTT.

The bottleneck of a network is estimated by enhancing RTP with the packet pair ap-

proach. The essential idea behind the approach is that if two packets can be caused to

travel together such that they are queued as a pair at the bottleneck, with no packets

intervening between them, then the inter-packet spacing will be proportional to the time

required for the bottleneck router to process the second packet of the pair. Therefore, a

stream of n packets is sent at the access speed of the end system. Then at the receiver site,

the bottleneck bandwidth is given by,

Bottleneck Bandwidth =probe packet size

gap between two probe packets. (17)

The data packets are used as the probe packets to avoid adding packets to the network

load.

28

The approach has some serious shortcomings. It does not include the times between

transmission of two probe packets and moreover, it does not consider packet drops or any

competing traffic.

In periods of no packet losses the sending rate is increased using an Additive Increase

Rate (AIR) that depends on the ratio of the current sending rate to the bottleneck band-

width. If the received RTCP messages from receiver i indicates no losses, then the sender

calculates the AIRi for this receiver as,

AIRi = AIR+Bf , (18)

where

Bf = 1− r

b. (19)

Here, AIR is the additive increase value calculated for the entire session, r is the current

transmission rate, b is the bottleneck bandwidth and Bf is the bandwidth factor that allows

connections with a low bandwidth share to use larger AIR values to converge faster to their

fair bandwidth share. The process of calculating the optimum AIR is a recursive process.

The AIRi for each receiver is limited to the average rate of increase a TCP connection

would utilize during periods without losses in a time interval equivalent to the the interval

between reception of two RTCP messages.

With each received RTCP packet from a member i, the sender recalculates the trans-

mission rate ri it would use if member i was the only member of the multicast session,

which is then saved in a database. If no losses were indicated, then the sender recalculates

the AIRi as shown in equation 18 and sets

ri = r +AIRi, (20)

where r is the transmission rate the sender uses for the entire session.

When the RTCP indicates losses, the sending rate is exponentially decreased in propor-

tion to the number of lost packets. If losses were indicated, then the sender reduces ri in a

TCP fashion, i.e. proportional to the indicated losses l, by setting it to

ri = r × (1− (l ×Rf )). (21)

Here Rf is the reduction factor which determines the degree of reaction of the sender to

losses. A high Rf leads to faster reduction but oscillatory behavior, while a low Rf leads

to more stable rate values but longer convergence period.

3.2.3 Equation based congestion control protocols

The Equation based congestion control protocols make use of a control equation to deter-

mine the sending rate. And generally this equation is derived from a model of the competing

29

traffic, for example TCP.

3.2.3.1 TCP Friendly Rate Control protocol

In TCP Friendly Rate Control protocol [2], the long term throughput equation of TCP

(Reno) is used as the control equation. The sender explicitly adjusts its sending rate as a

function of the measured rate of loss events in response to feedback from the receiver. The

loss event rate and RTT are fed to the control equation which governs the sending rate.

Therefore it performs similar to TCP’s AIMD mechanism.

3.2.3.2 Wave and Equation Based Rate Control

Wave and Equation Based Rate Control (WEBRC) [3] is an equation based multiple rate

multicast congestion control protocol. Being an equation based approach it ensures fairness

towards TCP with lesser fluctuations in the flow rate than TCP. It makes use of multicast

round trip time (MRTT) as a parameter to adjust the reception rate. MRTT is measured

independently by the receivers without any added burden on the sender, receiver or the

network. MRTT, similar to unicast RTT, increases with increasing queueing delay. It

synchronizes and equalizes the reception rates of the receivers in a proximity and causes

them to increase with the density of receivers.

A WEBRC sender transmits packets on a base channel and on T wave channels. The

transmission pattern on each wave channel is a sequence of periodically-spaced waves sep-

arated by quiescent periods. In a fluid model, the rate of each wave is predominantly

described by an exponential decay by a factor of P each T seconds. The beginnings of

the waves are designed so that the sum over all of the channels of the fluid-model rate is

constant. At any time the receiver is receiving from the base channel and some number

of other consecutive waves depending on the target reception rate of the receiver. The

receivers measure the loss event rate and MRTT and update their target reception rate.

WEBRC is mainly intended for applications for reliable download which can receive

packets from different channels.

3.3 Summary

As seen in the previous sections, an alternative to the window based congestion control

mechanisms are the rate based congestion control mechanisms, where the sending rate is

directly adjusted to the amount of congestion in the network. These are most useful for

applications like streaming multimedia, which are inherently rate based. In these cases

it is easier to modify the sending rate to conform to the timing, delay jitter or minimum

bandwidth constraints imposed by the application. It provides more flexibility than TCP

by decoupling reliability and congestion control.

30

As described in section 3.2.3.1, TCP Friendly Rate Control (TFRC) protocol is an

equation based congestion control scheme which has the TCP throughput equation as its

control equation ensuring TCP friendliness, in addition to the above mentioned advantages

of equation based approaches. Therefore TFRC is our chosen approach for congestion

control with bandwidth estimation. We give the details of the working of the TFRC protocol

in the next section.

3.4 TCP Friendly Rate Control (TFRC) Protocol

One of the aims of this thesis is to make our media oriented protocol suite TCP - friendly. As

mentioned earlier in section 1.1, fairness towards other competing protocols, specially TCP

is a big point of public concern. Non -TCP flows are considered TCP-friendly when their

long term throughput does not exceed the throughput of a TCP connection under the same

network conditions. Different TCP variants can achieve considerably varying throughputs.

The loss patterns also affect the TCP throughput, and therefore different TCP variants

respond differently to the same loss pattern. Therefore, a TCP-friendly flow’s sending rate

should be in the same order of magnitude as the corresponding TCP throughput under

the same network conditions, and not necessarily follow the throughput of a specific TCP

variant.

Now that we know what TCP friendliness is, we proceed on to describe how the TFRC

operates.

3.4.1 Loss Event Rate

The loss event rate p, is the key essence of the TFRC protocol. The loss event is defined

as one or more packets lost within one round trip time. Therefore subsequent losses, after

the first loss within a round trip time, are ignored. This means that at most there can

only be one loss event in one round trip time. Another term of importance is loss interval.

Loss interval is defined as the number of packets between loss events. Figure 7 shows the

relationship between the loss events and the loss intervals.

Loss event rate p is estimated as the inverse of the average loss interval, as described

later in section 3.4.4.

3.4.2 Model for TCP Throughput

For TCP friendly rate control, the appropriate choice for the control equation is the TCP

response function characterizing the steady state sending rate of TCP as a function of RTT

and the steady state loss event rate. (This does not accurately estimate the short-term

throughput during a single RTT, but average long-term throughput over multiple RTTs. )

31

Figure 7: An example of loss events and loss intervals

T =s

RTT√

2p3 + tRTO(3

√3p8 )p(1 + 32p2)

, (22)

is the TCP response function [2] [7] which gives the upper bound on the sending rate

T , as a function of the packet size s, RTT , steady state loss event rate p, and the TCP

retransmit time out value tRTO.

This model of the TCP throughput assumes that there is at most one window reduction

event per RTT. This TCP behavior is approximated by assuming that if a packet is lost in

a window, all the subsequent packets of the window are also lost.

This model is adjusted for TCP with selective acknowledgements (SACK - TCP). Since

SACK -TCP performs better than all other TCP variants in high loss states, therefore this

throughput model may overestimate the throughput of some of the TCP variants.

The loss event rate is measured at the receiver. The receiver either sends loss event rate

or the calculated transmission rate back to the sender, at least once per RTT. Every time a

feedback message is received, sender calculates the new value for the sending rate T, using

the control equation. If the actual sending rate is less than T, the sender may increase its

sending rate, otherwise it must decrease its sending rate to T.

For a multicast scenario it is more viable for the receiver to determine the relevant

parameters and calculate the allowed sending rate. In our implementation also the receiver

calculates the bandwidth estimate and sends it to the sender, as described in section 4.2.

32

3.4.3 Estimation of round-trip time and timeout value

The RTT can be measured at the sender as well as at the receiver. The timeout value, tRTO

is estimated as 4×RTT . This coarse estimation is justifiable because here, unlike in TCP,

it is only used as a parameter for the TCP model and not for scheduling the retransmissions

of packets. Therefore its impact on the sending rate is only noticeable at high loss rates.

3.4.4 Estimation of loss event rate

Most TCP implementations reduce their sending rate in response to a packet loss only once

per window. Further losses in the same window are ignored. Usually the losses are measured

as the loss fraction, which is just the ratio of the lost packets to the number of transmitted

packets. But the way TCP responds to losses is not modeled accurately by this loss fraction,

as TCP typically reduces the congestion window only once in response to several losses in

a window. A loss event therefore can consist of one or more packets lost within one RTT.

The definition of loss events complies with the one reduction event at maximum per RTT

by many TCP variants. To emulate the behavior of TCP conformant implementation, the

losses within an RTT that follow an initial loss are explicitly ignored and the protocol is

modeled such that it reduces its window at most once for a congestion notification in one

window of data. Therefore the losses are measured as the loss event fraction. If N packets

are transmitted in one RTT period, ploss is the packet loss probability, then the loss event

fraction is determined as,

Loss Event Fraction =Probability of losing at least 1 packet out of N

N(23)

=1− (1− ploss)N

N. (24)

Practically, we compute the loss event rate, indirectly by determining the average loss

interval, as described in the next section. Loss event rate is then the inverse of the average

loss interval.

3.4.4.1 Weighted Average Loss Interval Method

We measure the loss event rate over a certain interval of time, which is called the loss history.

The length of the measurement period provides a trade off between responsiveness by using

a short period, against stability by using a longer period. To measure the loss event rate

we use the indirect method of measuring the average loss interval, which is defined as the

average number of packets between loss events. The estimated loss event rate is the inverse

of the average loss interval.

The average loss interval method measures the arithmetic average loss event rate over

the last n loss intervals. Let si be the number of packets in the ith most recent loss interval,

33

and so be the interval containing the packets since the last loss event. so is the as yet non -

terminated loss interval and it must only be included in the average loss interval calculation

when it is large enough to increase the average loss interval value when included in this

calculation. The weighted average loss interval method takes a weighted average of the last

n loss intervals, with the average loss interval given by,

savg =

n∑i=1

wisi

n∑i=1

wi

(25)

Till the time the total number of loss intervals is less than n, the total number of loss

intervals are used to calculate the average loss interval. A weight distribution which is

best suited is such that it ensures that the recent loss intervals which represent the current

congestion state of the network have equal weights and the older intervals after a certain

number of intervals have smoothly decreasing weights so that the older loss events do not

affect the average loss interval estimate. For this reason, the weight of the n/2 most recent

intervals is set to one and the remaining n/2 have weights decreasing to 0.

wi = 1, 1 ≤ i ≤ n/2, (26)

= 1− i− n/2n/2 + 1

, n/2 < i ≤ n. (27)

Currently n=8 is chosen as it gives a good compromise between stability and responsive

as shown by the authors of TFRC [2]. Therefore we get the weights as w1, w2, w3, w4 = 1;

w5 = 0.8 ; w6 = 0.6; w7 = 0.4 and w8 = 0.2.

We also calculate the average loss interval including the as yet non terminated loss

interval, or so,

s′avg =

n−1∑i=0

wi+1si

n∑i=1

wi

(28)

and to ensure that so is only included at the right times as mentioned before, we use

the maximum of savg and s′avg as the estimate for the average loss interval.

3.4.4.2 History Discounting

To allow more timely response to sustained decrease in the congestion in the network,

history discounting is used to smoothly discount the weights given to older intervals when

a significantly long interval since the last loss event is encountered. When so is more than

34

twice the last estimate of average loss interval, the weights of older intervals are discounted

by the discount factor,

di = max(0.5,2savgso

), i > 0, (29)

do = 1. (30)

Therefore the estimated average loss interval is then,

s′avg =

n−1∑i=0

diwi+1si

n∑i=1

di−1wi

(31)

When loss occurs and so is shifted s1, then discount factors are also shifted such that if

a loss interval is ever discounted, then it is never un-discounted, and it’s discount factor is

never increased.

3.4.5 Bandwidth Estimation using TFRC

Now by observing the packet losses at the receiver, we can measure the loss event rate. This

packet loss history since the last feedback and the value of the RTT are are used to calculate

the bandwidth estimate for the network channel using equation 22. This estimate for the

channel bandwidth is fed back to the sender. The details of implementation of the TFRC

which is included within our media transport protocol PRRT, is given in section 4.2.

3.4.6 TCP Friendly Multicast Congestion Control (TFMCC) Protocol

A drawback of TFRC is that it is only meant for unicast environments. But with the

trend towards multicast and applications like multimedia streaming, which would benefit

from multicast, TFMCC [4] was developed which extends the functionality of TFRC to

multicast environment. The major problem with TFRC in multicast scenario is of feedback

implosion, where a large number of receivers would send feedback to the sender. Therefore

some changes need to be made. The target sending rate is computed at the receivers,

as the different receivers may experience different network conditions. Now the receiver

needs to measure the RTT between itself and the sender. Therefore the receivers send

packets to sender which echoes them including the timestamp for when it was sent. To

limit the feedback from the receivers to the sender, a feedback is sent only if the estimated

sending rate is less than the current actual rate. To ensure that there is some mechanism to

increase the sending rate, a receiver in the multicast group which seems to have the lowest

throughput is chosen as the ”Current Limiting Receiver” or CLR. It is allowed to send the

35

feedback immediately, and therefore the sender can increase or decrease the sending rate

appropriately. A new CLR needs to be chosen when another receiver’s throughput goes

below the throughput of CLR, or the CLR leaves the multicast group.

During a change in the network conditions when other receivers are affected, a CLR is

not of much help. Therefore in addition to the CLR, exponentially weighted randomized

timers are used, with a bias to favor feedback of the low-rate receivers, are used. When the

timer expires the receiver sends its calculated sending rate to the sender by unicast. If the

rate is lower than any of the feedback received previously, the sender forwards the sending

rate to all the receivers. The original technique of exponentially weighted randomized timers

is improved upon, as stated earlier, by biasing the feedback such that low rate receivers are

favored. Therefore when required a new CLR can be suitably selected, and all of it is done

while avoiding a feedback implosion.

TFMCC is designed to work with a multicast group consisting of thousands of receivers

and the authors have reported that TFMCC behaves similar to TFRC, with regards to

fairness towards TCP.

36

CHAPTER IV

PROPOSED SOLUTION FOR INCLUSION OF BANDWIDTH

LIMITATION

In this thesis, our aim is to estimate the bandwidth in the network, and incorporate this

bandwidth estimate with our analytical design of parameters so as to reduce or rather

control the congestion in the network. As we also described in section 1.1, the motivation

for this is two fold: firstly we want to reduce the bursts in the throughput introduced due to

packet correction in our AHEC scheme; and secondly, we want to provide fairness to other

protocols. To address the short comings of the current AHEC scheme and to provide fairness

towards other streams, an adaptive bandwidth estimation is proposed to be included in the

analysis and the PRRT stack for the media transmission.

In the next section 4.1, we describe analytically how we make use of the bandwidth

estimation to control the congestion in the network, and its inclusion in our parameter

analysis. Following that, in section 4.2, we give the proposed architecture details of our

solution for the bandwidth estimation and its incorporation in our PRRT stack.

4.1 Analytical Solution for Optimizing under Limited Bandwidth

In section 2.2, we have presented a simple analysis for the optimal coding parameters.

The optimization target there was to guarantee a certain target packet loss rate (PLR)

requirement under a strict delay constraint, and to do so with minimum redundancy, RI.

Therefore if we look closely there is already an inherent bandwidth limitation integrated

into the AHEC parameter analysis in the form of the redundancy information that can be

added, and this redundancy is kept to a minimum under the other two constraints of target

delay and residual packet loss rate.

With the estimate of the bandwidth in the network, we can basically have two different

modes of operation. We could either transmit the media stream as it is and the bandwidth

estimation could just determine whether error correction is feasible or not, with the resid-

ual loss rate varying accordingly. Or otherwise, we could adapt the source rate to some

bandwidth constraint with enough headroom to allow the amount of redundancy required

to meet a reliability constraint under a fixed amount of delay.

In the rest of the section we discuss these two options and their implications. We discuss

their feasibility for our parameter analysis and thus justify our choice of the second option

as our chosen mode of operation.

37

4.1.1 Adjusting channel coding rate

We begin our discussion with the first option that we described above, that is the inclusion

of another constraint for the bandwidth in the AHEC scheme for parameter calculation

along with the target delay constraint, and having the residual loss varying accordingly.

This option thus includes adjusting the channel coding rate.

Figure 8: Residual loss as an objective function to be minimized under delay and bandwidthconstraints

There is already a bandwidth limit integrated into the AHEC parameter analysis in

the form of the redundancy information that can be added. But till now we optimize the

protocol parameters always in order to obtain the minimal redundancy information on the

network. The optimization target currently is to guarantee a certain PLR under a strict

delay constraint, with minimum redundancy information added. But now we want to modify

this such that Bandwidth and therefore redundancy information becomes a strict constraint

such that the AHEC mechanism operates under TFRC estimated bandwidth. The target

delay would remain a constraint as before. However the residual PLR would now become

our objective function. This means, now we want to achieve the minimal residual PLR

achievable by error coding under the available bandwidth and under the target delay of the

application. This would require a change in the search algorithm for the optimal AHEC

coding parameters.

Though on a closer analysis it turned out that there is only a very small range in which

error correction is feasible. As shown in the figure 9, the margin of extra bandwidth or

residual RI where the change in Target PLR makes a change in the residual RI is fairly

narrow, and therefore there is not much range to adjust the channel coding rate.

Let us take a more careful look at the graph to understand this better. The point

at which a simple ARQ scheme becomes feasible is the extra bandwidth predicted by the

optimal amount of redundancy, which is given by,

RI =PLR

1− PLR(32)

This is the redundancy required for only the correction of packet losses over erasure

channels, and it gives the amount of extra bandwidth required to make error correction

38

Table 2: Optimum Parameter Sets for different values of Target Packet Loss Rate

PTarget RIRes Kopt Npopt1.0e-1 0.00523008003017575 148 0,11.0e-2 0.00523008003017575 148 0,11.0e-3 0.00995942137082703 79 0,1,1,11.0e-4 0.0100000000000000 1 0,11.0e-5 0.0101000000000000 1 0,1,11.0e-6 0.0101010000000000 1 0,1,1,11.0e-7 0.0101010000000000 1 0,1,1,11.0e-8 0.0101010000000000 1 0,1,1,11.0e-9 0.0101010100000001 1 0,1,1,1,11.0e-10 0.0101010101000001 1 0,1,1,1,1,11.0e-15 0.0101010103000001 1 0,1,1,1,1,31.0e-20 0.0101010106000001 1 0,1,1,1,1,61.0e-25 0.0101010108000001 1 0,1,1,1,1,81.0e-30 0.0101010111000002 1 0,1,1,1,1,111.0e-35 0.0101010113000002 1 0,1,1,1,1,131.0e-40 0.0101010116000002 1 0,1,1,1,1,16

Figure 9: Bandwidth (Residual RI) vs Reliability (Target PLR)

feasible. Before this, when the bandwidth or residual RI is fairly low, it may be a scenario

such that we can only have a few parity packets with very long blocks of data providing

39

very low error correction capabilities and in such cases FEC may not even be feasible. This

phenomenon can be clearly seen in table 3.

After this point, the residual RI becomes almost constant such that even when you drop

the target PLR from 10−5 to 10−40t there is not much change in the residual RI or the

extra bandwidth requirement.

Therefore when we make the residual PLR our objective function that we want to mini-

mize under a certain bandwidth constraint, we see that just changing the bottleneck band-

width in an extremely narrow range already drastically drops the residual PLR, rendering

this option useless for our purpose.

4.1.2 Adjusting source coding rate

We now take a deeper look at the second and our chosen option. Here we adjust the source

coding rate according to the bandwidth estimate in order to avoid congestion while still

providing optimum error correction capabilities.

In our current analytical design of the coding parameters, our objective function is to

minimize the coding overhead, or the amount of redundancy. This redundancy is the extra

bandwidth being utilized on top of the bandwidth occupied by the data packets being sent

at the source coding rate.

To be media friendly, our scheme has to ensure that the media stream is not stalled at

any time. We adapt the source coding rate such that we leave enough head room for the

coding overhead.

Therefore we vary the source coding rate as,

SR ≤ BWest

(1 +RI)(33)

where, SR is the modulated source coding rate, BWest is the estimated bandwidth, and

RI is the coding overhead or the redundancy added. Therefore our bandwidth estimate

becomes one of the indirect parameters in our analytical error correction parameter calcu-

lation. Here RI is determined analytically by adjusting the channel coding rate, as shown

in section 2.2. And we adapt our source coding rate according to our bandwidth estimate.

This gives the tradeoff introduced between the source coding rate and the channel coding

rate. And hence in this combined source and channel coding scheme, the estimated band-

width determines the maximum source coding rate under a certain reliability and delay

constraints.

Therefore as described, we can really analytically determine the source coding rate. This

adaptation of the source coding rate according to the bandwidth estimate is quite different

from the other available protocols.

We can explicitly provide this source coding rate adaptation for media transmission

according to our bandwidth estimate and according to our analytical model for reliability,

40

to achieve a certain residual loss rate (which means, with predictable reliability). This

tradeoff introduced between the source coding rate and the channel coding, in order to

achieve a certain reliability is not provided by the other available schemes. We either have

fixed or full reliability as in the case of TCP, or non-deterministic amount of reliability as

in the case of DCCP - PR, with a certain source coding rate. But this kind of analytical

adjustment between the two of them is not available there.

To put it differently, in our scheme we would be able to increase the source coding rate

or the perceptual quality of the video, at the expense of more artifacts in a certain amount

of time, or increase the reliability at the cost of more source coding artifacts in the form of

lower quality of coded images. Thus there is an adjustment between the losses, resolution

and hence the quality of experience.

4.2 Proposed Architecture for Bandwidth Estimation using TFRC

After describing our proposed solution analytically in the previous section, and showing how

it fits with our analytical design of the coding parameters, we now proceed to describing

our proposed architecture of the congestion control solution using bandwidth estimation.

As mentioned in the previous section, this basic idea of bandwidth adaptation method by

adjusting the source rate at the PRRT sender in our transport paradigm is quite a new one.

To begin with, we consider the scenario where we have one sender and one receiver with

a bottleneck router in between them. Both the sender and the receiver are equipped with

the PRRT stack which has been enhanced with our bandwidth estimation using TFRC to

provide a congestion control scheme in a TCP friendly manner.

Currently our solution is limited to offer bandwidth estimation for unicast scenario with

one sender and one receiver. Even though the extension to multicast scenario is left for

the future, we give an intuition and possible solution for our algorithm in the multicast

scenarios at every step.

Before going into the depth of the functionalities of the sender and the receivers for the

purpose of our bandwidth estimation using TFRC, lets us first enumerate the parameters

we require for it:

• Round Trip Time : In case of a multicast scenario, we need to have an estimate

of the group round trip time, GRTT. And we need to ensure that this estimate of

the GRTT leads to an underestimation of the bandwidth as compared to the actual

situation at each of the single receivers. This is ensured because we account for

the worst possible receiver in the receiver group and therefore the GRTT basically

represents the worst case RTT. But in the current case we consider a single receiver,

and the extension to multiple receivers is left to future work.

• Retransmit Time-out Interval : This is an input to the TCP throughput equation

41

(22). As mentioned in section 3.4.3, it is estimated as 4 times the RTT value.

• Minimum Packet Interval : This is the minimum packet interval observed at the

receiver, and is used to estimate the bandwidth in the initialization slow start phase

of our algorithm, as explained later in this section.

• Loss Map : The receiver also generates a loss map, which is basically the loss pattern

observed at the receiver representing which packets were received and which ones were

lost. The details of its generation are also given later in this section.

• Average Loss Interval : The average loss interval is required to estimate the average

loss event rate, which is given as the reciprocal of the average loss interval as shown

by the authors in [7]. The loss interval, as mentioned earlier also, is the number of

packets in between two loss events.

Figure 10: Functionalities of the sender and receiver in bandwidth estimation

As shown in figure 10, the sender estimates the group round trip time, and sends it

to the receiver. The receiver does an exponentially weighted moving average of the RTT

samples received to feed into the TCP throughput equation, given by equation 22 for the

purpose of bandwidth estimation. At the receiver, the loss map is also generated which

facilitates the computation of loss event rate. The minimum packet interval observed at the

receiver is made use of for the initialization of the bandwidth estimation. Making use of

all these parameters, the receiver estimates the bandwidth and this estimated bandwidth

is sent to the sender. The sender takes the estimated bandwidth reported back by the

42

receiver, and uses it to modulate the sending rate of the sender in such a manner, so as to

control the congestion in the underlying network. All these boxes shown in the figure are

the functionalities added to the PRRT protocol stack to function under limited bandwidth

while controlling the congestion in the network.

We will now elaborate on these functionalities of the sender and the receiver in the next

sections.

4.2.1 Sender Functionalities

As we can see from the figure 10, two main functions are performed at the sender side: the

RTT estimation and the modulation of sending rate. This in turn may include rate limiting

by traffic shaping at the sender. We will now delve into both of these in more detail.

4.2.1.1 RTT Measurement

Let us first see how RTT is measured in PRRT in the general case. In each packet the

sender sends, it also includes a time-stamp TSsent which denotes when the packet was sent.

At the receiver’s side, before it sends a feedback it selects the sender’s time-stamp Tsent

from the most recently received packet from the sender. It then adds to it the time elapsed

between receiving this packet and sending the feedback, Telapsed, and sends it back to the

sender. The sender receives this feedback at time Treceived.

Figure 11: Measurement of Round Trip Time

43

As evident from the figure 11, the RTT can be determined as

RTT = Treceived − (Tsent + Telapsed) (34)

The advantage of this method for determining the RTT is that it requires no synchro-

nization between the sender and the receiver clocks.

To work in a multicast scenario, the group RTT is measured at the sender, and then

broadcasted to all the receivers in each packet. In our current implementation of the protocol

RTT is computed at the sender and fed to the receivers in each data packet. This is essential

for the proper functioning of PRRT because the protocol decisions like the timeouts for the

different retransmission rounds and synchronization is dependent on this measure of the

group RTT. In the conservative approach to adapt to the worst receiver in the multicast

group, the RTT is determined for this worst receiver and used as the group RTT. Though

currently, we are using just a moving average of all the received RTT samples at the sender.

4.2.1.2 Modulating the Sending Rate

The estimated bandwidth sent in the feed back by the receiver to the sender, is used to

modulate the sending rate of the sender. Maintaining the sending rate at the right level is

essential so as to not lead to a congested state of the network.

The closed loop feedback inherent in this sender-receiver scheme leads to fluctuations

in the estimated bandwidth at the receiver. When the sending rate is much lower than the

bottleneck bandwidth and there are no losses, then the receiver sends a higher estimate.

When the sending rate is naively increased to this estimate, this may lead to more and

more traffic in the network, finally leading to a congested state, where the queues at the

bottleneck router are full. In this case RTT increases, and since packets may be dropped,

therefore the loss event rate also increases. Consequently the TFRC estimates a lower

throughput using the TCP throughput equation. This lower estimate is then sent to the

sender and it tries to now reduce the sending rate. To avoid this closed loop behavior and

the oscillations, we must not naively increase the sending rate to the estimated bandwidth,

but we must adapt slowly to this estimate. Instead of increasing the sending rate slowly at

the sender, we slowly increase the bandwidth estimate at the receiver, therefore sending a

more gradually varying bandwidth estimate to the sender to counter this effect of the closed

loop behavior. This is explained in more detail when we discuss the receiver functionalities

in section 4.2.2.

Also since this sending rate is the data rate of the data packets being sent, therefore

we need to leave some head-room for the redundancy which is added on top of these data

packets, in the form of the parity or redundancy packets. Therefore we need to reduce the

sending rate by an equivalent amount to be able to accommodate all the redundancy also.

44

And to improve the bandwidth estimate we should include the loss of parity packets in the

loss map for the calculation of the loss event rate.

Another aspect that we need to deal with due to the added redundancy is the bursty

nature of these parity packets. The parity packets tend to be sent all at once in a short

burst. Due to these bandwidth peaks congestion may develop in the network. To avoid

this we need to smoothen out the packet sending rate in time, such that there are no such

bursts.

We tried to make use of a token bucket approach to rate limit the sender, and to

smoothen out the sending rate to avoid the bandwidth peaks in transmission as reported

during the evaluation of the AHEC scheme under limited bandwidth, in section 2.4. It is a

popular algorithm for traffic shaping or rate limiting, and works by controlling the amount

of data that is sent on the network channel, though it still allows for bursts of data to be

sent.

In a token bucket 1approach, the traffic can only be transmitted if there are enough

tokens in the bucket. The bucket of size b contains tokens of fixed size, and these are used

up for the ability to send corresponding amounts of data. If the token rate is r, then every

updation interval of s seconds, s × r tokens are added to the bucket. The bucket can at

maximum hold b tokens, and if a token arrives while the bucket is full then it is discarded.

Over a long period of time, the sending rate of the packets is limited by the token rate

r. The estimated available bandwidth gives the upper limit to the possible sending rate,

therefore it is used to limit the token filling rate.

If m is the maximum possible transmission rate, then the maximum burst size for which

the maximum possible rate m is fully utilized if given by,

Lmax =

b×m(m−r) , if r < m

∞, otherwise(35)

where, Lmax is the maximum burst size, b is the token bucket size, and r is the token

filling rate. Therefore if configured properly, a flow can transmit up to its peak burst rate,

if there are enough tokens in the bucket.

NETEM provides a token bucket filter(TBF) which can be used to smoothen out the

sending rate. It could be configured with a rate twice the bottleneck bandwidth of the

router, and a buffer size equivalent to that of the routers. The details of the NETEM and

the TBF it provides are given in the next chapter in section 5.1.

Though in our current implementation we do not make use of the token bucket filter as

it was observed that it is not able to sufficiently space out the parity packets temporally.

1http : //en.wikipedia.org/wiki/Token bucket

45

Figure 12: Token Bucket Filter2

This spacing out will have to be included into the AHEC protocol stack, and this is not as

yet implemented. We discuss this further in the results and observations section 5.2.

4.2.2 Receiver Functionalities

We now proceed on to discuss the functionalities of the receiver. As can be seen from figure

10, the receiver contains all the functionality for the estimation of the bandwidth with

just group RTT being reported by the sender. The functions that the receiver performs

can be broken into two main subtasks: loss event rate measurement and then bandwidth

estimation. In the following sections we describe how both of these subtasks are done at

the receiver.

4.2.2.1 Loss Event Rate Measurement

As mentioned in section 3.4, the loss event rate is the main loss indicator in the TFRC

protocol. Therefore a good estimation of the loss event rate is essential for the performance

of the protocol and for our bandwidth estimation. Therefore we make use of the average

loss interval estimation method with history discounting to make sure that the bandwidth

2http://tldp.org/HOWTO/Traffic-Control-HOWTO/classless-qdiscs.html

46

estimation does react to drastic changes in the network conditions, while still providing a

stable sending rate.

The loss event rate, to be fed into the TCP response equation (22) which gives the

upper bound on the steady state TCP throughput, is estimated at the receiver. This is

specially beneficial for the multicast scenario, where each receiver just uses the loss event

rate experienced locally to estimate the bandwidth and sends only the bandwidth estimate

to the sender. It is better than to have the sender maintain loss event information for each

receiver, as that would have been an added overhead for the sender.

To be able to calculate the loss event rate, the receiver needs the loss pattern which is

basically a map of what all packets were received and which ones were lost. At the receiver

the loss map is maintained with a pointer that keeps track of the last packet that arrived.

By looking at the sequence numbers of the arriving packets, gap detection or the detection

of intermediate missing packets is possible. As and when a packet arrives, the pointer is

advanced that many positions ahead according to it’s sequence number, while marking the

intermediate positions on the map corresponding to the lost packets as 1. For the packets

which are received the corresponding positions in the loss map are marked as 0.

Every round trip time, the receivers calculate the loss event rate based on the loss pattern

observed in the last round trip time period. The receiver uses this loss pattern to populate

the loss history for the weighted average loss interval method as described in section 3.4.4.1,

to determine the average loss interval. The loss interval history is maintained as a circular

buffer, with pointers for the oldest and the most recent intervals. The history discounting

is also implemented to ensure the correct functioning as described in the earlier chapter.

As described in the aforementioned section, the loss event rate is estimated as the inverse

of the average loss interval length.

4.2.2.2 Estimating the Bandwidth

With the loss event rate and the RTT estimates in place, we will now talk about the

estimation of the bandwidth at the receiver.

To begin with, initially in the cases where the packet loss rate is almost zero, or where

there are almost no losses, the TCP response equation used in TFRC estimates a very high

value for the throughput. To counteract this, we make use of the minimum packet interval

observed at the receiver. Using this minimum packet interval and the packet size, we can

estimate the bottleneck bandwidth,

Bottleneck Bandwidth =packet size

minimum packet interval(36)

47

Figure 13: Bottleneck Bandwidth Estimation

Therefore to initialize our bandwidth estimate for our protocol, we make use of this

estimate like in the slow start phase of the TCP congestion control, till we encounter the

first loss, when we shift to estimating the bandwidth using the TCP throughput equation.

One inherent problem of loss based congestion control approaches is that it uses packet

losses to limit the sending rate. Thus TFRC increases the rate till any packet losses happen,

and therefore in a situation where there are no other competing flows, it ends up filling up

the queue of the bottleneck router. Though of course the queues are being filled up in the

case of multiple competing streams too.

Figure 14: Transition from Slow Start to Normal Operation Phase

In the cases when there are losses we make use of the TCP throughput equation to

estimate the bandwidth. This control equation has to be fed with the loss event rate and

48

Figure 15: RTT averaging using EWMA factor of 0.1

the RTT. In the previous section we have explained how the loss event rate is estimated at

the receiver. The group RTT estimates are received from the sender in each packet. These

samples may have quite some variation. The TCP model uses a long term notion of the

RTT and an RTT that reacts to changes in the queue level does not comply with this model.

Therefore we use an EWMA filter to obtain a smooth and stable RTT estimate from the

RTT samples that we receive from the sender. Here, the smoothed out RTT is given by

RTTnew = β ×RTTsample + (1− β)×RTTold (37)

where RTTnew is the EWMA filtered value of the RTT, RTTsample is the most recent

RTT estimate received from the sender, and RTTold is the previous determined EWMA

filtered value of RTT. We have used a value of 0.05 for the β factor, such that very little

weight is given to the most recent RTT sample and the variations in the RTT are damped,

while still being reactive to congestion. This can be seen in the figures 15 - 17. For the

EWMA factor of 0.1, there are too many variations in the bandwidth estimate, due to the

varying RTT, but at 0.05 these variations are reduced, while it is still responsive to the

changes. If we take a smaller value like 0.01, we do not get much more reduction in the

oscillations in the sending rate, but it may make our implementation less responsive without

49



50

gaining anything in return.

The RTT is used to estimate the retransmission timeout value tRTO. The bandwidth

estimation is closely related to the packet size used. To be able to compare to TCP, we

ensure that the packet size used in the equation is comparable to the TCP packet size.

We use a packet size of 1356 bytes. The RTT and the loss event rate have already been

determined. All of these values are fed to the TCP throughput equation and the bandwidth

is estimated, as shown in figure 18.

Figure 18: Bandwidth Estimation using TCP Response Equation

In order to not increase the bandwidth estimate too fast, we restrict the amount of

increase per RTT to 1 packet, in accordance to TCP behavior in the congestion avoidance

phase.

We keep track of the last sent estimate of the bandwidth, and then take the minimum

of either the previous estimate plus the 1 packet per RTT increase, or the most recently

determined estimate of the bandwidth. Therefore the bandwidth estimate sent back to the

sender is given by,

BWFinalest = min(BWOld

est + δ,BWCurrentest ) (38)

where δ is equivalent to an increase of one packet per round trip time, given by,

δ =PacketSize

RTT(39)

51

This final estimated bandwidth BWFinalest is then sent back to the sender in the feedback

from the receiver.

4.3 Implementation Details

Figure 19: Sender Functionality

In this section we give some of the implementation details of our solution extending

TFRC for bandwidth estimation for the purpose of congestion control. The functionalities

of the the sender and the receiver have been elaborated in the previous section. We begin

by presenting a flowchart diagram for both the sender and the receiver, which portrays their

detailed functioning and we then go on to give more implementation specific details for each

of them.

4.3.1 Sender Implementation

The sender listens for feedback from the receiver. On getting the feedback from the receiver,

the sender estimates the RTT as explained in section 4.2.1.1. The Sender then inserts the

RTT estimate in each of the packets and sets it’s data rate to the bandwidth estimate

sent by the receiver. It then continues to send the data packets at the rate specified by

52

the receiver, interspersed with bursts of parity packets, till a new bandwidth estimate is

received from the receiver, as shown in figure 19.

4.3.2 Receiver Implementation

The receiver, in our implementation, does most of the work for bandwidth estimation. The

majority of the functionality is implemented at the receiver to keep the design scalable for

multicast.

The receiver has two phases of operation, the slow start phase and the normal operation

phase. Before any losses are encountered, and the loss interval history is initialized, the

receiver is in the slow start phase, and thereafter shifts to the normal operation phase.

In the slow start phase the receiver makes use of the minimum packet interval observed

to estimate the bandwidth and in the normal operation phase it makes use of the TFRC

mechanism and its control equation giving the steady state TCP throughput.

The receiver implementation has two main functions, one for calculating the bandwidth

estimate, calc T(), and the another one to calculate the average loss interval, calc avg loss interval().

Next we briefly describe the functioning of both of these functions.

calc T

Initialization : Phase = SlowStart

1. Obtain EWMA filtered value of RTT,

RTT = 0.05 ∗RTT + 0.95 ∗RTTPrev

RTTPrev = RTT

2. Calculate Bottleneck BW

bnBW = PktSize ∗ 8/minPktInterval

3. Check if there are no losses in the loss map generated and current phase is Slow Start

Phase

if yes

then Slow Start Phase, go to 4

else

Normal Operation Phase, go to 5

4. Slow Start Phase

Multiply the bnBW by the slow start factor (currently set to 2 , same as TCP) and

return this to sender as bandwidth estimate.

Go back to 1

53

5. Calculate retransmit timeout as

tRTO = 4 ∗RTT

6. Calculate Avg Loss Interval

7. Determine Loss event rate as the reciprocal of avg loss interval

8. Calculate the throughput, using TFRC’s control equation 22

Feed in the RTT, tRTO and loss event rate to get BW Est

9. Store the throughput value as BWprev

10. Calculate increase of 1 pkt per RTT

δ = PktSize ∗ 8/RTT

11. Determine receiver’s BW estimate as

min ( BW Est , BWprev + δ)

12. Send final BW Est to Sender

13. Wait for observation period of time, then go back to 1

Next we describe the function calc avg loss interval(), which makes use of two ring

buffers for loss interval history and the history discounting weights. Each of them has two

pointers, one pointing to the most recently added element and one for the oldest element

in the buffer. These two pointers are manipulated appropriately to keep account of the the

two histories as described in sections 3.4.4 and 4.2.2.1.

calc avg loss interval()

1. Iterate through the loss map and keep incrementing the current loss interval s0 in the

history till the first lost packet is encountered

2. This is a loss event and beginning of a new loss interval.

Shift the loss interval into the loss history to s1 and start counting for the most recent

loss interval s0, and make corresponding changes in the history discounting ring buffer.

3. If the current loss interval s0 is more than twice the previously estimated average loss

interval, then enable new history discounting weights for it

di = max(0.5,2savgso

), i > 0,

do = 1.

and

s′avg =

n−1∑i=0

diwi+1si

n∑i=1

di−1wi

54

4. Calculate the average s avg 1 using loss interval history and history discounting, with-

out including the current loss interval s0

savg =

n∑i=1

wisi

n∑i=1

wi

5. Calculate the average s avg 0 using loss interval history and history discounting, in-

cluding the current loss interval s0

s′avg =

n−1∑i=0

wi+1si

n∑i=1

wi

6. avg loss interval = max(s avg 0, s avg 1)

For more details, the reader is requested to take a look at the code listings.

55

Figure 20: Receiver Functionality

56

CHAPTER V

EVALUATION

5.1 Experimental Setup

Our experimental setup basically consists of a sender and a receiver connected via a router

as shown in figure 21. Both the sender and receiver are equipped with the PRRT stack

along with our solution for congestion control by estimating the bandwidth. We emulate

the network conditions using Netem.

Figure 21: Experimental Setup

We use static routes, and have implemented the router using Netem and a token bucket

filter. Netem is a module of Linux kernel that provides Network Emulation functionality for

testing protocols by emulating the properties of wide area networks. The current version of

Netem emulates variable delay, loss, duplication and re-ordering.

Now we present the step by step procedure to set up the router and have the sender

and receiver communicating via the router, for our experiments.

1. Firstly we configure the sender and receiver with static ip addresses by assigning their

ethernet interfaces an ip address from different subnets using ifconfig as shown below.

i f c o n f i g eth0 1 9 2 . 1 6 8 . 0 . 2

i f c o n f i g eth0 1 9 2 . 1 6 8 . 1 . 2

57

Here, for example, 192.168.0.2 is the ip address of the sender and 192.168.1.2 is the

ip address of the receiver.

2. Next we configure the router by assigning the gateway ip addresses to its ethernet

interfaces.

i f c o n f i g eth0 1 9 2 . 1 6 8 . 0 . 1

i f c o n f i g eth1 1 9 2 . 1 6 8 . 1 . 1

3. Then we enable static routing by assigning the static routes using the gateways, as

shown below.

echo 1 | sudo tee −a / proc / sys / net / ipv4 / ip fo rward

route add −net 1 9 2 . 1 6 8 . 0 . 0 gw 1 9 2 . 1 6 8 . 1 . 1 netmask 2 5 5 . 2 5 5 . 2 5 5 . 0 dev eth0

route add −net 1 9 2 . 1 6 8 . 1 . 0 gw 1 9 2 . 1 6 8 . 0 . 1 netmask 2 5 5 . 2 5 5 . 2 5 5 . 0 dev eth1

4. Finally we add the bottleneck at the router by doing rate limiting using token bucket

filter (TBF) to limit the output, as Netem has no built-in rate control.

tc qd i s c add dev eth1 parent 1 : 1 handle 10 : tb f r a t e 15000 kb i t b u f f e r

3000 l i m i t 6000

tc qd i s c add dev eth1 root handle 1 : 0 netem delay 0ms

In the above case, we use a bottleneck rate of 15000 kbits, with a buffer of 3000 bytes

and a limit of 6000 bytes and no added delay.

5. Finally, at the sender and receiver we add the one way delays using Netem such that

we have our desired round trip time.

tc qd i s c add dev eth0 root netem delay Xms

If we configure both the sender and the receiver with this delay of Xms, then the

round trip would be approximately 2Xms.

One thing to note here is that we have created the bottleneck link by using Netem’s

token bucket filter for rate limiting at the outgoing ethernet interface towards the receiver.

This bottleneck link is shown as the link highlighted in red in the figure. This bottle-

neck bandwidth would then be observed by the receiver, as shown in the figure below and

depending on it the receiver would estimate the bandwidth.

58

Figure 22: Experimental Setup with the bottleneck at the router

5.2 Results & Observations

Congestion in the Internet is not a new phenomenon. It has always been there, maybe

even more due to the aggressive file streaming applications in the past rather than the

current burst of the media streaming applications. But as pointed out earlier, real-time

media streaming applications allocate a certain average, though limited, bandwidth due to

their encoding rate. Thus they have certain minimum bandwidth requirements even though

they may not saturate the channel. The remaining challenge now is to make sure that such

real-time media transmission applications interact in ”friendly and fair” manner with the

available internet services.

In this section we present the results of our work. We also discuss the reasons behind

some of the anomalies present in the results, as well as the weaknesses of the current

implementation. The aim of our thesis is to include the bandwidth limit into our AHEC

architecture for error correction and to modify the PRRT protocol stack to include it while

maintaining friendliness towards other protocols. As explained in the previous chapters, we

have adapted TFRC for our purpose of real time media transmission and this is integrated

with our AHEC scheme for the purpose of congestion control using bandwidth estimation.

For all of our experiments described next, we set the bottleneck bandwidth at the router

as 15000Kbps, with a round trip time of 30ms between the sender and the receiver. No

additional packet loss rate is emulated. The sender is configured for error correction with

number of data packets per coding block, k=1, retransmission rounds given by vector Np

= {0,1,1,8}, and target delay, Dtarget = 200ms, unless specified otherwise.

The loss event rate is the primary indicator of congestion in the TFRC mechanism, and

consequently in ours too. The loss event rate is estimated as the inverse of average loss

interval, which is defined as the number of packets between loss events. Please recall that

59

a loss event is defined as the one or more packets lost within one round trip time interval.

This means all the losses after the first loss in the round trip time observation interval

are ignored. Thus if we increase this observation period to a multiple of round trip time

periods, then we would have a lower loss event rate which reacts more slowly to losses, and

thus leads to higher estimated bandwidth. Though this would of course adversely affect the

fairness towards other protocols, specially TCP.

To observe the effect of the length of this observation interval on the bandwidth estimate,

we first varied the observation period for clustering together the packet losses into the same

loss event, from one RTT as prescribed by the TCP model used for TFRC, to thrice the

value of RTT. The resulting plots of the bandwidth estimated by the receiver are shown

in the following figures 23 − 26. Here we can notice the impact of different observation

intervals for loss event rate computation on the sending rate. With a longer observation

interval, the sending rate is higher on an average and this is expected to lead to less fair

behavior towards other streams.

Figure 23: Observation Interval = 1 x RTT

As the observation period increases, the variation in the throughput decreases. But at

the same time, the observed residual losses also increased. We have chosen the observation

period of one RTT for the rest of our experiments in order to be comparable to TCP’s

behavior of changing its congestion window just once per RTT in an attempt to ensure

60

Figure 24: Observation Interval = 1.5 x RTT


61


TCP friendliness.

We can see in figure 23 that the throughput varies around the bottleneck bandwidth of

15000Kbps, even though there is an overestimation of the bandwidth at the receiver. The

reasons for this over estimation and the oscillations in the sending rate are two fold. Firstly,

in our loss map generation we do not as yet include the losses of the redundancy packets.

And secondly, the losses of the data and the redundancy packets are both overcome by

retransmissions in our AHEC scheme due to the ARQ mechanism kicking in. Therefore

at those instances the actual sending rate including the redundancy packets is in reality

a multiple of the bandwidth estimated by the receiver. And this, in fact, leads to more

congestion in the network and potentially to more congestion losses. To understand this

better, lets take a look at figure 27.

There is a slight overestimation of the bandwidth at the receiver due to the inaccurate

loss map lacking the loss information about redundancy packets. This results in an un-

derestimation of loss even rate, and thus the sending rate does not get reduced enough at

the right times. And on top of it the retransmissions lead to higher actual sending rate

as described above, and worsen the situation. This can be seen clearly in figure 27. The

oscillations in the sending rate have less amplitude in the case of error correction without

retransmissions. But in case of retransmissions for error correction, the drop in the sending

62

(a) With Retrnsmissions

(b) Without Retransmissions

Figure 27: Impact of retransmissions for error correction on sending rate

63

rate is more severe, potentially due to the bursty retransmissions of redundancy packets. In

this experiment we have used an error correction configuration with one data packet packet

per coding block with 11.8% redundancy information. Therefore the redundancy packets

not included in the bandwidth estimation computation can have a significant impact, as

also demonstrated in the figure.

At the instances when there are packet losses, the ARQ mechanism kicks in and there are

retransmissions as described earlier. This is an inherent short coming of the AHEC scheme

because as soon as we have these retransmissions the bandwidth increases significantly for

a short period of time, leading to congested network and potentially more losses. To avoid

this we need to temporally space out these redundancy packets, and this is not incorporated

in the AHEC scheme for media transmission as yet. This temporal spacing of redundancy

packets needs to be included into the analytical model itself to be able to get rid of these

bandwidth peaks and to ensure that the network does not get congested by modulating the

source coding rate according to the actual estimated bandwidth.

Finally we now take a look at the behavior of our bandwidth estimation solution for

congestion control in the presence of other competing traffic. TCP being the most prevalent

protocol on Internet, is specially of interest to us in order to show fairness towards the

protocols. In the following experiments we have generated TCP streams using iperf 1, and

transmitted them concurrently with our own stream of PRRT. The TCP streams are flowing

in the same direction as ours, i.e. from the sender to receiver across the bottleneck link as

shown in figure 28.

To observe the fairness of our protocol, lets take a look at the plots for the variation in

the sending rate in the presence of competing TCP streams. We can see that the average

sending rate in each case behaves quite fairly to the other streams, the sending rate being

approximately equal to the bottleneck bandwidth divided by the total number of streams

in the network. This is shown in the table 3 also, where the first column gives the number

of concurrent TCP streams flowing along with our PRRT stream. the second column gives

the bandwidth estimated by iperf for each TCP stream. The third column specifies the

average long term throughput of our PRRT stream, while the last column gives the fair

share of the bottleneck bandwidth according to the total number of streams sharing it.

A TCP friendly flow is defined as a flow whose sending rate is in the same order of

magnitude as the corresponding TCP throughput under the same network conditions as

described in section 3.4 . In table 3, we can see that the bandwidth estimated by iperf TCP

tests is of the same order of magnitude as our PRRT stream. There is an underestimation

of bandwidth by the iperf in case of very few TCP streams, as in that case the TCP streams

generated by it are not able to attain the bottleneck bandwidth due to the limited queue

size at our router implementation. Nevertheless, the bandwidth estimated by iperf’s TCP

1http://iperf.sourceforge.net/

64

Figure 28: Experimental Setup with concurrent TCP streams

Table 3: Estimated Bandwidth: Comparison of results

Num of TCPStreams

iperf estimated bandwidthper TCP stream (Kbps)

Avg throughputof PRRT Stream (Kbps)

Bottleneck Bandwidth/num of streams (Kbps)

1 2784 7733.06 75002 2719 5465.80 50005 2083 3453.74 250010 1278 1635.36 1363.6315 931 854.00 937.5

streams is of the same order of magnitude as ours and we have a reasonably TCP friendly

solution.

Therefore we have shown in this section the behavior of our bandwidth estimation

solution for congestion control of real time media transmission and also we have discussed

some of the shortcomings of our current implementation and their effect on the results. In

section 7.2, we summarize the missing features of our current implementation and give hints

about how to overcome the current deficiencies.

65

Figure 29: Impact of 1 competing TCP stream on sending rate

Figure 30: Impact of 2 competing TCP streams on sending rate

66



67


68

CHAPTER VI

DIFFERENTIATING CONGESTION AND CORRUPTION LOSSES

6.1 Need for loss differentiation

With the advent of wireless heterogeneous networks, a number of weaknesses of the current

transport layer protocols, specifically standard TCP, have become evident. One of the

shortcomings of the current transport layer protocols including TCP is that their congestion

control mechanism interprets all the losses as congestion losses due to overflowing queues at

the routers in the congested network. This is true even for other transport layer protocols

besides TCP, like SCTP and TFRC, where the packet losses are used as an indicator of

congestion in the network. This assumption leads to suboptimal performance due to the

transport layer’s inability to derive the reason for the packet being dropped. This is even

more incorrect in situations where we have wireless links in the network path, where a non

negligible percentage of packets are corrupted due to wireless corruption losses, and are

eventually dropped to ensure reliability. Therefore the performance is hampered by the

needless reduction of the sending rate due to the non-existent but perceived congestion,

which is in reality just packets being dropped due to corruption.

Therefore if we can differentiate between losses due to congestion and corruption then

we can react accordingly in our congestion control protocol. For instance, when the losses

are truly due to congestion, we should reduce our sending rate to reduce the number of

packets in the network, such that the queues at the router can come out of the overflowing

state. But on the other hand, in case of purely corruption losses it does not make sense to

reduce the sending rate. We should, in fact, retransmit the lost data and maybe even apply

stronger error correction techniques for reliable transport.

Besides this advantage of avoiding unnecessary reduction of sending rate, the differen-

tiation of losses can also be used to give useful feedback to the video encoder. Therefore, if

the encoder knows that there are a lot of wireless losses, then it can better balance its bits

between the source coding which represent the video and the channel coding which protect

the source coded bits.

In the next section, we discuss briefly the different techniques for improving TCP be-

havior in wireless lossy environments, and in the final section, we give a hint about how

we can integrate this loss differentiation information with our congestion control mecha-

nism in our media transport protocol. The actual implementation and inclusion of the loss

differentiation into the PRRT stack is left as future work.

69

6.2 Available Loss Differentiation Techniques

There are a fairly large variety of loss differentiation algorithms and techniques for improving

TCP performance available today, specially with the advent of the wireless heterogeneous

networks. Preventing TCP from reacting to wireless losses as if they indicated congestion

is an active area of research. In this section we give just a very brief introduction to some

of the broad types.

To avoid the degradation of performance of TCP due to all losses being interpreted as

congestion losses, several schemes have been proposed to improve the TCP performance

in lossy wireless environments. The authors of [33] have classified them broadly into 3

categories. The first one is the end-to-end protocols, where loss recovery is performed by the

sender by the use of selective acknowledgements (SACK) such that the sender can recover

from multiple packet losses in a window without having to resort to timeouts. Additionally,

it enables the sender to differentiate between losses by explicit loss notification (ELN)

mechanism. The second category is split connection protocols that break the end-to end

connection into two parts at the base station. The performance can be improved by the

use of negative or selective acknowledgements on the wireless link between the base station

and the end host . And the last ones are the link-layer protocols based on a combination

of ARQ and FEC techniques such that the wireless losses are hidden from the sender via

retransmissions and forward error correction. [9] is an example of the last type.

There has also been work on evaluating and improving TFRC for wireless networks. In

[14], the authors have presented an enhanced TFRC (E-TFRC) which incorporates a two

phase loss differentiation algorithm (TP-LDA) to detect and identify the cause of packet loss

events. The ratio of congestion losses to link losses is estimated by a cross layer approach

and this ratio is used to modify the loss event rate.

One final technique that we mention here is [34], where the authors have combined

TFRC with FEC. They apply FEC dynamically in only those instances when they detect

potential periods of increased TCP-induced congestion, such that the overhead generated in

form of redundant parity packets in FEC is used judiciously and kept to a minimum. They

observe the delay samples (Round Trip Time and Forward Trip Time) and their derivatives

and based on the clustering of loss events over the {RTT, ˙RTT} or {FTT, ˙FTT}, they

propose a dynamic FEC whose code rate is computed on the fly based on the instantaneous

values of these delays and their derivatives.

6.3 Integration with our solution - A Hint

Thus for a more efficient congestion control mechanism in today’s heterogeneous networks,

we need to differentiate between congestion and corruption losses. It’s inclusion in our con-

gestion control mechanism as an input to the loss rate calculation can help us to determine

the true loss rate due to congestion in the network, and lead to better and more optimal

70

congestion control.

Figure 34: Inclusion of Loss Differentiation into our Bandwidth Estimation Solution

We can extend our TFRC implementation to use a loss differentiation algorithm when-

ever a wireless link exists in the network path. Whenever the TFRC receiver would detect

a packet loss, it would invoke the loss differentiation algorithm. If the algorithm classifies

the loss as a wireless corruption loss then the receiver would not include this loss in the loss

event rate calculation, otherwise it would.

This is just a hint about how we can integrate this loss differentiation information with

our congestion control mechanism in our media transport protocol. The actual implemen-

tation and inclusion of the loss differentiation into the PRRT stack is left as future work.

71

CHAPTER VII

CONCLUSION AND OUTLOOK

7.1 Summary

In this thesis we have used bandwidth estimation for the purpose of congestion control for

real-time media transmission. We have estimated the bandwidth using an adaptation of

the TFRC protocol.

We studied various methodologies for bandwidth estimation and congestion control and

found the equation based approach of TFRC to be favorable for inclusion into our AHEC

error correction scheme.

We considered two different scenarios for the inclusion of this bandwidth limit in our

AHEC scheme. The first option was to include bandwidth limit as a strict constraint in the

AHEC parameter analysis along with the target delay constraint and to treat the residual

packet loss rate as the objective function. But this approach of changing the channel

coding rate according to the bandwidth available in the network was later discarded as it

was discovered that the range in which the extra bandwidth for redundancy can be varied

is very narrow to be of much practical use. The second option was to change the source

coding rate according to the estimated bandwidth in the network. We chose this option of

changing the source coding rate according to the bandwidth estimated at the receiver. The

sender uses this estimated bandwidth to modulate its sending rate. The bandwidth limit is

inherently a part of the AHEC parameter analysis by the virtue of redundancy information

which is minimized under the target delay and packet loss rate constraints. The redundancy

information represents the extra bandwidth on top of the source data rate which is utilized.

We have implemented TFRC to estimate the bandwidth and integrated it with the

PRRT protocol stack’s implementation to provide real time media transmission in a con-

gestion controlled manner, along with error correction capabilities. Our protocol is fair

towards other streams and behaves in a TCP friendly way.

7.2 Future Work

In our current implementation, we have considered a unicast scenario, though our approach

can be extended to the multicast case. The basic difference would come in the RTT mea-

surement and feedback suppression. We can use the longest RTT as the limiting case. Or

the RTT estimation at the sender can be done by using a multicast tree approach such that

all the parent nodes know the RTT to their child nodes, and the total RTT along a path can

be the sum of the RTTs along the path. Also instead of sending a feedback immediately we

73

can have the receiver back off by sometime, and send the feedback only if no other receiver

has already sent back a lower estimated bandwidth. This would be a conservative approach

where we adapt to the worst conditions. In such a case we can have some entry check where

only those receivers are allowed to join the multicast groups which satisfy certain minimum

requirements.

For wireless scenarios, if a loss differentiation algorithm is used to differentiate between

the congestion and wireless corruption losses, then this information can be fed into our

solution to account for this distinction, such that the sending rate is reduced only in the

case of congestion losses and not corruption losses.

And finally, we need to take into account the losses of redundancy packets, which is

missing right now in our loss maps. We should include their loss information in the loss

map. Also we need to modify the current analysis in such a manner so as to temporally

space out the retransmissions and not send them in a bursty way. This is as yet lacking in

the AHEC parameter analysis.

74

REFERENCES

[1] M. Gorius, J. Miroll, M. Karl, T. Herfet, “Predictable Reliability and Packet Loss

Domain Separation for IP Media Delivery”, IEEE International Conference on Com-

munications (ICC), June 2011.

[2] S. Floyd, M. Handley, J. Padhye, J. Widmer, ”Equation-Based Congestion Control for

Unicast Applications: the Extended Version”, TR-00-003, March 2000.

[3] M. Luby, V. K. Goyal, S. Skaria, G. B. Horn,“Wave and equation based rate control

using multicast round trip time”, ACM SIGCOMM , 2002.

[4] J. Widmer, M. Handley , “TCP-friendly multicast congestion control (TFMCC): Pro-

tocol specification”, RFC 4654, August 2006.

[5] I. Rhee, V. Ozdemir, Y. Yi,“TEAR: TCP emulation at receivers - flow control for

multimedia streaming”, Technical Report, 2000.

[6] B. Chang, S. Lin, J. Jin, ”LIAD: Adaptive bandwidth prediction based Logarithmic

Increase Adaptive Decrease for TCP congestion control in heterogeneous wireless net-

works ”, May 2009.

[7] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, ”Modeling TCP Throughput: A Simple

Model and its Empirical Validation”, May 1998

[8] D. Sisalem, H. Schulzrinne, ”The Loss-Delay Based Adjustment Algorithm: A TCP-

Friendly Adaptation Scheme”, Sisalem, 1998.

[9] F. Sun, V. O. K. Li, S. C. Liew, “Clustered-loss Retransmission Protocol over Wireless

TCP”, IEEE PIMRC, 2005.

[10] M. Gorius, M. Karl, T. Herfet, ”Optimized Link-level Error Correction for Internet

Media Transmission”, NEM Summit, 2009

[11] R. Gogolok, ”Optimization of an Application Layer Hybrid Error Correction Scheme

under Strict Delay Constraint”, Master Thesis, 2008

[12] J. Gruen, ”Design and Implementation of a Media oriented Network Protocol Stack”,

Diploma Thesis, 2009

[13] Future Media Internet : Video & Audio Transport - A New Paradigm, Manuscript,

Telecommunications Lab, University of Saarland, 2010.

75

[14] S. Pack, X. Shen, J. W. Mark, L. Cai,“A Two-Phase Loss Differentiation Algorithm

for Improving TFRC Performance in IEEE 802.11 WLANs”, IEEE Transactions on

Wireless Communications, 2007.

[15] Cisco and/or its affiliates, “Cisco visual networking index: Forecast and methodology,

2009-2014”, 2010.

[16] European Commission: Future Media Internet,

ftp://ftp.cordis.europa.eu/pub/fp7/ict/docs/netmedia/20080101-fimen.pdf.

[17] International Telecommunications Union: ITU-T Recommendation Y.1541, “Network

Performance Objecties for IP-based Services”, 2006.

[18] G. Tan, “Optimum Hybrid Error Correction Scheme under Strict Delay Constraints”,

Dissertation, 2008.

[19] J. C. Hoe, “Improving the Start-up Behavior of a Congestion Control Scheme for TCP”

, SIGCOMM, 1996.

[20] P. Ramanathan, C. Dovrolis, D. Moore, “What do Packet Dispersion Techniques Mea-

sure?”, INFOCOM, January 2001.

[21] R. L. Carter, M. E. Crovella, “Measuring Bottleneck Link Speed in Packet-Switched

Networks”, Perform. Eval.,1996.

[22] V. Jacobson, “Pathchar: A tool to Infer Characteristics of Internet Paths.”,

ftp://ftp.ee.lbl.gov/pathchar/, April 1997.

[23] S. Bellovin,“A Best-Case Network Performance Model.”, Technical Report, ATT Re-

search, Feb. 1992.

[24] M. Jain, C. Dovrolis, “End-to-End Available Bandwidth: Measurement Methodology,

Dynamics, and Relation with TCP Throughput.”, IEEE ACM Trans. Netw., 2003.

[25] B. Melander, M. Bjorkman, P. Gunningberg, “A New End-to-End Probing and Anal-

ysis Method for Estimating Bandwidth Bottlenecks.”, GLOBECOM O00. IEEE, 2000.

[26] G. Tan, T. Herfet, “Evaluation of the Performance of a Hybrid Error Correction Scheme

for DVB Services over IEEE 802.11a”, IEEE International Symposium on Broadband

Multimedia Systems and Broadcasting (ISBMSB),March 2007.

[27] M. Jain, C. Dovrolis, “Pathload: A Measurement Tool for End-to-End Available Band-

width”, International Symposium on Computer and Information Sciences, 2002.

[28] A. Downey, “Clink: a Tool for Estimating Internet Link Characteristics”, 1999.

76

[29] B. A. Mah, “Pchar: A tool for measuring internet path characteristics”, 2000.

[30] R. S. Prasad, M. Murray, C. Dovrolis, K. Claffy, “Bandwidth Estimation: Metrics,

Measurement Techniques, and Tools”, IEEE Network, November 2003.

[31] E. Kohler, M. Handley, S. Floyd, “Datagram Congestion Control Protocol”, 2006.

[32] Y. C. Lai, C. N. Lai, “DCCP partial reliability extension with sequence number com-

pensation”, Computer Networks, Volume 52, Issue 16, Pages 3085-3100, ISSN 1389-

1286, 13 November 2008.

[33] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, R. H. Katz,“A comparison of mech-

anisms for improving TCP performance over wireless links”, ACM SIGCOMM Con-

ference, August 1996.

[34] H. Seferoglu, U. C. Kozat, M. R. Civanlar, J. Kempf, “Congestion state-based dynamic

FEC algorithm for media friendly transport layer”, Packet Video Workshop, 2009.

77

congestion control and fairness for real-time media ... · congestion control and fairness for ......

Documents