Computer Networks

Performance and Quality of Service

Ivan Marsic
Department of Electrical and Computer Engineering and the CAIP Center

Rutgers University
 Contents

i
 Chapter 1
Introduction to Computer Networks

Contents
1.1 Introduction
1.1.1 x
1.1.2 x

1.1 Introduction 1.1.3 x

1.2 Reliable Transmission via Redundancy

1.2.1 x
1.2.2 x
1.2.3
Networking is about transmitting messages from senders to
receivers (over a “channel”). Key issues we encounter include: 1.3 Reliable Transmission by Retransmission
1.3.1 Stop-and-Wait
• “Noise” damages (corrupts) the messages; we would like 1.3.2 Sliding-Window Protocols
1.3.3 x
to be able to communicate reliably in the presence of 1.3.4 x
noise 1.4 Routing and Forwarding
• Establishing and maintaining physical communication 1.4.1
1.4.2 Internet Protocol: Naming and Addressing
lines is costly; we would like to be able to connect 1.4.3
arbitrary senders and receivers while keeping the 1.5 x
economic cost of network resources are a minimum 1.5.1
1.5.2
• Time is always an issue in information systems as is 1.5.3
generally in life; we would like to be able to provide 1.6 Quality of Service Overview
expedited delivery particularly for messages that have 1.5.1 x
1.5.2 x
short deadlines 1.5.3 x
Figure 1-1 illustrates what the customer usually cares about and 1.7 Summary and Bibliographical Notes
what the network engineer can do about it. The visible network Problems
variables (“symptoms”), easily understood by a non-technical
person include: fault tolerance, (cost) effectiveness, and quality of service (psychological
determinants).
Limited resources can become overbooked, resulting in message loss. Network should be able to
deliver messages even if some links experience outages.
The tunable parameters (or “knobs”) for a network include: network topology, communication
protocols, architecture, components, and the physical medium (connection lines) over which the
signal is transmitted.
- Connection topology: completely connected graph vs. mux/demux which switches packets

1
Ivan Marsic • Rutgers University 2

Visible network properties:

QoS Cost
Correct delivery Fault tolerance
(speed, loss) effectiveness

Customer

Tunable network parameters:

Network Communication Network Physical

Components
topology protocols architecture medium

Network
Engineer

Figure 1-1: The customer cares about the visible network properties that can be controlled
by the adjusting the network parameters.

- Network architecture: how much of the network is a fixed infrastructure vs. ad hoc based
- Component characteristics: reliability and performance of individual components (nodes and
links)
- when switch/router from faster to slower link ⇒ congestion + waiting queue. In practice all
queues have limited capacity, so loss is possible
- performance metric: success rate of transmitted packets + average delay + delay variability
(jitter)
- different applications (data/voice/multimedia) have different requirements: sensitive to loss vs.
sensitive to delay/jitter

Presentation: to “dress” the messages in a “standard” manner

Session: to maintain a “docket number” across multiple exchanges between two hosts

Example exchanges (“protocol”), task-related:

1. → Request catalog of products
2. ← Respond catalog
3. → Make selections
4. ← Deliver selections
5. → Confirm delivery
6. ← Issue bill
7. → Make payment
8. ← Issue confirmation
Chapter 1 • Introduction to Computer Networks 3

Voltage at transmitting end

Idealized voltage at receiving end

Line noise

Voltage at receiving end

Figure 1-2: Digital signal distortion in transmission due to noise and time constants
associated with physical lines.

1.2 Reliable Transmission via Redundancy

There are many phenomena that affect the transmitted signal, some of which are illustrated in
Figure 1-2. Although the effects of time constants and noise are exaggerated, they illustrate an
important point. The input pulses must be well separated since too short pulses will be “smeared”
together. This can be observed for the short-duration pulses at the right-hand side of the pulse
train. Obviously, the receiver of the signal that is shown in the bottom row will have great
difficulty figuring out whether or not there were pulses in the transmitted signal. You can also see
that longer pulses are better separated and easier to recognize in the distorted signal. The
minimum tolerable separation depends on the physical characteristics of a transmission line. If
each pulse corresponds to a single bit of information, then the minimum tolerable separation of
pulses determines the maximum number of bits that can be transmitted over a particular
transmission line.
Although information bits are not necessarily transmitted as rectangular pulses of voltage, all
transmission line are conceptually equivalent, as represented in Figure 1-3, since the transmission
capacity for every line is expressed in bits/sec or bps. In this text we will always visualize

1 0 1 1 0 0 1
Line 1:
1 Mbps

1 0 1 1 0 01
Time
Line 2:
10 Mbps

Figure 1-3: Transmission line capacity determines the speed at which the line can transmit
data. In this example, Line 2 can transmit ten times more data than Line 1 in the same
period.
Ivan Marsic • Rutgers University 4

transmitted data as a train of digital pulses. The reader interested in physical methods of signal
transmission should consult a communications engineering textbook, such as [Haykin, 2006].
A common characterization of noise on transmission lines is bit error rate (BER): the fraction of
bits received in error relative to the total number of bits received in transmission. Given a packet
n bits long and assuming that bit errors occur independently of each other, a simple
approximation for the packet error rate is
PER = 1 − (1−BER)n (1.1)
To counter the line noise, a common technique is to add redundancy or context to the message.
For example, assume that the transmitted word is “information” and the received word is
“inrtormation.” A human receiver would quickly figure out that the original message is
“information,” since this is the closest meaningful word to the one which is received. Similarly,
assume you are tossing a coin and want to transmit the sequence of outcomes (head/tail) to your
friend. Instead of transmitting H or T, for every H you can transmit HHH and for every T you can
transmit TTT. The advantage of sending two redundant letters is that if one of the original letters
flip, say TTT is sent and TTH is received, the receiver can easily determine that the original
message is TTT, which corresponds to “tail.” Of course, if two letters become flipped,
catastrophically, so TTT turns to THH, then the receiver would erroneously infer that the original
is “head.” We can make messages more robust to noise by adding greater redundancy. So, instead
of two redundant letters, we can have ten: for every H you can transmit HHHHHHHHHH and for
every T you can transmit TTTTTTTTTT. The probability that the message will be corrupted by
noise catastrophically becomes progressively lower with more redundancy. However, there is an
associated penalty: the economic cost of transmitting the longer message grows higher since the
line can transmit only a limited number of bits per unit of time. Finding the right tradeoff between
robustness and cost requires the knowledge of the physical characteristics of the transmission line
as well as the knowledge about the importance of the message to the receiver (and the sender).
Example of adding redundancy to make messages more robust will be seen in Internet telephony
(VoIP), where forward error correction (FEC) is used to counter the noise effects.
If damage/loss can be detected, then an option is to request retransmission but, request +
retransmission takes time ⇒ large response latency. FEC is better but incurs overhead.

1.2.1 Error Coding

To bring the message home, here is a very simplified example for the above discussion. Notice
that this oversimplifies many aspects of error coding to get down to the essence. Assume that you
need to transmit 5 different messages, each message containing a single integer number between
1 – 5. You are allowed to “encode” the messages by mapping each message to a number between
1 – 100. The noise amplitude is distributed according to the normal distribution, as shown in
Figure X. What are the best choices for the codebook?
Note: this really represents a continuous case, not digital, because numbers are not binary and
errors are not binary. But just for the sake of simplicity.
Chapter 1 • Introduction to Computer Networks 5

1.3 Reliable Transmission by

Retransmission
We introduced channel encoding as a method for dealing with errors. But, encoding provides only
probabilistic guarantees about the error rates—it can reduce the number errors to an arbitrarily
small amount, but it cannot eliminate them. When error is detected it is remedied by repeated
transmission. This is the task for Automatic Repeat Request (ARQ) protocols.
Failed transmissions manifest in two ways:
• Packet error: Receiver receives the packet and discovers error via error control
• Packet loss: Receiver never receives the packet
If the former, the receiver can request retransmission. If the latter, the sender must detect the loss
by the lack of response from the receiver within a given amount of time.
Common requirements for a reliable protocol are that: (1) it delivers at most one copy of a given
packet to the receiver; and, (2) all packets are delivered in the same order they are presented to
the sender. “Good” protocol:
- Delivers a single copy of every packet to the receiver application
- Delivers the packets in the order they were presented to the sender
A lost or damaged packet should be retransmitted and, to make this possible, a copy is kept in the
transmitter buffer (temporary local storage) until it is successfully received by the receiver and
the sender received the acknowledgement. Buffering generally uses the fastest and, therefore, the
most expensive memory; thus, the buffering space is scarce. Disk storage is cheap but not
practical for buffering since it is relatively slow.
In network, different packets can take different routes to the destination, and thus arrive in a
different order than sent. The receiver may keep buffered the out-of-order packets until the
missing packets arrive. Different ARQ protocols are designed by making different choices for the
following issues:
• Where to buffer: at sender only, or both sender and receiver?
• What is the maximum allowed number of outstanding packets, waiting to be
acknowledged?
• How is a packet loss detected: a timer expires, or the receiver explicitly sends a “negative
acknowledgement” (NAK)? (Assuming that the receiver is able to detect a damaged
packet.)
The throughput of an ARQ connection is defined to be the fraction of time that the sender is busy
sending data.
The goodput of an ARQ connection is defined to be the rate at which data are sent once, i.e., this
rate does not include data that are retransmitted. In other words, the goodput is the fraction of
time that the receiver is receiving data that it has not received before.
Ivan Marsic • Rutgers University 6

Sender Receiver

Time
transmission Data
delay propagation
delay

ACK

Data

Figure 1-4: Packet transmission from sender to receiver.

The transmissions of packets between a sender and a receiver are usually illustrated on a timeline
as in Figure 1-4. There are several important concepts associated with packet transmissions. The
first is the transmission delay, which is the time that takes the received to place the data bits in
the packets onto the transmission medium. This delay depends on the transmission rate R offered
by the medium (in bits per second or bps), which determines how many bits (or pulses) can be
generated per unit of time at the transmitter. It also depends on the length L of the packet (in bits).
Hence, the transmission delay is:
L (bits)
tx = (1.2)
R (bits per second)
Propagation delay is defined as the time elapsed between when a bit is sent at the sender and
when it is received at the receiver. This delay depends on the distance d between the sender and
the receiver and the velocity v of electromagnetic waves in the transmission medium, which is
proportional to the speed of light in vacuum (c ≈ 3×108 m/s), v = c/n, where n is the index of
refraction of the medium. Both in copper wire and glass fiber or optical fiber n ≈ 3/2, so v ≈ 2 ×
108 m/s. The index of refraction for dry air is approximately equal to 1. The propagation delay is:
d ( m)
tp = (1.3)
v (m/s)
Another important parameter is the round-trip time (or RTT), which is the time a bit of
information takes from departing until arriving back at the sender if it is immediately bounced
back at the receiver. This time on a single transmission link equals RTT = 2 × tp. Determining the
RTT is much more complex if the sender and receiver are connected over a network where
multiple alternative paths exist, as will be seen in Section 2.1.1 below.
Next I describe several popular ARQ protocols.
Chapter 1 • Introduction to Computer Networks 7

1.3.1 Stop-and-Wait
The simplest retransmission strategy is stop-and-wait. This protocol buffers only a single packet
at the sender and does not deal with the next packet before ensuring that the current packet is
correctly received. A packet loss is detected by the expiration of a timer, which is set when the
packet is transmitted.
When the sender receives a corrupted ACK/NAK, it could send back to the receiver NAK
(negative acknowledgement). For pragmatic reasons, the sender just re-sends the data.
Given a probability of packet transmission error pe, which can be computed using Eq. (1.1)
above, we can determine how many times, on average, a packet will be (re-)transmitted until
successfully received and acknowledged. This is known as expected number of transmissions.
Our simplifying assumption is that error occurrences in successively transmitted packets are
independent events. A successful transmission in one round requires error-free transmission of
two packets: forward data and feedback acknowledgement. We can assume that these are
independent events, so the joint probability of success is
( )(
psucc = 1 − peDATA ⋅ 1 − peACK ) (1.5)

The probability of a failed transmission in one round is pfail = 1 − psucc. Then, we can consider k
transmission attempts as k independent Bernoulli trials. The probability that the first k attempts
will fail and the (k+1)st attempt will succeed equals:
⎛k ⎞
Q(1, k) = ⎜⎜ ⎟⎟ ⋅ (1 − psucc ) ⋅ psucc
1
= pfail ⋅ psucc
k k
(1.6)
1
⎝ ⎠
where k = 1, 2, 3, … . The round in which a packet is successfully transmitted is a random
variable N, with the probability distribution function given by (1.6). Its expected value is
∞ ∞
⎛ ∞ ∞
⎞
E{N } = ∑ (k + 1) ⋅ Q(1, k ) = ∑ (k + 1) ⋅ pfailk ⋅ psucc = psucc ⋅ ⎜⎜ ∑ pfailk + ∑ k ⋅ pfailk ⎟⎟
k =0 k =0 ⎝ k =0 k −0 ⎠
Recall that the well-known summation formula for the geometric series is
∞ ∞
1 x
∑ xk = 1− x
, ∑ k ⋅ x k = (1 − x )2
k =0 k =0

Therefore we obtain (recall that pfail = 1 − psucc):

⎛ 1 pfail ⎞⎟ 1
E{N } = psucc ⋅ ⎜⎜ + 2 ⎟
= (1.7)
⎝ 1 − pfail (1 − pfail ) ⎠ psucc
We can also determine the average delay per packet as follows. Successful transmission of one
packet takes a total of tsucc = tx + 2×tp, assuming that transmission time for acknowledgement
packets can be ignored. A failed packet transmission takes a total of tfail = tx + tout, where tout is the
retransmission timer’s countdown time. If a packet is successfully transmitted after k failed
attempts, then its total transmission time equals: Tktotal
+1 = k ⋅ t fail + tsucc , where k = 0, 1, 2, … (see

Figure 1-5). The total transmission time for a packet is a random variable Tktotal
+1 , with the
probability distribution function given by (1.6). Its expected value is
Ivan Marsic • Rutgers University 8

Sender Receiver

Time
transmission error

2nd attempt 1st attempt

time

timeout
time
error

error
k-th attempt
k+1st attempt

transmission
time
Received
error-free
RTT ACK

Figure 1-5: Stop-and-Wait with errors. The transmission succeeds after k failed attempts.

∞
⎛ ∞ ∞
⎞
E{Tktotal
+1 } = ∑ (k ⋅ tfail + tsucc ) ⋅ pfailk ⋅ psucc = psucc ⋅ ⎜⎜ tsucc ∑ pfailk + tfail ∑ k ⋅ pfailk ⎟⎟
k =0 ⎝ k =0 k =0 ⎠
Following a derivation similar as for (1.7) above, we obtain
⎛ tsucc p ⋅t ⎞ p
E{Tktotal ⎜
+1 } = psucc ⋅ ⎜ + fail fail2 ⎟⎟ = tsucc + fail ⋅ tfail (1.8)
⎝ 1 − pfail (1 − pfail ) ⎠ psucc

1.3.2 Sliding-Window Protocols

Stop-and-wait is very simple but also very inefficient, since the sender spends most of the time
waiting for the acknowledgement. We would like the sender to send as much as possible, short of
causing path congestion or running out of the memory space for buffering copies of the
outstanding packets.
The window size N is a measure of the maximum number of outstanding (i.e., unacknowledged)
packets in the network.
An ARQ protocol that has higher efficiency is Go-back-N, where the sender buffers N
outstanding packets, but the receiver buffers none, i.e., the receiver immediately discards the out-
of-order packets.
K&R, p.217
Chapter 1 • Introduction to Computer Networks 9

Go-back-N
The receiver could buffer the out-of-order packets, but because of the way the sender works, it
will send them anyway. (p.220)

Selective Repeat (SR)

In practice, a combination of selective-ACK and Go-back-N is used, as will be seen with TCP in
Chapter 2 below.

1.4 Routing and Forwarding

The main purpose of routing is to bring a packet to its destination. A good routing protocol will
also do it in an efficient way, meaning via the shortest path or the path that is in some sense
optimal. The capacity of the resulting end-to-end path directly depends on the efficiency of the
routing protocol employed.
Graph distance = shortest path
Shortest path can be determined in different ways:
• Knowing the graph topology, calculate the shortest path
• Send “boomerang” probes on round trips to the destination along the different outgoing
paths. Whichever returns back the first is the one that carries the information about the
shortest path

Path MTU is the smallest MTU of any link on the current path (route) between two hosts.

1.4.1 Networks and Internetworks

Network is a set of computers directly connected to each other, i.e., with no intermediaries. A
network of networks is called internetwork.

1.4.2 Internet Protocol: Naming and Addressing

Names and addresses play an important role in all computer systems as well as any other
symbolic systems. They are labels assigned to entities such as physical objects or abstract
concepts, so those entities can be referred to in a symbolic language. Since computation is
specified in and communication uses symbolic language, the importance of names should be
clear. It is important to emphasize the importance of naming the network nodes, since if a node is
not named, it does not exist! The main issues about naming include:
Ivan Marsic • Rutgers University 10

Figure 1-6. The map of the connections between the major Internet Service Providers
(ISPs). [From the Internet mapping project: http://www.cheswick.com/ ]

• Names must be unique so that different entities are not confused with each other
• Names must be resolved with the entities they refer to, to determine the object of
computation or communication
The difference between names and addresses, as commonly understood in computing and
communications, is as follows. Names are usually human-understandable, therefore variable
length (potentially rather long) and may not follow a strict format. Addresses, for efficiency
reasons, have fixed lengths and follow strict formatting rules. For example, you could name your
computers: “My office computer for development-related work” and “My office computer for
business correspondence.” The addresses of those computers could be: 128.6.236.10 and
128.6.237.188, respectively.
Separating names and addresses is useful for another reason: this separation allows keeping the
same name for a computer that needs to be labeled differently when it moves to a different
physical place. For example, a telephone may retain its name when moved to a region with a
different area code. Of course, the name/address separation implies that there should be a
mechanism for name-to-address translation, and vice versa.
Two most important address types in contemporary networking are:
Chapter 1 • Introduction to Computer Networks 11

• Link address of a device, also known as MAC address, which is a physical address for a
given network interface card (NIC), also known as network adaptor. These addresses are
standardized by the IEEE group in charge of a particular physical-layer communication
standard
• Network address of a device, also known as IP address, which is a logical address. These
addresses are standardized by the Internet Engineering Task Force (http://www.ietf.org/)
Notice that a quite independent addressing scheme is used for telephone networks and it is
governed by the International Telecommunications Union (http://www.itu.int/).

1.4.3 Packets and Statistical Multiplexing

The communication channel essentially provides an abstraction of a continuous stream of
symbols transmitted subject to a certain error probability. Although from the implementer’s
viewpoint these are discrete chunks of information, each chunk supplemented with redundancy
for error resilience, there was no obvious benefit or need for the user to know about slicing the
information stream. Unlike this, in a network discrete chunks of information are essential in
understanding the issues and devising solutions. Messages represented by long sequence of bits
are broken into shorter bit strings called packets. These packets are then transmitted
independently and reassembled into messages at the destination. This allows individual packets to
opportunistically take alternate routes to the destination and interleave the network usage by
multiple sources, thus avoiding inordinate waiting periods for some sources to transmit their
information.

1.4.4 Distance Vector Routing Algorithm

When determining the minimum cost path, it is important to keep in mind that it is not how
people would solve the problem that we are looking for. Rather, what matters is how a group of
computer can solve such a problem. Computers (routers) cannot rely on what we people see by
looking at the network’s graphical representation; computers must work only with the
information exchanged in messages. Figure 1-7 shows an example network that will be used to
illustrate the distance vector routing algorithm. This algorithm is also known by the names of its
inventors as Bellman-Ford algorithm.
Let N denote the set of all nodes in a network. In Figure 1-7, N = {A, B, C, D}. There are two
types of quantities that the algorithm works with:
(i) Link costs attached to individual links directly connecting pairs of nodes (routers). These
are given to the algorithm either by having the network operator manually enter the cost
values or having an independent program determine these costs. For example, in Figure
1-7 the cost of the link connecting the nodes A and B is labeled as “10” units, that is
c(A, B) = 10.
Ivan Marsic • Rutgers University 12

Scenario 1: Scenario 2: Scenario 3:

Original network Cost c(C,D) ← 1 Link BD outage Link BC outage

B B B B
10 1 10 1 10 10 1

A 1 D A 1 D A 1 D A D

1 7 1 7 1 7 1 7
C C 1 C C

Figure 1-7: Example network used for illustrating the routing algorithms.

(ii) Node distances representing the paths with the lowest overall cost between pairs of
nodes. The distance from node X to node Y is denoted as DX(Y). These will be computed
by the routing algorithm.
The distance vector of node X is the vector of distances from this node to all the nodes in the
network, denoted as DV(X) = {DX(Y)}, Y ∈ N.
Let η(X) symbolize the set of neighboring nodes of node X. For example, in Figure 1-7 η(A) =
{B, C} since these are the only nodes directly linked to node A. The distance vector routing
algorithm runs at every node X and calculates the distance to every other node Y ∈ N, Y ≠ X,
using the following formula:
DX (Y ) = min {c( X , Y ) + DV (Y )} (1.9)
V ∈η ( X )

To apply this formula, every node must receive the distance vector from all other nodes in the
network. Every node maintains a table of distance vectors, which includes its own distance vector
and distance vector of its neighbors. Initially, the node assumes that the distance vectors of its
neighbors are filled with infinite elements.
Routing Distance to
table at
node A A B C D
A 0 10 1 ∞
From

B ∞ ∞ ∞ ∞
C ∞ ∞ ∞ ∞
Notice that node A only keeps the distance vectors of its immediate neighbors, B and C, and not
that of any other nodes, such as D. Other nodes initialize their routing tables as shown in the left
column of Figure 1-8.
As illustrated in Figure 1-8, each node sends its distance vector to its immediate neighbors. When
a node receives an updated distance vector from its neighbor, the node overwrites the neighbor’s
old distance vector with the new one. Next, it re-computes its own distance vector according to
Eq. (1.9). For the sake of simplicity, let us assume that at every node all distance vector packets
arrive simultaneously. Of course, this is not the case in reality, but asynchronous arrivals of
routing packets do not affect the algorithm operation. Then consider how node A computes its
new distance vector:
DA ( B) = min{c( A, B) + DB ( B), c( A, C ) + DC ( B)} = min{10 + 0, 1 + 1} = 2
Chapter 1 • Introduction to Computer Networks 13

Initial routing tables: After 1st exchange: After 2nd exchange: After 3rd exchange:

Routing table
A Distance to Distance to Distance to Distance to

at node A A B C D A B C D A B C D A B C D

A 0 10 1 ∞ A 0 2 1 8 A 0 2 1 3 A 0 2 1 3
From

From

From

From
B ∞ ∞ ∞ ∞ B 10 0 1 1 B 2 0 1 1 B 2 0 1 1
C ∞ ∞ ∞ ∞ C 1 1 0 7 C 1 1 0 2 C 1 1 0 2

B Distance to Distance to Distance to Distance to

Routing table

A B C D A B C D A B C D A B C D
at node B

A ∞ ∞ ∞ ∞ A 0 10 1 ∞ A 0 2 1 8 A 0 2 1 3
B 10 0 1 1 B 2 0 1 1 B 2 0 1 1 B 2 0 1 1

From

From
From

C ∞ ∞ ∞ ∞ From C 1 1 0 7 C 1 1 0 2 C 1 1 0 2
D ∞ ∞ ∞ ∞ D ∞ 1 7 0 D 8 1 2 0 D 3 1 2 0

C Distance to Distance to Distance to Distance to

Routing table

A B C D A B C D A B C D A B C D
at node C

A ∞ ∞ ∞ ∞ A 0 10 1 ∞ A 0 2 1 8 A 0 2 1 3

B ∞ ∞ ∞ ∞ B 10 0 1 1 B 2 0 1 1 B 2 0 1 1

From
From

From

From
C 1 1 0 7 C 1 1 0 2 C 1 1 0 2 C 1 1 0 2
D ∞ ∞ ∞ ∞ D ∞ 1 7 0 D 8 1 2 0 D 3 1 2 0

D Distance to Distance to Distance to Distance to

Routing table

A B C D A B C D A B C D A B C D
at node D

B ∞ ∞ ∞ ∞ B 10 0 1 1 B 2 0 1 1 B 2 0 1 1

From
From

From

From

C ∞ ∞ ∞ ∞ C 1 1 0 7 C 1 1 0 2 C 1 1 0 2
D ∞ 1 7 0 D 8 1 2 0 D 3 1 2 0 D 3 1 2 0

Figure 1-8: Distance vector (DV) algorithm for the original network in Figure 1-7.

DA (C ) = min{c( A, B) + DB (C ), c( A, C ) + DC (C )} = min{10 + 1, 1 + 0} = 1
DA ( D) = min{c( A, B) + DB ( D), c( A, C ) + DC ( D)} = min{10 + 1, 1 + 7} = 8

Similar computations will take place on all other nodes and the end result is as shown in Figure
1-8 as column entitled “After 1st exchange.” Since for every node the newly computed distance
vector is different from the previous one, each node sends its distance new vector to its immediate
neighbors. The cycle repeats until for every node there is no difference between the new and the
previous distance vector. As shown in Figure 1-8, this happens after three exchanges.

1.5 Quality of Service Overview

This text reviews basic results about quality of service (QoS) in networked systems, particularly
highlighting the wireless networks.
The recurring theme in this text is the delay and its statistical properties for a computing system.
Delay (also referred to as latency) is modeled differently at different abstraction levels, but the
key issue remains the same: how to limit the delay so it meets task constraints. A complement of
Ivan Marsic • Rutgers University 14

Network
Network

Figure 1-9: Conceptual model of information delivery over network.

delay is capacity, also referred to as bandwidth, which was covered in the previous volume.
Therein, we have seen that the system capacity is subject to physical (or economic) limitations.
Constraints on delay, on the other hand, are imposed subjectively by the task of the information
recipient—information often loses value for the recipient if not received within a certain deadline.
Processing and communication of information in a networked system are generally referred to as
servicing of information. The dual constraints of capacity and delay naturally call for
compromises on the quality of service. If the given capacity and delay specifications do not
permit providing the full service to the customer (in our case information), a compromise in
service quality must be made and a sub-optimal service agreed to as a better alternative to
unacceptable delays or no service at all. In other words, if the receiver can admit certain degree of
information loss, then the latencies can be reduced to an acceptable range.
In order to achieve the optimal tradeoff, the players and their parameters must be considered as
shown in Figure 1-10. We first define information qualities and then analyze how they get
affected by the system processing.

Latency and information loss are tightly coupled and by adjusting one we can control the other.
Thus both enter the quality-of-service specification. If all information must be received to meet
the receiver’s requirements, then the loss must be dealt with within the system, and the user is
only aware of latencies.
Time is always an issue in information systems as is generally in life. However, there are
different time constraints, such as soft, hard, as well as their statistical properties.
We are interested in assessing the servicing parameters of the intermediate and controlling them
to achieve information delivery satisfactory for the receiver.
Since delay is inversely proportional to the packet loss, by adjusting one we can control the other.
Some systems are “black box”—they cannot be controlled, e.g., Wi-Fi, where we cannot control
the packet loss since the system parameters of the maximum number of retries determine the
delay. In such case we can control the input traffic to obtain the desired output.
Source is usually some kind of computing or sensory device, such as microphone, camera, etc.
However, it may not be always possible to identify the actual traffic source. For example, it could
be within the organizational boundaries, concealed for security or privacy reasons.
Figure 1-10 is drawn as if the source and destination are individual computers and
(geographically) separated. The reality is not always so simple. Instead of computers, these may
Chapter 1 • Introduction to Computer Networks 15

Examples:
• Communication channel
• Computation server

Source Intermediary Destination

Parameters: Parameters: Parameters:

• Source information rate • Servicing capacity • Delay constraints
• Statistical characteristics • List of servicing quality options • Information loss tolerance
- Delay options
- Information loss options

Figure 1-10: Key factors in quality of service assurance.

be people or organizations using multiple computers, or they could be networks of sensors and/or
actuators.
Users exchange information through computing applications. A distributed application at one end
accepts information and presents it at the other end. Therefore, it is common to talk about the
characteristics of information transfer of different applications. These characteristics describe the
traffic that the applications generate as well as the acceptable delays and information losses by
the intermediaries (network) in delivering that traffic. We call “traffic” the aggregate bitstreams
that can be observed at any cut-point in the system.
The information that applications generate can take many forms: text, audio, voice, graphics,
pictures, animations, and videos. Moreover, the information transfer may be one-way, two-way,
broadcast, or multipoint.
Traffic management is the set of policies and mechanisms that allow a network to efficiently
satisfy a diverse range of service requests. The two fundamental aspects of traffic management,
diversity in user requirements and efficiency in satisfying them, act at cross purposes, creating a
tension that has led to a rich set of mechanisms. Some of these mechanisms include scheduling
and flow control.

QoS guarantees: hard and soft

Our primary concerns here are delay and loss requirements that applications impose on the
network. We should keep in mind that other requirements, such as reliability and security may be
important. When one or more links or intermediary nodes fail, the network may be unable to
provide a connection between source and destination until those failures are repaired. Reliability
refers to the frequency and duration of such failures. Some applications (e.g., control of electric
power plants, hospital life support systems, critical banking operations) demand extremely
reliable network operation. Typically, we want to be able to provide higher reliability between a
few designated source-destination pairs. Higher reliability is achieved by providing multiple
disjoint paths between the designated node pairs.
In this text we first concentrate on the parameters of the network players, traffic characteristics of
information sources, information needs of information sinks, and delay and loss introduced by the
Ivan Marsic • Rutgers University 16

intermediaries. Then we review the techniques designed to mitigate the delay and loss to meet the
sinks information needs in the best possible way.

Performance Bounds
Network performance bounds can be expressed either deterministically or statistically. A
deterministic bound holds for every packet sent on a connection. A statistic bound is a
probabilistic bound on network performance. For example, a deterministic delay bound of 200 ms
means that every packet sent on a connection experiences an end-to-end, from sender to receiver,
delay smaller than 200 ms. On the other hand, a statistical bound of 200 ms with a parameter of
0.99 means that the probability that a packet is delayed by more than 200 ms is smaller than 0.01.

Quality of Service
Network operator can guarantee performance bounds for a connection only by reserving
sufficient network resources, either on-the-fly, during the connection-establishment phase, or in
advance.
There is more than one way to characterize quality-of-service (QoS). Generally, QoS is the ability
of a network element (e.g., an application, a host or a router) to provide some level of assurance
for consistent network data delivery. Some applications are more stringent about their QoS
requirements than others, and for this reason (among others) we have two basic types of QoS
available:
• Resource reservation (integrated services): network resources are apportioned according
to an application’s QoS request, and subject to bandwidth management policy.
• Prioritization (differentiated services): network traffic is classified and apportioned
network resources according to bandwidth management policy criteria. To enable QoS,
network elements give preferential treatment to classifications identified as having more
demanding requirements.
These types of QoS can be applied to individual traffic “flows” or to flow aggregates, where a
flow is identified by a source-destination pair. Hence there are two other ways to characterize
types of QoS:
• Per Flow: A “flow” is defined as an individual, unidirectional, data stream between two
applications (sender and receiver), uniquely identified by a 5-tuple (transport protocol,
source address, source port number, destination address, and destination port number).
• Per Aggregate: An aggregate is simply two or more flows. Typically the flows will have
something in common (e.g., any one or more of the 5-tuple parameters, a label or a
priority number, or perhaps some authentication information).
Chapter 1 • Introduction to Computer Networks 17

1.5.1 QoS Outlook

There has been a great amount of research on QoS in wireline networks, but very little of it ended
up being employed in actual products. Many researchers feel that there is higher chance that QoS
techniques will be actually employed in wireless networks. Here are some of the arguments:

Wireline Network vs. Wireless Network

• Deals with thousands of traffic flows, • Deals with tens of traffic flows (max
thus not feasible to control about 50), thus it is feasible to control
• Am I a bottleneck? • I am the bottleneck!
• Easy to add capacity • Hard to add capacity
• Scheduling interval ~ 1 μs • Scheduling interval ~ 1 ms, so a larger
period is available to make decision

1.6 Summary and Bibliographical Notes

This chapter covers many different topics aspects of computer networks and wireless
communications. At many places the knowledge networking topics is assumed and no
explanations are given. The reader should check a networking book; perhaps two of the most
regarded networking books currently are [Peterson & Davie 2003] and [Kurose & Ross 2005].

Raj Jain, “Books on Quality of Service over IP,”

Online at: http://www.cse.ohio-state.edu/~jain/refs/ipq_book.htm
Useful information about QoS can be found here:
Leonardo Balliache, “Practical QoS,” Online at: http://www.opalsoft.net/qos/index.html

Problems
Ivan Marsic • Rutgers University 18

Problem 1.1
Suppose host A has four packets to be sent to host B using Stop-and-Wait protocol. If the packets
are unnumbered (i.e., the header does not contain the sequence number), draw a time-sequence
diagram to show what packets arrive at the receiver and what ACKs are sent back to host A if the
ACK for packet 2 is lost.

Problem 1.2
Suppose two hosts, sender A and receiver B, communicate using Stop-and-Wait ARQ method.
Subsequent packets from A are alternately numbered with 0 or 1, which is known as the
alternating-bit protocol.
(a) Show that the receiver B will never be confused about the packet duplicates if and only if there
is a single path between the sender and the receiver.
(b) In case there are multiple, alternative paths between the sender and the receiver and
subsequent packets are numbered with 0 or 1, show step-by-step an example scenario where
receiver B is unable to distinguish between an original packet and its duplicates.

Problem 1.3
Assume that the network configuration described in Example 2.1 in Section 2.2 below runs the
Stop-and-Wait protocol. The signal propagation speed for both links is 2 × 108 m/s. The length of
the link from the sender to the router is 100 m and from the router to the receiver is 10 km.
Determine the sender utilization.
PROBLEM: Timeout time calculation: Assume that the delay times are distributed according to a
normal distribution, with mean = (.) and stdDev = (.). Provision the timeout parameter, so to not
have more than 10 % unnecessary duplicate packets sent.

Problem 1.4
Suppose two stations are using Go-back-2 ARQ. Draw the time-sequence diagram for the
transmission of seven packets if packet 4 was received in error.

Problem 1.5
Consider a system using the Go-back-N protocol over a fiber link with the following parameters:
10 km length, 1 Gbps transmission rate, and 512 bytes packet length. (Propagation speed for fiber
≈ 2 × 108 m/s and assume error-free and duplex communication, i.e., link can transmit
simultaneously in both directions. Also assume that the acknowledgment packet size is
negligible.) What value of N yields the maximum utilization of the sender?

Problem 1.6
Suppose three hosts are connected as shown in the figure. Host A sends packets to host C and host
B serves merely as a relay. However, as indicated in the figure, they use different ARQ’s for
reliable communication (Go-back-N vs. Selective Repeat). Notice that B is not a router; it is a
regular host running both receiver (to receive packets from A) and sender (to forward A’s packets
to C) applications. B’s receiver immediately relays in-order packets to B’s sender.
Chapter 1 • Introduction to Computer Networks 19

A B C
Go-back-3 SR, N=4

Draw side-by-side the timing diagrams for A→B and B→C transmissions up to the time where
the first seven packets from A show up on C. Assume that the 2nd and 5th packets arrive in error to
host B on their first transmission, and the 5th packet arrives in error to host C on its first
transmission.
Discuss whether ACKs should be sent from C to A, i.e., end-to-end.

Problem 1.7
Consider the network configuration as in Problem 1.6. However, this time around assume that the
protocols on the links are reverted, as indicated in the figure, so the first pair uses Selective
Repeat and the second uses Go-back-N, respectively.

A B C
SR, N=4 Go-back-3

Draw again side-by-side the timing diagrams for A→B and B→C transmissions assuming the
same error pattern. That is, the 2nd and 5th packets arrive in error to host B on their first
transmission, and the 5th packet arrives in error to host C on its first transmission.

Problem 1.8
Assume the following system characteristics (see the figure below):
The link transmission speed is 1 Mbps; the physical distance between the hosts is 300 m; the link
is a copper wire with signal propagation speed of 2 × 108 m/s. The data packets to be sent by the
hosts are 2 Kbytes each, and the acknowledgement packets (to be sent separately from data
packets) are 10 bytes long. Each host has 100 packets to send to the other one. Assume that the
transmitters are somehow synchronized, so they never attempt to transmit simultaneously from
both endpoints of the link.
Each sender has a window of 5 packets. If at any time a sender reaches the limit of 5 packets
outstanding, it stops sending and waits for an acknowledgement. Since there is no packet loss (as
stated below), the timeout timer value is irrelevant. This is similar to a Go-back-N protocol, with
the following difference.
The hosts do not send the acknowledgements immediately upon a successful packet reception.
Rather, the acknowledgements are sent periodically, as follows. At the end of an 82 ms period,
the host examines whether any packets were successfully received during that period. If one or
more packets were received, a single (cumulative) acknowledgement packet is sent to
acknowledge all the packets received in this period. Otherwise, no acknowledgement is sent.
 Ivan Marsic • Rutgers University 20

Consider the two scenarios depicted in the figures (a) and (b) below. The router in (b) is 150 m
away from either host, i.e., it is located in the middle. If the hosts in each configuration start
sending packets at the same time, which configuration will complete the exchange sooner? Show
the process.
Packets to Packets to
send send

Router

Host A Host B Host A Host B

(a) (b)

Assume no loss or errors on the communication links. The router buffer size is unlimited for all
practical purposes and the processing time at the router approximately equals zero. Notice that the
router can simultaneously send and receive packets on different links.

Problem 1.9
Consider two hosts directly connected and communicating using Go-back-N ARQ in the presence
of channel errors. Assume that data packets are of the same size, the transmission delay tx per
packet, one-way propagation delay tp, and the probability of error for data packets equals pe.
Assume that ACK packets are effectively zero bytes and always transmitted error free.
(a) Find the expected delay per packet transmission. Assume that the duration of the timeout
tout is large enough so that the source receives ACK before the timer times out, when both
a packet and its ACK are transmitted error free.
(b) Assume that the sender operates at the maximum utilization and determine the expected
delay per packet transmission.
Note: This problem considers only the expected delay from the start of the first attempt at a
packet’s transmission until its successful transmission. It does not consider the waiting delay,
which is the time the packet arrives at the sender until the first attempt at the packet’s
transmission. The waiting delay will be considered in Section 4.3 below.

Problem 1.10
Given a 64Kbps link with 1KB packets and RTT of 0.872 seconds:
(a) What is the maximum possible throughput, in packets per second (pps), on this link if a
Stop-and-Wait ARQ scheme is employed?
(b) Again assuming S&W ARQ is used, what is the expected throughput (pps) if the
probability of error-free transmission is p=0.95?
Chapter 1 • Introduction to Computer Networks 21

(c) If instead a Go-back-N (GBN) sliding window ARQ protocol is deployed, what is the
average throughput (pps) assuming error-free transmission and fully utilized sender?
(d) For the GBN ARQ case, derive a lower bound estimate of the expected throughput (pps)
given the probability of error-free transmission p=0.95.

Problem 1.11
You are hired as a network administrator for the network of sub-networks shown in the figure.
Assume that the network will use the CIDR addressing scheme.
A C
R1
B D

R2

E F
(a) Assign meaningfully the IP addresses to all hosts on the network. Allocate the minimum
possible block of addresses for your network, assuming that no new hosts will be added
to the current configuration.
(b) Show how routing/forwarding tables at the routers should look after the network
stabilizes (don’t show the process).

Problem 1.12
The following is a routing table of a router X using CIDR. Note that the last three entries cover
every address and thus serve in lieu of a default route.
Subnet Mask Next Hop A
B
223.92.32.0 / 20 A
223.81.196.0 / 12 B X
C

223.112.0.0 / 12 C
223.120.0.0 / 14 D D
128.0.0.0 / 1 E G
64.0.0.0 / 2 F F
E
32.0.0.0 / 3 G
State to what next hop the packets with the following destination IP addresses will be delivered:
(a) 195.145.34.2
(b) 223.95.19.135
(c) 223.95.34.9
Ivan Marsic • Rutgers University 22

(d) 63.67.145.18
(e) 223.123.59.47
(f) 223.125.49.47
(Recall that the default matches should be reported only if no other match is found.)

Problem 1.13
Suppose a router receives a set of packets and forwards them as follows:
(a) Packet with destination IP address 128.6.4.2, forwarded to the next hop A
(b) Packet with destination IP address 128.6.236.16, forwarded to the next hop B
(c) Packet with destination IP address 128.6.29.131, forwarded to the next hop C
(d) Packet with destination IP address 128.6.228.43, forwarded to the next hop D
Reconstruct only the part of the router’s routing table that you suspect is used for the above
packet forwarding. Use the CIDR notation and select the shortest network prefixes that will
produce unambiguous forwarding:
Network Prefix Subnet Mask Next Hop
…………………………… ……………….. …
…………………………… ……………….. …
…………………………… ……………….. …
…………………………… ……………….. …

Problem 1.14
Consider the network in the figure below and assume that the distance vector algorithm is used
for routing. Show the distance vectors after the routing tables on all nodes are stabilized. Now
assume that the link AC with weight equal to 1 is broken. Show the distance vectors on all nodes
for up to five subsequent exchanges of distance vectors or until the routing tables become
stabilized, whichever comes first.

C
50
1
1

A B
4

Problem 1.15
Consider the following network, using distance-vector routing:
Chapter 1 • Introduction to Computer Networks 23

A B C D
1 1 1

Suppose that, after the network stabilizes, link C–D goes down. Show the routing tables on the
nodes A, B, and C, for the subsequent five exchanges of the distance vectors. How do you expect
the tables to evolve for the future steps? State explicitly all the possible cases and explain your
answer.

Problem 1.16
For the network in Figure 1-7, consider Scenario 3, which involves link BC outage. Assume that
all the routing tables have stabilized, as in the last column of Figure 1-8. Show step-by-step
procedure for the first four distance vector exchanges after the outage is detected.
 Chapter 2
Transport Control Protocol (TCP)

Contents
2.1 Introduction
2.1.1 Retransmission Timer

2.1 Introduction 2.1.2 Flow Control

2.1.3 x

2.2 Congestion Avoidance and Control

2.2.1 TCP Tahoe
2.2.2 TCP Reno
2.2.3

TCP is usually not associated with quality of service; but one 2.3 Fairness
could argue that TCP offers QoS in terms of assured delivery 2.3.1 x
2.3.2 x
and efficient use of bandwidth, although it provides no delay 2.3.3 x
guarantees. TCP is, after all, mainly about efficiency: how to 2.3.4 x

deliver data utilizing the maximum available (but fair) share of 2.4 TCP Over Wireless Channel
the network capacity so to reduce the delay. That is why our 2.4.1 x
2.4.2
main focus here is only one aspect of TCP—congestion 2.4.3
avoidance and control. The interested reader should consult 2.5 x
other sources for comprehensive treatment of TCP, e.g., 2.5.1 x
[Stevens 1994; Peterson & Davie 2003; Kurose & Ross 2005]. 2.5.2
2.5.3
I start quality-of-service review with TCP because it does not
2.6 Recent TCP Versions
assume any knowledge of or any cooperation from the network.
2.5.1 x
The network is essentially seen as a black box. 2.5.2 x
2.5.3 x
In Chapter 1 we have seen that pipelined ARQ protocols, such
2.8 Summary and Bibliographical Notes
as Go-back-N, increase the utilization of network resources by
Problems
allowing multiple packets to be simultaneously in flight from
sender to receiver. The “flight size” is controlled by a
parameter called window size which must be set according to the available network resources.
Remember that network is responsible for data from the moment it accepts them at the sender’s
end until they are delivered at the receiver’s end. The network is “holding” the data for the “flight
duration” and for this it must reserve resources, avoiding the possibility of becoming overbooked.
In case of two end hosts connected by a single link, the optimal window size is easy to determine
and remains static for the duration of session. However, this task is much more complex in a
multi-hop network.
In the following discussion, I use the common term “segment” for TCP packets.

24
Chapter 2 • Transport Control Protocol (TCP) 25

2.1.1 Retransmission Timer

An important parameter for reliable transport over multihop networks is retransmission timer.
This timer triggers the retransmission of packets that are presumed lost. Obviously, it is very
important to set the right value for the timer. For, if the timeout time is too short, the packets will
be unnecessarily retransmitted thus wasting the network bandwidth. And, if the timeout time is
too long, the sender will unnecessarily wait when it should have already retransmitted thus
underutilizing and perhaps wasting the network bandwidth.
It is relatively easy to set the timeout timer for single-hop networks since the propagation time
remains effectively constant. However, in multihop networks queuing delays at intermediate
routers and propagation delays over alternate paths introduce significant uncertainties.
TCP has a special algorithm for dynamically updating the retransmission timeout (RTO) value.
The details are available in RFC-2988 [Paxson & Allman, 2000], and here I provide a summary.
The RTO timer value, denoted as TimeoutInterval, is initially set as 3 seconds. When the
retransmission timer expires (presumably because of a lost packet), the earliest unacknowledged
data segment is retransmitted and the next timeout interval is set to twice the previous value:
TimeoutInterval(t) = 2 × TimeoutInterval(t−1)
This property of doubling RTO on each timeout is known as exponential backoff. If a segment’s
acknowledgement is received before the retransmission timer expires, the TCP sender measures
the round-trip time (RTT) for this segment, denoted as SampleRTT. TCP only measures
SampleRTT for segments that have been transmitted once and not for segments that have been
retransmitted.
For the subsequent data segments, the TimeoutInterval is set according to the following
equation:
TimeoutInterval = EstimatedRTT + 4 ⋅ DevRTT (2.1)
where:
⎧SampleRTT for the first RTT measurement
EstimatedRTT = ⎨
⎩(1 − α ) ⋅ EstimatedRTT + α ⋅ SampleRTT for all subsequent RTT measurements
and
⎧SampleRTT / 2 for the first RTT measurement
DevRTT = ⎨
⎩ (1 − β ) ⋅ DevRTT + β ⋅ SampleRTT − EstimatedRTT for all subsequent RTT measurements
The recommended values of the control parameters α and β are α = 0.125 and β = 0.25. These
were determined empirically.
In theory, it is simplest to maintain individual retransmission timer for each outstanding packet.
In practice, timer management involves considerable complexity, so most protocol
implementations maintain single timer per sender. RFC-2988 recommends maintaining single
retransmission timer per TCP sender, even if there are multiple transmitted-but-not-yet-
acknowledged segments. Of course, individual implementers may decide otherwise, but in this
text I follow the single-timer recommendation.
Ivan Marsic • Rutgers University 26

TCP sends segments in bursts or groups of segments, every burst containing the number of
segments limited by the current window size. As with any other sliding window protocol, TCP
sender is allowed to have only up to the window-size outstanding amount of data (yet to be
acknowledged). Once the window-size worth of segments is sent, the sender stops and waits for
acknowledgements to arrive. For every arriving ACK, the sender is allowed to send certain
number of additional segments, as governed by the rules described below. The retransmission
timer management can be summarized as follows (see also Figure 2-4):

LastByteSent = initial sequence number;

LastByteAcked = initial sequence number;
loop (forever) {
switch (event) {
data received from application layer above: {
create new TCP segment with sequence_number = LastByteSent;
if (RTO timer not already running) { start the timer };
pass the segment to IP;
LastByteSent += length(data);
}
RTO timer timeout: {
retransmit the segment with sequence_number = LastByteAcked
start the timer
}
ACK(y) received: {
if (y > LastByteAcked) {
LastByteAcked = y
if (LastByteAcked < LastByteSent) {
re-start the RTO timer
} // i.e., there are segments not yet acknowledged
}
}
}
}

An important peculiarity to notice is as follows. When a window-size worth of segments is sent,

the timer is set for the first one (assuming that the timer is not already running). For every
acknowledged segment of the burst, the timer is restarted for its subsequent segment in Event #3
above. Thus, the actual timeout time for the segments towards the end of a burst can run quite
longer than for those near the beginning of the burst. An example will be seen in Section 2.2
below in the solution of Example 2.1.

2.1.2 Flow Control

TCP receiver accepts out-of-order segments, but they are buffered and not delivered to the
application above before the gaps are filled. For this, the receiver allocates memory space of the
size RcvBuffer, which is typically set to 4096 bytes, although older versions of TCP set it to
2048 bytes. The receive buffer is used to store in-order segments as well, since the application
may be busy with other tasks and does not fetch the incoming data immediately. In the discussion
below, for the sake of simplicity we will assume that in-order segments are immediately fetched
by the application, unless stated otherwise.
 Chapter 2 • Transport Control Protocol (TCP) 27

(Sender) (Receiver)
Client
Client Server
Server
LISTEN
SYN 122750000:122750 (passive open)

Establishment
#1 000(0)

Connection
SYN_SENT win 2048, <mss 1024>
(active open) 3371521(0) #2
SYN 2363371521:236 SYN_RCVD
512>
ack , win 4096, <mss
ESTABLISHED #2 ack 1, win 2048

ESTABLISHED

CongWin = 1 MSS = 512 bytes

#3 1:513(512), ack
RcvWindow = 4096 bytes 1, win 2048

ack 513, win 4096

#4
CongWin = 1 + 1 = 2 #4 513:1025(512), ack
1, win 2048
#5 1025:1537(512), ack 1, win 2048

(Initial phase: “Slow Start”)

6 #6
ack 1537, win 409

CongWin = 2 +1+1 = 4 #6 1537:2049(512), ack 1, win 2048

Data Transport
#7 2049:256
1(512), ac
k 1, win 20 #7
#8 2561:3073(512) 48 ack 2049, win 4096
Gap in sequence!
CongWin = 4 +1 = 5 4 #7
#9 3073:3585(512), ack ack 2049, win 358 (buffer 512 bytes)
1, win 2048

6
#10
#10 ack 3585, win 409
3585:4
097(51
CongWin = 5 +1+1+1 = 8 #11 2), ack
4097:4609(512) 1, win
2048
Time

#12 4609:5121(512), ack 1, win 2048 #10 Gap in sequence!

4
ack 3585, win 358
#13 5121:5633(512), ack
1, win 2048 ack 3585, win 3072 #10 (buffer 1024 bytes)

#14 #14
ack 5633, win 4096

CongWin = 8 +1+1+1+1 = 12

Figure 2-1: Initial part of the time line of an example TCP session. Time increases down the
page. See text for details. (The CongWin parameter on the left side of the figure will be
described in Section 2.2 below.)

To avoid overrunning the receive buffer, the receiver continuously advertises the remaining
buffer space to the sender using a field in the TCP header; we call this variable RcvWindow. It is
dynamically changing to reflect the current occupancy state of the receiver’s buffer. The sender
should never have more than the current RcvWindow amount of data outstanding.
Figure 2-1 shows how an actual TCP session might look like. The notation 1:513(512) means
transmitted data bytes 1 through but not included 513, which is a total of 512 bytes. The first
action is to establish the session, which is done by the first three segments, which represent the
three-way handshake procedure. These segments are special in that they do not contain data (i.e.,
there is header only), and the SYN flag in the header is set. In this example, the client offers
RcvWindow = 2048 bytes, and the server offers RcvWindow = 4096 bytes. In our case, the client
happens to be the “sender,” but server or both of them can simultaneously be senders and
receivers. They also exchange the size of the future segments, MSS (to be described below, Table
2-1), and settle on the smaller one of 1024 and 512 bytes. During the connection-establishment
phase, the client and the server will transition through different states, such as LISTEN,
SYN_SENT, and ESTABLISHED. The interested reader should consult another source for more
details, e.g., [Stevens 1994; Peterson & Davie 2003; Kurose & Ross 2005].
Ivan Marsic • Rutgers University 28

Figure 2-2: Simple congestion-control scenario for TCP.

After establishing the connection, the sender starts sending the packets. Figure 2-1 illustrates how
TCP incrementally increases the number of outstanding segments, the procedure called slow start,
which will be described below. TCP assigns byte sequence numbers, but for simplicity we usually
show packet sequence numbers. Notice that the receiver is not obliged to acknowledge
individually every single in-order segment—it can use cumulative ACKs to acknowledge several
of them up to the most recent contiguously received data. Conversely, the receiver must
immediately generate (duplicate) ACK—dupACK—for every out-of-order segment, since
dupACKs help the sender detect segment loss.
Notice that it can happen that receiver sends dupACKs even for successfully transmitted
segments because of random re-ordering of segments in the network. In Figure 2-1, this is the
case with segment #7, which arrives after segment #8. Thus, if a segment is delayed further than
three or more of its successors, the duplicate ACKs will trigger the sender to re-transmit the
delayed segment, and the receiver may eventually receive a duplicate of such a segment.

2.2 Congestion Avoidance and Control

TCP maneuvers to avoid congestion in the first place, and controls the damage if congestion
occurs. The key characteristic is that all the TCP’s intelligence for congestion avoidance and
control is in the end hosts—no help is expected from the intermediary hosts.
A key problem addressed by the TCP protocol is to dynamically determine the optimal window
size in the presence of uncertainties and dynamic variations of available network resources.
Early versions of TCP would start a connection with the sender injecting multiple segments into
the network, up to the window size advertised by the receiver. The problems would arise due to
intermediate router(s) which must queue the packets before forwarding them. If that router runs
out of space, large number of packets would be lost and had to be retransmitted. Jacobson [1988]
shows how this naïve approach can reduce the throughput of a TCP connection drastically.
The problem is illustrated in Figure 2-2, where the whole network is abstracted as a single
bottleneck router. It is easy for the receiver to know about its available buffer space and advertise
the right window size to the sender. The problem is with the intermediate router(s) which serve
data flows between many sources and receivers. Bookkeeping and policing of fair use of router’s
resources is a difficult task, since it must forward the packets as quickly as possible, and it is
Chapter 2 • Transport Control Protocol (TCP) 29

[ Sending Application ] [ Receiving Application ]

Increasing Increasing
Sent & Allowed to sequence num. Delivered to Gap in sequence num.
acked send application recv’d data
TCP TCP
sender’s receiver’s
byte stream byte stream

LastByteAcked LastByteSent NextByteExpected LastByteRecvd

FlightSize Buffered in RcvBuffer

(Buffered in send buffer)

Figure 2-3: Parameters for TCP send and receive buffers.

practically impossible to dynamically determine the “right window size” for each flow and
advertise it back to the sender.
TCP approaches this problem by putting the entire burden of determining the right window size
of the bottleneck router unto the end hosts. Essentially, the sender dynamically probes the
network and adjusts the amount of data in flight to match the bottleneck resource. The algorithm
used by TCP sender can be summarized as follows:

1. Start with a small size of the sender window

2. Send a burst (size of the current sender window) of packets into the network
3. Wait for feedback about success rate (acknowledgements from the receiver end)
4. When feedback obtained:
a. If the success rate is greater than zero, increase the sender window size and go to
Step 2
b. If loss is detected, decrease the sender window size and go to Step 2
This simplified procedure will be elaborated as we present the details below.
Table 2-1 shows the most important parameters (all the parameters are maintained in integer units
of bytes). Buffering parameters are shown in Figure 2-3. Figure 2-4 and Figure 2-5 summarize
the algorithms run at the sender and receiver. These are digested from RFC 2581 and RFC 2001
and the reader should check the details on TCP congestion control in [Allman et al. 1999; Stevens
1997]. [Stevens 1994] provides a detailed overview with traces of actual runs.

Table 2-1. TCP congestion control parameters.

Variable Definition

MSS The size of the largest segment that the sender can transmit. This value can be
based on the maximum transmission unit of the network, the path MTU
discovery algorithm, or other factors. The size does not include the TCP/IP
headers and options. [Note that RFC 2581 distinguishes sender maximum
segment size (SMSS) and receiver maximum segment size (RMSS).]
Ivan Marsic • Rutgers University 30

RcvWindow The size of the most recently advertised receiver window.

CongWindow Sender’s current estimate of the available buffer space in the bottleneck router.

LastByteAcked The highest sequence number currently acknowledged.

LastByteSent The sequence number of the last byte the sender sent.

FlightSize The amount of data that the sender has sent, but not yet got acknowledged.

EffectiveWindow The maximum amount of data that the sender is currently allowed to send. At
any given time, the sender must not send data with a sequence number higher
than the sum of the highest acknowledged sequence number and the minimum
of CongWindow and RcvWindow.

SSThresh The slow start threshold used by the sender to decide whether to employ the
slow-start or congestion-avoidance algorithm to control data transmission.

Notice that the sender must assure that:

LastByteSent ≤ LastByteAcked + min {CongWindow, RcvWindow}
Therefore, FlightSize should not exceed this value:
FlightSize = LastByteSent − LastByteAcked ≤ min {CongWindow, RcvWindow}
At any moment during a TCP session, the maximum amount of data the TCP sender is allowed to
send is (marked as “allowed to send” in Figure 2-3):
EffectiveWindow = min {CongWindow, RcvWindow} − FlightSize (2.2a)
Here we assume that the sender can only send MSS-size segments; the sender holds with
transmission until it collects at least an MSS worth of data. This is not always true, and the
application can request speedy transmission, thus generating small packets, so called tinygrams.
The application does this using the TCP_NODELAY socket option, which sets PSH flag. This is
particularly the case with interactive applications, such as telnet or secure shell. Nagle’s
algorithm [Nagle 1984] constrains the sender to have outstanding at most one segment smaller
than one MSS. For simplicity, we assume that the effective window is always rounded down to
integer number of MSS-size segments:
EffectiveWindow = ⎣min {CongWindow, RcvWindow} − FlightSize⎦ (2.2b)
Figure 2-1 above illustrates TCP slow start. In slow start, CongWindow starts at one segment
and gets incremented by one segment every time an ACK is received. As it can be seen, this
opens the congestion window exponentially: send one segment, then two, four, eight and so on.
The only “feedback” TCP receives from the network is by having packets lost in transport. TCP
considers that these are solely lost to congestion, which, of course, is not necessarily true—
packets may be lost to channel noise or even to a broken link. A design is good as long as its
assumptions hold, and TCP works fine over wired networks, since other types of loss are
uncommon therein. However, in wireless networks this underlying assumption breaks and it
causes a great problem as will be seen in Section 2.4 below.
Chapter 2 • Transport Control Protocol (TCP) 31

Reno Sender Fast retransmit

ACK received & (CongWin > SSThresh) / dupACK received & count ≥ 3 /
Send EfctWin (∗) of data re-send oldest outstanding segment
& Re-start RTO timer (†) & Re-start RTO timer (†)
Start /

Slow Start Congestion Avoidance

Fast retransmit
dupACK received & count ≥ 3 /
dupACK received / re-send oldest outstanding segment dupACK received /
Count it & Send EfctWin of data & Re-start RTO timer (†) Count it & Send EfctWin (∗) of data

dupACKS dupACKs dupACKS dupACKs

count ≡ 0 count > 0 count ≡ 0 count > 0

ACK received / ACK received /

ACK received / Send EfctWin (∗) of data ACK received / Send EfctWin (∗) of data
Send EfctWin (∗) of data & Re-start RTO timer (†) Send EfctWin (∗) of data & Re-start RTO timer (†)
& Re-start RTO timer (†) & Re-start RTO timer (†)

RTO timeout / RTO timeout /

Re-send oldest outstanding segment Re-send oldest outstanding segment
& Re-start RTO timer (‡) & Re-start RTO timer (‡)

Figure 2-4: TCP Reno sender state diagram. (∗) Effective window depends on CongWin,
which is computed differently in slow-start vs. congestion-avoidance. (†) RTO timer is
restarted if LastByteAcked < LastByteSent. (‡) RTO size doubles, SSThresh = CongWin/2.

Receiver Out-of-order segment /

All segments received in-order
Buffer it & Send dupACK
(LastByteRecvd ≡ NextByteExpected) Out-of-order segment /
Buffer it & Send dupACK
In-order segment received /
Start /

Immediate Delayed
acknowledging acknowledging Buffering out-of-order segments
In-order segment / (LastByteRecvd ≠ NextByteExpected)
Send ACK

500 msec elapsed /

Send ACK
In-order segment,
partially fills gaps /
Send ACK
In-order segment, completely fills gaps /
Send ACK

Figure 2-5: TCP receiver state diagram.

As far as TCP is concerned, it does not matter when a packet loss happened; what matters is
when the loss is detected. Packet loss happens in the network and the network is not expected to
notify the TCP endpoints about the loss—the endpoints have to detect loss and deal with it on
their own. Packet loss is of little concern to TCP receiver, except that it buffers out-of-order
segments and waits for the gap in sequence to get filled. TCP sender is the one mostly concerned
about the loss and it is the one that takes actions in response to detected loss. TCP sender detects
loss via two types of events (whichever occurs first):
1. Timeout timer expiration
Ivan Marsic • Rutgers University 32

2. Reception of three1 duplicate ACKs (four identical ACKs without the arrival of any other
intervening packets)
Upon detecting the loss, TCP sender takes action to avoid further loss by reducing the amount of
data injected into the network. (TCP also performs fast retransmission of what appears to be the
lost segment, without waiting for a RTO timer to expire.) There are many versions of TCP, each
having different reaction to loss, but two most popular ones are TCP Tahoe and TCP Reno, of
which TCP Reno is more recent and currently prevalent. Table 2-2 shows how they detect and
handle segment loss.

Table 2-2: How different TCP senders detect and deal with segment loss.
Event TCP Version TCP Sender’s Action
Tahoe
Timeout Set CongWindow = 1×MSS
Reno
≥ 3×dup Tahoe Set CongWindow = 1×MSS
ACKs Reno Set CongWindow = max {⎣½ FlightSize⎦, 2×MSS} + 3×MSS

As can be seen in Table 2-2, different versions react differently to three dupACKs: the more
recent version of TCP, i.e., TCP Reno, reduces the congestion window size to a lesser degree than
the older version, i.e., TCP Tahoe. The reason is that researchers realized that three dupACKs
signalize lower degree of congestion than RTO timeout. If the RTO timer expires, this may signal
a “severe congestion” where nothing is getting through the network. Conversely, three dupACKs
imply that three packets got through, although out of order, so this signals a “mild congestion.”
The initial value of the slow start threshold SSThresh is commonly set to 65535 bytes = 64 KB.
When a TCP sender detects segment loss using the retransmission timer, the value of SSThresh
must be set to no more than the value given as:
SSThresh = max {⎣½ FlightSize⎦, 2×MSS} (2.3)
where FlightSize is the amount of outstanding data in the network (for which the sender has
not yet received acknowledgement). The floor operation ⎣⋅⎦ rounds the first term down to the next
multiple of MSS. Notice that some networking books and even TCP implementations state that,
after a loss is detected, the slow start threshold is set as SSThresh = ½ CongWindow, which
according to RFC 2581 is incorrect.2

1
The reason for three dupACKs is as follows. Since TCP does not know whether a lost segment or just a
reordering of segments causes a dupACK, it waits for a small number of dupACKs to be received. It is
assumed that if there is just a reordering of the segments, there will be only one or two dupACKs before
the reordered segment is processed, which will then generate a fresh ACK. Such is the case with
segments #7 and #10 in Figure 2-1. If three or more dupACKs are received in a row, it is a strong
indication that a segment has been lost.
2
The formula SSThresh = ½ CongWindow is an older version for setting the slow-start threshold, which
appears in RFC 2001 as well as in [Stevens 1994]. I surmise that it was regularly used in TCP Tahoe, but
should not be used with TCP Reno.
Chapter 2 • Transport Control Protocol (TCP) 33

Congestion can occur when data arrives on a big pipe (a fast LAN) and gets sent out a smaller
pipe (a slower WAN). Congestion can also occur when multiple input streams arrive at a router
whose output capacity (transmission speed) is less than the sum of the input capacities. Here is an
example:

Example 2.1 Congestion Due to Mismatched Pipes with Limited Router Resources
Consider an FTP application that transmits a 10 Mbps
huge file (e.g., 20 MBytes) from host A to B
1 Mbps
over the two-hop path shown in the figure. The
link between the router and the receiver is called Sender Receiver
the “bottleneck” link since it is much slower
6+1 packets
than any other link on the sender-receiver path.
Assume that the router can always allocate the buffer size of only six packets for our session and in
addition have one of our packets currently being transmitted. Packets are only dropped when the buffer
fills up. We will assume that there is no congestion or queuing on the path taken by ACKs.
Assume MSS = 1KB and a constant TimeoutInterval = 3×RTT = 3×1 sec. Draw the graphs for
the values of CongWindow (in KBytes) over time (in RTTs) for the first 20 RTTs if the sender’s TCP
congestion control uses the following:
(a) TCP Tahoe: Additive increase / multiplicative decrease and slow start and fast retransmit.
(b) TCP Reno: All the mechanisms in (a) and fast recovery.
Assume a large RcvWindow (e.g., 64 KB) and error-free transmission on all the links. Assume also
that that duplicate ACKs do not trigger growth of the CongWindow. Finally, to simplify the graphs,
assume that all ACK arrivals occur exactly at unit increments of RTT and that the associated
CongWindow update occurs exactly at that time, too.
The solutions for (a) and (b) are shown in Figure 2-6 through Figure 2-11. The discussion of the
solutions is in the following text. Notice that, unlike Figure 2-1, the transmission rounds are “clocked”
and neatly aligned to the units of RTT. This idealization is only for the sake of illustration and the real
world would look more like Figure 2-1. [Note that this idealization would stand in a scenario with
propagation delays much longer than transmission delays.]

The link speeds are mismatched by a factor of 10 : 1, so the second link succeeds in transmitting a
single packet while the first link already transmitted ten packets. Normally, this would only cause
delays, but with limited router resources there is also a loss of packets. This is detailed in Figure
2-7, where the three packets in excess of the router capacity are discarded. Thereafter, until the
queue slowly drains, the router has one buffer slot available for every ten new packets that arrive.
Ivan Marsic • Rutgers University 34

Sender
Sender Receiver
Receiver
CongWin = 1 MSS #1 seg 1 1024 bytes
EfctWin = 1 #2
1 × RTT ack 2
to application
CongWin = 1 + 1 #2,3
EfctWin = 2 2 KB
2 × RTT #4 to appl
CongWin = 2 +1+1
EfctWin = 4 #4,5,6,7
#7 4 KB
3 × RTT #8 to appl
CongWin = 4 +1+1+1+1
EfctWin = 8 #8,9, …,14,15
7 KB
seg 15 to appl
8 segments sent (loss)
4 × RTT ack 15
#15 [ 1 segment lost ]
CongWin = 8 +1+…+1
#16,17, …,22, Gap in sequence!
EfctWin = 14 (buffer 7 KB)
7 23,…,27,28,29
[ 4 segments lost ]
14 sent dup ack 15 #15,15,…,15

seg 27
#15 (buffer 1KB)
5 × RTT 7+1 × dupACKs dup ack 15 [ 2 segments lost ]
CongWin = 1
#15 seg 15 (retransmission)
8 KB
6 × RTT ack 23
#23
to appl
CongWin = 1 + 1
#30 (1 byte) seg 30 (1 byte)
EfctWin = 0
7 × RTT ack 23
#23 (buffer 1 byte)
CongWin = 2′
#31 (1 byte) seg 31 (1 byte)
EfctWin = 0
8 × RTT ack 23
#23 (buffer 1 byte)
CongWin = 2′
#32 (1 byte) seg 32 (1 byte)
EfctWin = 0
9 × RTT 3 × dupACKs ack 23
#23 (buffer 1 byte)
CongWin = 1
#23 seg 23 (retransmission)
EfctWin = 1 1024 bytes
10 × RTT ack 24
#24
to application
CongWin = 1 + 1
EfctWin = 0 Time [RTT]

Figure 2-6: TCP Tahoe—partial timeline of segment and acknowledgement exchanges for
Example 2.1. Shown on the sender’s side are ordinal numbers of the sent segments and on
the receiver’s side are those of the ACKs (which indicate the next expected segment).

It is instructive to observe how the retransmission timer is managed (Figure 2-8). Up to time =
4×RTT, the timer is always reset for the next burst of segments. However, at time = 4×RTT the
timer is set for the 15th segment, which was sent in the same burst as the 8th segment, and not for
the 16th segment since the acknowledgement for the 15th segment is still missing. The reader is
encouraged to inspect the timer management for all other segments in Figure 2-8.

2.2.1 TCP Tahoe

TCP sender begins with a congestion window equal to one segment and incorporates the slow
start algorithm. In slow start the sender follows a simple rule: For every acknowledged segment,
increment the congestion window size by one MSS (unless the current congestion window size
exceeds the SSThresh threshold, as will be seen below). This procedure continues until a
segment loss is detected. Of course, a duplicate acknowledgement does not contribute to
increasing the congestion window.
Chapter 2 • Transport Control Protocol (TCP) 35

Sender Router Receiver

Time = 4 × RTT 6 packets buffered:

Segments #16

LastByteRecvd NextByteExpected
22 21 20 19 18 17
transmitted: #17
#18
LastByteAcked

#19
Transmission time on link_2

#14 #15
#20
#21 equals 10 × (Tx time on link_1)
#14 #15

#22
#23
#16
#24
#25
FlightSize

#26
#27 Dropped
#28 packets
#29
#29 #30
LastByteSent

#17
Segment #16
received
27 22 21 20 19 18
Time

#18
Segment #17
received

Figure 2-7: Detail from Figure 2-6 starting at time = 4×RTT. Mismatched transmission
speeds result in packet loss at the bottleneck router.

When the sender receives a dupACK, it does nothing but count it. If this counter reaches three or
more dupACKs, the sender decides, by inference, that a loss occurred. In response, it adjusts the
congestion window size and the slow-start threshold (SSThresh), and re-sends the oldest
unacknowledged segment. (The dupACK counter also should be reset to zero.) As shown in
Figure 2-8, the sender detects the loss first time at the fifth transmission round, i.e., 5×RTT, by
receiving eight duplicate ACKs. The congestion window size at this instance is equal to 15360
bytes or 15×MSS. After detecting a segment loss, the sender sharply reduces the congestion
window size in accordance with TCP’s multiplicative decrease behavior. As explained above, a
Tahoe sender resets CongWin to one MSS and reduces SSThresh as given by Eq. (2.3). Just
before the moment the sender received eight dupACKs FlightSize equals 15, so the new
value of SSThresh = 7.5×MSS.
Notice that in TCP Tahoe any additional dupACKs in excess of three do not matter—no new
packet can be transmitted while additional dupACKs after the first three are received. As will be
seen below, TCP Reno sender differs in that it starts fast recovery based on the additional
dupACKs received after the first three.
Upon completion of multiplicative decrease, TCP carries out fast retransmit to quickly retransmit
the segment that is suspected lost, without waiting for the timer timeout. Notice that at time =
5×RTT Figure 2-8 shows EffectiveWindow = 1×MSS. Obviously, this is not in accordance
with Eq. (2.2b), since currently CongWin equals 1×MSS and FlightSize equals 15×MSS.
This simply means that the sender in fast retransmit ignores the EffectiveWindow and simply
retransmits the segment that is suspected lost. The times when three (or more dupACKs are
received and fast retransmit is employed are highlighted with circle in Figure 2-8.
Ivan Marsic • Rutgers University 36

EffctWin
65535
SSThresh
[bytes] [MSS]
16384 15
Timeout
15 29 57 82
8 Timer 28 53 75
4 50 68
2 24 48 62
1 23
8192 8 7.5×MSS FlightSize

EffctWin
4096 4
CongWin 2×MSS
2048 2
1024 1 Time
0 1 2 3 4 5 6 7 8 9 10 11 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 [RTT]

#83,84, …,88
#82
#89,90
#50,51,52

#57,58,59,60,61

#75,76, …,82
#45

#29

#53,54,55,56
#33 (1 byte)
#34 (1 byte)

#42 (1 byte)
#43 (1 byte)
#44 (1 byte)

#46 (1 byte)
#47 (1 byte)

#62,63, …,67
#68,69, …,74
#48,49
#32 (1 byte)
#23

#26

#28
#30 (1 byte)
#31 (1 byte)
#8,9, …,14,15
#16,17, …,22,23,…,29
Segments sent

#4,5,6,7
#1
#2,3

#15

Figure 2-8: TCP Tahoe sender—the evolution of the effective and congestion window sizes
for Example 2.1. The sizes are given on vertical axis (left) both in bytes and MSS units.

Only after receiving a regular, non-duplicate ACK (most likely the ACK for the fast retransmitted
packet), the sender enters a new slow start cycle. After the 15th segment is retransmitted at time =
6×RTT, the receiver’s acknowledgement requests the 23rd segment thus cumulatively
acknowledging all the previous segments. The sender does not re-send it immediately since it still
has no indication of loss. Although at time = 7×RTT the congestion window doubles to 2×MSS
(since the sender is currently back in the slow start phase), there is so much data in flight that
EffectiveWindow = 0 and the sender is shut down. Notice also that for repetitive slow starts,
only ACKs for the segments sent after the loss was detected count. Cumulative ACKs for
segments before the loss was detected do not count towards increasing CongWin. That is why,
although at 6×RTT the acknowledgement segment cumulatively acknowledges packets 15–22,
CongWin grows only by 1×MSS although the sender is in slow start.
However, even if EffectiveWindow = 0, TCP sender must send a 1-byte segment as
indicated in Figure 2-6 and Figure 2-8. This usually happens when the receiver end of the
connection advertises a window of RcvWindow = 0, and there is a persist timer (also called the
zero-window-probe timer) associated with sending these segments. The tiny, 1-byte segment is
treated by the receiver same as any other segment. The sender keeps sending these tiny segments
until the effective window becomes non-zero or a loss is detected.
In our example, three duplicate ACKs are received by time = 9×RTT at which point the 23rd
segment is retransmitted. (Although TimeoutInterval = 3×RTT, we assume that ACKs are
processed first, and the timer is simply restarted for the retransmitted segment.) This continues
until time = 29×RTT at which point the congestion window exceeds SSThresh and congestion
avoidance takes off. The sender is in the congestion avoidance (also known as additive increase)
Chapter 2 • Transport Control Protocol (TCP) 37

15 Multiplicative decrease
CongWin [MSS]

Slow start
Additive increase
8 (Congestion avoidance)

2
1 Time
0 1 2 3 4 5 6 7 8 9 10 11 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 [RTT]

Fast retransmit

Figure 2-9: TCP Tahoe sender—highlighted are the key mechanisms for congestion
avoidance and control; compare to Figure 2-8.

phase when the current congestion window size is greater than the slow start threshold,
SSThresh. During congestion avoidance, each time an ACK is received, the congestion window
is increased as3:
MSS
CongWin t = CongWin t −1 + MSS × [bytes] (2.4)
CongWin t-1

where CongWin t−1 is the congestion window size before receiving the current ACK. The
parameter t is not necessarily an integer multiple of round-trip time. Rather, t is just a step that
occurs every time a new ACK is received and this can occur several times in a single RTT, i.e., a
transmission round. It is important to notice that the resulting CongWin is not rounded down to
the next integer value of MSS as in other equations. The congestion window can increase by at
most one segment each round-trip time (regardless of how many ACKs are received in that RTT).
This results in a linear increase.
Figure 2-9 summarizes the key congestion avoidance and control mechanisms. Notice that the
second slow-start phase, starting at 5×RTT, is immediately aborted due to the excessive amount
of unacknowledged data. Thereafter, the TCP sender enters a prolonged phase of dampened
activity until all the lost segments are retransmitted through “fast retransmits.”
It is interesting to notice that TCP Tahoe in this example needs 39×RTT in order to successfully
transfer 71 segments (not counting 17 one-byte segments to keep the connection alive, which
makes a total of 88 segments). Conversely, should the bottleneck bandwidth been known and
constant, Go-back-7 ARQ would need 11×RTT to transfer 77 segments (assuming error-free
transmission). Bottleneck resource uncertainty and dynamics introduce delay greater than three
times the minimum possible one.

3
The formula remains the same for cumulative acknowledgements, which acknowledge more than a single
segment, but the reader should check further discussion in [Stevens 1994].
Ivan Marsic • Rutgers University 38

EffctWin
65535
[bytes] [MSS]
SSThresh

CongWin
16384 15
73
15 29 66
8 28 59
4 37
2 24 36
1 23
8192 8

4096 4
EffctWin
FlightSize
2048 2
1024 1 Time
0 1 2 3 4 5 6 7 8 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [RTT]

#52 (1 byte)
#24
#40 (1 byte)

#47 (1 byte)
#48 (1 byte)
#49 (1 byte)

#51 (1 byte)

#75,76, …,81
#41 (1 byte)

#74,82,83
#59 (1 byte)
#38 (1 byte)
#39 (1 byte)

#50 (1 byte)

#53,54,55,56

#37
#60,61, …,66
#67,68, …,73,74

#84,85,…,90,91,…,94,95
#23

#29

#36,57
#58
#26

#28
#8,9, …,14,15
#16,17, …,22,23,…,29
#15,30,…,35,36,37
#4,5,6,7
#1
#2,3
Segments sent

6 × dupACKs 3 × dupACKs
4 × dupACKs

7 × dupACKs
7+1 × dupACKs

Figure 2-10: TCP Reno sender—the evolution of the effective and congestion window sizes
for Example 2.1. The sizes are given on vertical axis (left) both in bytes and MSS units.

2.2.2 TCP Reno

TCP Tahoe and Reno senders differ in their reaction to three duplicate ACKs. As seen above,
Tahoe enters slow start; conversely, Reno enters fast recovery. This is illustrated in Figure 2-10,
derived from Example 2.1.
After the fast retransmit algorithm sends what appears to be the missing segment, the fast
recovery algorithm governs the transmission of new data until a non-duplicate ACK arrives. It is
recommend [Stevens 1994; Stevens 1997; Allman et al. 1999] that CongWindow be
incremented by one MSS for each additional duplicate ACK received over and above the first
three dupACKs. This artificially inflates the congestion window in order to reflect the additional
segment that has left the network. Since three dupACKs are received by the sender, this means
that three segments have left the network and arrived successfully, but out-of-order, at the
receiver. After fast recovery is finished, congestion avoidance is entered.
As mentioned in the discussion of Table 2-2 above, the reason for performing fast recovery rather
than slow start is that the receipt of the dupACKs not only indicates that a segment has been lost,
but also that segments are most likely leaving the network (although a massive segment
duplication by the network can invalidate this conclusion). In other words, since the receiver can
only generate a duplicate ACK when an error-free segment has arrived, that segment has left the
network and is in the receiver's buffer, so we know it is no longer consuming network resources.
Chapter 2 • Transport Control Protocol (TCP) 39

Furthermore, since the ACK “clock” [Jac88] is preserved, the TCP sender can continue to
transmit new segments (although transmission must continue using a reduced CongWindow).
TCP Reno sender retransmits the lost segment and sets congestion window to:
CongWindow = max {⎣½ FlightSize⎦, 2×MSS} + 3×MSS (2.5)
where FlightSize is the amount of sent but unacknowledged data at the time of receiving the
third dupACK. Compare this equation to (2.3), for computing SSThresh. This artificially
“inflates” the congestion window by the number of segments (three) that have left the network
and which the receiver has buffered. In addition, for each additional dupACK received after the
third dupACK, increment CongWindow by MSS. This artificially inflates the congestion window
in order to reflect the additional segment that has left the network (the TCP receiver has buffered
it, waiting for the missing gap in the data to arrive).
As a result, in Figure 2-10 at 5×RTT CongWindow becomes equal to 15
2
+ 3 +1+1+1+1+1 =
15.5 × MSS. The last five 1’s are due to 7+1−3 = 5 dupACKs received after the initial 3 ones. At
6×RTT the receiver requests the 23rd segment (thus cumulatively acknowledging up to the 22nd).
CongWindow grows slightly to 17.75, but since there are 14 segments outstanding (#23 → #37),
the effective window is shut up. The sender arrives at standstill and thereafter behaves similar to
the TCP Tahoe sender, Figure 2-8.
Notice that, although at time = 10×RTT three dupACKs indicate that three segments that have left
the network, these are only 1-byte segments, so it may be inappropriate to add 3×MSS as Eq. (2.5)
postulates. RFC 2581 does not mention this possibility, so we continue applying Eq. (2.5) and
because of this CongWindow converges to 6×MSS from above.
Figure 2-11 shows partial timeline at the time when the sender starts recovering. After receiving
the 29th segment, the receiver delivers it to the application along with the buffered segments #30
→ #35 (a total of seven segments). At time = 27×RTT, a cumulative ACK arrives requesting the
36th segment (since segments #36 and #37 are lost at 5×RTT). Since CongWindow > 6×MSS and
FlightSize = 2×MSS, the sender sends four new segments and each of the four makes the
sender to send a dupACK. At 28×RTT, CongWindow becomes equal to 62 + 3 + 1 = 7& × MSS and
&

FlightSize = 6×MSS (we are assuming that the size of the unacknowledged 1-byte segments
can be neglected).
Regarding the delay, TCP Reno in this example needs 37×RTT to successfully transfer 74
segments (not counting 16 one-byte segments to keep the connection alive, which makes a total
of 90 segments—segment #91 and the consecutive ones are lost). This is somewhat better that
TCP Tahoe and TCP Reno should better stabilize for a large number of segments.
Ivan Marsic • Rutgers University 40

Sender
Sender Receiver
Receiver

CongWin = 6.7& × MSS

#52 (1 byte) seg 52 (1 byte)
EfctWin = 0
26 × RTT #29 (buffer 1 byte)
3 × dupACKs ack 29
CongWin = 62.7 + 3 + 1 = 6.3&
&
#29 seg 29 7168 bytes
EfctWin = 1 27 × RTT #36
ack 36 to application
CongWin = 6.3& #53,54,55,56 Gap in sequence!
EfctWin = 4 (buffer 4 KB)
28 × RTT 4 × dupACKs #36,36,36,36
ack 36
CongWin = 6.3& + 1
#36,57 seg 36 1024 bytes
EfctWin = 2 #37 to appl
29 × RTT ack 37
ack 37 #37
CongWin = 7.3& (buffer 1024 bytes)
#58 seg 58
EfctWin = 1
30 × RTT ack 37
#37 (buffer 1 KB)
CongWin = 7.3&
#59 (1 byte) seg 59 (1 byte)
EfctWin = 0
31 × RTT 3 × dupACKs ack 37
#37 (buffer 1 byte)
CongWin = 72.3 + 3 = 6.6&
&
#37 seg 37
EfctWin = 1 1024 + 16 + 6144
32 × RTT ack 60
#60
bytes to application
CongWin = 7.6&
EfctWin = 7 #60,61, …,66

Time [RTT]

Figure 2-11: TCP Reno—partial timeline of segment and ACK exchanges for Example 2.1.
(The slow start phase is the same as for Tahoe sender, Figure 2-6.)

The so-called NewReno version of TCP introduces a further improvement on fast recovery,
which handles a case where two segments are lost within a single window as follows. After a fast
retransmit, when the ACK arrives for the re-transmitted segment, there are two possibilities:
(1) The ACK specifies the sequence number at the end of the current window, in which case
the retransmitted segment was the only segment lost from the current window
(2) The ACK specifies the sequence number higher than the lost segment, but lower than the
end of the window, in which case (at least) one more segment from the window has also
been lost.
In the latter case, NewReno proceeds to retransmit the second missing segment, without waiting
for three dupACKs or RTO timer expiration.
 Chapter 2 • Transport Control Protocol (TCP) 41

18000

16000
CongWindow
EffctWindow
14000 FlightSize
SSThresh
12000

10000

8000

6000

4000

2000

0
12

15

18

21

24

27

30

33

36

39

42

45

48

51

54

57

60

63

66

69

72

75

78

81

84

87

90

93

96

99
0

Figure 2-12: TCP Tahoe congestion parameters for Example 2.1 over the first 100
transmission rounds. The overall sender utilization comes to only 25 %. The lightly shaded
background area shows the bottleneck router’s capacity, which, of course, is constant.

2.3 Fairness

2.4 TCP Over Wireless Channel

The TCP congestion control algorithms presented in Section 2.2 above assume most packet losses
are caused by routers dropping packets due to traffic congestion. However, packets may be also
dropped if they are corrupted in their path to destination. In wired networks the fraction of packet
loss due to transmission errors is generally low (less than 1 percent).
Several factors affect TCP performance in MANET:
• Wireless transmission errors
• Power saving operation
• Multi-hop routes on shared wireless medium (for instance, adjacent hops typically cannot
transmit simultaneously)
Ivan Marsic • Rutgers University 42

• Route failures due to mobility

2.5 Recent TCP Versions

Early TCP versions, Tahoe and Reno, perform relatively simple system observation and control.
The TCP Tahoe performance is illustrated in Figure 2-12 over the first 100 transmission rounds.
Although the obvious inefficiency (sender utilization is only 25 %) can be somewhat attributed to
the contrived scenario of Example 2.1, this is not far from reality. By comparison, a simple Stop-
and-Wait protocol would achieve the sender utilization of ?? %. Recent TCP versions introduce
sophisticated observation and control mechanisms to improve performance.
TCP Vegas [Brakmo & Peterson 1995] watches for the signs of incipient congestion—before
losses occur—and takes actions to avert it.
TCP Westwood [Mascolo et al. 2001] uses bandwidth estimates to compute the congestion
window and slow start threshold after a congestion episode.
FAST TCP [Jin et al. 2003] detects congestion by measuring packet delays.

2.6 Summary and Bibliographical Notes

RFC 3168, 3155, 3042, 2884, 2883, 2861, 2757, 2582 (NewReno)
[Stevens 1994] provides the most comprehensive coverage of TCP in a single book. It appears
that this whole book is available online at http://www.uniar.ukrnet.net/books/tcp-ip_illustrated/.
[Comer 2006] is also very good, although does not go in as much detail.
Electronics Research Group, “A Brief History of TCP,” Department of Engineering, University
of Aberdeen, Aberdeen, UK. Online at: http://erg.abdn.ac.uk/research/satcom/tcp-evol.html
SSFnet.org, “TCP Regression Tests,” Online at: http://www.ssfnet.org/Exchange/tcp/tcpTestPage.html
The SSFnet.org tests show the behavior of SSF TCP Tahoe and Reno variants for different
networks, TCP parameter settings, and loss conditions.

Problems
Chapter 2 • Transport Control Protocol (TCP) 43

Problem 2.1
Consider the TCP procedure for estimating RTT with α = 0.125 and β = 0.25. Assume that the
TimeoutInterval is initially set as 3 seconds. Suppose that all measured RTT values equal 5
seconds, no segment loss, and the segment transmission time is negligible. The sender starts
sending at time zero.
(a) What values will TimeoutInterval be set to for the segments sent during the first 11
seconds?
(b) Assuming a TCP Tahoe sender, how many segments will the sender transmit (including
retransmissions) during the first 11 seconds?
(c) Repeat steps (a) and (b) but this time around assume that the sender picked the initial
TimeoutInterval as 5 seconds?
Show the work.

Problem 2.2
Consider two hosts connected by a local area network with a negligible round-trip time. Assume
that one is sending to the other a large amount of data using TCP with RcvBuffer = 20 Kbytes
and MSS = 1 Kbytes. Also assume error-free transmission, high-speed processors in the hosts,
and reasonable values for any other parameters that you might need.
(a) Draw the congestion window diagram during the slow-start (until the sender enters
congestion avoidance) for the network speed of 100 Mbps.
(b) How different the diagram becomes if the network speed is reduced to 10 Mbps?
1 Mbps?
(c) What will be the average throughput (amount of data transmitted per unit of time) once
the sender enters congestion avoidance?
Explain your answers.

Problem 2.3
Suppose that the hosts from Problem 2.2 are connected over a satellite link with RTT = 20 ms
(low earth orbit satellites are typically 850 km above the Earth surface). Draw the congestion
window diagram during the slow-start for the network speed of 100 Mbps. Explain any
similarities or differences compared to the one from Problem 2.2(a).

Problem 2.4
Consider the network shown in the figure. TCP senders at hosts A and B have 3.6 KB of data each
to send to their corresponding TCP receivers, both running at host C. Assume MTU = 512 bytes
for all the links and TimeoutInterval = 2×RTT = 2×1 sec. The router buffer size is 3
packets in addition to the packet currently being transmitted; should the router need to drop a
packet, it drops the last arrived from the host which currently sent more packets. Sender A runs

10 Mbps
Sender A
1 Mbps

2 Receivers
at host C
10 Mbps
3+1 packets
Sender B
Ivan Marsic • Rutgers University 44

TCP Tahoe and sender B runs TCP Reno and assume that sender B starts transmission 2×RTTs
after sender A.
(a) Trace the evolution of the congestion window sizes on both senders until all segments are
successfully transmitted.
(b) What would change if TimeoutInterval is modified to 3×RTT = 3×1 sec?
Assume a large RcvWindow and error-free transmission on all the links. Finally, to simplify the
graphs, assume that all ACK arrivals occur exactly at unit increments of RTT and that the
associated CongWindow update occurs exactly at that time, too.

Problem 2.5
Consider a TCP Tahoe sender working on the network with RTT = 1 sec, MSS = 1 KB, and the
bottleneck link bandwidth equal to 128 Kbps. Ignore the initial slow-start phase and assume that
the sender exhibits periodic behavior where a segment loss is always detected in the congestion
avoidance phase via duplicate ACKs when the congestion window size reaches CongWindow =
16×MSS.
(a) What is the min/max range in which the window size oscillates?
(b) What will be the average rate at which this sender sends data?
(c) Determine the utilization of the bottleneck link if it only carries this single sender.
[Hint: When computing the average rate, draw the evolution of the congestion window. Assume
RcvWindow large enough not to matter.]

Problem 2.6
Specify precisely a system that exhibits the same behavior as in Problem 2.5 above:
• What is the buffer size at the bottleneck router?
• What is the minimum value of TimeoutInterval?
Demonstrate the correctness of your answer by graphing the last two transmission rounds before
the segment loss is detected and five transmission rounds following the loss detection.

Problem 2.7
Consider two hosts communicating by TCP-Tahoe protocol. Assume RTT = 1, MSS = 512 bytes,
TimeoutInterval = 3×RTT, SSThresh = 3×MSS to start with, and RcvBuffer = 2 KB.
Also assume that the bottleneck router has available buffer size of 1 packet in addition to the
packet currently being transmitted.
(a) Starting with CongWindow = 1×MSS, determine the congestion window size when the
first packet loss will happen at the router (not yet detected at the sender).
(b) What will be the amount of unacknowledged data at the sender at the time the sender
detects the loss? What is the total number of segments acknowledged by that time?
Assume that no cumulative ACKs are sent, i.e., each segment is acknowledged individually.
Chapter 2 • Transport Control Protocol (TCP) 45

Problem 2.8
Consider two hosts communicating by TCP-Reno protocol. Assume RTT = 1, MSS = 256 bytes,
TimeoutInterval = 3×RTT, RcvBuffer = 2 KB, and the sender has a very large file to
send. Start considering the system at the moment when it is in slow start state, CongWin =
8×MSS, SSThresh = 10×MSS and the sender just sent eight segments, each 1×MSS bytes long.
Assume that there were no lost segments before this transmission round and currently there are no
buffered segments at the receiver.
Assuming that, of the eight segments just sent, the fourth segment is lost, trace the evolution of
the congestion window sizes for the subsequent five transmission rounds. Assume that no more
segments are lost for all the considered rounds. For every step, indicate the transmitted segments
and write down the numeric value of CongWin (in bytes). To simplify the charts, assume that
ACK arrivals occur exactly at unit increments of RTT and that the associated CongWin update
occurs exactly at that time, too.

Problem 2.9
Consider the network configuration shown in the figure below. The mobile node connects to the
server using the TCP protocol to download a large file. Assume MSS = 1024 bytes, error-free
transmission, and sufficiently large storage spaces at the access point and the receiver.
Assume that the Assuming that the TCP receiver sends only cumulative acknowledgements.
Calculate how long time it takes to deliver the first 15 Kbytes of data from that moment the TCP
connection is established. In addition, draw the timing diagram of data and acknowledgement
transmissions. (You can exploit the fact that TCP sends cumulative acknowledgements.)

Ethernet
(802.3)
10 Mbps Server

Wi-Fi
(802.11)
1 Mbps
Mobile Access
Node Point
(In case you need these, assume the distance between the mobile node and the access point equal
to 100 m, and the same from the access point to the server. Also, the speed of light in the air is
3 × 108 m/s, and in a copper wire is 2 × 108 m/s.)

Problem 2.10
Consider an application that is engaged in a lengthy file transfer using the TCP Tahoe protocol
over the following network.
Ivan Marsic • Rutgers University 46

100 Mbps 9+1 packets 10 Mbps

Sender A Receiver B
100 Mbps 10 Mbps

tprop = 10 ms tprop = 10 ms

The following assumptions are made:

A1. Parallel and equal links connect the router to each endpoint host. Data packets always
take one of the paths, say the upper one, and ACK packets always take the other path.
The link transmission rates are as indicated. One way propagation delay on each link
equals 10 ms. All packet transmissions are error free.
A2. Each data segment from the sender to the receiver contains 1250 bytes of data. You can
ignore all header overheads, so the transmission delay over a 100 Mbps link for data
packets is exactly 0.1 ms and over 10 Mbps is exactly 1 ms. Also assume that the ACK
packet size is negligible, i.e., their transmission delay is approximately zero.
A3. The router buffer size is only nine packets plus one packet currently in transmission. The
packets that arrive to a full buffer are dropped. However, there is no congestion or loss
on the path taken by ACKs.
A4. The receiver does not use delayed ACKs, i.e., it sends an ACK immediately after
receiving a data segment.
A5. The receiver has set aside a buffer of RcvBuffer = 14 Kbytes for the received segments.
Answer the following questions:
(a) What is the minimum possible time interval between receiving two consecutive ACKs at
the sender?
(b) Write down the transmission start times for the first 5 segments.
(c) Write down the congestion widow sizes for the first 10 transmission rounds, i.e., the first
10 RTTs.
(d) When will the first packet be dropped at the router? Explain your answer.
(e) What is the congestion window size at the 11th transmission round?
(f) What is the long-term utilization of the TCP sender (ignore the initial period until it
stabilizes)?
(g) What is the long-term utilization of the link between the router and the receiver (again,
ignore the initial period until it stabilizes)?
(h) What will change if delayed ACKs are used to cumulatively acknowledge multiple
packets?
(i) Estimate the sender utilization under the delayed ACKs scenario.

Problem 2.11
Calculate the total time required for transferring a 1-MB file from a server to a client in the
following cases, assuming an RTT of 100 ms, a segment size of 1 KB, and an initial 2×RTT of
“handshaking” (initiated by the client) before data is sent. Assume error-free transmission.
(a) The bottleneck bandwidth is 1.5 Mbps, and data packets can be sent continuously (i.e.,
without waiting for ACKs)
(b) The bottleneck bandwidth is 1.5 Mbps, but Stop-and-wait ARQ is employed
Chapter 2 • Transport Control Protocol (TCP) 47

(c) The bandwidth is infinite, meaning that we take transmission time to be zero, and
Go-back-20 is employed
(d) The bandwidth is infinite, and TCP Tahoe is employed
 Chapter 3
Traffic and User Models

Contents
3.1 Introduction
3.1.1 x

3.1 Introduction 3.1.2 x

3.1.3 x

3.2 Source Modeling and Traffic

Characterization
3.2.1 x
People needs determine the system requirements. 3.2.2 x
3.2.3
In some situations it is necessary to consider human users as
3.3 Self-Similar Traffic
part of an end-to-end system, treating them as active
3.3.1 x
participants, rather than passive receivers of information. For 3.3.2 x
instance, people have thresholds of boredom, and finite 3.3.3 x
3.3.4 x
reaction times. A specification of the user’s perceptions is thus
3.4 Standards of Information Quality
required, as it is the user that ultimately defines whether the
3.4.1 x
result has the right quality level. 3.4.2
3.4.3

3.5 User Models

A traffic model summarizes the expected “typical” behavior of 3.5.1
3.5.2
a source or an aggregate of sources. Of course, this is not 3.5.3
necessarily the ultimate source of the network traffic. The
3.6 x
model may consider an abstraction by “cutting” a network link 3.5.1 x
or a set of link at any point in the network and considering the 3.5.2 x
3.5.3 x
aggregate “upstream” system as the source(s).
3.7 Summary and Bibliographical Notes
Traffic models fall into two broad categories. Some models are
Problems
obtained by detailed traffic measurements of thousands or
millions of traffic flows crossing the physical link(s) over days
or years. Others are chosen because they are amenable to mathematical analysis. Unfortunately,
only a few models are both empirically obtained and mathematically tractable.
Two key traffic characteristics are:
• Message arrival rate
• Message servicing time
Message (packet) arrival rate specifies the average number of packets generated by a given source
per unit of time. Message servicing time specifies the average duration of servicing for messages

48
Chapter 3 • Traffic and User Models 49

of a given source at a given server (intermediary). Within the network, packet servicing time
comprises not much more than inspection for correct forwarding plus the transmission time,
which is directly proportional to the packet length.
In the analysis below we will almost always assume that the traffic source is infinite, since an
infinite source is easier to describe mathematically. For a finite source, the arrival rate is affected
by the number of messages already sent; indeed, if all messages are already sent, the arrival rate
drops to zero. If the source sends finite but large number of messages, we assume an infinite
source to simplify the analysis.
Traffic models commonly assume that packets arrive as a Poisson process, that is, the interarrival
time between calls is drawn from an exponential distribution.
Packet servicing times have traditionally been modeled as drawn from an exponential
distribution. That is, the probability that the servicing lasts longer than a given length x decreases
exponentially with x. However, recent studies have shown servicing times to be heavy-tailed.
Intuitively, this means that many packets are very long. More precisely, if Tp represents the
packet servicing time, and c(t) is defined to be a slowly varying function of t when t is large, the
probability that the packet is serviced longer than t is given by:
P(T > t) = c(t)⋅t−α as t→∞, 1 < α < 2
As Figure 3-1 shows, a heavy-tailed distribution has a significantly higher probability mass at
large values of t than an exponential function.

3. NEWS
When Is a "Little in the Middle" OK? The Internet's End-to-End Principle Faces More Debate
Gregory Goth
The recent attempt by VeriSign to launch their SiteFinder search engine has renewed interest in
the ongoing debate about Internet governance.
http://dsonline.computer.org/0403/f/o3002a.htm

Multimedia application bandwidth requirements range from G.729 8Kbps speech codec and
H.263 64Kbps video codec to 19.2 Mbps for MPEG2, P, 4:2:0 (US standard) based
videoconferencing and 63Mbps SXGA 3D computer games [DuVal & Siep 2000]. Applications
may also have periodic traffic for real-time applications, aperiodic traffic for web browsing
clients, aperiodic traffic with maximum response times for interactive devices like the mouse and
keyboard, and non-real time traffic for file transfers. Thus we see that the range of bandwidth and
timeliness requirements for multimedia applications is large and diverse.

Table 3-1: Characteristics of traffic for some common sources/forms of information.

Source Traffic type Arrival rate/Service time Size or Rate
Voice CBR Deterministic/ Deterministic 64 Kbps
Video CBR Deterministic/ Deterministic 64 Kbps, 1.5 Mbps
Ivan Marsic • Rutgers University 50

VBR Deterministic/Random Mean 6 Mbps, peak 24 Mbps

ASCII Random/Random 2 KB/page
Text
Fax Random/ Deterministic 50 KB/page
600 dots/in, 256
Random/ Deterministic 33.5 MB
colors, 8.5 × 11 in
Picture
70 dots/in, b/w,
Random/ Deterministic 0.5 MB
8.5 × 11 in

Table 3-1 presents some characteristics about the traffic generated by common forms of
information. Notice that the bit streams generated by a video signal can vary greatly depending on
the compression scheme used. When a page of text is encoded as a string of ASCII characters, it
produces a 2-Kbyte string; when that page is digitized into pixels and compressed as in facsimile,
it produces a 50-KB string. A high-quality digitization of color pictures (similar quality to a good
color laser printer) generates a 33.5-MB string; a low-quality digitization of a black-and-white
picture generates only a 0.5-MB string.
We classify all traffic into three types. A user application can generate a constant bit rate (CBR)
stream, a variable bit rate (VBR) stream, or a sequence of messages with different temporal
characteristics. We briefly describe each type of traffic, and then consider some examples.

Constant Bit Rate (CBR)

To transmit a voice signal, the telephone network equipment first converts it into a stream of bits
with constant rate of 64 Kbps. Some video-compression standards convert a video signal into a
bit stream with a constant bit rate (CBR). For instance, MPEG-1 is a standard for compressing
video into a constant bit rate stream. The rate of the compressed bit stream depends on the
parameters selected for the compression algorithm, such as the size of the video window, the
number of frames per second, and the number of quantization levels. MPEG-1 produces a poor
quality video at 1.15 Mbps and a good quality at 3 Mbps.
Voice signals have a rate that ranges from about 4 Kbps when heavily compressed and low
quality to 64 Kbps. Audio signals range in rate from 8 Kbps to about 1.3 Mbps for CD quality.

Variable Bit Rate (VBR)

Some signal-compression techniques convert a signal into a bit stream that has variable bit rate
(VBR). For instance, MPEG-2 is a family of standards for such variable bit rate compression of
video signals. The bit rate is larger when the scenes of the compressed movies are fast moving
than when they are slow moving. Direct Broadcast Satellite (DBS) uses MPEG-2 with an average
rate of 4 Mbps.
To specify the characteristics of a VBR stream, the network engineer specifies the average bit rate
and a statistical description of the fluctuations of that bit rate. More about such descriptions will
be said below.
Chapter 3 • Traffic and User Models 51

Messages
Many user applications are implemented as processes that exchange messages over a network. An
example is Web browsing, where the user sends requests to a web server for Web pages with
embedded multimedia information and the server replies with the requested items. The message
traffic can have a wide range of characteristics. Some applications, such as email, generate
isolated messages. Other applications, such as distributed computation, generate long streams of
messages. The rate of messages can vary greatly across applications and devices.
To describe the traffic characteristics of a message-generating application, the network engineer
may specify the average traffic rate and a statistical description of the fluctuations of that rate, in
a way similar to the case of a VBR specification.

See definition of fidelity in:

B. Noble, “System support for mobile, adaptive applications,” IEEE Personal Communications,
7(1), pp.44-49, February 2000.
E. de Lara, R. Kumar, D. S. Wallach, and W. Zwaenepoel, “Collaboration and Multimedia
Authoring on Mobile Devices,” Proc. First Int’l Conf. Mobile Systems, Applications, and
Services (MobiSys 2003), San Francisco, CA, pp. 287-301, May 2003.

In any scenario where information is communicated, two key aspects of information are fidelity
and timeliness. Higher fidelity implies greater quantity of information, thus requiring more
resources. The system resources may be constrained, so it may not be possible to transmit, store,
and visualize at a particular fidelity. If memory and display are seen only as steps on
information’s way to a human consumer, then they are part of the communication channel. The
user could experience pieces of information at high fidelity, sequentially, one at a time, but this
requires time and, moreover, it requires the user to assemble in his or her mind the pieces of the
puzzle to experience the whole. Some information must be experienced within particular
temporal and or spatial (structural?) constraints to be meaningful. For example, it is probably
impossible to experience music one note at a time with considerable gaps in between. Or, a
picture cannot be experienced one pixel at a time. Therefore, the user has to trade fidelity for
temporal or spatial capacity of the communication channel.
Information loss may sometimes be tolerable; e.g., if messages contain voice or video data, most
of the time the receiver can tolerate some level of loss.
Shannon had to introduce fidelity in order to make problem tractable [Shannon & Weaver 1949].
Information can be characterized by fidelity ~ info content (entropy). The effect of a channel can
be characterized as deteriorating the information’s fidelity and increasing the latency:
fidelityIN + latencyIN →()_____)→ fidelityOUT + latencyOUT
Wireless channels in particular suffer from limitations reviewed in Volume 2. Increasing the
channel capacity to reduce latency is usually not feasible—either it is not physically possible or it
is too costly.
Ivan Marsic • Rutgers University 52

Information qualities can be considered in many dimensions. We group them in two opposing
ones:
• Those that tend to increase the information content
• Delay and its statistical characteristics

The computing system has its limitations as well. If we assume finite buffer length, then in
addition to delay problem, there is a random loss problem. This further affects the fidelity.
Fidelity has different aspects, such as:
• Spatial (sampling frequency in space and quantization – see Brown&Ballard CV book)
• Temporal (sampling frequency in time)
• Structural (topologic, geometric, …)
Delay or latency may also be characterized with more parameters than just instantaneous value,
such as the amount of variability of delay, also called delay jitter. In real life both fidelity and
latency matter and there are thresholds for each, below which information becomes useless. The
system is forced to manipulate the fidelity in order to meet the latency constraints. A key question
is, how faithful should signal be in order to be quite satisfactory without being too costly? In
order arrive at a right tradeoff between the two, the system must know:
1. Current channel quality parameters, e.g., capacity, which affect fidelity and latency
2. User’s tolerances for fidelity and latency
The former determines what can be done, i.e., what fidelity/latency can be achieved with the
channel at hand, and the latter determines how to do it, i.e., what matters more or less to the user
at hand. Of course, both channel quality and user preferences change with time.
Example with telephone: sound quality is reduced to meet the delay constraints, as well as reduce
the costs.
Targeted reduction of information fidelity in a controlled manner helps meet the latency
constraints and averts random loss of information. Common techniques for reducing information
fidelity include:
• Lossless and lossy data compression
• Packet dropping (e.g., RED congestion-avoidance mechanism in TCP/IP)
• …?
The above presentation is a simplification in order to introduce the problem. Note that there are
many other relevant parameters, such as security, etc., that characterize the communicated
information and will be considered in detail below.

Organizational concerns:
• Local traffic that originates at or terminates on nodes within an organization (also called
autonomous system, AS)
Chapter 3 • Traffic and User Models 53

• Transit traffic that passes through an AS

3.2 Source Modeling and Traffic

Characterization
Different media sources have different traffic characteristics.
Primitive traffic characterization is given by the source entropy (Chapter 1).
See also MobiCom’04, p. 174: flow characterization
For example, image transport is often modeled as a two state on-off process. While on, a source
transmits at a uniform rate. For more complex media sources such as variable bit rate (VBR)
video coding algorithms, more states are often used to model the video source. The state
transitions are often assumed Markovian, but it is well known that non-Markovian state
transitions could also be well represented by one with more Markovian states. Therefore, we shall
adopt a general Markovian structure, for which a deterministic traffic rate is assigned for each
state. This is the well-known Markovian fluid flow model [Anick et al. 1982], where larger
communication entities, such as an image or a video frame, is in a sense “fluidized” into a fairly
smooth flow of very small information entities called cells. Under this fluid assumption, let Xi(t)
be the rate of cell emission for a connection i at the time t, for which this rate is determined by the
state of the source at time t.
The most common modeling context is queuing, where traffic is offered to a queue or a network
of queues and various performance measures are calculated.
Simple traffic consists of single arrivals of discrete entities (packets, frames, etc.). It can be
mathematically described as a point process, consisting of a sequence of arrival instants T1, T2,
…, Tn, … measured from the origin 0; by convention, T0 = 0. There are two additional equivalent
descriptions of point processes: counting processes and interarrival time processes. A counting
process {N (t )}t∞=0 is a continuous-time, non-negative integer-valued stochastic process, where
N(t) = max{n : Tn ≤ t} is the number of (traffic) arrivals in the interval (0, t]. An interarrival time
process is a non-negative random sequence { An }∞n =1 , where An = Tn − Tn−1 is the length of the time
interval separating the n-th arrival from the previous one. The equivalence of these descriptions
follows from the equality of events:

{N (t ) = n} = {Tn ≤ t < Tn +1} = ⎧⎨∑ Ak ≤ t < ∑ Ak ⎫⎬

n n +1

⎩k =1 k =1 ⎭

since Tn = ∑ k =1 Ak . Unless otherwise stated, we assume throughout that {An} is a stationary

n

sequence and that the common variance of the An is finite.

Ivan Marsic • Rutgers University 54

3.3 Self-Similar Traffic

3.4 Standards of Information Quality

In text, the entropy per character depends on how many values the character can assume. Since a
continuous signal can assume an infinite number of different value at a sample point, we are led
to assume that a continuous signal must have an entropy of an infinite number of bits per sample.
This would be true if we required absolutely accurate reproduction of the continuous signal.
However, signals are transmitted to be heard, seen, or sensed. Only a certain degree of fidelity of
reproduction is required. Thus, in dealing with the samples which specify continuous signals,
Shannon introduces fidelity criterion. To reproduce the signal in a way meeting the fidelity
criterion requires only a finite number of binary digits per sample per second, and hence we say
that, within the accuracy imposed by a particular fidelity criterion, the entropy of a continuous
source has a particular value in bits per sample or bits per second.
Standards of information quality help perform ordering of information bits by importance (to the
user).

Man best handles information if encoded to his abilities. (Pierce, p.234)

For video, expectations are low

For voice, ear is very sensitive to jitter and latencies, and loss/flicker

In some cases, we can apply common sense in deciding the user’s servicing quality needs. For
example, in applications such as voice and video, users are somewhat tolerable of information
loss, but very sensitive to delays. Conversely, in file transfer or electronic mail applications, the
users are expected to be intolerable to loss and tolerable to delays. Finally, there are applications
where both delay and loss can be aggravating to the user, such as in the case of interactive
graphics or interactive computing applications.
Human users are not the only recipients of information. For example, network management
system exchanges signaling packets which may never reach human user. These packets normally
receive preferential treatment at the intermediaries (routers), and this is particularly required
during times of congestion or failure.
It is particularly important during periods of congestion that traffic flows with different
requirements be differentiated for servicing treatments. For example, a router might transmit
higher-priority packets ahead of lower-priority packets in the same queue. Or a router may
maintain different queues for different packet priorities and provide preferential treatment to the
higher priority queues.
Chapter 3 • Traffic and User Models 55

User Studies
User studies uncover the degree of service degradation that the user is capable of tolerating
without significant impact on task-performance efficiency. A user may be willing to tolerate
inadequate QoS, but that does not assure that he or she will be able to perform the task
adequately.
Psychophysical and cognitive studies reveal population levels, not individual differences. Context
also plays a significant role in user’s performance.
The human senses seem to perceive the world in a roughly logarithmic way. The eye, for
example, cannot distinguish more than six degrees of brightness; but the actual range of physical
brightness covered by those six degrees is a factor of 2.5 × 2.5 × 2.5 × 2.5 × 2.5 × 2.5, or about
100. A scale of a hundred steps is too fine for human perception. The ear, too, perceives
approximately logarithmically. The physical intensity of sound, in terms of energy carried
through the air, varies by a factor of a trillion (1012) from the barely audible to the threshold of
pain; but because neither the ear nor the brain can cope with so immense a gamut, they convert
the unimaginable multiplicative factors into comprehensible additive scale. The ear, in other
words, relays the physical intensity of the sound as logarithmic ratios of loudness. Thus a normal
conversation may seem three times as loud as a whisper, whereas its measured intensity is
actually 1,000 or 103 times greater.
Fechner’s law in psychophysics stipulates that the magnitude of sensation—brightness, warmth,
weight, electrical shock, any sensation at all—is proportional to the logarithm of the intensity of
the stimulus, measured as a multiple of the smallest perceptible stimulus. Notice that this way the
stimulus is characterized by a pure number, instead of a number endowed with units, like seven
pounds, or five volts, or 20 degrees Celsius. By removing the dependence on specific units, we
have a general law that applies to stimuli of different kinds. Beginning in the 1950s, serious
departures from Fechner’s law began to be reported, and today it is regarded more as a historical
curiosity than as a rigorous rule. But even so, it remains important approximation …
Define j.n.d. (just noticeable difference)

For the voice or video application to be of an acceptable quality, the network must transmit the bit
stream with a short delay and corrupt at most a small fraction of the bits (i.e., the BER must be
small). The maximum acceptable BER is about 10−4 for audio and video transmission, in the
absence of compression. When an audio and video signal is compressed, however, an error in the
compressed signal will cause a sequence of errors in the uncompressed signal. Therefore the
tolerable BER is much less than 10−4 for transmission of compressed signals.
The end-to-end delay should be less than 200 ms for real-time video and voice conversations,
since people find larger delay uncomfortable. That delay can be a few seconds for non-real-time
interactive applications such as interactive video and information on demand. The delay is not
critical for non-interactive applications such as distribution of video or audio programs.
Typical acceptable values of delays are a few seconds for interactive services, and many seconds
for non-interactive services such as email. The acceptable fraction of messages that can be
corrupted ranges from 10−8 for data transmissions to much larger values for noncritical
applications such as junk mail distribution.
Ivan Marsic • Rutgers University 56

Among applications that exchange sequences of messages, we can distinguish those applications
that expect the messages to reach the destination in the correct order and those that do not care
about the order.

3.5 User Models

User Preferences

User Utility Functions

3.5.1 Example: Augmented Reality

{PROBLEM STATEMENT}
Inaccuracy and delays on the alignment of computer graphics and the real world are one of the
greatest constrains in registration for augmented reality. Even with current tracking techniques it
is still necessary to use software to minimize misalignments of virtual and real objects. Our
augmented reality application represents special characteristics that can be used to implement
better registration methods using an adaptive user interface and possibly predictive tracking.

{CONSTRAINS}
AR registration systems are constrained by perception issues in the human vision system.
Between the human factors we should consider the acceptable frame rates; it has been found for
virtual reality that is 20 fps with periodical variations of 40% [Watson 97] and maximum delays
of 10 milliseconds [Azuma 95]. The perception of misalignment by the human eye is also
restrictive. Azuma found with experiments that it is about 2-3 mm of error at the length of the
arm (with an arm length of ~ 70 cm) is acceptable [Azuma 95]. However the human eye can
detect even smaller differences as of one minute of arc [Doenges 85]. Current commercially
available head mounted displays used for AR cannot provide more than 800 by 600 pixels, this
resolution makes impossible to provide an accuracy one minute of arc.

{SOURCES OF ERROR}
Errors can be classified as static and dynamic. Static errors are intrinsic on the registration system
and are present even if there is no movement of the head or tracked features.
Most important static errors are optical distortions and mechanical misalignments on the HMD,
errors in the tracking devices (magnetic, differential, optical trackers), incorrect viewing
Chapter 3 • Traffic and User Models 57

parameters as field of view, tracker-to-eye position and orientation. If vision is used to track, the
optical distortion of the camera also has to be added to the error model.
Dynamic errors are caused by delays on the registration system. If a network is used, dynamic
changes of throughput and latencies become an additional source of error.

{OUR AUGMENTED REALITY SYSTEM}

Although research projects have addressed some solutions for registrations involving predictive
tracking [Azuma 95] [Chai 99] we can extended the research because our system has special
characteristics (many of these approaches). It is necessary to have accurate registration most of
its usage however it is created for task where there is limited movement of the user, as in a
repairing task. Delays should be added to the model if processing is performed on a different
machine. Also there is the necessity of having a user interface that can adapt to registration
changes or according to the task being developed, for example removing or adding information
only when necessary to avoid occluding the view of the AR user.

{PROPOSED SOLUTION}
The proposed solution is based on two approaches: predictive registration and adaptive user
interfaces. Predictive registration allows saving processing time, or in case of a networked system
it can provide better registration in presence of latency and jitter. With predictive registration
delays as long as 80ms can be tolerated [Azuma 94]. A statistical model of Kalman filters and
extended Kalman filters can be used to optimize the response of the system when multiple
tracking inputs as video and inertial trackers are used [Chai 99].
Adaptive user interfaces can be used to improve the view of the augmented world. This approach
essentially takes information form the tracking system to determine how the graphics can be
gracefully degraded to match the real world. Estimation of the errors was used before to get and
approximated shape of the 3D objects being displayed [MacIntyre 00]. Also some user interface
techniques based on heuristics where used to switch different representations of the augmented
world [Höllerer 01]. The first technique has a strict model to get an approximated AR view but it
degrades the quality of the graphics, specially affecting 3D models. The second technique
degrades more gracefully but the heuristics used are not effective for all the AR systems. A
combination would be desirable.

{TRACKING PIPELINE}
This is a primary description of our current registration pipeline

Image Processing
[Frame capture] => [Image threshold] => [Subsampling] => [Features Finding] =>
[Image undistortion] => [3D Tracking information] => [Notify Display]
Ivan Marsic • Rutgers University 58

Video Display
[Get processed frame] => [Frame rendering in a buffer] => [3D graphics added to Buffer]
=> [Double buffering] => [Display]

These processes are executed by two separated threads for better performance and resource usage.

{REFERENCES}
[Watson 97]
Watson, B., Spaulding, V., Walker, N., Ribarsky W., “Evaluation of the effects of frame time
variation on VR task performance,” IEEE VRAIS'96, 1996, pp. 38-52.
http://www.cs.northwestern.edu/~watsonb/school/docs/vr97.pdf

[Azuma 95]
Azuma, Ronald, “Predictive Tracking for Augmented Reality,” UNC Chapel Hill Dept. of
Computer Science Technical Report TR95-007 (February 1995), 262 pages.
http://www.cs.unc.edu/~azuma/dissertation.pdf

[Doenges 85]
Doenges, Peter K, “Overview of Computer Image Generation in Visual Simulation,” SIGGRAPH
'85 Course Notes #14 on High Performance Image Generation Systems (San Francisco, CA, 22
July 1985).
(Not available on the web, I read about it on Azuma’s paper)

[Chai 99]
L. Chai, K. Nguyen, W. Hoff, and T. Vincent, “An adaptive estimator for registration in
augmented reality,” Proc. of 2nd IEEE/ACM Int'l Workshop on Augmented Reality, San
Franscisco, Oct. 20-21, 1999.
http://egweb.mines.edu/whoff/projects/augmented/iwar1999.pdf

[Azuma 94]
Azuma, Ronald and Gary Bishop, “Improving Static and Dynamic Registration in an Optical See-
Through HMD,” Proceedings of SIGGRAPH '94 (Orlando, FL, 24-29 July 1994), Computer
Graphics, Annual Conference Series, 1994, 197-204.
http://www.cs.unc.edu/~azuma/sig94paper.pdf
Chapter 3 • Traffic and User Models 59

[MacIntyre 00]
MacIntyre, Blair; Coelho, Enylton; Julier, Simon. “Estimating and Adapting to Registration
Errors in Augmented Reality Systems,” In IEEE Virtual Reality Conference 2002 (VR 2002), pp.
73-80, Orlando, Florida, March 24-28, 2002.
http://www.cc.gatech.edu/people/home/machado/papers/vr2002.pdf

[Hollerer 01]
Tobias Höllerer, Drexel Hallaway, Navdeep Tinna, Steven Feiner, “Steps toward accommodating
variable position tracking accuracy in a mobile augmented reality system,” In Proc. 2nd Int.
Workshop on Artificial Intelligence in Mobile Systems (AIMS '01), pages 31-37, 2001.
http://monet.cs.columbia.edu/publications/hollerer-2001-aims.pdf

3.5.2 Performance Metrics

Delay (the average time needed for a packet to travel from source to destination), statistics of
delay (variation, jitter), packet loss (fraction of packets lost, or delivered so late that they are
considered lost) during transmission, packet error rate (fraction of packets delivered in error);
Bounded delay packet delivery ratio (BDPDR): Ratio of packets forwarded between a mobile
node and an access point that are successfully delivered within some pre-specified delay
constraint. The delay measurement starts at the time the packet is initially queued for
transmission (at the access point for downstream traffic or at the originating node for upstream
traffic) and ends when it is delivered successfully at either the mobile node destination
(downstream traffic) or AP (upstream traffic).

DiffServ Traffic Classes

DiffServ (Differentiated Services) is an IETF model for QoS provisioning. There are different
DiffServ proposals, and some simply divide traffic types into two classes. The rationale behind
this approach is that, given the complexities of the best effort traffic, it makes sense to add new
complexity in small increments.
Suppose that we have enhanced the best-effort service model by adding just one new class, which
we call “premium.”
Assuming that packets have been marked in some way, we need to specify the router behavior on
encountering a packet with different markings. This can be done in different ways and IETF is
standardizing a set of router behaviors to be applied to marked packets. These are called “per-hop
behaviors” (PHBs), a term indicating that they define the behavior of individual routers rather
than end-to-end services.
One PHB is “expedited forwarding” (EF), which states that the packets marked as EF should be
forwarded by the router with minimal delay and loss. Of course, this is only possible if the arrival
Ivan Marsic • Rutgers University 60

rate of EF packets at the router is always less than the rate at which the router can forward EF
packets.
Another PHB is known as “assumed forwarding” (AF).

3.5.3 Quality of Service

QoS, Keshav p.154
Cite Ray Chauduhuri’s W-ATM paper {cited in Goodman}

Quality of Service (QoS)

Performance measures
Throughput
Latency
Real-time guarantees
Other factors
Reliability
Availability
Security
Synchronization of data streams
Etc.

3.6 Summary and Bibliographical Notes

The material presented in this chapter requires basic understanding of probability and random
processes. [Yates & Goodman 2004] provides an excellent introduction and [Papoulis & Pillai
2001] is a more advanced and comprehensive text.

For video, expectations are low

For voice, ear is very sensitive to jitter and latencies, and loss/flicker
As an important research topic: show that multihop can or cannot support multiple streams of
voice.
Chapter 3 • Traffic and User Models 61

Problems

Problem 3.1

Problem 3.2
Consider an internet telephony session, where both hosts use pulse code modulation to encode
speech and sequence numbers to label their packets. Assume that the user at host A starts
speaking at time zero, the host sends a packet every 20 ms, and the packets arrive at host B in the
order shown in the table below. If B uses fixed playout delay of q = 210 ms, write down the
playout times of the packets.
Packet sequence number Arrival time ri [ms] Playout time pi [ms]
#1 195
#2 245
#3 270
#4 295
#6 300
#5 310
#7 340
#8 380
#9 385
#10 405

Problem 3.3
Consider an internet telephony session over a network where the observed propagation delays
vary between 50–200 ms. Assume that the session starts at time zero and both hosts use pulse
code modulation to encode speech, where voice packets of 160 bytes are sent every 20 ms. Also,
both hosts use a fixed playout delay of q = 150 ms.
(a) Write down the playout times of the packets received at one of the hosts as shown in the
table below.
(b) What size of memory buffer is required at the destination to hold the packets for which
the playout is delayed?
Packet sequence number Arrival time ri [ms] Playout time pi [ms]
#1 95
#2 145
#3 170
#4 135
#6 160
#5 275
#7 280
Ivan Marsic • Rutgers University 62

#8 220
#9 285
#10 305

Problem 3.4
Consider the same internet telephony session as in Problem 3.2, but this time the hosts use
adaptive playout delay. Assume that the first packet of a new talk spurt is labeled k, the current
estimate of the average delay is dk = 90 ms, the average deviation of the delay is vk = 15 ms, and
the constants u = 0.01 and K = 4.
The table below shows how the packets are received at the host B. Write down their playout
times, keeping in mind that the receiver must detect the start of a new talk spurt.
Packet Timestamp Arrival time Playout time Average delay di Average
seq. # ti [ms] ri [ms] pi [ms] [ms] deviation vi
k 400 480
k+1 420 510
k+2 440 570
k+3 460 600
k+4 480 605
k+7 540 645
k+6 520 650
k+8 560 680
k+9 580 690
k+10 620 695
k+11 640 705

Problem 3.5
 Chapter 4
Queuing Delay Models

Contents
4.1 Introduction
4.1.1 Server Model

4.1 Introduction 4.1.2 Little’s Law

4.1.3

4.2 M / M / 1 Queuing System

4.2.1
4.2.2 M / M / 1 / m Queuing System
Part of the delay for a network packet or a computing task is 4.2.3
due to waiting in line before being serviced. Queuing models 4.3 M / G / 1 Queuing System
are used as a prediction tool to estimate this waiting time. 4.3.1 x
Generally, packets and tasks in a networked system experience 4.3.2 x
4.3.3 x
these types of delays: queuing + processing + transmission + 4.3.4 x
propagation 4.4 Networks of Queues
Two types of servers: 4.4.1 x
4.4.2
• Computation (queuing delays while waiting for 4.4.3

processing) 4.5 x
4.5.1
• Communication (queuing delays while waiting for 4.5.2
4.5.3
transmission)
4.6 Summary and Bibliographical Notes
Problems

4.1.1 Server Model

General Server
A general service model is shown in Figure 4-1. Customers arrive in the system at a certain rate.
It is helpful if the arrival times happened to be random and independent of the previous arrivals,
because such systems can be well modeled. The server services customers in a certain order, the
simplest being their order of arrival, also called first-come-first-served (FCFS). Every physical
processing takes time, so a customer i takes a certain amount of time to service, the service time
denoted as Xi.

63
Ivan Marsic • Rutgers University 64

Interarrival
time = A2 − A1
Server

C1 C2 C3 Ci
Input
sequence Time
Arriving System Departing
customers customers A1 A2 A3 Ai

C1 C2 C3 Ci
Output
in out sequence

Service X2 X3 Xi
time = X1
Waiting
time = W3

Figure 4-1: General service delay model: customers are delayed in a system for their own
service time plus a possible waiting time. Customer 3 has to wait in line because a previous
customer is being serviced at customer 3’s arrival time.

Most commonly used performance measures are: (1) the average number of customers in the
system; and, (2) average delay per customer. A successful method for calculating these
parameters is based on the use of a queuing model. Figure 4-2 shows a simple example of a
queuing model, where the system is represented by a single-server queue. The queuing time is the
time that a customer waits before it enters the service. Figure 4-3 illustrates queuing system
parameters on an example of a bank office with a single teller.

Why Queuing Happens?

Queuing delay results from the server’s inability to process the customers at the rate at which they
are arriving. When a customer arrives at a busy server, it enters a waiting line (queue) and waits
on its turn for processing. The critical assumption here is the following:
Average arrival rate ≤ Maximum service rate
Otherwise, the queue length would grow unlimited and the system would become meaningless
since some customers would have to wait infinite amount of time to be serviced. A corollary of
this requirement is that queuing is an artifact of irregular customer arrival patterns, sometimes
being too many, sometimes very few. Customers arriving in groups create queues. Had they been

System

Queue Server
Departing
Arriving packets Queued packets Serviced packet packets

Source
Source

Arrival rate Service rate

= λ packets per second = μ packets per second

Figure 4-2: Simple queuing system with a single server.

Chapter 4 • Queuing Delay Models 65

Total delay of customer i = Waiting + Service time

Ti = W i + Xi

Server
Service rate μ
Arrival rate λ
customers
customers unit of time
NQ
unit of time Customers in queue
Customer
in service
N
Customers in system

Figure 4-3: Illustration of queuing system parameters parameters.

arriving “individually” (well spaced), allowing the server enough time to process the previous
one, there would be no queuing. The arrival pattern where the actual arrival rate is equal to the
average one would incur no queuing delays on any customer.
This is illustrated in Figure 4-4 where we consider a bank teller that can service five customers
customers
per hour, μ = 5 , on average. This means, serving one customer takes 12 minutes, on
hour
average. Assume that for a stretch of time all arriving customers take 12 minutes to be served and
that three customers arrive as shown in the figure. Although the server capacity is greater than the
arrival rate, the second and third customers still need to wait in line before being served, because
their arrivals are too closely spaced. If the customers arrived spaced according to their departure
times at the same server, there would be no queuing delay for any customer. However, if this
sequence arrived at a server that can service only four customers per hour, again there would be
queuing delays. Thus, having a server with service rate greater than the arrival rate is no
guarantee that there will be no queuing delays. In summary, queuing results because packet
arrivals cannot be preplanned and provisioned for—it is too costly or physically impossible to
support peak arrival rates.
Ivan Marsic • Rutgers University 66

Arrival times sequence Departure times sequence

C3
C2 C1 C2 C3
C1 Server

:17

:41
:00
:05

10 9

:00

:00

:29

:00
:13
:0

10

10
10
10
10

11

10

10

11
Time Time

Figure 4-4: Illustration of how queues get formed. The server can serve 5 customers per
hour and only 3 customers arrive during an hour period. Although the server capacity is
greater than the arrival rate, some customers may still need to wait before being served,
because their arrivals are too closely spaced.

Note also that in the steady state, the average departure rate equals the average arrival rate. Server
utilization = (arrival rate / max. service rate)

Communication Channel
Queuing delay is the time it takes to transmit the packets that arrived earlier at the network
interface. Packet’s service time is its transmission time, which is equal to L/C, where L is the
packet length and C is the server capacity. In case of packet transmission, “server capacity” is the
outgoing channel capacity. The average queuing time is typically a few transmission times,
depending on the load of the network.
→()_____)→ delay ~ capacity −1
Another parameter that affects delay is error rate—errors result in retransmissions, which
significantly impact the delay. Reliable vs. unreliable (if error correction is employed + Gaussian
channel)
We study what are the sources of delay and try to estimate its amount. In a communication
system, main delay contributors are:
• Processing (e.g., conversion of a stream of bytes to packets or packetization,
compression/fidelity reduction, encryption, switching at routers, etc.)
• Queuing, due to irregular packet arrivals, sometimes too many, sometimes just few
• Transmission, converting the digital information into analog signals that travel the
medium
• Propagation, signals can travel at most at the speed of light, which is finite
• Errors or loss in transmission or various other causes (e.g., insufficient buffer space in
routers, recall Figure 2-7 for TCP), resulting in retransmission
Errors result in retransmission. For most links error rates are negligible, but for multiaccess links,
particularly wireless links, they are significant.
Processing may also need to be considered to form a queue if this time is not negligible.
Chapter 4 • Queuing Delay Models 67

Give example of how delay and capacity are related, see Figure from Peterson & Davie, or from
[Jeremiah Hayes 1984].

Notation
Some of the symbols that will be used in this chapter are defined as follows (see also Figure 4-3):
A(t) Counting process that represents the total number of tasks/customers that arrived from 0 to
time t, i.e., A(0) = 0, and for s < t, A(t) − A(s) equals the number of arrivals in the time
interval (s, t]
λ Arrival rate, i.e., the average number of arrivals per unit of time, in steady state
N(t) Number of tasks/customers in the system at time t
N Average number of tasks/customers in the system (this includes the tasks in the queue and
the tasks currently in service) in steady state
NQ Average number of tasks/customers waiting in queue (but not currently in service) in
steady state
μ Service rate of the server (in customers per unit time) at which the server operates when
busy
Xi Service time of the ith arrival (depends on the particular server’s service rate μ and can be
different for different servers)
Ti Total time the ith arrival spends in the system (includes waiting in queue plus service time)
T Average delay per task/customer (includes the time waiting in queue and the service time)
in steady state
W Average queuing delay per task/customer (not including the service time) in steady state
ρ Rate of server capacity utilization (the fraction of time that the server is busy servicing a
task, as opposed to idly waiting)

4.1.2 Little’s Law

Imagine that you perform the following experiment. You are frequently visiting your local bank
office and you always do the following:
1. As you walk into the bank, you count how many customers are in the room, including
those waiting in the line and those currently being served. Let us denote the average
count as N. You join the queue as the last person; there is no one behind you.
2. You will be waiting W time, on average, and then it will take X time, on average, for you
to complete your job. The expected amount of time that has elapsed since you joined the
queue until you are ready to leave is T = W + X. During this time T new customers will
arrive at an arrival rate λ.
Ivan Marsic • Rutgers University 68

3. At the instant you are about to leave, you look over your shoulder at the customers who
have arrived after you. These are all new customers that have arrived while you were
waiting or being served. You will count, on average, λ ⋅ T customers in the system.
If you compare the average number of customers you counted at your arrival time (N) and the
average number of customers you counted at your departure time (λ ⋅ T), you will find that they
are equal. This is called Little’s Law and it relates the average number of tasks in the system, the
average arrival rate of new tasks, and the average delay per task:
Average number of tasks in the system = Arrival rate × Average delay per task
N=λ⋅T (4.1a)
I will not present a formal proof of this result, but the reader should glean some intuition from the
above experiment. For example, if customers arrive at the rate of 5 per minute and each spends 10
minutes in the system, Little’s Law tells us that there will be 50 customers in the system on
average.
The above observation experiment essentially states that the number of customers in the system,
on average, does not depend on the time when you observe it. A stochastic process is stationary
if all its statistical properties are invariant with respect to time.
Another version of Little’s Law is
NQ = λ ⋅ W (4.1b)
The argument is essentially the same, except that the customer looks over her shoulder as she
enters service, rather than when completing the service. A more formal discussion is available in
[Bertsekas & Gallagher 1992].
Little’s Law applies to any system in equilibrium, as long as nothing inside the system is creating
new tasks or destroying them. Of course, to reach an equilibrium state we have to assume that the
traffic source generates infinite number of tasks.
Using Little’s Law, given any two variables, we can determine the third one. However, in
practice it is not easy to get values that represent well the system under consideration. The reader
should keep in mind that N, T, NQ, and W are random variables; that is, they are not constant but
have probability distributions. One way to obtain those probability distributions is to observe the
system over a long period of time and acquire different statistics, much like traffic observers
taking tally of people or cars passing through a certain public spot. Another option is to make
certain assumptions about the statistical properties of the system. In the following, we will take
the second approach, by making assumptions about statistics of customer arrivals and service
times. From these statistics, we will be able to determine the expected values of other parameters
needed to apply Little’s Law.
Kendall’s notation for queuing models specifies six factors:
Arrival Process / Service Proc. / Num. Servers / Max. Occupancy / User Population / Scheduling Discipline
1. Arrival Process (first symbol) indicates the statistical nature of the arrival process. The
letter M is used to denote pure random arrivals or pure random service times. It stands for
Markovian, a reference to the memoryless property of the exponential distribution of
interarrival times. In other words, the arrival process is a Poisson process. Commonly
Chapter 4 • Queuing Delay Models 69

used letters are:

M – for exponential distribution of interarrival times
G – for general independent distribution of interarrival times
D – for deterministic (constant) interarrival times
2. Service Process (second symbol) indicates the nature of the probability distribution of the
service times. For example, M, G, and D stand for exponential, general, and deterministic
distributions, respectively. In all cases, successive interarrival times and service times are
assumed to be statistically independent of each other.
3. Number of Servers (third symbol) specifies the number of servers in the system.
4. Maximum Occupancy (fourth symbol) is a number that specifies the waiting room
capacity. Excess customers are blocked and not allowed into the system.
5. User Population (fifth symbol) is a number that specifies the total customer population
(the “universe” of customers)
6. Scheduling Discipline (sixth symbol) indicates how the arriving customers are scheduled
for service. Scheduling discipline is also called Service Discipline or Queuing Discipline.
Commonly used service disciplines are the following:
FCFS – first-come-first-served, also called first-in-first-out (FIFO), where the first
customer that arrives in the system is the first customer to be served
LCFS – last-come-first served (like a popup stack)
FIRO – first-in-random-out
Service disciplines will be covered in Chapter 5 below, where fair queuing (FQ) service
discipline will be introduced. Only the first three symbols are commonly used in specifying a
queuing model, although other symbols will be used sometimes below.

4.2 M / M / 1 Queuing System

A correct notation for the system we consider is M/M/1/∞/∞/FCFS. This system can hold
unlimited (infinite) number of customers, i.e., it has an unlimited waiting room size or the
maximum queue length; the total customer population is unlimited; and, the customers are served
in the FCFS order. It is common to omit the last three items and simply use M/M/1.
Figure 4-5 illustrates an M/M/1 queuing system, for which the process A(t), total number of
customers that arrived from 0 to time t, has a Poisson distribution. A Poisson process is generally
considered to be a good model for the aggregate traffic of a large number of similar and
independent customers. Then, A(0) = 0, and for s < t, A(t) − A(s) equals the number of arrivals in
the interval (s, t). The intervals between two arrivals (interarrival times) for a Poisson process are
independent of each other and exponentially distributed with parameter λ. If tn denotes the time of
the nth arrival, the interarrival intervals τn = tn+1 − tn have the probability distribution
P{τ n ≤ s} = 1 − e − λ⋅s , s≥0
Ivan Marsic • Rutgers University 70

Number of departures, B(t)

Number of arrivals, A(t) A(t)
N(t)
Cumulative

B(t)
T2
T1
Time
N(t)

δ Time

Figure 4-5: Example of birth and death processes. Top: Arrival and departure processes;
Bottom: Number of customers in the system.

It is important that we select the unit time period δ in Figure 4-5 small enough so that it is likely
that at most one customer will arrive during δ. In other words, δ should be so small that it is
unlikely that two or more customers will arrive during δ.
The process A(t) is a pure birth process because it monotonically increases by one at each arrival
event. So is the process B(t), the number of departures up until time t. The process N(t), the
number of customers in the system at time t, is a birth and death process because it sometimes
increases and at other times decreases. It increases by one at each arrival and decreases by one at
each completion of service. We say that N(t) represents the state of the system at time t. Notice
that the state of this particular system (a birth and death process) can either increases by one or
decreases by one—there are no other options. The intensity or rate at which the system state
increases is λ and the intensity at which the system state decreases is μ. This means that we can
represent the rate at which the system changes the state by the diagram in Figure 4-7.
Now suppose that the system has evolved to a steady-state condition. That means that the state of
the system is independent of the starting state. The sequence N(t) representing the number of
customers in the system at different times does not converge. This is a random process taking
unpredictable values. What does converge are the probabilities pn that at any time a certain
number of customers n will be observed in the system
lim P{N (t ) = n} = pn
t →∞
Chapter 4 • Queuing Delay Models 71

Room 0 Room n – 1 Room n Room n + 1

t(n+1 → n)

t(n → n+1)

⏐ t(n → n+1) − t(n+1 → n)⏐≤ 1

Figure 4-6: Intuition behind the balance principle for a birth and death process.

1 − λ⋅δ 1 − λ⋅δ − μ⋅δ 1 − λ⋅δ − μ⋅δ 1 − λ⋅δ − μ⋅δ 1 − λ⋅δ − μ⋅δ 1 − λ⋅δ − μ⋅δ

λ⋅δ λ⋅δ λ⋅δ λ⋅δ

0 1 2 n−1 n n+1
μ⋅δ μ⋅δ μ⋅δ μ⋅δ

Figure 4-7: Transition probability diagram for the number of customers in the system.

Note that during any time interval, the total number of transitions from state n to n + 1 can differ
from the total number of transitions from n + 1 to n by at most 1. Thus asymptotically, the
frequency of transitions from n to n + 1 is equal to the frequency of transitions from n + 1 to n.
This is called the balance principle. As an intuition, each state of this system can be imagined as
a room, with doors connecting the adjacent rooms. If you keep walking from one room to the
adjacent one and back, you can cross at most once more in one direction than in the other. In
other words, the difference between how many times you went from n + 1 to n vs. from n to n + 1
at any time can be no more than one.
Given the stationary probabilities and the arrival and service rates, from our rate-equality
principle we have the following detailed balance equations
pn ⋅ λ = pn+1 ⋅ μ, n = 0, 1, 2, … (4.2)
These equations simply state that the rate at which the process leaves state n equals the rate at
which it enters that state. The ratio ρ = λ/μ is called the utilization factor of the queuing system,
which is the long-run proportion of the time the server is busy. With this, we can rewrite the
detailed balance equations as
pn+1 = ρ ⋅ pn = ρ ² ⋅ pn−1 = … = ρ n+1 ⋅ p0 (4.3)
If ρ < 1 (service rate exceeds arrival rate), the probabilities pn are all positive and add up to unity,
so
∞ ∞ ∞

∑ p = ∑ρ ∑ρ
p0
1= n
⋅ p0 = p0 ⋅ n
= (4.4)
1− ρ
n
n=0 n=0 n=0

by using the well-known summation formula for the geometric series (see the derivation of Eq.
(1.7) in Section 1.3.1 above). Combining equations (4.3) and (4.4), we obtain the probability of
finding n customers in the system
pn = P{N(t) = n} = ρ n ⋅ (1 − ρ), n = 0, 1, 2, … (4.5)
Ivan Marsic • Rutgers University 72

The average number of customers in the system in steady state is N = lim E{N (t )} . Since (4.5) is
t →∞

the p.m.f. for a geometric random variable, meaning that N(t) has a geometric distribution,
checking a probability textbook for the expected value of geometric distribution quickly yields
ρ λ
N = lim E{N (t )} = = (4.6)
t →∞ 1− ρ μ −λ
It turns out that for an M/M/1 system, by knowing only the arrival rate λ and service rate μ, we
can determine the average number of customers in the system. From this, Little’s Law (4.1a)
gives the average delay per customer (waiting time in queue plus service time) as
N 1
T= = (4.7)
λ μ −λ
The average waiting time in the queue, W, is the average delay T less the average service time
1/μ, like so
1 1 1 ρ
W =T − = − =
μ μ −λ μ μ −λ

and by using the version (4.1b) of Little’s Law, we have N Q = λ ⋅ W = ρ 2 (1 − ρ ) .

4.2.1 M / M / 1 / m Queuing System

Now consider the M/M/1/m system which is the same as M/M/1 except that the system can be
occupied by up to m customers, which implies a finite waiting room or maximum queue length.
The customers arriving when the queue is full are blocked and not allowed into the system. We
∑
m
have pn = ρn ⋅ p0 for 0 ≤ n ≤ m; otherwise pn = 0. Using the relation n=0
pn = 1 we obtain

1 1− ρ
p0 = = , 0≤n≤m
∑ 1 − ρ m +1
m
n=0
ρn

From this, the steady-state occupancy probabilities are given by (cf. Eq. (4.5))
ρ n ⋅ (1 − ρ )
pn = , 0≤n≤m (4.8)
1 − ρ m+1

Assuming again that ρ < 1, the expected number of customers in the system is
m
1− ρ m
1− ρ m
ρ ⋅ (1 − ρ ) ∂ ⎛⎜ m n ⎞⎟
N = E{N (t )} = ∑n⋅ p
n=0
n = ⋅ ∑
1 − ρ m +1 n = 0
n ⋅ ρ n
=
1 − ρ m +1
⋅ ρ ⋅
n=0
n ⋅∑ρ n −1
= ⋅ ρ
1 − ρ m +1 ∂ρ ⎜⎝ n = 0 ⎟⎠
∑
ρ ⋅ (1 − ρ ) ∂ ⎛ 1 − ρ m +1 ⎞ ρ (m + 1) ⋅ ρ m +1
= ⋅ ⎜ ⎟ = − (4.9)
1 − ρ m +1 ∂ρ ⎜⎝ 1 − ρ ⎟⎠ 1− ρ 1 − ρ m +1

Thus, the expected number of customers in the system is always less than for the unlimited queue
length case, Eq. (4.6).
Chapter 4 • Queuing Delay Models 73

It is also of interest to know the probability of a customer arriving to a full waiting room, also
called blocking probability pB. Generally, the probability that a customer arrives when there are n
customers in the queue is (using Bayes’ formula)
P{a customer arrives in (t , t + δ ) | N (t ) = n} ⋅ P{N (t ) = n}
P{N (t ) = n | a customer arrives in (t , t + δ )} =
P{a customer arrives in (t , t + δ )}
(λ ⋅ δ ) ⋅ pn
= = pn
λ ⋅δ
because of the memoryless assumption about the system. Thus, the blocking probability is the
probability that an arrival will find m customers in the system, which is (using Eq. (4.8))
ρ m ⋅ (1 − ρ )
pB = P{N (t ) = m} = pm = (4.10)
1 − ρ m+1

4.3 M / G / 1 Queuing System

We now consider a class of systems where arrival process is still memoryless with rate λ.
However, the service times have a general distribution—not necessarily exponential as in the
M/M/1 system—meaning that we do not know anything about the distribution of service times.
Suppose again that the customers are served in the order they arrive (FCFS) and that Xi is the
service time of the ith arrival. We assume that the random variables (X1, X2, …) are independent of
each other and of the arrival process, and identically distributed according to an unspecified
distribution function.
The class of M/G/1 systems is a superset of M/M/1 systems. The key difference is that in general
there may be an additional component of memory. In such a case, one cannot say as for M/M/1
that the future of the process depends only on the present length of the queue. To calculate the
average delay per customer, it is also necessary to account for the customer that has been in
service for some time. Similar to M/M/1, we could define the state of the system as the number of
customers in the system and use the so called moment generating functions to derive the system
parameters. Instead, a simpler method from [Bertsekas & Gallagher, 1992] is used.
Assume that upon arrival the ith customer finds Ni customers waiting in queue and one currently
in service. The time the ith customer will wait in the queue is given as
i −1
Wi = ∑X
j =i − Ni
j + Ri (4.11)

where Ri is the residual service time seen by the ith customer. By this we mean that if customer j
is currently being served when i arrives, Ri is the remaining time until customer j’s service is
completed. The residual time’s index is i (not j) because this time depends on i’s arrival time and
is not inherent to the served customer. If no customer is served at the time of i’s arrival, then Ri is
zero.
Ivan Marsic • Rutgers University 74

A2 = 9:30 A4 = 10:10 A6 = 11:05

A1 = 9:05 A3 = 9:55 A5 = 10:45

X1 = 30 X2 = 10 X3 = 75 X4 = 15 X5 = 20 X6 = 25

(a) 1 2 3 4 5 6

9:00 9:05 9:35 9:45 9:55 11:10 11:25 11:45

Time

Customer 5
Customer 4
service time = 15 min
service time = 20 min

(b) Customer 6
arrives at 11:05 Server

Customers 4 and 5
waiting in queue
Residual service time r(τ)

Service time for customer 3 Customer 3 in service;

X3 = 75 min Ni = 2 Residual time = 5 min
75

(c) Customer 6
arrives at 11:05

5 Time τ

9:55 11:10

Figure 4-8: (a) Example of customer arrivals and service times; see Example 4.1 for details.
(b) Detail of the situation found by customer 6 at his/her arrival. (c) Residual service time.

Example 4.1 Delay in a Bank Teller Service

An example pattern of customer arrivals to the bank from Figure 4-3 is shown in Figure 4-8. Assume
that nothing is known about the distribution of service times. In this case, customer k = 6 will find
customer 3 in service and customers 4 and 5 waiting in queue, i.e., N6 = 2. The residual service time
for 3 at the time of 6’s arrival is 5 min. Thus, customer 6 will experience the following queuing delay:
5
W6 = ∑Xj =4
j + R6 = (15 + 20 ) + 5 = 40 min

This formula simply adds up all the times shown in Figure 4-8(b). Notice that the residual time
depends on the arrival time of customer i = 6 and not on how long the service time of customer
(i − Ni − 1) = 3 is.
The total time that 6 will spend in the system (the bank) is T6 = W6 + X6 = 40 + 25 = 65 min.

By taking expectations of Eq. (4.11) and using the independence of the random variables Ni and
Xi−1, Xi−2, …, Xi−Ni (which means that how many customers are found in the queue is independent
of what business they came for), we have
 Chapter 4 • Queuing Delay Models 75

Residual service time r(τ)

X1

Time τ

X1 X2 XM(t) t

Figure 4-9: Expected residual service time computation. The time average of r(τ) is
computed as the sum of areas of the isosceles triangles over the given period t.

⎧⎪ i −1 ⎫⎪ 1
E{Wi } = E ⎨ ∑ E{ X j | N i }⎬ + E{Ri } = E{ X } ⋅ E{N i } + E{Ri } =
⎪⎩ j =i − Ni ⎪⎭
⋅ N + E{Ri }
μ Q
(4.12)

Throughout this section all long-term average quantities should be viewed as limits when time or
customer index converges to infinity. We assume that these limits exist, which is true for most
systems of interest provided that the utilization ρ < 1.The second term in the above equation is the
mean residual time, R = lim E{Ri } , and it will be determined by a graphical argument. The
t →∞

residual service time r(τ) can be plotted as in Figure 4-8(c). The general case is shown in Figure
4-9. Every time a new customer enters the service, the residual time equals that customer’s
service time. Then it decays linearly until the customer’s service is completed. The time average
of r(τ) in the interval [0, t] is

1 M (t ) 1 2
t
1
t0∫r (τ )dτ = ∑
t i =1 2
Xi

where M(t) is the number of service completions within [0, t]. Hence, we obtain
⎛ M (t ) 2 ⎞
⎛1 ⎞ 1 ⎛ M (t ) 1 M (t ) 2 ⎞ 1
t
⎛ ( ) ⎞
⎜
⎜
Xi ⎟
⎟ 1
∑
R = lim E{Ri } = lim⎜ r (τ )dτ ⎟ = lim⎜⎜ ∑
M t
∫ X i ⎟⎟ = lim⎜ ⎟ ⋅ lim⎜ i =1 ⎟= 2λ⋅X
2
⋅
i →∞ ⎜
i →∞ t ⎟ 2 i →∞ M (t ) t 2 i →∞ ⎝ t ⎠ i →∞ M (t )
⎝ 0 ⎠ ⎝ i =1 ⎠ ⎜ ⎟
⎜ ⎟
⎝ ⎠

where X 2 is the second moment of service time, computed as

⎧ ∑ pi ⋅ ( X i ) n if X is discrete r.v.
⎪
E{ X n } = ⎨ X : p∞i >0
⎪ ∫ f ( x) ⋅ x n ⋅ dx if X is continuous r.v.
⎩ -∞
By substituting this expression in the queue waiting time, Eq. (4.12), we obtain the so called
Pollaczek-Khinchin (P-K) formula

λ⋅X2
W= (4.13)
2 ⋅ (1 − ρ )
Ivan Marsic • Rutgers University 76

The P-K formula holds for any distribution of service times as long as the variance of the service
times is finite.

Example 4.2 Queuing Delays of an Go-Back-N ARQ

Consider a Go-Back-N ARQ such as described in Section 1.3.2 above. Assume that packets arrive at
the sender according to a Poisson process with rate λ. Assume also that errors affect only the data
packets, from the sender to the receiver, and not the acknowledgment packets. What is the expected
queuing delay per packet in this system?
Notice that the expected service time per packet equals the expected delay per packet transmission,
which is determined in the solution of Problem 1.9 at the back of this text as follows
pfail
X = E{Ttotal } = tsucc + ⋅ tfail
1 − pfail

The second moment of the service time, X 2 , is determined similarly as:

Finally, Eq. (4.13) yields

λ⋅X2 λ⋅X2 λ⋅X2

W= = =
2(1 − ρ ) 2(1 − λ / μ ) 2(1 − λ ⋅ X )

4.4 Networks of Queues

4.5 Summary and Bibliographical Notes

The material presented in this chapter requires basic understanding of probability and random
processes. [Yates & Goodman, 2004] provides an excellent introduction and [Papoulis & Pillai,
2001] is a more advanced and comprehensive text.

[Bertsekas & Gallagher, 1992] provides a classic treatment of queuing delays in data networks.
Most of the material in this chapter is derived from this reference.
Chapter 4 • Queuing Delay Models 77

Problems

Problem 4.1
Consider a router that can process 1,000,000 packets per second. Assume that the load offered to
it is 950,000 packets per second. Also assume that the interarrival times and service durations are
exponentially distributed.
(a) How much time will a packet, on average, spend being queued before being serviced?
(b) Compare the waiting time to the time that an average packet would spend in the router if
no other packets arrived.
(c) How many packets, on average, can a packet expect to find in the router upon its arrival?

Problem 4.2
Consider an M/G/1 queue with the arrival and service rates λ and μ, respectively. What is the
probability that an arriving customer will find the server busy (i.e., serving another customer)?

Problem 4.3
Messages arrive at random to be sent across a communications link with a data rate of 9600 bps.
The link is 70% utilized, and the average message length is 1000 bytes. Determine the average
waiting time for exponentially distributed length messages and for constant-length messages.

Problem 4.4
A facility of m identical machines is sharing a single repairperson. The time to repair a failed
machine is exponentially distributed with mean 1/λ. A machine, once operational, fails after a
time that is exponentially distributed with mean 1/μ. All failure and repair times are independent.
What is the steady-state proportion of time where there is no operational machine?

Problem 4.5
Imagine that K users share a link (e.g., Ethernet or Wi-Fi) with throughput rate R bps (i.e., R
represents the actual number of file bits that can be transferred per second, after accounting for
overheads and retransmissions). User’s behavior is random and we model it as follows. Each user
requests a file and waits for it to arrive. After receiving the file, the user sleeps for a random time,
and then repeats the procedure. Each file has an exponential length, with mean A × R bits.
Sleeping times between a user’s subsequent requests are also exponentially distributed but with a
mean of B seconds. All these random variables are independent. Write a formula that estimates
the average time it takes a user to get a file since completion of his previous file transfer.

Problem 4.6
Consider a single queue with a constant service time of 4 seconds and a Poisson input with mean
rate of 0.20 items per second.
Ivan Marsic • Rutgers University 78

(a) Find the mean and standard deviation of queue size

(b) Find the mean and standard deviation of the time a customer spends in system.

Problem 4.7
Consider the Go-back-N protocol used for communication over a noisy link with the probability
of packet error equal to pe. Assume that the link is memoryless, i.e., the packet error events are
independent from transmission to transmission. Also assume that the following parameters are
given: the round-trip time (RTT), packet size L, and transmission rate R. What is the average
number of successfully transmitted packets per unit of time (also called throughput), assuming
that the sender always has a packet ready for transmission?
Hint: Recall that the average queuing delay per packet for the Go-back-N protocol is derived in
Example 4.2 above.

Problem 4.8
 Chapter 5
Scheduling and Policing

Contents
5.1 Introduction
5.1.1 x

5.1 Introduction 5.1.2 x

5.1.3 x

5.2 Fair Queuing

5.2.1 Generalized Processor Sharing
5.2.2 Fair Queuing
5.2.3 Weighted Fair Queuing

The queuing models in Chapter 4 considered delays and 5.3 Policing

blocking probabilities under the assumption that tasks/packets 5.3.1 x
5.3.2 x
are served on a first-come-first-served (FCFS) basis and that a 5.3.3 x
5.3.4 x
task is blocked if it arrives at a full queue (if the waiting room
capacity is limited). The property of a queue that decides the 5.4 x
order of servicing of packets is called scheduling discipline 5.4.1 x
5.4.2
(also called service discipline or queuing discipline, see Section 5.4.3
4.1.1 above). The property of a queue that decides which task is 5.5 x
blocked from entering the system or which packet is dropped 5.5.1
for a full queue is called blocking policy or packet-discarding 5.5.2
5.5.3
policy or drop policy. The simplest combination is FCFS with
5.6 x
tail drop, i.e., always service head of the line and, if necessary,
5.6.1
drop the last arriving packet and this is what we considered in 5.6.2
Section 4.2.1 above. 5.6.3

5.7 Summary and Bibliographical Notes

Scheduling has direct impact on a packet’s queuing delay and
Problems
hence on its total delay. Dropping decides whether the packet
will arrive to destination at all. FCFS does not make any
distinction between packets. Another scheme that does not discriminate packets is FIRO—first-
in-random-out—mentioned in Section 4.1.2 above. Additional concerns may compel the network
designer to consider making distinction between packets and design more complex scheduling
disciplines and dropping policies. Such concerns include:
• Prioritization, where different tasks/packets can have assigned different priorities, so that
the delay time for certain packets is reduced (at the expense of other packets)
• Fairness, so that different flows (identified by source-destination pairs) are offered
equitable access to system resources

79
Ivan Marsic • Rutgers University 80

Class 1 queue (Waiting line)

Transmitter
Class 2 queue (Server)
Arriving packets

Classifier Scheduler

Class n queue
Scheduling
discipline
Packet drop
when queue full

Figure 5-1. Components of a scheduler. Classifier sorts the arriving packets into different
waiting lines based on one or more criteria, such as priority or source identity. Scheduler
then places the packets into service based on the scheduling discipline. A single server
serves all waiting lines.

• Protection, so that misbehavior of some flows (by sending packets at a rate faster than
their fair share) should not affect the performance achieved by other flows
Prioritization and fairness are complementary, rather than mutually exclusive. Fairness ensures
that traffic flows of equal priority receive equitable service and that flows of lower priority are
not excluded from receiving any service because all of it is consumed by higher priority flows.
Fairness and protection are related so that ensuring fairness automatically provides protection,
because it limits a misbehaving flow to its fair share. However, the converse need not be true. For
example, if flows are policed at the entrance to the network, so that they are forced to confirm to
a predeclared traffic pattern, they are protected from each other, but their resource shares may not
be fair. Policing will be considered in Section 5.3 below.
The system that wishes to make distinction between packets needs two components (Figure 5-1):
1. Classifier—Forms different waiting lines for different packet types. The criteria for
sorting packets into different lines include: priority, source and/or destination network
address, application port number, etc.
2. Scheduler—Calls packets from waiting lines for service. Options for the rules of calling
the packets for service (scheduling discipline) include: (i) first serve all the packets
waiting in the high-priority line, if any; then go to the next lower priority class, etc.; (ii)
serve the lines in round-robin manner by serving one or more packets from one line (but
not necessarily all that are currently waiting), then go to serve few from the next waiting
line, etc., then repeat the cycle.
FCFS places indiscriminately all the arriving packets at the tail of the queue. The idea with
prioritization is that the packets with highest priority, upon arrival to the system, are placed at the
head-of-the line, so they bypass waiting in the line. They may still need to wait if there is another
packet (perhaps even of a lower priority) currently being transmitted. Non-preemptive scheduling
is the discipline under which the ongoing transmission of lower-priority packets is not interrupted
upon the arrival of a higher-priority packet. Conversely, preemptive scheduling is the discipline
under which lower-priority packet is bumped out of service (back into the waiting line or dropped
Chapter 5 • Scheduling and Policing 81

from the system) if a higher-priority packet arrives at the time a lower-priority packet is being
transmitted.
Packet priority may be assigned simply based on the packet type, or it may be result of applying a
complex set of policies. For example, the policies may specify that a certain packet type of a
certain user type has high priority at a certain time of the day and low priority at other times.
While priority scheduler does provide different performance characteristics to different classes, it
still has shortcomings. For example, it does not deal with fairness and protection. An aggressive
or misbehaving high-priority source may take over the communication line and elbow out all
other sources. Not only the flows of the lower priority will suffer, but also the flows of the same
priority are not protected from misbehaving flows.
A round robin scheduler alternates the service among different flows or classes of packets. In the
simplest form of round robin scheduling the head of each queue is called, in turn, for service.
That is, a class 1 packet is transmitted, followed by a class 2 packet, and so on until a class n
packet is transmitted. The whole round is repeated forever or until there are no more packets to
transmit. If a particular queue is empty, since no packets of such type arrived in the meantime, the
scheduler has two options:
1. Keep unused the portion of service or work allocated for that particular class and let the
server stay idle (non-work-conserving scheduler)
2. Let the packet from another queue, if any, use this service (work-conserving scheduler)
A work-conserving scheduler will never allow the link (server) to remain idle if there are packets
(of any class or flow) queued for transmission. When such scheduler looks for a packet of a given
class but finds none, it will immediately check the next class in the round robin sequence.
One way to achieve control of channel conditions (hence, performance bounds) is to employ time
division multiplexing (TDM) or frequency division multiplexing (FDM). TDM/FDM maintains a
separate channel for each traffic flow and never mixes packets from different flows, so they never
interfere with each other. TDM and FDM are non-work-conserving. Statistical multiplexing is
work-conserving and that is what we consider in the rest of this chapter.

5.2 Fair Queuing

Suppose that a system, such as transmission link, has insufficient resource to satisfy the demands
of all users, each of whom has an equal right to the resource, but some of whom intrinsically
demand fewer resources than others. How, then, should we divide the resource? A sharing
technique widely used in practice is called max-min fair share. Intuitively, a fair share first fulfils
the demand of users who need less than they are entitled to, and then evenly distributes unused
resources among the “big” users (Figure 5-2). Formally, we define max-min fair share allocation
to be as follows:
• Resources are allocated in order of increasing demand
• No source obtains a resource share larger than its demand
Ivan Marsic • Rutgers University 82

1. Satisfy customers who need less than their fair share

2. Split the remainder equally among the remaining customers

desired: Fair share: 1/3 each

2/3

desired: 1/8 P2 desired: 1/8 P2

P1 P1
desired: 1/3
Return surplus: New fair share
1/3 − 1/8 = 5/24 for P2 & P3:

1/3 + ½ (5/24) each

a P3 b P3

1. Satisfy customers who need less than their fair share

2. Split the remainder equally among the remaining customers Final fair distribution:
Fair share:
1/3 + ½ (5/24) each

received: 1/8 P2 received: 1/8 P2

received: 1/3 + 5/24

P1 P1

Remainder of
received: 1/3
Return surplus: 1/3 + 2 × ½ (5/24) deficit: 1/8
1/3 + ½ (5/24) − 1/3
goes to P2

c
= ½ (5/24)

P3 d P3

Figure 5-2. Illustration of max-min fair share algorithm; see text for details.

• Sources with unsatisfied demands obtain an equal share of the resource

This formal definition corresponds to the following operational definition. Consider a set of
sources 1, ..., n that have resource demands r1, r2, ..., rn. Without loss of generality, order the
source demands so that r1 ≤ r2 ≤ … ≤ rn. Let the server have capacity C. Then, we initially give
C/n of the resource to the source with the smallest demand, r1. This may be more than what
source 1 wants, perhaps, so we can continue the process. The process ends when each source
receives no more than what it asks for, and, if its demand was not satisfied, no less than what any
other source with a higher index received. We call such an allocation a max-min fair allocation,
because it maximizes the minimum share of a source whose demand is not fully satisfied.

Example 5.1 Max-Min Fair Share

Consider the server in Figure 5-3 where packets are arriving from n = 4 sources of equal priority and
need to be transmitted over a wireless link. The total required link capacity is:
8 × 2048 + 25 × 2048 + 50 × 512 + 40 × 1024 = 134,144 bytes/sec = 1,073,152 bits/sec
and the available capacity of the link is C = 1 Mbps = 1,000,000 bits/sec. By the notion of fairness and
given that all sources are equally “important,” each source is entitled to C/n = ¼ of the total capacity =
250 Kbps. Some sources may not need this much and the surplus is equally divided among the sources
that need more than their fair share. The following table shows the max-min fair allocation procedure.

Demands Balances Allocation #2 Balances after Allocation #3 Final

Sources
[bps] after 1st round [bps] 2nd round (Final) [bps] balances
Chapter 5 • Scheduling and Policing 83

8 packets per sec

Application 1
L1 = 2048 bytes

25 pkts/s Link capacity

Application 2
L2 = 2 KB = 1 Mbps

50 pkts/s
Application 3 L3 = 512 KB
Wi-Fi transmitter
(Server)
40 pkts/s
Application 4
L4 = 1 KB

Figure 5-3. Example of a server (Wi-Fi transmitter) transmitting packets from four sources
(applications) over a wireless link; see text for details.

Application 1 131,072 bps +118,928 bps 131,072 0 131,072 bps 0

Application 2 409,600 bps −159,600 bps 332,064 −77,536 bps 336,448 bps −73,152 bps
Application 3 204,800 bps +45,200 bps 204,800 0 204,800 bps 0
Application 4 327,680 bps −77,680 bps 332,064 +4,384 bps 327,680 bps 0

After the first round in which each source receives ¼C, sources 1 and 3 have excess capacity, since
they are entitled to more than what they need. The surplus of C′ = 118,928 + 45,200 = 164,128 bps is
equally distributed between the sources in deficit, that is sources 2 and 4. After the second round of
allocations, source 4 has excess of C″ = 4,384 bps and this is allocated to the only remaining source in
deficit, which is source 2. Finally, under the fair resource allocation, sources 1, 3, and 4 have fulfilled
their needs, but source 2 remains short of 73.152 Kbps.

Thus far, we have assumed that all sources are equally entitled to the resources. Sometimes, we
may want to assign some sources a greater share than others. In particular, we may want to
associate weights w1, w2, ..., wn with sources 1, 2, …, n, to reflect their relative entitlements to the
resource. We extend the concept of max-min fair share to include such weights by defining the
max-min weighted fair share allocation as follows:
• Resources are allocated in order of increasing demand, normalized by the weight
• No source obtains a resource share larger than its demand
• Sources with unsatisfied demands obtain resource shares in proportion to their weights
The following example illustrates the procedure.

Example 5.2 Weighted Max-Min Fair Share

Consider the same scenario as in Example 5.1, but this time assume that the sources are weighted as
follows: w1 = 0.5, w2 = 2, w3 = 1.75, and w4 = 0.75. The first step is to normalize the weights so they
are all integers, which yields: w1′ = 2 , w′2 = 8 , w3′ = 7 , and w′4 = 3 . A source i is entitled to wi′ ⋅ 1 ′
∑ wj
of the total capacity, which yields 2/20, 8/20, 7/20, and 3/20, for the respective four sources. The
following table shows the results of the weighted max-min fair allocation procedure.

Allocation Balances Allocation Balances after Allocation #3 Final

Src Demands
#1 [bps] after 1st round #2 [bps] 2nd round (Final) [bps] balances
Ivan Marsic • Rutgers University 84

Waiting lines (queues)

Service times: XE,3 = 3 XE,2 = 5 XE,1 = 2

Economy-class
passengers
?
Customer Server
First-class
in service
passengers
Service time: XF,1 = 8

Figure 5-4. Dynamic fair-share problem: in what order should the customers be called for
service?

1 131,072 bps 100,000 −31,072 122,338 −8,734 bps 131,072 bps 0

2 409,600 bps 400,000 −9,600 489,354 +79,754 bps 409,600 bps 0
3 204,800 bps 350,000 +145,200 204,800 0 204,800 bps 0
4 327,680 bps 150,000 −177,680 183,508 −144,172 bps 254,528 bps −73,152 bps

This time around, source 3 in the first round gets allocated more than it needs, while all other sources
are in deficit. The excess amount of C′ = 145,200 bps is distributed as follows. Source 1 receives
2+8+3 ⋅145,200 = 22,338
2 bps, source 2 receives 2+88+3 ⋅ 145,200 = 89,354 bps, and source 4 receives
⋅ 145,200 = 33,508 bps. Notice that in the denominators is always the sum of weights for the
3
2+8+3

currently considered sources. After the second round of allocations, source 2 has excess of C″ = 79,754
bps and this is distributed among sources 1 and 4. Source 1 receives 2+2 3 ⋅ 79,754 = 31,902 , which
along with 122,338 it already has yields more than it needs. The excess of C″′ = 23,168 is given to
source 4, which still remains short of 73.152 Kbps.

Min-max fair share (MMFS) defines the ideal fair distribution of a shared scarce resource. Given
the resource capacity C and n customers, under MMFS a customer i is guaranteed to obtain at
least Ci = C/n of the resource. If some customers need less than what they are entitled to, then
other customers can receive more than C/n. Under weighted MMFS (WMMFS), a customer i is
w
guaranteed to obtain at least Ci = n i C of the resource.
wj ∑j =1

However, MMFS does not specify how to achieve this in a dynamic system where the demands
for resource vary over time. To better understand the problem, consider the airport check-in
scenario illustrated in Figure 5-4. Assume there is a single window (server) and both first-class
and economy passengers are given the same weight. The question is, in which order the waiting
customers should be called for service so that both queues obtain equitable access to the server
resource? Based on the specified service times (Figure 5-4), the reader may have an intuition that,
in order to maintain fairness on average, it is appropriate to call the first two economy-class
passengers before the first-class passenger and finally the last economy-class passenger. The rest
Chapter 5 • Scheduling and Policing 85

Flo
w 1q
ueu
e

Transmitter
(Server)
Flow 2 queue

ue
que
w3
Flo Bit-by-bit
round robin
service

Figure 5-5. Bit-by-bit generalized processor sharing.

of this section reviews practical schemes that achieve just this and, therefore, guarantee
(weighted) min-max fair share resource allocation when averaged over a long run.

5.2.1 Generalized Processor Sharing

Min-max fair share cannot be directly applied in network scenarios because packets are
transmitted as atomic units and they can be of different length, thus requiring different
transmission times. In Example 5.1 above, packets from sources 1 and 2 are twice longer than
those from source 4 and four times than from source 3. It is, therefore, difficult to keep track of
whether each source receives its fair share of the server capacity. To arrive at a practical
technique, we start by considering an idealized technique called Generalized Processor Sharing
(GPS).
GPS maintains different waiting lines for packets belonging to different flows. There are two
restrictions that apply:
• A packet cannot jump its waiting line, i.e., scheduling within individual queues is FCFS
• Service is non-preemptive, meaning that an arriving packet never bumps out a packet that
is currently being transmitted (in service)
GPS works in a bit-by-bit round robin fashion, as illustrated in Figure 5-5. That is, the router
transmits a bit from queue 1, then a bit from queue 2, and so on, for all queues that have packets
ready for transmission. Let Ai,j denote the time that jth packet arrives from ith flow at the server
(transmitter). Let us, for the sake of illustration, consider the example in Figure 5-6. Packets from
flow 1 are 2 bits long, and from flows 2 and 3 are 3 bits long. At time zero, packet A3,1 arrives
from flow 3 and finds an idle link, so its transmission starts immediately, one bit per round. At
time t = 2 there are two arrivals: A2,1 and A3,2. Since in flow 3 A3,2 finds A3,1 in front of it, it must
wait until the transmission of A3,1 is completed. The transmission of A2,1 starts immediately since
currently this is the only packet in flow 2. However, one round of transmission now takes two
time units, since two flows must be served per round. (The bits should be transmitted atomically,
a bit from each flow per unit of time, rather than continuously as shown in the figure, but since
this is an abstraction anyway, I leave it as is.)
Ivan Marsic • Rutgers University 86

Ai,j Arrival
A1,1 Waiting
Flow 1
L1 = 2 bits Service

A2,2

Flow 2 A2,1
L2 = 3 bits

A3,2

Flow 3 A3,1
L3 = 3 bits

Time
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Round
number 1 2 3 4 5 6 7 8

Figure 5-6. Example of bit-by-bit GPS. The output link service rate is C = 1 bit/s.

As seen, a k-bit packet takes always k rounds to transmit, but the actual time duration can vary,
depending on the current number of active flows—the more flows served in a round, the longer
the round takes. (A flow is active if it has packets enqueued for transmission.) For example, in
Figure 5-6 it takes 4 s to transmit the first packet of flow 3, and 8 s for the second packet of the
same flow.
The piecewise linear relationship between the time and round number is illustrated in Figure 5-7
for the example from Figure 5-6. Each linear segment has the slope inversely proportional to the
current number of active flows. In the beginning, the slope of the round number curve is 1/1 due
to the single active flow (flow 3). At time 2, flow 2 becomes active, as well, and the slope falls to
1/2. Similarly, at time 6 the slope falls to 1/3. In general, the function R(t) increases at a rate
dR(t ) C
= (5.1)
dt nactive (t )
where C is the transmission capacity of the output line. Obviously, if nactive(t) is constant then
R(t) = t ⋅ C / nactive, but this need not be the case since packets in different flows arrive randomly.
In general, the round number is determined in a piecewise manner
i (t − t
j −1 ) ⋅ C t ⋅C
R (ti ) = ∑ + 1
j
as will be seen in Example 5.3 below. Each time R(t) reaches
j =1 nactive (t j ) nactive (t1 )
a new integer value marks an instant at which all the queues have been given an equal number of
opportunities to transmit a bit (of course, an empty queue does not utilize its given opportunity).
GPS provides max-min fair resource allocation. Unfortunately, GPS cannot be implemented since
it is not feasible to interleave the bits from different flows. A practical solution is the fair queuing
mechanism that approximates this behavior on a packet-by-packet basis, which is presented next.
Chapter 5 • Scheduling and Policing 87

1
7

1/
=
e
op
6

sl
Round number R(t)
5
1 /3
e=
slop
4
Round
number
3
= 1/2 F1(t)
pe
2 sl o F2(t)
F3(t)

1
1/
1

=
e
op
sl
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Time t

Figure 5-7. Piecewise linear relationship between round number and time for the example
from Figure 5-6. Also shown are finish numbers Fi(t) for the different flows.

5.2.2 Fair Queuing

Similar to GPS, a router using FQ maintains different waiting lines for packets belonging to
different flows at each output port. FQ determines when a given packet would finish being
transmitted if it were being sent using bit-by-bit round robin (GPS) and then uses this finishing
tag to rank order the packets for transmission.
The service round in which a packet Ai,j would finish service under GPS is called the packet’s
finish number, denoted Fi,j. For example, in Figure 5-6 packet A1,1 has finish number F1,1 = 6,
packet A2,1 has finish number F2,1 = 5, and so on. Obviously, packet’s finish number depends on
the packet size and the round number at the start of packet’s service. It is important to recall that
the finish number is, generally, different from the actual time at which the packet is served.
Let Li,j denote the size (in bits) of packet Ai,j. Under bit-by-bit GPS it takes Li,j rounds of service to
transmit this packet. Let Fi,j denote the time when the transmitter finishes transmitting jth packet
from ith flow. Suppose that a packet arrives at time ta on a server which previously cycled through
R(ta) rounds. Under GPS, the packet would have to wait for service only if there are currently
packets from this flow either under service or enqueued for service or both—packets from other
flows would not affect the start of service for this packet. Therefore, the start round number for
servicing packet Ai,j is the highest of these two
• The current round R(ta) at the packet’s arrival time ta
• The finishing round of the last packet, if any, from the same flow
or in short, the start round number of the packet Ai,j is max{Fi,j−1, R(ta)}. The finish number of this
packet is computed as
{
Fi , j = max Fi , j −1 , R(t a ) + Li , j } (5.2)

Once assigned, the finish number remains constant and does not depend on future packet arrivals
and departures. FQ scheduler performs the following procedure every time a new packet arrives:
1. Calculate the finish number for the newly arrived packet using Eq. (5.2)
Ivan Marsic • Rutgers University 88

a 4 Arrival time Packet size Flow ID

t=0 16,384 bytes @Flow1

number R(t)
3 1/1
2 t=0 4,096 bytes @Flow3

Round
1/2 t=3 16,384 bytes @Flow2
1
0 t=3 8,192 bytes @Flow4
0 1 2 3 4 5 t=6 4,096 bytes @Flow3
Flow 1:

Flow 3:
Flow 2:

Flow 4:
t = 12 4,096 bytes @Flow3

1
3,
P
Time t

1,
1,
P
b 6
1/1

number R(t)
5
4

Round
1/3
3
1/1
2
1

2 3 4 5 6 7 8 9 10 11
Flow 1:

Flow 3:
Flow 2:

Flow 4: P 2,1
, P 4,1 Time t

Figure 5-8: Determining the round numbers under bit-by-bit GPS for Example 5.3. (a)
Initial round numbers as determined at the arrival of packets P1,1 and P3,1. (b) Round
numbers recomputed at the arrival of packets P2,1 and P4,1. (Continued in Figure 5-9.)

2. For all the packets currently waiting for service (in any queue), sort them in the
ascending order of their finish numbers
3. When the packet currently in transmission, if any, is finished, call the packet with the
smallest finish number in transmission service
Note that the sorting in step 2 does not include the packet currently being transmitted, if any,
because FQ uses non-preemptive scheduling. Also, it is possible that a packet can be scheduled
ahead of a packet waiting in a different line because the former is shorter than the latter and its
finish number happens to be smaller than the finish number of the already waiting (longer)
packet. The fact that FQ uses non-preemptive scheduling makes it an approximation of the bit-by-
bit round robin GPS, rather than an exact simulation.
For example, Figure 5-7 also shows the curves for the finish numbers Fi(t) of the three flows from
Figure 5-6. At time 2, packets A2,1 and A3,2 arrive simultaneously, but since F2,1 is smaller than
F3,2, packet A2,1 gets into service first.

Example 5.3 Packet-by-Packet Fair Queuing

Consider the system from Figure 5-3 and Example 5.1 and assume for the sake of illustration that the
time is quantized to the units of the transmission time of the smallest packets. The smallest packets are
512 bytes from flow 3 and on a 1 Mbps link it takes 4.096 ms to transmit such a packet. For the sake of
illustration, assume that a packet arrives on flows 1 and 3 each at time zero, then a packet arrives on
flows 2 and 4 each at time 3, and packets arrive on flow 3 at times 6 and 12. Show the corresponding
packet-by-packet FQ scheduling.
Chapter 5 • Scheduling and Policing 89

number R(t)
Round
7
6
1/1
5
1/4
4
1/3
3
1/1
2
1/2
1
Time t
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13
Flow 2:

Flow 4:
Flow 1:

Flow 3:

1
3,

4,
P

3
3,

3,
1,

1,

P
1,

2,
P

Figure 5-9: Determining the round numbers under bit-by-bit GPS for Example 5.3,
completed from Figure 5-8.

The first step is to determine the round numbers for the arriving packets, given their arrival times. The
process is illustrated in Figure 5-8. The round numbers are shown also in the units of the smallest
packet’s number of bits, so these numbers must be multiplied by 4096 to obtain the actual round
number. Bit-by-bit GPS would transmit two packets (A1,1 and A3,1) in the first round, so the round takes
two time units and the slope is 1/2. In the second round, only one packet is being transmitted (A1,1), the
round duration is one time unit and the slope is 1/1. The GPS server completes two rounds by time 3,
R(3) = 2, at which point two new packets arrive (A2,1 and A4,1). The next arrival is at time 6 (the actual
time is t1 = 24.576 ms) and the round number is determined as
(t 3 − t 2 ) ⋅ C (0.024576 − 0.012288 ) × 1000000
R (t 3 ) = + R (t 2 ) = + 8192 = 4094 + 8192 = 12288
nactive (t 3 ) 3

which in our simplified units is R(6) = 3. The left side of each diagram in Figure 5-8 also shows how
the packet arrival times are mapped into the round number units. Figure 5-9 summarizes the process of
determining the round numbers for all the arriving packets.
The actual order of transmissions under packet-by-packet FQ is shown in Figure 5-10. At time 0 the
finish numbers are: F1,1 = 4 and F3,1 = 1, so packet A3,1 is transmitted first and packet A1,1 goes second.
At time 3 the finish numbers for the newly arrived packets are: F2,1 = max{0, R(3)} + L2,1 = 2 + 4 = 6
and F4,1 = max{0, R(3)} + L4,1 = 2 + 2 = 4, so F4,1 < F2,1. The ongoing transmission of packet A1,1 is not
preempted and will be completed at time 5, at which point packet A4,1 will enter the service. At time 6
the finish number for packet A3,2 is F3,2 = max{0, R(6)} + L3,2 = 3 + 1 = 4. The current finish numbers
are F3,2 < F2,1 so A3,2 enters the service at time 7, followed by A2,1 which enters the service at time 8.
Finally, at time 12 the finish number for the new packet A3,3 is F3,3 = max{0, R(12)} + L3,3 = 6 + 1 = 7
and it is transmitted at 12.
In summary, the order of arrivals is {A1,1, A3,1}, {A2,1, A4,1}, A3,2, A3,3 where simultaneously arriving
packets are delimited by curly braces. The order of transmissions under packet-by-packet FQ is: A3,1,
A1,1, A4,1, A3,2, A2,1, A3,3.
Ivan Marsic • Rutgers University 90

Ai,j Arrival
Flow 1
L1 = 2 KB A1,1 Waiting
Service

Flow 2
L2 = 2 KB A2,1

A3,3
Flow 3 A3,2
L3 = 512 B A3,1

Flow 4
L4 = 1 KB A4,1

Time [ms] 0 4.096 8.192 12.288 16.384 20.480 24.576 28.672 32.768 36.864 40.96 45.056 49.152 53.248

Figure 5-10: Time diagram of packet-by-packet FQ for Example 5.3.

There is a problem with the above algorithm of fair queuing which the reader may have noticed
besides that computing the finish numbers is no fun at all! At the time of a packet’s arrival we
know only the current time, not the current round number. As suggested above, one could try
using the round number slope, Eq. (5.1), to compute the current round number from the current
time, but the problem with this is that the round number slope is not necessarily constant. An FQ
scheduler computes the current round number on every packet arrival, to assign the finish number
to the new packet. Since the computation is fairly complex, this poses a major problem with
implementing fair queuing in high-speed networks. Some techniques for overcoming this problem
have been proposed, and the interested reader should consult [Keshav 1997].

5.2.3 Weighted Fair Queuing

Now assume that weights w1, w2, ..., wn are associated with sources (flows) 1, 2, …, n, to reflect
their relative entitlements to transmission bandwidth. As before, a queue is maintained for each
source flow. Under weighted min-max fair share, flow i is guaranteed to obtain at least Ci =
wi
C of the total bandwidth C. The bit-by-bit approximation of weighted fair queuing (WFQ)
∑ wj
would operate by allotting each queue a different number of bits per round. The number of bits
per round allotted to a queue should be proportional to its weight, so the queue with twice higher
weight should receive two times more bits/round.
Packet-by-packet WFQ can be generalized from bit-by-bit WFQ as follows. For a packet of
length Li,j (in bits) that arrives at ta the finish number under WFQ is computed as

Fi , j = max (Fi , j −1 , R(ta ) ) +

Li , j
(5.3)
wi
Chapter 5 • Scheduling and Policing 91

Traffic pattern 1

Average delay
Delay

Traffic pattern 2

Time

Figure 5-11: Different traffic patterns yield the same average delay.

From the second term in the formula, we see that if a packet arrives on each of the flows i and k
and wi = 2⋅wk, then the finish number for a packet of flow i is calculated assuming a bit-by-bit
depletion rate that is twice that of a packet from flow k.

All queues are set to an equal maximum size, so the flows with the highest traffic load will suffer
packet discards more often, allowing lower-traffic ones a fair share of capacity. Hence, there is no
advantage of being greedy. A greedy flow finds that its queues become long, since its packets in
excess of fair share linger for extended periods of time in the queue. The result is increased delays
and/or lost packets, whereas other flows are unaffected by this behavior. In many cases delayed
packets can be considered lost since delay sensitive applications ignore late packets.
The problem is created not only for the greedy source, but lost packets represent wasting network
resources upstream the point at which they are delayed or lost. Therefore, they should not be
allowed into the network at the first place. This is a task for policing.

5.3 Policing

So far we saw ho to distribute fairly the transmission bandwidth or other network resources using
WFQ scheduler. However, this does not guarantee delay bounds and low losses to traffic flows. A
packet-by-packet FQ scheduler guarantees a fair distribution of the resource, which results in a
certain average delay per flow. However, even an acceptable average delay may have great
variability for individual packets. This point is illustrated in Figure 5-11. Multimedia applications
are particularly sensitive to delay variability (known as “jitter”).
Ivan Marsic • Rutgers University 92

5.4 Active Queue Management

Packet-dropping strategies deal with case when there is not enough memory to buffer an
incoming packet. The simplest policy is to drop the arriving packet, known as drop-tail policy.
Active Queue Management (AQM) algorithms employ more sophisticated approaches. One of the
most widely studied and implemented AQM algorithms is the Random Early Detection (RED)
algorithm.

5.4.1 Random Early Detection (RED) Algorithm

5.5 Wireless 802.11 QoS

There is anecdotal evidence of W-LAN spectrum congestion; Unlicensed systems need to scale to
manage user “QoS.” Density of wireless devices will continue to increase; ~10x with home
gadgets; ~100x with sensors/pervasive computing

Decentralized scheduling

We assume that each message carries the data of a single data type. The messages at the producer
are ordered in priority-based queues. The priority of a data type is equal to its current utility,
U (Ti | S j ) . Figure 5-12 shows the architecture at the producer node. Scheduler works in a round-
robin manner, but may have different strategies for sending the queued messages, called queuing
discipline. It may send all high priority messages first, or it may assign higher probability of
sending to the high-priority messages, but the low-priority messages still get non-zero probability
of being sent.
Chapter 5 • Scheduling and Policing 93

Location, Rules Message queues

Battery,
Role, State High priority
Device, T3 T1
…
Medium priority
T2 T2 T5 T5 Scheduler
Utility Low priority
Producer T4 T5 Assessor
T1 T4 T4 T4 T4
Messages

Figure 5-12: Priority-based scheduling of the messages generated by a producer. Messages

are labeled by data types of the data they carry (T1, …, T5).

It s not clear whose rules for assigning the utilities should be used at producers: producer’s or
consumer’s. If only the consumer’s preferences are taken into the account, this resembles to the
filtering approach for controlling the incoming information, e.g., blocking unsolicited email
messages. One of the drawbacks of filtering is that does not balance the interests of senders and
recipients: filtering is recipient-centric and ignores the legitimate interests of the sender [Error!
Reference source not found.]. This needs to be investigated as part of the proposed research.

5.6 Summary and Bibliographical Notes

If a server (router, switch, etc.) is handling multiple flows, there is a danger that aggressive flows
will grab too much of its capacity and starve all the other flows. Simple processing of packets in
the order of their arrival is not appropriate in such cases, if it is desired to provide equitable
access to transmission bandwidth. Scheduling algorithms have been devised to address such
issues. The best known is fair queuing (FQ) algorithm, originally proposed by [Nagle, 1987],
which has many known variations. A simple approach is to form separate waiting lines (queues)
for different flows and have the server scan the queues round robin, taking the first packet (head-
of-the-line) from each queue (unless a queue is empty). In this way, with n hosts competing for a
given transmission line, each host gets to send one out of every n packets. Aggressive behavior
does not pay off, since sending more packets will not improve this fraction.
A problem with the simple round robin is that it gives more bandwidth to hosts that send large
packets at the expense of the hosts that send small packets. Packet-by-packet FQ tackles this
problem by transmitting packets from different flows so that the packet completion times
approximate those of a bit-by-bit fair queuing system. Every time a packet arrives, its completion
time under bit-by-bit FQ is computed as its finish number. The next packet to be transmitted is
the one with the smallest finish number among all the packets waiting in the queues.
If it is desirable to assign different importance to different flows, e.g., to ensure that voice packets
receive priority treatment, then packet-by-packet weighted fair queuing (WFQ) is used. WFQ
plays a central role in QoS architectures and it is implemented in today’s router products [Cisco,
1999; Cisco, 2006]. Organizations that manage their own intranets can employ WFQ-capable
routers to provide QoS to their internal flows.
Ivan Marsic • Rutgers University 94

[Keshav, 1997] provides a comprehensive review of scheduling disciplines in data networks.

[Bhatti & Crowcroft, 2000] has a brief review of various packet scheduling algorithms
[Elhanany et al., 2001] reviews hardware techniques of packet forwarding through a router or
switch
Packet scheduling disciplines are also discussed in [Cisco, 1995]

Problems

Problem 5.1

Problem 5.2
Eight hosts, labeled A, B, C, D, E, F, G, and H, share a transmission link the capacity of which is
85. Their respective bandwidth demands are 14, 7, 3, 3, 25, 8, 10, and 18, and their weights are 3,
4, 1, 0.4, 5, 0.6, 2, and 1. Calculate the max-min weighted fair share allocation for these hosts.
Show your work neatly, step by step.

Problem 5.3

Problem 5.4
Consider a packet-by-packet FQ scheduler that discerns three different classes of packets (forms
three queues). Suppose a 1-Kbyte packet of class 2 arrives upon the following situation. The
current round number equals 85000. There is a packet of class 3 currently in service and its finish
number is 106496. There are also two packets of class 1 waiting in queue 1 and their finish
numbers are F1,1 = 98304 and F1,2 = 114688.
Determine the finish number of the packet that just arrived. For all the packets under
consideration, write down the order of transmissions under packet-by-packet FQ. Show the
process.

Problem 5.5
Consider the following scenario for a packet-by-packet FQ scheduler and transmission rate equal
1 bit per unit of time. At time t=0 a packet of L1,1=100 bits arrives on flow 1 and a packet of
L3,1=60 bits arrives on flow 3. The subsequent arrivals are as follows: L1,2=120 and L3,2=190 at
t=100; L2,1=50 at t=200; L4,1=30 at t=250; L1,3=160 and L4,2=30 at t=300, L4,3=50 at 350, L2,2=150
and L3,3=100 at t=400; L1,4=140 at t=460; L3,4=60 and L4,4=50 at t=500; L3,5=200 at t=560;
Chapter 5 • Scheduling and Policing 95

L2,3=120 at t=600; L1,5=700 at t=700; L2,4=50 at t=800; and L2,5=60 at t=850. For every time new
packets arrive, write down the sorted finish numbers. What is the actual order of transmissions
under packet-by-packet FQ?

Problem 5.6
A transmitter works at a rate of 1 Mbps and distinguishes three types of packets: voice, data, and
video. Voice packets are assigned weight 3, data packets 1, and video packets 1.5. Assume that
initially arrive a voice packet of 200 bytes a data packet of 50 bytes and a video packet of 1000
bytes. Thereafter, voice packets of 200 bytes arrive every 20 ms and video packets every 40 ms.
A data packet of 500 bytes arrives at 20 ms, another one of 1000 bytes at 40 ms and a one of 50
bytes at 70 ms. Write down the sequence in which a packet-by-packet WFQ scheduler would
transmit the packets that arrive during the first 100 ms. Show the procedure.

Problem 5.7
Suppose a router has four input flows and one output link with the transmission rate of
1 byte/second. The router receives packets as listed in the table below. Assume the time starts at 0
and the “arrival time” is the time the packet arrives at the router. Write down the order and times
at which the packets will be transmitted under:
(a) Packet-by-packet fair queuing (FQ)
(b) Packet-by-packet weighted fair queuing (WFQ), where flows 2 and 4 are entitled to twice
the link capacity of flow 3, and flow 1 is entitled to twice the capacity of flow 2
Packet Arrival time Packet size Flow Departure order/ Departure order/
# [sec] [bytes] ID time under FQ time under WFQ
1 0 100 1
2 0 60 3
3 100 120 1
4 100 190 3
5 200 50 2
6 250 30 4
7 300 30 4
8 300 60 1
9 650 50 3
10 650 30 4
11 710 60 1
12 710 30 4
 Chapter 6
Network Monitoring

Contents
6.1 Introduction
6.1.1 x

6.1 Introduction 6.1.2 x

6.1.3 x

6.2
6.2.1 x
6.2.2 x
See: http://www.antd.nist.gov/ 6.2.3

Wireless link of a mobile user does not provide guarantees. 6.3 x

Unlike wired case, where the link parameters are relatively 6.3.1 x
6.3.2 x
stable, stability cannot be guaranteed for a wireless link. Thus, 6.3.3 x
6.3.4 x
even if lower-level protocol layers are programmed to perform
as best possible, the application needs to know the link quality. 6.4 x
The “knowledge” in the wired case is provided through quality 6.4.1 x
6.4.2
guarantees, whereas here link quality knowledge is necessary 6.4.3
to adapt the behavior. 6.5 x
6.5.1
6.5.2
6.5.3
Adaptation to the dynamics of the wireless link bandwidth is a
frequently used approach to enhance the performance of 6.6 x
6.5.1 x
applications and protocols in wireless communication 6.5.2 x
environments [Katz 1994]. Also, for resource reservation in 6.5.3 x
such environments, it is crucial to have the knowledge of the 6.7 Summary and Bibliographical Notes
dynamics of the wireless link bandwidth to perform the Problems
admission control.

96
Chapter 6 • Network Monitoring 97

6.2 Dynamic Adaptation

Holistic QoS, system level

Computation and communication delays
Combinatorial optimization

Adaptive Service Quality

It may be that only two options are offered to the customers by the server: to be or not to be
processed. In other words, quality of servicing is offered either in the fullest or no servicing at all.
But, it may be that the server offers different options for customers “in hurry.” In this case, we
can speak of different qualities of service—from no service whatsoever, through partial service,
to full service. The spectrum of offers may be discrete or continuous. Also, servicing options may
be explicitly known and advertised as such, so the customer simply chooses the option it can
afford. The other option is that servicing options are implicit, in which case they could be
specified by servicing time or cost, or in terms of complex circumstantial parameters. Generally,
we can say that the customer specifies the rules of selecting the quality of service in a given rule
specification language.

Associated with processing may be a cost of processing. Server is linked with a certain resource
and this resource is limited. Server capacity C expresses the number of customers the server can
serve per unit of time and it is limited by the resource availability.
Important aspects to consider:
• Rules for selecting QoS
• Pricing the cost of service
• Dealing with uneven/irregular customer arrivals
• Fairness of service
• Enforcing the policies/agreements/contracts
- Admission control
- Traffic shaping
Ivan Marsic • Rutgers University 98

6.2.1 Data Fidelity Reduction

Compression
Simplification
Abstraction
Conversion (different domains/modalities)

We consider the model shown in Figure 6-?? where there are multiple clients producing and/or
consuming dynamic content. Some shared content may originate or be cached locally while other
may originate from remote and change with time. The data that originates locally may need to be
distributed to other clients. The clients have local computing resources and share some global
resources, such as server(s) and network bandwidth, which support information exchange.
Although producers and consumers are interrelated, it is useful to start with a simpler model
where we consider them independently to better understand the issues before considering them
jointly. We first consider individual clients as data consumers that need to visualize the content
with the best possible quality and provide highest interactivity. We then consider clients as data
producers that need to update the consumers by effectively and efficiently employing global
resources.
We will develop a formal method for maximizing the utility of the shared content given the
limited, diverse, and variable resources. Figure 6-1 illustrates example dimensions of data
adaptation; other possible dimensions include modality (speech, text, image, etc.), security,
reliability, etc. The user specifies the rules R for computing the utilities of different data types that
may depend on contextual parameters. We define the state of the environment as a touple
containing the status of different environmental variables. For example, it could be defined as:
state = (time, location, battery energy, user’s role, task, computer type). The location may include
both the sender and the receiver location. Given a state Sj the utility of a data type Ti is
determined by applying the user-specified rules: U (Ti | S j ) = R(Ti | S j ) . We also normalize the
utilities since it is easier for users to specify relative utilities, so in a given state Sj the utilities of
all data types are: ∑ U (Ti | S j ) = 1 .
i

Our approach is to vary the fidelity and timeliness of data to maximize the sum of the utilities of
the data the user receives. Timeliness is controlled, for example, by the parameters such as update

utility

fidelity

timeliness

Figure 6-1 Dimensions of data adaptation.

Chapter 6 • Network Monitoring 99

frequency, latency and jitter. Fidelity is controlled by parameters such as the detail and accuracy
of data items and their structural relationships. Lower fidelity and/or timeliness correspond to a
lower demand for resources. Our method uses nonlinear programming to select those values for
fidelity and timeliness that maximize the total data utility, subject to the given resources. Note
that the user can also require fixed values for fidelity and/or timeliness, and seek an optimal
solution under such constraints.

6.2.2 Application Functionality Adaptation

6.2.3 Computing Fidelity Adaptation

Review CMU-Aura work

6.3 Summary and Bibliographical Notes

Problems
 Chapter 7
Technologies and Future Trends

Contents
7.1 x
7.1.1 x
burst.com Technology-Burst vs. HTTP streaming 7.1.2 x
7.1.3 x
http://www.burst.com/new/technology/versus.htm 7.2 x
7.2.1 x
7.2.2 x
7.2.3

7.3 x
7.3.1 x
7.3.2 x
Lucent ORiNICO 802.11b outdoors, no obstruction—these are 7.3.3 x
7.3.4 x
practically ideal conditions!
7.4 x
7.4.1 x
7.4.2
7.4.3

7.5 x
7.5.1
7.5.2
7.5.3

7.6 x
7.5.1 x
7.5.2 x
7.5.3 x

7.7 x
7.5.1
7.5.2
7.5.3

7.8 x
x

Transmission rate % of coverage area

11 Mbps 8%
5.5 Mbps

100
Chapter 7 • Technologies and Future Trends 101

2 Mbps
1 Mbps 47 %

Thus, low probability of having good link!!

7.1 Internet Telephony and VoIP

Voice over IP (VoIP) is an umbrella term used for all forms of packetized voice, whether it is
Internet telephony, such as Skype.com, or Internet telephony services provided by cable
operators. Voice over IP is also used interchangeably with IP telephony, which is very much
enterprise focused. And there the problems with service quality are very real.
IP telephony is really a LAN-based system and as an application inside the enterprise it is going
to be a pervasive application. The evolution from a LAN-based system to the broader context of
the Internet is not straightforward. Integrating the Voice over IP that may be on a LAN and the
Voice over IP that is going to be Internet-based is going to become a reality.
Study Shows VoIP Quality Leaves Room for Improvement
But other factors, such as external microphones and speakers, Internet connection speeds, and
operating systems, also can affect call quality and should be taken into account before writing off
a service provider's performance as poor, warns Chris Thompson, senior director for unified
communications solutions marketing at Cisco Systems. "It doesn't tend to be as much of a service
problem as it is an access or device problem for the consumer," he says.
In fact, call quality and availability are expected to vary between services, Thompson explains.
"Consumers make trade-offs based on price, accessibility, and mobility, and it's important to
understand that mix," he says. "If you were using a home telephony product from your cable
company, they would offer a different grade of service than a free service like Skype.
[Consumers] put up with a little call quality degradation for cheapness."
There is also an issue of securing IP telephony environments. We should encrypt our voice inside
the LAN, and the same applies to data and video in the long run. It is not an IP telephony or voice
over IP issue; it is an IP issue, one should not get lulled into the suspicion that IP or the layers
above it are secure. We have already seen vulnerabilities against PBXs, against handsets, so it is
only a matter of time before we see execution against these vulnerabilities. ... attacks at the server
level or at massive denial-of-service attack at the desktop level ...

7.2 Wireless Multimedia

Video phones
Ivan Marsic • Rutgers University 102

7.3 Telepresence and Telecollaboration

7.4 Augmented Reality

7.5 Summary and Bibliographical Notes

Programming Assignments

The following assignments are designed to illustrate how a simple model can allow studying
individual aspects of a complex system. In this case, we study the congestion control in TCP.
The assignments are based on the reference example software available at this web site:
http://www.caip.rutgers.edu/~marsic/Teaching/CCN/TCP/. This software implements a simple TCP
simulator for Example 2.1 (Section 2.2 above) in the Java programming language. Only the
Tahoe version of the TCP sender is implemented. This software is given only as a reference, to
show how to build a simple TCP simulator. You can take it as is and only modify or extend the
parts that are required for your programming assignments. Alternatively, you can write your own
software anew, using the programming language of your choosing. Instead of Java, you can use
C, C++, C#, Visual Basic, or another programming language.

Project Report Preparation

When you get your program working, run it and plot the relevant charts similar to those provided
for Example 2.1. Calculate the sender utilization, where applicable, and provide explanations and
comments on the system performance. Also calculate the latency for transmitting a 1 MB file.
Each chart/table should have a caption and the results should be discussed. Explain any results
that you find non-obvious or surprising. Use manually drawn diagrams (using a graphics program
such as PowerPoint), similar to Figure 2-10 and Figure 2-11, where necessary to support your
arguments and explain the detailed behavior.

Assignment 1: TCP Reno

Implement the Reno version of the TCP sender which simulates Example 2.1. You can use the
Java classes from the TCP-Tahoe example, in which case you only need to extend from
TCPSender and implement TCPSenderReno, fashioned after the existing
TCPSenderTahoe. Alternatively, you can implement everything anew. Use RFC 2581 as the
primary reference, to be found here http://www.apps.ietf.org/rfc/rfc2581.html.
(a) Use the same network parameters as in Example 2.1.
(b) Modify the router to randomly drop up to one packet during every transmission round, as
follows. The router should draw a random number from a uniform distribution between 0
and bufferSize, which in our case equals to 7. Use this number as the index of the

103
Ivan Marsic • Rutgers University 104

segment to delete from the segments array. (Note that the given index may point to a
null element if the array is not filled up with segments, in which case do nothing.)
1. Compare the sender utilization for the TCP Reno sender with that of a Tahoe sender (given in
Figure 2-12). Explain any difference that you may observe.
2. Compare the sender utilization for case (b) with random dropping of packets at the router.
3. Show the detail of slow-start and additive increase phases diagrams. Compare them to Figure
2-10 and Figure 2-11. Explain any differences that you may find.
Include these findings in your project report, which should be prepared as described at the
beginning of this section.

Assignment 2: TCP Tahoe with Bandwidth Bottleneck

Consider the network configuration as in the reference example, but with the router buffer size set
to a large number, say 10,000 packets. Assume that RTT = 0.5 s and that at the end of every RTT
period the sender receives a cumulative ACK for all segments relayed by the router during that
period.
Due to the large router buffer size there will be no packet loss, but the bandwidth mismatch
between the router’s input and output lines still remains. Because of this, the router may not
manage to relay all the packets from the current round before the arrival of the packets from the
subsequent round. The remaining packets are carried over to the next round and accumulate in the
router’s queue. As the sender’s congestion window size grows, there will be a queue buildup at
the router. There will be no loss because of the large buffer size, but packets will experience
delays. The packets carried over from a previous round will be sent first, before the newly arrived
packets. Thus, the delays still may not trigger the RTO timer at the sender because the packets
may clear out before the timeout time expires.
The key code modifications are to the router code, which must be able to carry over the packets
that were not transmitted within one RTT. In addition, you need to modify
TCPSimulator.java to increase the size of the arrays segments and acks, since these
currently hold only up to 100 elements.
1. Determine the average queuing delay per packet once the system stabilizes. Explain why
buffer occupancy will never reach its total capacity. Are there any retransmissions (quantify,
how many) due to large delays, although packets are never lost. Use manually drawn
diagrams to support your arguments.
2. In addition to the regular charts, plot the two charts shown in the following figure:
The chart on the left should show the number of the packets that remain buffered in the router
at the end of each transmission round, which is why the time axis is shown in RTT units.
(Assume the original TimeoutInterval = 3×RTT = 3 sec.) To generate the chart on the
right you should vary the size of TimeoutInterval and measure the corresponding
utilization of the TCP sender. Of course, RTT remains constant at 1 sec. (Notice the
logarithmic scale on the horizontal axis. Also, although it may appear strange to set
TimeoutInterval smaller than RTT, this illustrates the scenario where RTT may be
unknown, at least initially.) Provide explanation for any surprising observations or anomalies.
Programming Assignments 105

Number of packets left unsent in the router TCP Sender utilization [%]
buffer at the end of each transmission round

Assumption: RTT = 1 second

Time TimeoutInterval
0 1 2 3 4 [in RTT units] 0.1 1 10 100 [seconds]

Prepare the project report as described at the beginning of this section.

Assignment 3: TCP Tahoe with More Realistic Time Simulation

and Packet Reordering
In the reference example implementation, the packet sending times are clocked to the integer
multiples of RTT (see Figure 2-6). For example, Packets #2 and 3 are sent together at the time = 1
× RTT; packets #4, 5, 6, and 7 are sent together at the time = 2 × RTT; and so on. Obviously, this
does not reflect the reality, as illustrated in Figure 2-1. Your task is to implement a new version of
the TCP Tahoe simulator, so that segments are sent one-by-one, independently of each other
rather than all “traveling” in the same array.
When designing your new version, there are several issues to consider. Your iterations are not
aligned to RTT as in the reference implementation, but you need to make many more iterations.
How many? You calculate this as follows. We are assuming that the sender always has a segment
to send (sending a large file); so, it will send if EffectiveWindow allows. Given the speed of
the first link (10 Mbps) and the segment size (MSS = 1KB), you can calculate the upper limit to
the number of segments that can be sent within one RTT. This yields your number of iterations
per one RTT; the total number of iterations should be run for at least 100 × RTT for a meaningful
comparison with the reference example.
When your modified TCPSimulator.java invokes the TCP sender, your modified sender
should check the current value of EffectiveWindow and return a segment, if allowed;
otherwise, it returns a nil pointer. Keep in mind that your modified sender returns a single
segment, not an array as in the reference implementation. Also, instead of the above upper limit
of sent segments, the actual number sent is limited by the dynamically changing
EffectiveWindow.
Next, the sender’s return value is passed on to the router. If it is a segment (i.e., not a nil pointer),
the router stores it in its buffer unless the buffer is already full, in which case the segment is
discarded. To simulate the ten times higher transmission speed on the first link (see Example 2.1),
only at each tenth invocation the router removes a segment from its buffer and returns it;
otherwise it returns a nil pointer. The receiver is invoked only when the router returns a non-nil
segment. The receiver processes the segment and returns an ACK segment or nil; this return value
is passed on to the sender and the cycle repeats. The reason for the receiver to return a nil pointer
is explained below.
Notice that, unlike Example 2.1 where a segment can arrive at the receiver out-of-sequence only
because a previous segment was dropped at the router, in your assignment an additional reason
Ivan Marsic • Rutgers University 106

for out-of-sequence segments is that different segments can experience different amounts of
delay. To simulate the packet re-ordering, have the router select two packets in its buffer for
random re-ordering, at pre-specified periods. The router simply swaps the locations of the
selected pair of segments in the buffer. The re-ordering period should be made an input variable
to the program. Also, the number of reordered packet pairs should be an input variable to the
program.
As per Figure 2-5, after receiving an in-order segment, the receiver should wait for an arrival of
one more in-order segment and sends a cumulative acknowledgment for both segments. Hence,
the return value for the first segment is a nil pointer, instead an ACK segment, as described
above. Recall, however, that for every out-of-order segment, the receiver reacts immediately and
sends a duplicate ACK (see Figure 2-5).
Prepare the project report as described at the beginning of this section. Average over multiple
runs to obtain average sender utilization.

Assignment 4: TCP Tahoe with a Concurrent UDP Flow

In the reference example implementation, there is a single flow of packets, from the sender, via
the router, to the receiver. Your task is to add an additional, UDP flow of packets that competes
with the TCP flow for the router resources (i.e., the buffering memory space). Modify the router
Java class so that it can accept simultaneously input from a TCP sender and an UDP sender, and
it should correctly deliver the packets to the respective TCP receiver and UDP receiver. The UDP
sender should send packets in an ON-OFF manner. First, the UDP sender enters an ON period for
the first four RTT intervals and it sends five packets at every RTT interval. Then the UDP sender
enters an OFF period and becomes silent for four RTT intervals. This ON-OFF pattern of activity
should be repeated for the duration of the simulation. At the same time, the TCP Tahoe sender is
sending a very large file via the same router.
1. In addition to the TCP-related charts, plot also the charts showing the statistics of the packet
loss for the UDP flow.
2. How many iterations takes the TCP sender to complete the transmission of a 1 MByte file?
(Since randomness is involved, you will need to average over multiple runs.)
3. Perform the experiment of varying the UDP sender regime as shown in the figure below. In
the diagram on the left, the UDP sender keeps the ON/OFF period duration unchanged and
varies the number of packets sent per transmission round. In the diagram on the right, the
UDP sender sends at a constant rate of 5 packets per transmission round, but varies the length
of ON/OFF intervals.
4. Based on these two experiments, can you speculate how increasing the load of the competing
UDP flow affects the TCP performance? Is the effect linear or non-linear? Can you explain
your observation?
Prepare the project report as described at the beginning of this section.
Programming Assignments 107

Note: UDP sender ON period = 4 × RTT Note: UDP sender sends 5 packets in every

Sender utilization
Sender utilization OFF period = 4 × RTT transmission round during an ON period
de r er
Sen end
P PS
UD UD

er er
end end
PS PS
TC TC

1 2 3 4 5 6 7 8 9 10 ON =1 ON =2 ON =3 ON =3 ON =4 ON =4
OFF=0 OFF=1 OFF=1 OFF=3 OFF=2 OFF=4
Number of packets sent in ON =1 ON =2 ON =3 ON =4 ON =4 ON =5
one round of ON interval OFF=1 OFF=2 OFF=2 OFF=1 OFF=3 OFF=1

Length of ON/OFF interval [in RTT units]

Assignment 5: Competing TCP Tahoe Senders

Suppose that you have a scenario where two TCP Tahoe senders send data segments via the same
router to their corresponding receivers. In case the total number of packets arriving from both
senders exceeds the router’s buffering capacity, the router should discard all the excess packets as
follows. Discard the packets that are the tail of a group of arrived packets. The number of packets
discarded from each flow should be (approximately) proportional to the total number of packets
that arrived from the respective flow. That is, if more packets arrive from one sender then
proportionally more of its packets will be discarded, and vice versa.
Assume that the second sender starts sending with a delay of three RTT periods after the first
sender. Plot the relevant charts for both TCP flows and explain any differences or similarities in
the corresponding charts for the two flows. Calculate the total utilization of the router’s output
line and compare it with the throughputs achieved by individual TCP sessions. Note: to test your
code, you should swap the start times of the two senders so that now the first sender starts
sending with a delay of three RTT periods after the second sender.
In addition to the above charts, perform the
experiment of varying the relative delay in der
1
Sender utilization

Sen
transmission start between the two senders. Plot the
utilization chart for the two senders as shown in the 2
der
figure. Are the utilization curves for the two Sen

senders different? Provide an explanation for your Relative delay of

answer. Note: Remember that for fair comparison transmission start
you should increase the number of iterations by the 0 1 2 3 4 5 6 7 [in RTT units]
amount of delay for the delayed flow.
Prepare the project report as described at the beginning of this section.

Assignment 6: Random Loss and Early Congestion Notification

The network configuration is the same as in Example 2.1 with the only difference being in the
router’s behavior.
Ivan Marsic • Rutgers University 108

(a) First assume that, in addition to discarding the packets that exceed the buffering capacity,
the router also discards packets randomly. For example, suppose that 14 packets arrive at
the router in a given transmission round. Then in addition to discarding all packets in
excess of 6+1=7 as in the reference example, the router also discards some of the six
packets in the buffer. For each packet currently in the buffer, the router draws a random
number from a normal distribution, with the mean equal to zero and adjustable standard
deviation. If the absolute value of the random number exceeds a given threshold, then the
corresponding is dropped. Otherwise, it is forwarded.
(b) Second, assume that the router considers for discarding only the packets that are located
within a certain zone in the buffer. For example, assume that the random-drop zone starts
at 2/3 of the total buffer space and
Packet currently
runs up to the end of the buffer. Router buffer being transmitted
Then perform the above dropping
procedure only on the packets that 6 5 4 3 2 1 0
are located between 2/3 of the total
buffer space and the end of the
Random-drop zone:
buffer. (Packets that arrive at a full Packets subject to
Head of the queue

buffer are automatically dropped!) being dropped

Drop start location

Your program should allow entering different values of parameters for running the simulation,
such as: variance of the normal distribution and the threshold for random dropping the packets in
(a); and, the start discarding location in (b).
1. In addition to the regular charts, plot the three-dimensional chart shown in the figure. (Use
MatLab or a similar tool to
draw the 3D graphics.) Since
the router drops packets
TCP Sender average utilization [%]

randomly, you should repeat

the experiment several times
(minimum 10) and plot the
average utilization of the TCP
sender.
2. Find the regions of maximum
and minimum utilization and
indicate the corresponding
points/regions on the chart. 5
Explain your findings: why Ran 4
dom 3 100
80
dro fer]
the system exhibits higher/ p th 2 40
60
of buf
resh 1
old 20 e start [%
lower utilization with certain (σ)
0 0
om dr
op zon
Rand
parameters?
3. You should also present
different two-dimensional cross-sections of the 3D graph, if this can help illuminate your
discussion.
Prepare the project report as described at the beginning of this section.
Solutions to Selected Problems

Problem 1.1 — Solution

Problem 1.2 — Solution

(a)
Having only a single path ensures that all packets will arrive in order, although some may be lost
or damaged due to the non-ideal channel. Assume that A sends a packet with SN = 1 to B and the
packet is lost. Since A will not receive ACK within the timeout time, it will retransmit the packet
using the same sequence number, SN = 1. Since B already received a packet with SN = 1 and it is
expecting a packet with SN = 0, it concludes that this is a duplicate packet.
(b)
If there are several alternative paths, the packets can arrive out of order. There are many possible
cases where B receives duplicate packets and cannot distinguish them. Two scenarios are shown
below, where either the retransmitted packet or the original one gets delayed, e.g., by taking a
longer path. These counterexamples demonstrate that the alternating-bit protocol cannot work
over a general network.
Sender A Receiver B Sender A Receiver B
Time

SN=0
pkt #1 SN=0
Tout ack0 Tout

Retransmit Retransmit
SN=0 SN=0
pkt #1
ack0
SN=1
pkt #2 SN=1
ack1
pkt #2
ack1
SN=0 (lost) pkt #1
ack0 (duplicate, pkt #1
SN=0 (duplicate,
SN=1 mistaken for pkt #3)
mistaken for pkt #3)
pkt #3
pkt #3
(Scenario 1) (Scenario 2)

Problem 1.3 — Solution

109
Ivan Marsic • Rutgers University 110

Problem 1.4 — Solution

Problem 1.5 — Solution

Recall that the utilization of a sender is defined as the fraction of time the sender is actually busy
sending bits into the channel. Since we assume errorless communication, the sender is maximally
used when it is sending without taking a break to wait for an Sender Receiver
acknowledgement. This happens if the first packet of the window is #1
#2
acknowledged before the transmission of the last packet in the window #3
#4
is completed. That is,
ack #1
(N − 1) × tx ≥ RTT = 2 × tp #N
#N+1

where tx is the packet transmission delay and tp is the propagation delay.

The left side represents the transmission delay for the remaining (N − 1) packets of the window,
⎡2×tp ⎤
after the first packet is sent. Hence, N ≥ ⎢ ⎥ + 1 . The ceiling operation ⎡⋅⎤ ensures integer
⎢ tx ⎥
number of packets.
In our case, l = 10 km, v ≈ 2 × 108 m/s, R = 1 Gbps, and L = 512 bytes.
L 512 × 8 (bits)
Hence, the packet transmission delay is: t x = = = 4.096 μs
R 1 × 109 (bits / sec)

l 10000 m
The propagation delay is: t p = = = 50 μs
v 2 × 108 m / s

Finally, N ≥ ⎡24.41⎤ + 1 = 26 packets.

Problem 1.6 — Solution

The solution is shown in the following figure. We are assuming that the retransmission timer is
set appropriately, so ack0 is received before the timeout time expires. Notice that host A simply
ignores the duplicate acknowledgements of packets 0 and 3, i.e., ack0 and ack3.
There is no need to send end-to-end acknowledgements (from C to A) in this particular example
since both AB and BC links are reliable and there are no alternative paths from A to C but via
B. The reader should convince themselves that should alternative routes exist, e.g., via another
host D, then we would need end-to-end acknowledgements in addition to (or instead of) the
acknowledgements on individual links.
Solutions to Selected Problems 111

A Go-back-3 B SR, N=4 C

pkt0
pkt1
pkt2 (lost) ack0
Tout pkt0
pkt3 ack0 ack0
Retransmit pkt1 (retransmission) ack0
pkt1, pkt2, pkt3 pkt2 (retransmission)
pkt3 (retransmission) ack1 pkt1
ack2 pkt2
pkt4 ack3 pkt3 ack1
pkt5 (lost) ack2
Tout pkt6 ack3
ack3
(retransmission)
ack3
Retransmit pkt4
pkt4, pkt5, pkt6 pkt5 (retransmission)
pkt6 (retransmission) ack4
pkt4
ack5 (lost)
pkt5
ack6 pkt6 pkt4 & pkt5
ack5
Time

Tout buffered
ack6
Retransmit pkt4 (retransmission)
pkt4
ack4

Problem 1.7 — Solution

The solution is shown in the following figure.
A SR, N=4 B Go-back-3 C
pkt0
pkt1
(lost)
pkt2 ack0
pkt0
Tout pkt3
pkt4 (lost) ack2 ack0
Retransmit pkt1 (retransmission) ack3
pkt1

Tout ack1 pkt1

Retransmit pkt4 pkt4 (retransmission) pkt2
pkt5 pkt3 ack1
pkt6 ack4 ack2
ack5 pkt4 ack3
ack6 pkt5 (lost)
pkt6
Tout ack3
pkt2 & pkt3 ack3
Retransmit pkt4 (retransmission)
Time

buffered at
host B pkt4, pkt5, pkt6 pkt5
pkt6 ack4
ack5
ack6
 Ivan Marsic • Rutgers University 112

Problem 1.8 — Solution

It is easy to get tricked into believing that the second, (b), configuration would offer better
performance, since the router can send in parallel in both directions. However, this is not true, as
will be seen below.
(a)
Propagation delay = 300 m / (2 × 108) = 1.5 × 10−6 s = 1.5 μs
Transmission delay per data packet = 2048×8 / 106 = 16.384 × 10−3 = 16.384 ms
Transmission delay per ACK = 108 / 106 = 0.08 × 10−3 = 0.08 ms
Transmission delay for N = 5 (window size) packets = 16.384×5 < 82
82 + 0.08 + 0.0015 × 2 = 82.083
Subtotal time for 100 packets in one direction = 100 × 82.083 / 5 = 1641.66 ms
Total time for two ways = 1641.66 × 2 = 3283.32 ms

(b)
If host A (or B) sends packets after host B (or A) finishes sending, then the situation is similar to
(a) and the total time is about 3283.32 ms.
If hosts A and B send a packet each simultaneously, the packets will be buffered in the router and
then forwarded. The time needed is roughly double (!), as shown in this figure.
Host A Router Host B

Host A Host A

0
81 + 0.08 + 0.0015 × 2

16 × 5 × 2 = 160 ms
= 81.083

ACK

ACK

(a) (b)
Solutions to Selected Problems 113

Problem 1.9 — Solution

Go-back-N ARQ.
Packet error probability = pe for data packets; ACKs error free. Successful receipt of a given
packet with the sequence number k requires successful receipt of all previous packets in the
sliding window. In the worst case, retransmission of frame k is always due to corruption of the
k
earliest frame appearing in its sliding window. So, psucc = ∏ (1 − p ) = (1 − p )
i =k − N
e e
N
, where N is the

sliding window size. An upper bound estimate of E{n} can be obtained easily using Eq. (1.7) as
1 1
E{n} = = . On average, however, retransmission of frame k will be due to an error
psucc (1 − pe )N
in frame (k−LAR)/2, where LAR denotes the sequence number of the Last Acknowledgement
Received.
(a)
Successful transmission of one packet takes a total of tsucc = tx + 2×tp
The probability of a failed transmission in one round is pfail = 1 − psucc = 1 − (1 − pe)N
Every failed packet transmission takes a total of tfail = tx + tout
(assuming that the remaining N−1 packets in the window will be transmitted before the timeout
occurs for the first packet).
Then, using Eq. (1.8) the expected (average) total time per packet transmission is:
pfail
E{Ttotal } = tsucc + ⋅ tfail
1 − pfail

(b)
If the sender operates at the maximum utilization (see the solution of Problem 1.5 above), then
the sender waits for N−1 packet transmissions for an acknowledgement, tout = (N−1) ⋅ tx, before a
packet is retransmitted. Hence, the expected (average) time per packet transmission is:
pfail ⎛ p ⎞
E{Ttotal } = tsucc + ⋅ tfail = 2 ⋅ t p + t x ⋅ ⎜⎜1 + ( N − 1) ⋅ fail ⎟⎟
1 − pfail ⎝ 1 − pfail ⎠

Problem 1.10 — Solution

(a)
Packet transmission delay equals = 1024 × 8 / 64000 = 0.128 sec; acknowledgement transmission
delay is assumed to be negligible. Therefore, the throughput SMAX = 1 packet per second (pps).
(b)
Ivan Marsic • Rutgers University 114

To evaluate E{S}, first determine how many times a given packet must be (re-)transmitted for
successful receipt, E{n}. According to Eq. (1.7), E{n} = 1/p ≅ 1.053. Then, the expected
throughput is E{S } = MAX = 0.95 pps.
S
E{n}
(c)
64000
The fully utilized sender sends 64Kbps, so SMAX = = 7.8125 pps.
1024 × 8
(d)
Again, we first determine how many times a given packet must be (re-)transmitted for successful
receipt, E{n}. The sliding window size can be determined as N = 8 (see the solution for Problem
1.5 above). A lower bound estimate of E{S} can be obtained easily by recognizing that E{n} ≤
1/p8 ≅ 1.5 (see the solution for Problem 1.9 above). Then, SMAX×p8 ≅ (7.8125)×(0.6634) ≅ 5.183
pps represents a non-trivial lower bound estimate of E{S}.

Problem 1.11 — Solution

(a)
Example IP address assignment is as shown:

Subnet
Subnet
223.1.1.4/30
223.1.1.0/30 223.1.1.5
223.1.1.1

A C
223.1.1.2 223.1.1.6
R1
B D
223.1.1.3 223.1.1.7

223.1.1.9
R2
Subnet 223.1.1.10
223.1.1.8/30 223.1.1.13

E F
223.1.1.14 223.1.1.15

Subnet
223.1.1.12/30

(b)
Routing tables for routers R1 and R2 are:
Destinat. IPaddr / Subnet Mask Next Hop Output Interface
Router R1
223.1.1.2 (A) 223.1.1.2 (A) 223.1.1.1
223.1.1.3 (B) 223.1.1.3 (B) 223.1.1.1
Solutions to Selected Problems 115

223.1.1.6 (C) 223.1.1.6 (C) 223.1.1.5

223.1.1.7 (D) 223.1.1.7 (D) 223.1.1.5
223.1.1.12/30 223.1.1.10 223.1.1.9

Destinat. IPaddr / Subnet Mask Next Hop Output Interface

Router R2
223.1.1.14 (E) 223.1.1.14 (E) 223.1.1.13
223.1.1.15 (F) 223.1.1.15 (F) 223.1.1.13
223.1.1.0/30 223.1.1.9 223.1.1.10
223.1.1.4/30 223.1.1.9 223.1.1.10

Problem 1.12 — Solution

Recall that in CIDR the x most significant bits of an address of the form a.b.c.d/x constitute the
network portion of the IP address, which is referred to as prefix (or network prefix) of the
address. In our case the forwarding table entries are as follows:
Subnet mask Network prefix Next hop
223.92.32.0/20 11011111 01011100 00100000 00000000 A
223.81.196.0/12 11011111 01010001 11000100 00000000 B
223.112.0.0/12 11011111 01110000 00000000 00000000 C
223.120.0.0/14 11011111 01111000 00000000 00000000 D
128.0.0.0/1 10000000 00000000 00000000 00000000 E
64.0.0.0/2 01000000 00000000 00000000 00000000 F
32.0.0.0/3 00100000 00000000 00000000 00000000 G
Notice that the network prefix is shown in bold face, whereas the remaining 32−x bits of the
address are shown in gray color. When forwarding a packet, the router considers only the leading
x bits of the packet’s destination IP address, i.e., its network prefix.
Packet destination IP address Best prefix match Next hop
(a) 195.145.34.2 = 11000011 10010001 00100010 00000010 1 E
(b) 223.95.19.135 = 11011111 01011111 00010011 10000111 11011111 0101 B
(c) 223.95.34.9 = 11011111 01011111 00100010 00001001 11011111 0101 B
(d) 63.67.145.18 = 00111111 01000011 10010001 00010010 001 G
(e) 223.123.59.47 = 11011111 01111011 00111011 00101111 11011111 011110 D
(f) 223.125.49.47 = 11011111 01111101 00110001 00101111 11011111 0111 C

Problem 1.13 — Solution

The packet forwarding is given as follows:
Destination IP address Binary representation Next hop
(a) 128.6.4.2 (cs.rutgers.edu) 10000000 00000110 00000100 00000010 A
Ivan Marsic • Rutgers University 116

(b) 128.6.236.16 (caip.rutgers.edu) 10000000 00000110 11101100 00010000 B

(c) 128.6.29.131 (ece.rutgers.edu) 10000000 00000110 00011101 10000011 C
(d) 128.6.228.43 (toolbox.rutgers.edu) 10000000 00000110 11100100 00001010 D
From this, we can reconstruct the routing table as:
Network Prefix Subnet Mask Next Hop
10000000 00000110 0000 128.6.0.0 / 20 A
10000000 00000110 11101 128.6.232.0 / 21 B
10000000 00000110 0001 128.6.16.0 / 20 C
10000000 00000110 111 128.6.224.0 / 19 D
Notice that in the last row we could have used the prefix “10000000 00000110 11100” and the
subnet mask “128.6.224.0 / 21” but it suffices to use only 19 most significant bits since the router
forwards to the best possible match.

Problem 1.14 — Solution

The tables of distance vectors at all nodes after the network stabilizes are shown in the leftmost
column of the figure below. Notice that, although, there are two alternative AC links, the nodes
select the best available, which is AC =1.
When the link AC with weight equal to 1 is broken, both A and C detect the new best cost AC
as 50.
1. A computes its new distance vector as
D A ( B ) = min{c( A, B ) + D B ( B), c( A, C ) + DC ( B)} = min{4 + 0, 50 + 1} = 4
D A (C ) = min{c( A, C ) + DC (C ), c( A, B ) + D B (C )} = min{50 + 0, 4 + 1} = 5
Similarly, C computes its new distance vector as
DC ( A) = min{c(C , A) + D A ( A), c(C , B) + D B ( A)} = min{50 + 0, 1 + 2} = 3
DC ( B ) = min{c(C , B) + D B ( B), c(C , A) + D A ( B )} = min{1 + 0, 50 + 2} = 1
Having a global view of the network, we can see that the new cost DC(A) via B is wrong.
Of course, C does not know this and therefore a routing loop is created.
Both B and C send their new distance vectors out, each to their own neighbors, as shown
in the second column in the figure (first exchange).
2. Upon receiving C’s distance vector, A is content with its current d.v. and makes no
changes. Ditto for node C.
B computes its new distance vector as
D B ( A) = min{c( B, A) + D A ( A), c( B, C ) + DC ( A)} = min{4 + 0, 1 + 3} = 4
D B (C ) = min{c( B, C ) + DC (C ), c( B, A) + D A (C )} = min{1 + 0, 4 + 5} = 1
B sends out its new distance vector to A and C (second exchange).
3. Upon receiving B’s distance vector, A does not make any changes so it remains silent.
Meanwhile, C updates its distance vector to the correct value for DC(A) and sends out its
new distance vector to A and B (third exchange).
4. A and B will update the C’s distance vector in their own tables, but will not make further
updates to their own distance vectors. There will be no further distance vector exchanges
related to the AC breakdown event.
Solutions to Selected Problems 117
After AC=1 is broken,
Before AC=1 is broken: 2nd exchange: 3rd exchange:
1st exchange:

A Distance to Distance to Distance to Distance to

Routing table A B C A B C A B C A B C
at node A
A 0 2 1 A 0 4 5 A 0 4 5 A 0 4 5

From
From

From

From
B 2 0 1 B 2 0 1 B 2 0 1 B 4 0 1
C 1 1 0 C 1 1 0 C 3 1 0 C 3 1 0

B Distance to Distance to Distance to Distance to

Routing table

A B C A B C A B C A B C
at node B

A 0 2 1 A 0 2 1 A 0 4 5 A 0 4 5

From
From

From

From
B 2 0 1 B 2 0 1 B 4 0 1 B 4 0 1
C 1 1 0 C 1 1 0 C 3 1 0 C 3 1 0

C Distance to Distance to Distance to Distance to

Routing table

A B C A B C A B C A B C
at node C

A 0 2 1 A 0 2 1 A 0 4 5 A 0 4 5
From

From

From
From
B 2 0 1 B 2 0 1 B 2 0 1 B 4 0 1

C 1 1 0 C 3 1 0 C 3 1 0 C 5 1 0

Problem 1.15 — Solution

Problem 1.16 — Solution

Problem 2.1 — Solution

(a)
Scenario 1: the initial value of TimeoutInterval is picked as 3 seconds.
At time 0, the first segment is transmitted and the initial value of TimeoutInterval is set as 3
s. The timer will expire before the ACK arrives, so the segment is retransmitted and this time the
RTO timer is set to twice the previous size, which is 6 s. The ACK for the initial transmission
arrives at 5 s, but the sender cannot distinguish whether this is for the first transmission or for the
retransmission. This does not matter, since the sender simply accepts the ACK, doubles the
congestion window size (it is in slow start) and sends the second and third segments. The RTO
timer is set at the time when the second segment is transmitted and the value is 6 s (unchanged).
At 8 s a duplicate ACK will arrive for the first segment and it will be ignored, with no action
 Ivan Marsic • Rutgers University 118

taken. At 10 s, the ACKs will arrive for the second and third segments, the congestion window
doubles and the sender sends the next four segments. SampleRTT is measured for both the
second and third segments, but we assume that the sender sends the fourth segment immediately
upon receiving the ACK for the second. This is the first SampleRTT measurement so
EstimatedRTT = SampleRTT = 5 s
DevRTT = SampleRTT / 2 = 2.5 s
and the RTO timer is set to
TimeoutInterval = EstimatedRTT + 4 ⋅ DevRTT = 15 s
After the second SampleRTT measurement (ACK for the third segment), the sender will have
EstimatedRTT = (1−α) ⋅ EstimatedRTT + α ⋅ SampleRTT
= 0.875 × 5 + 0.125 × 5 = 5 s
DevRTT = (1−β) ⋅ DevRTT + β ⋅ | SampleRTT − EstimatedRTT |
= 0.75 × 2.5 + 0.25 × 0 = 1.875 s
but the RTO timer is already set to 15 s and remains so while the fifth, sixth, and seventh
segments are transmitted. The following table summarizes the values that TimeoutInterval
is set to for the segments sent during the first 11 seconds:
Times when the RTO timer is set RTO timer values
t = 0 s (first segment is transmitted) TimeoutInterval = 3 s (initial guess)
t = 3 s (first segment is retransmitted) TimeoutInterval = 6 s (RTO doubling)
t = 10 s (fourth and subsequent segments) TimeoutInterval = 15 s (estimated value)

Sender Receiver Sender Receiver

Time

0 seg-0 0 seg-0
T-out=5
T-out=3

seg-0 seg-0
3 seg-0 (r
etransm ack-1 3 ack-1
it)
T-out=6

5 seg-1 5 seg-1
duplicate
seg-2 ack-1 seg-2
T-out=15

seg-1 seg-1
8 seg-2 8 seg-2
9 9
seg-3 seg-3
11 seg-4 11 seg-4
T-out=12.5

seg-5 seg-5
T-out=15

seg-6 seg-3 seg-6 seg-3

… …

Scenario 1: initial T-out = 3 s Scenario 2: initial T-out = 5 s

(b)
As shown in the above figure, the sender will transmit seven segments during the first 11 seconds
and there will be a single (unnecessary) retransmission.
(c)
Solutions to Selected Problems 119

Scenario 2: the initial value of TimeoutInterval is picked as 5 seconds.

This time the sender correctly guessed the actual RTT interval. Therefore, the ACK for the first
segment will arrive before the RTO timer expires. This is the first SampleRTT measurement
and, as above, EstimatedRTT = 5 s, DevRTT = 2.5 s. When the second segment is transmitted,
the RTO timer is set to TimeoutInterval = EstimatedRTT + 4 ⋅ DevRTT = 15 s.
After the second SampleRTT measurement (ACK for the second segment), the sender will have,
as above, EstimatedRTT = 5 s, DevRTT = 1.875 s.
When the fourth segment is transmitted, the RTO timer is set to
TimeoutInterval = EstimatedRTT + 4 ⋅ DevRTT = 12.5 s
After the third SampleRTT measurement (ACK for the third segment), the sender will have
EstimatedRTT = 0.875 × 5 + 0.125 × 5 = 5 s
DevRTT = 0.75 × 1.875 + 0.25 × 0 = 1.40625 s
but the RTO timer is already set to 12.5 s and remains so while the fifth, sixth, and seventh
segments are transmitted. The following table summarizes the values that TimeoutInterval
is set to for the segments sent during the first 11 seconds:
Times when the RTO timer is set RTO timer values
t = 0 s (first segment is transmitted) TimeoutInterval = 3 s (initial guess)
t = 5 s (second segment is transmitted) TimeoutInterval = 15 s (estimated value)
t = 10 s (fourth and subsequent segments) TimeoutInterval = 12.5 s (estimated val.)

Problem 2.2 — Solution

The congestion window diagram is shown in the figure below.
First, notice that since both hosts are fast and there is no packet loss, the receiver will never buffer
the received packets, so sender will always get notified that RcvWindow = 20 Kbytes, which is
the receiver’s buffer size.
The congestion window at first grows exponentially. However, in transmission round #6 the
congestion window of 32 × MSS = 32 Kbytes exceeds RcvWindow = 20 Kbytes. At this point
the sender will send only min{CongWin, RcvWindow} = 20 segments and when these get
acknowledged, the congestion window grows to 52 × MSS, instead of 64 × MSS under the
exponential growth. Thereafter, the sender will keep sending only 20 segments and the
congestion window will keep growing by 20 × MSS.
It is very important to notice that the growth is not exponential after the congestion window
becomes 32 × MSS.
In transmission round #8 the congestion window grows to 72 × MSS, at which point it exceeds the
slow start threshold (initially set to 64 Kbytes), and the sender enters the congestion avoidance
state.
Ivan Marsic • Rutgers University 120

72

SSThresh = 64 Kbytes
Congestion window size

52

32

RcvBuffer = 20 Kbytes
16

8
4
1
1 2 3 4 5 6 7 8 9 Transmission round
This diagram has the same shape under different network speeds, the only difference being that a
transmission round lasts longer, depending on the network speed.

Problem 2.3 — Solution

Problem 2.4 — Solution

Notice that sender A keeps a single RTO retransmission timer for all outstanding packets. Every
time a regular, non-duplicate ACK is received, the timer is reset if there remain outstanding
packets. Thus, although a timer is set for segments sent in round 3×RTT, including segment #7,
the timer is reset at time 4×RTT since packet #7 is unacknowledged. This is why the figure
below shows the start of the timer for segment #7 at time 4×RTT, rather than at 3×RTT.
At time 5×RTT, sender A has not yet detected the loss of #7 (neither the timer expired, nor three
dupACKs were received), so CongWin = 7×MSS (remains constant). There are two segments in
flight (segments #7 and #8), so at time = 5×RTT sender A could send up to
EffctWin = min{CongWin, RcvWindow} − FlightSize = min{7, 64} − 2 = 5×MSS
but it has nothing left to send, A sends a 1-byte segment to keep the connection alive. Recall that
TCP guarantees reliable transmission, so although sender sent all data it cannot close the
connection until it receives acknowledgement that all segments successfully reached the receiver.
Ditto for sender B at time = 7×RTT.
Solutions to Selected Problems 121

[bytes] [MSS]
4

Tahoe Sender A
4096 8 7 Timer timeout
7

CongWin
2048 4
3
1024 2
512 1 Time
1 2 3 4 5 6 7 [RTT]

(1-byte)
#7
#8
#2,3
#1

#4,5,6,7
4
Reno Sender B

4096 8 7
7
CongWin

2048 4

1024 2
512 1
1 2 3 4 5 6 7 8 9
#7
(1-byte)
#8
#2,3
#4,5,6,7
#1

The A’s timer times out at time = 6×RTT (before three dupACKs are received), and A re-sends
segment #7 and enters slow start. At 7×RTT the cumulative ACK for both segments #7 and #8 is
received by A and it, therefore, increases CongWin = 1 + 2 = 3×MSS, but there is nothing left to
send.
The Reno sender, B, behaves in the same way as the Tahoe sender because the loss is detected by
the expired RTO timer. Both types of senders enter slow start after timer expiration. (Recall that
the difference between the two types of senders is only in Reno implementing fast recovery,
which takes place after three dupACKs are received.)

Problem 2.5 — Solution

The range of congestion window sizes is [1, 16]. Since the loss is detected when CongWindow =
16×MSS, SSThresh is set to 8×MSS. Thus, the congestion window sizes in consecutive
transmission rounds are: 1, 2, 4, 8, 9, 10, 11, 12, 13, 14, 15, and 16 MSS (see the figure below).
This averages to 9.58×MSS per second (recall, a transmission round is RTT = 1 sec), and a mean
9.58 × 8
utilization of [Kbps/Kbps] = 0.59875, or about 60%.
128
Ivan Marsic • Rutgers University 122

Congestion window size

16

4
1

10
11
12
2
1

3
4
5
6
7
8
9
Transmission round

Problem 2.6 — Solution

The solution of Problem 2.5 above is an idealization that cannot occur in reality. A better
approximation is as follows. The event sequence develops as follows:
packet loss happens at a router (last transmitted segment), current CongWin = 16×MSS.
the sender receives 16-1=15 ACKs which is not enough to grow CongWin to 17
but it still sends 16 new segments, last one will be lost
the sender receives 15 dupACKs, loss detected at the sender
retransmit the oldest outstanding packet, CongWin ← 1
the sender receives cumulative ACK for 16 recent segments, except for the last one
CongWin ← 2, FlightSize = 1×MSS, send one new segment
the sender receives 2 dupACKs, FlightSize = 3×MSS, EffctWin = 0, sends one 1-byte
segment
the sender receives 3rd dupACK, retransmits the oldest outstanding packet, CW ← 1
the sender receives cumulative ACK for 4 recent segments (one of them was 1-byte),
FlightSize ← 0
CongWin ← 2, the sender resumes slow start

Problem 2.7 — Solution

MSS = 512 bytes
SSThresh = 3×MSS
Sender Receiver
RcvBuffer = 2 KB = 4×MSS 1+1 packets

TimeoutInterval = 3×RTT
Solutions to Selected Problems 123

6)
,#
#5
nd
(a

6
6

t#
t#
4
t#

en
en
en

gm
gm
gm

se
e
rs
se

or
o

tf
or

tf

se
se
f
et

re
re
s

er
er

er

m
m

Ti
Ti

Ti
[bytes] [MSS]
6
4096 8
4
EffctWin
CongWin

3.91 CongWin
2048 4 3.33

1024 2 SSThresh
512 1
Time
1 2 3 4 5 6 7 [RTT]

#6
#7,8
(1-byte)
#4,5,6
#1
#2,3

At time = 3×RTT, after receiving the acknowledgement for the 2nd segment, the sender’s
congestion window size reaches SSThresh and the sender enters additive increase mode.
MSS 1
Therefore, the ACK for the 3rd segment is worth MSS × = 1 × = 0.33 MSS.
CongWindow t-1 3
CongWindow3×RTT = 3.33×MSS. Therefore the sender sends 3 segments: 4 , 5 , and 6th. The 6th
th th

segment is discarded at the router due to the lack of buffer space. The acknowledgements for the
1 1
4th and 5th segment add 1 × = 0.3 ×MSS and 1 × = 0.28 ×MSS, respectively, so
3.33 3.63
CongWindow4×RTT = 3.91×MSS. The effective window is smaller by one segment since the 6th
segment is outstanding
EffctWin = ⎣min{CongWin, RcvWindow} − FlightSize⎦ = ⎣min{3.91, 4} − 1⎦ = 2×MSS
At time = 4×RTT the sender sends two segments, both of which successfully reach the receiver.
Acknowledgements for 7th and 8th segments are duplicate ACKs, but since this makes only two so
far, so the loss of #6 is still not detected. Notice that at this time the receiver’s buffer store two
segments (RcvBuffer = 2 KB = 4 segments), so the receiver starts advertising RcvWindow =
1 Kbytes = 2 segments.
The sender computes
EffctWin = ⎣min{CongWin, RcvWindow} − FlightSize⎦ = ⎣min{3.91, 2} − 3⎦ = 0
so it sends a 1-byte segment at time = 5×RTT.
At time = 6×RTT, the loss of the 6th segment is detected via three duplicate ACKs. Recall that the
sender in fast retransmit does not use the above formula to determine the current EffctWin—it
simply retransmits the segment that is suspected lost. That is why the above figure shows
EffctWin = 2 at time = 6×RTT. The last EffctWin, at time = 7×RTT, equals 2×MSS but
there are no more data left to send.
Ivan Marsic • Rutgers University 124

Therefore, the answers are:

(a)
The first loss (segment #6 is lost in the router) happens at 3×RTT, so
CongWindow 3×RTT = 3.33×MSS.

(b)
The loss of the 6th segment is detected via three duplicate ACKs at time = 6×RTT.
Not-yet-acknowledged segments are: 6th, 7th, and 8th, a total of three.

Problem 2.8 — Solution

In solving the problem, we should keep in mind that the receiver buffer size is set relatively small
to 2Kbytes = 8×MSS.
In the transmission round i, the sender sent segments k, k+1, …, k+7, of which the segment k+3 is
lost. The receiver receives the four segments k+4, …, k+7, as out-of-order and buffers them and
sends back four duplicate acknowledgements. In addition, the receiver notifies the sender that the
new RcvWindow = 1 Kbytes = 4×MSS.
At i+1, the sender first receives three regular (non-duplicate!) acknowledgements for the first
three successfully transferred segments, so CongWin = 11×MSS. Then, four duplicate
acknowledgements will arrive while FlightSize = 5. After receiving the first three dupACKs,
Reno sender reduces the congestion window size by half, CongWin = ⎣11 / 2⎦ = 5×MSS.
The new value of SSThresh = ⎣CongWin / 2⎦ + 3×MSS = 8×MSS.
Since Reno sender enters fast recovery, each dupACK received after the first three increment the
congestion window by one MSS. Therefore, CongWin = 6×MSS. The effective window is:
EffctWin = min{CongWin, RcvWindow} − FlightSize = min{6, 4} − 5 = −1 (#)
Thus, the sender is allowed to send nothing but the oldest unacknowledged segment, k+3, which
is suspected lost.
There is an interesting observation to make here, as follows. Knowing that the receiver buffer
holds the four out-of-order segments and it has four more slots free, it may seem inappropriate to
use the formula (#) above to determine the effective window size. After all, there are four free
slots in the receiver buffer, so that should not be the limiting parameter! The sender’s current
knowledge of the network tells it that the congestion window size is 6×MSS so this should allow
sending more!? Read on.
The reason that the formula (#) is correct is that you and I know what receiver holds and where
the unaccounted segments are currently residing. But the sender does not know this! It only
knows that currently RcvWindow = 4×MSS and there are five segments somewhere in the
network. As far as the sender knows, they still may show up at the receiver. So, it must not send
anything else.
Solutions to Selected Problems 125

At i+2, the sender receives ACK asking for segment k+8, which means that all five outstanding
segments are acknowledged at once. Since the congestion window size is still below the
SSThresh, the sender increases CongWin by 5 to obtain CongWin = 11×MSS. Notice that by
now the receiver notifies the sender that the new RcvWindow = 2 Kbytes = 8×MSS, since all the
receiver buffer space freed up.
The new effective window is:
EffctWin = min{CongWin, RcvWindow} − FlightSize = min{11, 8} − 0 = 8×MSS
so the sender sends the next eight segments, k+8, …, k+15.
Next time the sender receives ACKs, it’s already in congestion avoidance state, so it increments
CongWin by 1 in every transmission round (per one RTT).
Notice that, although CongWin keeps increasing, the sender will keep sending only eight
segments per transmission round because of the receiver’s buffer limitation.
CongWin

15 14

12 11
SSThresh
10

8
8

5
4

i i+1 i+2 i+3 i+4 i+5 Transmission round

but, it’s congestion avoidance.
Send k, k+1, k+2, … k+7

3 ACKs + 4 dupACKs

Send k+8, k+9, … k+15

Send k+8, k+16, … k+23

(5 segments acked)
ACK k+9 received
lost segment: k+3

All 8 ACKs received

re-send k+3

Some networking books give a simplified formula for computing the slow-start threshold size
after a loss is detected as SSThresh = CongWin / 2 = 5.5×MSS. Rounding CongWin down to
the next integer multiple of MSS is often not mentioned and neither is the property of fast
recovery to increment CongWin by one MSS for each dupACK received after the first three that
triggered the retransmission of segment k+3.
Ivan Marsic • Rutgers University 126

In this case, the sender in our example would immediately enter congestion avoidance, and the
corresponding diagram is as shown in the figure below.
CongWin
SSThresh
10 9.5
8
8 6.5

5.5
4

i i+1 i+2 i+3 i+4 i+5 Transmission round

but, it’s congestion avoidance.

but, it’s congestion avoidance.

Send k, k+1, k+2, … k+7

3 ACKs + 4 dupACKs

Send k+15, k+16, … k+21

Send k+9, k+10, … k+14
lost segment: k+3

All 6 ACKs received

(5 segments acked)
re-send k+3

ACK k+9 received

Problem 2.9 — Solution

We can ignore the propagation times since they are negligible relative to the packet transmission
times (mainly due to short the distance between the transmitter and the receiver). Also, the
transmission times for the acknowledgements can be ignored. Since the transmission just started,
the sender is in the slow start state. Assuming that the receiver sends only cumulative
acknowledgements, the total time to transmit the first 15 segments of data is (see the figure):
4 × 0.8 + 15 × 8 = 123.2 ms.
Solutions to Selected Problems 127

Server Access Point Mobile Node

Segments
transmitted: #1

Packet transmission time

Packet transmission time
#1 on the Wi-Fi link = 8 ms
on the Ethernet link = 0.8 ms

ack #2 Segment #1
#2 received
#3

#2

Segment #2
received

#3

ack #4 Segment #3
#4 received
#5
#6
#7 #4
Time

ack #8 #7 Segment #7
#8 received
#9
#10 #8

The timing diagram is as shown in the figure.

Problem 2.10 — Solution

Problem 2.11 — Solution

Object size, O = 1 MB = 220 bytes = 1048576 bytes = 8388608 bits
Segment size MSS = 1 KB, S = MSS × 8 bits = 8192 bits
Round-trip time RTT = 100 ms
Transmission rate, R = as given for each individual case (see below)
1 MB 2 20
There are a total of L = = = 210 = 1024 segments (packets) to transmit.
1 KB 210
Ivan Marsic • Rutgers University 128

(a)
Bottleneck bandwidth, R = 1.5 Mbps, data sent continuously:

O 2 20 × 8 1048576 × 8 8388608
= = = = 5.59 sec
R 1.5 × 10 6 1500000 1500000
latency = 2 × RTT + O / R = 200 × 10−3 + 5.59 sec = 5.79 sec

(b)
R = 1.5 Mbps, Stop-and-wait
⎛S ⎞ ⎛ 8192 ⎞
latency = 2 × RTT + ⎜ + RTT ⎟ × L = 0.2 + ⎜ + 0.1⎟ × 1024 = 108.19 sec
⎝R ⎠ ⎝ 1500000 ⎠

(c)
R = ∞, Go-back-20
Since transmission time is assumed equal to zero, all 20 packets will be transmitted
instantaneously and then the sender waits for the ACK for all twenty. Thus, data will be sent in
chunks of 20 packets:
L
latency = 2 × RTT + RTT × = 0.2 + 5.12 = 5.22 sec
20

(d)
R = ∞, TCP Tahoe
Since the transmission is error-free and the bandwidth is infinite, there will be no loss, so the
congestion window will grow exponentially (slow start) until it reaches the slow start threshold
SSThresh = 65535 bytes = 64 × MSS, which is the default value. From there on it will grow
linearly (additive increase). Therefore, the sequence of congestion window sizes is as follows:
Congestion window sizes:
1, 2, 4, 8, 16, 32, 64, 65, 66, 67, 68, 69, 70, ...

Slow start Additive increase

-- total 7 bursts -- total 13 bursts

Then, slow start phase consists of 7 bursts, which will transfer the first 127 packets. The additive
increase for the remaining 1024 − 127 = 897 packets consists of at most 897/64 ≈ 14 bursts.
Quick calculation gives the following answer:
Assume there will be thirteen bursts during the additive increase.
Solutions to Selected Problems 129

With a constant window of 64 × MSS, this gives 13 × 64 = 832.

On the other hand, additive increase adds 1 for each burst, so starting from 1 this gives
13 × (13 + 1)
1+2+3+ … + 13 = = 91 packets.
2
Therefore, starting with the congestion window size of 64 × MSS, the sender can in 13 bursts
send up to a total of 832 + 91 = 923 packets, which is more than 832.
Finally, sender needs total of 7 + 13 = 20 bursts:
latency = 2 × RTT + 20 × RTT = 2.2 sec.

Problem 3.1 — Solution

Problem 3.2 — Solution

Notice that the first packet is sent at 20 ms, so its playout time is 20 + 210 = 230 ms. The playout
of all subsequent packets are spaced apart by 20 ms (unless a packet arrives too late and is
discarded).
Notice also that the packets are labeled by sequence numbers. Therefore, although packet #6
arrives before packet #5, it can be scheduled for playout in its correct order.

Packet sequence number Arrival time ri [ms] Playout time pi [ms]

#1 195 230
#2 245 250
#3 270 270
#4 295 discarded ( >290)
#6 300 330
#5 310 310
#7 340 350
#8 380 discarded ( >370)
#9 385 390
#10 405 410

The playout schedule is also illustrated in this figure:

Ivan Marsic • Rutgers University 130

10 Playout
schedule
9
8
Packets
Packet number

7 received
Packets at host B
6 generated
at host A
5
Missed
4 playouts
3

2
q = 210 ms
1
0

0
0
0

0
0
0

0
0
0

0
0
0

0
0
40

80

0
0
20

60

14
16

18
20
22

24
26
28

30
32
34

36
38
40

42
10
12

Time [ms]
Talk starts r1 = 195 p1 = 230

First packet sent: t1 = 20

Problem 3.3 — Solution

(a)
Packet sequence number Arrival time ri [ms] Playout time pi [ms]
#1 95 170
#2 145 190
#3 170 210
#4 135 230
#6 160 250
#5 275 discarded ( >270)
#7 280 290
#8 220 310
#9 285 330
#10 305 350
(b)
The minimum propagation delay given in the problem statement is 50 ms. Hence, the maximum a
packet can be delay for playout is 100 ms. Since the source generates a packet every 20 ms, the
maximum number of packets that can arrive during this period is 5. Therefore, the required size
of memory buffer at the destination is 6 × 160 bytes = 960 bytes. (The buffer should be able to
hold 6 packets, rather than 5, because I assume that the last arriving packet is first buffered and
then the earliest one is removed from the buffer and played out.)

Problem 3.4 — Solution

The length of time from when the first packet in this talk spurt is generated until it is played out
is:
Solutions to Selected Problems 131

qk = dk + K ⋅ vk = 90 + 4 × 15 = 150 ms
The playout times for the packets including k+9 are obtained by adding this amount to their
timestamp, because they all belong to the same talk spurt. Notice that the packet k+5 is lost, but
this is not interpreted as the beginning of a new talk spurt. Also, when calculating dk+6 we are
missing dk+5, but we just use dk+4 in its stead.
The new talk spurt starts at i+10, since there is no gap in sequence numbers, but the difference
between the timestamps of subsequent packets is tk+10 − tk+9 = 40 ms > 20 ms, which indicates the
beginning of a new talk spurt. The length of time from when the first packet in this new talk spurt
is generated until it is played out is:
qk+10 = dk+10 + K ⋅ vk+10 = 92.051 + 4 × 15.9777 = 155.9618 ms ≈ 156 ms
and this is reflected on the playout times of packets k+10 and k+11.

Packet Timestamp Arrival time Playout time Average delay di Average

seq. # ti [ms] ri [ms] pi [ms] [ms] deviation vi
k 400 480 550 90 15
k+1 420 510 570 90 14.85
k+2 440 570 590 90.4 15.0975
k+3 460 600 610 90.896 15.4376
k+4 480 605 630 91.237 15.6209
k+7 540 645 690 91.375 15.6009
k+6 520 650 670 91.761 15.8273
k+8 560 680 710 92.043 15.9486
k+9 580 690 730 92.223 15.9669
k+10 620 695 776 92.051 15.9777
k+11 640 705 796 91.78 16.0857

Problem 3.5 — Solution

Problem 4.1 — Solution

(a)
This is an M/M/1 queue with the arrival rate λ = 950,000 packets/sec and service rate
μ = 1,000,000 packets/sec. The expected queue waiting time is:
λ 950000
W= = = 19 × 10 −6 sec
μ ⋅ (μ − λ ) 1000000 × (1000000 − 950000)
Ivan Marsic • Rutgers University 132

(b)
The time that an average packet would spend in the router if no other packets arrive during this
1 1
time equals its service time, which is = = 1 × 10 −6 sec
μ 1000000
(c)
By Little’s Law, the expected number of packets in the router is
⎛ 1⎞
N = λ ⋅ T = λ ⋅ ⎜⎜W + ⎟⎟ = 950000 × 20 × 10 −6 = 19 packets
⎝ μ⎠

Problem 4.2 — Solution

Problem 4.3 — Solution

Given
1 average packet length 1000 × 8
Data rate is 9600 bps ⇒ the average service time is = = = 0.83
μ link data rate 9600
∴ μ = 1.2
Link is 70% utilized ⇒ the utilization rate is ρ = 0.7
For exponential message lengths: M/M/1 queue with μ = 1.2, ρ = 0.7, the average waiting time is
ρ 0.7
W= = = 1.94 sec .
μ ⋅ (1 − ρ ) 1.2 × 0.3
For constant-length messages we have M/D/1 queue and the average waiting time is derived in
ρ 0.7
the solution of Problem 4.6(b) below as: W = = = 0.97 sec .
2 ⋅ μ ⋅ (1 − ρ ) 2 × 1.2 × 0.3
It is interesting to notice that constant-length messages have 50 % shorter expected queue waiting
time than the exponentially distributed length messages.

Problem 4.4 — Solution

The single repairperson is the server in this system and the customers are the machines. Define
the system state to be the number of operational machines. This gives a Markov chain, which is
the same as in an M/M/1/m queue with arrival rate μ and service rate λ. The required probability
m
is simply pm for such a queue. Because the sum of state probabilities is ∑p
i =0
i = 1 , the fraction of

time the system spends in state m equals pm. From Eq. (4.8), we have the steady-state proportion
ρ m ⋅ (1 − ρ )
of time where there is no operational machine as pm = .
1 − ρ m+1
Solutions to Selected Problems 133

Problem 4.5 — Solution

This can be modeled as an M/M/1/m system, since the there are a total of K users, and there can
be up to K tasks in the system if their file requests coincide. The average service time is
1 average packet length A × R
= = = A and the service rate is μ = 1/A. The user places the
μ throughput rate R
request, but may need to wait if there are already pending requests of other users. Let W denote
the waiting time once the request is placed but before the actual transmission starts, which is
unknown. Every user comes back, on average, after A+B+W seconds. Hence, the arrival rate is λ
K
= .
A + B +W
From Little’s Law, given the average number N of customers in the system, the average waiting
N
delay per customer is W = T − A = − A . The time T is from the moment the user places the
λ
request until the file transfer is completed, which includes waiting after the users who placed their
request earlier but are not yet served, plus the time it takes to transfer the file (service time),
which on average equals A seconds. (Only one customer at a time can be served in this system.)
N K N ⋅ ( A + B) − K ⋅ A
Then, λ = = and from here: W =
W+A A + B +W K−N
For an M/M/1/m system, the average number N of users requesting the files is:
ρ ( K + 1) ⋅ ρ K +1
N= −
1− ρ 1 − ρ K +1

where ρ = λ /μ is the utilization rate. Finally, the average time it takes a user to get a file since
completion of his previous file transfer is A + B + W.

Problem 4.6 — Solution

This is an M/D/1 queue with deterministic service times. Recall that M/D/1 is a sub-case of
M/G/1. Given: Service rate, μ = 1/4 = 0.25 items/sec; arrival rate, λ = 0.2 items/sec.
(a)
Mean service time X = 4 sec.
1 λ2 ⋅ X 2 λ2
X2 = and N Q = = = 16
μ2 2 ⋅ (1 − ρ ) 2 ⋅ μ 2 ⋅ (1 − λ μ )

The second moment of service time for the deterministic case is obtained as

{ } { }
0 = E{x − μ} = E x 2 − E 2 {x} and from here, we have E x 2 = E 2 {x} = X =
2 2 1
μ2
(b)
Ivan Marsic • Rutgers University 134

The total time spent by a customer in the system, T, is T = W + X , where W is the waiting time in
ρ
the queue W = = 8 sec so the total time T = 12 sec.
2 ⋅ μ ⋅ (1 − ρ )

Problem 4.7 — Solution

Problem 4.8 — Solution

Problem 5.1 — Solution

Problem 5.2 — Solution

Problem 5.3 — Solution

Problem 5.4 — Solution

Recall that packet-by-packet FQ is non-preemptive, so the packet that is already in transmission
will be let to finish regardless of its finish number. Therefore, the packet of class 3 currently in
transmission can be ignored from further consideration. It is interesting to notice that the first
packet from flow 1 has a smaller finish number, so we can infer that it must have arrived after the
packet in flow 3 was already put in service.
The start round number for servicing the currently arrived packet equals the current round
number, since its own queue is empty. Hence, F2,1 = R(t) + L2,1 = 85000 + 1024×8 = 93192.
Therefore, the order of transmissions under FQ is: pkt2,1 < pkt1,1 < pkt1,2 ; that is, the newly arrived
packet goes first (after the one currently in service is finished).
Solutions to Selected Problems 135

BEFORE FLOW 2 PACKET ARRIVAL: AFTER SCHEDULING THE ARRIVED PACKET:

Flow 1 Flow 2 Flow 3 Flow 1 Flow 2 Flow 3

F1,2 = 114688 F1,2 = 114688

F1,1 = 98304 F1,1 = 98304

2 3 F2,1 = 93192
1 2 1

F3,1 = 106496 F3,1 = 106496

(in transmission) (in transmission)

Problem 5.5 — Solution

Problem 5.6 — Solution

Problem 5.7 — Solution

(a) Packet-by-packet FQ
The following figure helps to determine the round numbers, based on bit-by-bit GPS. The packets
are grouped in two groups, as follows. Regardless of the scheduling discipline, all of the packets
that arrived by 300 s will be transmitted by 640 s. It is easy to check this by using a simple FIFO
Part B: R(t)
100
650 – 850 s 1/1
Part A: 50 1/2
1/3
1/2
0 – 650 s
number R(t)

P1,4

0
Flow 3: P3,3
Flow 4: P4,3
Round

650

800
700
Flow 1:
Flow 2:

Time t
4, 3

4,4
P

300
3, 3 ,

1, 4 ,
P

1/1
P

200 1/2

1/3
100 1/4
P4,1

1/3
P2,1

1/2
0
Flow 1: P1,1

Flow 3: P3,1

100

200

250

300

500

700
400

600
0
Flow 2:

Flow 4:

3,1

3,2

1, 3

Time t [s]
P

P
2, 1

4,1
1, 1 ,

1, 2 ,

4, 2 ,
P

P
P

P
Ivan Marsic • Rutgers University 136

scheduling. Therefore, the round number R(t) can be considered independently for the packets
that arrive up until 300 s vs. those that arrive thereafter. This is shown as Part A and B in the
above figure. (Resetting the round number is optional, only for the sake of simplicity.)
The packet arrivals on different flows are illustrated on the left hand side of the figure, in the
round number units. Thus, e.g., packet P2,1 arrives at time t2,1 = 200 s or round number R(t2,1) =
100. The following table summarizes all the relevant computations for packet-by-packet FQ.
Arrival times & state Parameters Values under packet-by-packet FQ
t = 0: {P1,1, P3,1} arrive Finish numbers R(0) = 0; F1,1 = L1,1 = 100; F3,1 = L3,1 = 60
server idle, q’s empty Transmit periods Start/end(P3,1): 0→60 sec; Start/end(P1,1): 60→160 s
R(t) = t⋅C/N = 100×1/2 = 50
t = 100: {P1,2, P3,2}
Finish numbers F1,2 = max{F1,1, R(t)} + L1,2 = 100 + 120 = 220;
P1,1 in transmission
F3,2 = max{0, R(t)} + L3,2 = 50 + 190 = 240
All queues empty
Transmit periods Start/end(P1,2): 160→280 s; Queued packets: P3,2
R(t) = t⋅C/N = 200×1/2 = 100
t = 200: {P2,1} arrives
Finish numbers F2,1 = max{0, R(t)} + L2,1 = 100 + 50 = 150
P1,2 in transmission
F3,2 = 240 (unchanged);
P3,2 in queue
Transmit periods P1,2 ongoing; Queued packets: P2,1 < P3,2
R(t) = (t−t′)⋅C/N + R(t′) = 50×1/3 + 100 = 116 2/3
t = 250: {P4,1} arrives F2,1 = 150 (unchanged);
Finish numbers
P1,2 in transmission F3,2 = 240 (unchanged);
{P2,1, P3,2} in queues F4,1 = max{0, R(t)} + L4,1 = 116.67& + 30 = 146.67&
Transmit periods Start/end(P4,1): 280→310 s; Queued pkts: P2,1 < P3,2
R(t) = (t−t′)⋅C/N + R(t′) = 50×1/4 + 116.67& = 129 1/6
F1,3 = max{0, R(t)}+L1,3 = 129.16& + 60 = 189.16& ;
Finish numbers F2,1 = 150 (unchanged);
t = 300: {P4,2, P1,3}
F3,2 = 240 (unchanged);
P4,1 in transmission
{P2,1, P3,2} in queues F4,2 = max{0, R(t)} + L4,2 = 129.16& + 30 = 159.16&
P4,1 ongoing; Queued packets: P2,1 < P4,2 < P1,3 < P3,2
Transmit periods Start/end(P2,1): 310→360 s; s/e(P4,2): 360→390 s;
Start/end(P1,3): 390→450 s; s/e(P3,2): 450→640 s.
At t = 640 s, round number reset, R(t) = 0, since the system becomes idle.
t = 650: {P3,3, P4,3} Finish numbers R(0) = 0; F3,3 = L3,3 = 50; F4,3 = L4,3 = 30
server idle, q’s empty Transmit periods Start/end(P4,3): 650→680 sec; s/e(P3,3): 680→730 s.
R(t) = (t−t′)⋅C/N + R(t′) = 110×1/2 + 0 = 55
t = 710: {P1,4, P4,4} Finish numbers F1,4 = max{0, R(t)} + L1,4 = 55 + 60 = 115;
P3,3 in transmission F4,4 = max{30, R(t)} + L4,4 = 55 + 30 = 85
All queues empty P3,3 ongoing; Queued packets: P4,4 < P1,4
Transmit periods
Start/end(P4,4): 730→760 s; s/e(P1,4): 760→820 s.

(b) Packet-by-packet WFQ; Weights for flows 1-2-3-4 are 4:2:1:2

Round number computation, based on bit-by-bit GPS, remains the same as in the figure above.
The only difference is in the computation of finish numbers under packet-by-packet WFQ, see
Eq. (5.3), as summarized in the following table.
Solutions to Selected Problems 137

Packets P1,4 and P4,4 end up having the same finish number (70); the tie is broken by a random
drawing so that P1,4 is decided to be serviced first, ahead of P4,4.
Arrival times & state Parameters Values under packet-by-packet FQ
t = 0: {P1,1, P3,1} arrive Finish numbers R(0) = 0; F1,1 = L1,1/w1 = 100/4 = 25; F3,1 = 60
server idle, q’s empty Transmit periods Start/end(P1,1): 0→100 s; Start/end(P3,1): 100→160 s
R(t) = t⋅C/N = 100×1/2 = 50
t = 100: {P1,2, P3,2}
Finish numbers F1,2 = max{F1,1, R(t)} + L1,2/w1 = 100 + 120/4 = 130;
P3,1 in transmission
F3,2 = max{0, R(t)} + L3,2/w3 = 50 + 190/1 = 240
All queues empty
Transmit periods Start/end(P1,2): 160→280 s; Queued packets: P3,2
R(t) = t⋅C/N = 200×1/2 = 100
t = 200: {P2,1} arrives
Finish numbers F2,1 = max{0, R(t)} + L2,1/w2 = 100 + 50/2 = 125
P1,2 in transmission
F3,2 = 240 (unchanged);
P3,2 in queue
Transmit periods P1,2 ongoing; Queued packets: P2,1 < P3,2
R(t) = (t−t′)⋅C/N + R(t′) = 50×1/3 + 100 = 116 2/3
t = 250: {P4,1} arrives F2,1 = 125 (unchanged);
Finish numbers
P1,2 in transmission F3,2 = 240 (unchanged);
{P2,1, P3,2} in queues F4,1 = max{0, R(t)} + L4,1/w4 = 116.67& +30/2 = 131.67&
Transmit periods Start/end(P2,1): 280→330 s; Queued pkts: P4,1 < P3,2
R(t) = (t−t′)⋅C/N + R(t′) = 50×1/4 + 116.67& = 129 1/6
F1,3 = max{0, R(t)}+L1,3/w1 = 129.16& +60/4 = 144.16& ;
Finish numbers F3,2 = 240 (unchanged);
t = 300: {P4,2, P1,3}
P2,1 in transmission F4,1 = 131.67& (unchanged);
{P3,2, P4,1} in queues F4,2 = max{ 131.67& , R(t)} + L4,2/w4 = 146.67&
P2,1 ongoing; Queued packets: P4,1 < P1,3 < P4,2 < P3,2
Transmit periods Start/end(P4,1): 330→360 s; s/e(P1,3): 360→420 s;
Start/end(P4,2): 420→450 s; s/e(P3,2): 450→640 s.
At t = 640 s, round number reset, R(t) = 0, since the system becomes idle.
t = 650: {P3,3, P4,3} Finish numbers R(0) = 0; F3,3 = L3,3/w3 = 50; F4,3 = L4,3/w4 = 15
server idle, q’s empty Transmit periods Start/end(P4,3): 650→680 sec; s/e(P3,3): 680→730 s.
R(t) = (t−t′)⋅C/N + R(t′) = 110×1/2 + 0 = 55
t = 710: {P1,4, P4,4} Finish numbers F1,4 = max{0, R(t)} + L1,4/w1 = 55 + 60/4 = 70;
P3,3 in transmission F4,4 = max{30, R(t)} + L4,4/w4 = 55 + 30/2 = 70
All queues empty P3,3 ongoing; Queued pkts: P1,4 = P4,4 (tie ⇒ random)
Transmit periods
Start/end(P1,4): 730→790 s; s/e(P4,4): 790→820 s.
Finally, the following table summarizes the order/time of departure:
Packet Arrival time Packet size Flow Departure order/ Departure order/
# [sec] [bytes] ID time under FQ time under WFQ
1 0 100 1 #2 / 60 s #1 / 0 s
2 0 60 3 #1 / 0 s #2 / 100 s
3 100 120 1 #3 / 160 s #3 / 160 s
4 100 190 3 #8 / 450 s #8 / 450 s
5 200 50 2 #5 / 310 s #4 / 280 s
6 250 30 4 #4 / 280 s #5 / 330 s
7 300 30 4 #6 / 360 s #7 / 420 s
8 300 60 1 #7 / 390 s #6 / 360 s
9 650 50 3 #10 / 680 s #10 / 680 s
Ivan Marsic • Rutgers University 138

10 650 30 4 #9 / 650 s #9 / 650 s

11 710 60 1 #12 / 760 s #11 / 730 s (tie)
12 710 30 4 #11 / 730 s #11 / 790 s (tie)
Appendix A: Probability Refresher

Random Events

Random Variables and Their Statistics

If X is a discrete random variable, define SX = {x1, x2, … , xN} as the range of X. That is, the value
of X belongs to SX.
Probability mass function (PMF): PX(x) = P[X = x]
Properties of X with PX(x) and SX:
a) PX (x) ≥ 0 ∀x
b) ∑P
x∈S X
X ( x) = 1

c) Given B ⊂ SX, P[ B ] = ∑P
x∈B
X ( x)

Define a and b as upper and lower bounds of X if X is a continuous random variable.

Cumulative distribution function (CDF): FX(x) = P[X ≤ x]
dF ( x)
Probability density function (PDF): f X ( x) =
dx
Properties of X with PDF fX(x):
a) fX(x) ≥ 0 ∀x
x
b) FX ( x) = ∫f
−∞
X (u ) ⋅ du

∞
c) ∫f
−∞
X ( x) ⋅ dx = 1

Expected value:
The mean or first moment.

139
Ivan Marsic • Rutgers University 140

b
Continuous RV case: E[ X ] = μ X = ∫ x ⋅ f X ( x) ⋅ dx
a

N
Discrete RV case: E[ X ] = μ X = ∑ xk ⋅ PX ( xk )
k =1

Variance:

[
Second moment minus first moment-squared: Var[ X ] = E ( X − μ X ) = E X 2 − μ X2
2
] [ ]
[ ]
b
Continuous RV case: E X 2 = ∫ x 2 ⋅ f X ( x ) ⋅ dx
a

[ ]
N
Discrete RV case: E X 2 = ∑ xk2 ⋅ PX ( xk )
k =1

Standard Deviation: σ X = Var[ X ]

Random Processes
A process is a naturally occurring or designed sequence of operations or events, possibly taking
up time, space, expertise or other resource, which produces some outcome. A process may be
identified by the changes it creates in the properties of one or more objects under its influence.
A function may be thought of as a computer program or mechanical device that takes the
characteristics of its input and produces output with its own characteristics. Every process may be
defined functionally and every process may be defined as one or more functions.
An example random process that will appear later in the text is Poisson process. It is usually
employed to model arrivals of people or physical events as occurring at random points in time.
Poisson process is a counting process for which the times between successive events are
independent and identically distributed (IID) exponential random variables. For a Poisson
process, the number of arrivals in any interval of length τ is Poisson distributed with a parameter
λ⋅τ. That is, for all t, τ > 0,
(λτ ) n
P{A(t + τ ) − A(t ) = n} = e −λτ , n = 0,1,... (A.1)
n!
The average number of arrivals within an interval of length τ is λτ (based on the mean of the
Poisson distribution). This implies that we can view the parameter λ as an arrival rate (average
number of arrivals per unit time). If X represents the time between two arrivals, then P(X > x),
that is, the probability that the interarrival time is longer than x, is given by e−x/λ. An interesting
property of this process is that it is memoryless: the fact that a certain time has elapsed since the
last arrival gives us no indication about how much longer we must wait before the next event
arrives. An example of the Poisson distribution is shown in Figure A-1.
Solutions to Selected Problems 141

percent of occurrences (%)

20

15

10

0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
arrivals per time unit (n)

Figure A-1. The histogram of the number of arrivals per unit of time (τ = 1) for a Poisson
process with average arrival rate λ = 5.

This model is not entirely realistic for many types of sessions and there is a great amount of
literature which shows that it fails particularly at modeling the LAN traffic. However, such
simple models provide insight into major tradeoffs involved in network design, and these
tradeoffs are often obscured in more realistic and complex models.
Markov process is a random process with the property that the probabilities of occurrence of the
various possible outputs depend upon one or more of the preceding outputs.
References

1. I. Aad and C. Castelluccia, “Differentiation mechanisms for IEEE 802.11,” Proceedings of the IEEE
Infocom 2001, April 2001.
2. M. Allman, V. Paxson, and W. R. Stevens, “TCP congestion control,” IETF Request for Comments
2581, April 1999. Online at: http://www.apps.ietf.org/rfc/rfc2581.html
3. G. Anastasi and L. Lenzini, “QoS provided by the IEEE 802.11 wireless LAN to advanced data
applications: A simulation analysis,” ACM Wireless Networks, vol. 6, no. 2, pp. 99-108, 2000.
4. D. Andersen, D. Bansal, D. Curtis, S. Seshan, and H. Balakrishnan, “System support for bandwidth
management and content adaptation in Internet applications,” Proceedings of the USENIX OSDI
Conference, San Diego, CA, October 2000.
5. D. Anick, D. Mitra, and M. M. Sondhi, “Stochastic theory of data-handling system with multiple
sources,” Bell System Technical Journal, vol. 61, no. 8, pp. 1871-1894, 1982.
6. B. Badrinath, A. Fox, L. Kleinrock, G. Popek, P. Reiher, and M. Satyanarayanan, “A conceptual
framework for network and client adaptation,” Mobile Networks and Applications (MONET), ACM /
Kluwer Academic Publishers, vol. 5, pp. 221-231, 2000.
7. D. Bertsekas and R. Gallagher. Data Networks. 2nd edition, Prentice Hall, Upper Saddle River, NJ,
1992.
8. S. N. Bhatti and J. Crowcroft, “QoS-sensitive flows: Issues in IP packet handling,” IEEE Internet
Computing, vol. 4, no. 4, pp. 48-57, July 2000.
9. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An architecture for differentiated
services,” IETF Request for Comments 2475, December 1998. Online at:
http://www.apps.ietf.org/rfc/rfc2475.html
10. M. S. Blumenthal and D. D. Clark, “Rethinking the design of the Internet: The end-to-end arguments
vs. the brave new world,” ACM Transactions on Internet Technology, vol. 1, no. 1, pp. 70-109, August
2001.
11. B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall,
C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, and L. Zhang,
“Recommendations on queue management and congestion avoidance in the Internet,” IETF Request
for Comments 2309, April 1998. Online at: http://www.apps.ietf.org/rfc/rfc2309.html
12. L. S. Brakmo and L. L. Peterson, “TCP Vegas: End-to-end congestion avoidance on a global internet,”
IEEE Journal on Selected Areas in Communications, vol. 13, no. 8, pp. 1465-1480, October 1995.
13. Z. Cao and E. Zegura, “Utility max-min: An application-oriented bandwidth allocation scheme,” Proc.
IEEE InfoCom, vol. 2, pp. 793-801, 1999.
14. D. Chalmers and M. Sloman, “A survey of quality of service in mobile computing environments,”
IEEE Communications Surveys, vol. 2, no. 2, 1999.
15. H. S. Chhaya and S. Gupta, “Performance of asynchronous data transfer methods of IEEE 802.11
MAC protocol,” IEEE Personal Communications, vol. 3, no. 5, October 1996.
16. Cisco Systems Inc., “Interface Queue Management,” Cisco white paper, posted August 1995. Online
at: http://www.cisco.com/warp/public/614/16.html

142
References 143

17. Cisco Systems Inc., “Performance Measurements of Advanced Queuing Techniques in the Cisco IOS,”
Cisco white paper, posted July 1999. Online at: http://www.cisco.com/warp/public/614/15.html
18. Cisco Systems Inc., “Advanced QoS Services for the Intelligent Internet,” Cisco white paper, posted
June 2006. Online at: http://www.cisco.com/warp/public/cc/pd/iosw/ioft/ioqo/tech/qos_wp.htm
19. D. D. Clark and W. Feng, “Explicit allocation of best-effort packet delivery service,” IEEE/ACM
Transactions on Networking, vol. 6, no. 4, pp. 362-373, August 1998.
20. D. D. Clark, S. Shenker, and L. Zhang, “Supporting real-time applications in an integrated services
packet network: Architecture and mechanisms,” Proc. SIGCOMM '92, Baltimore, MD, August 1992.
21. D. E. Comer, Internetworking With TCP/IP, Volume I: Principles, Protocols, and Architecture, 5th
Edition, Pearson Prentice Hall, Upper Saddle River, NJ, 2006.
22. W. Dapeng and R. Negi, “Effective capacity: A wireless link model for support of quality of service,”
IEEE Transactions on Wireless Communications, vol. 2, no. 4, pp. 630-643, July 2003.
23. D-J. Deng and R-S. Chang, “A priority scheme for IEEE 802.11 DCF access method,” IEICE
Transactions on Communications, E82-B-(1), January 1999.
24. M. DuVal and T. Siep, “High Rate WPAN for Video,” IEEE document: IEEE 802.15-00/029,
Submission date: 6 March 2000. Online at:
http://grouper.ieee.org/groups/802/15/pub/2000/Mar00/00029r0P802-15_CFA-Response-High-Rate-WPAN-for-
Video-r2.ppt
25. I. Elhanany, M. Kahane, and D. Sadot, “Packet scheduling in next-generation multiterabit networks,”
IEEE Computer, vol. 34, no. 4, pp. 104-106, April 2001.
26. S. Floyd, “Congestion control principles,” IETF Request for Comments 2914, September 2000. Online
at: http://www.apps.ietf.org/rfc/rfc2914.html
27. P. Goyal, S. S. Lam, and H. M. Vin, “Determining end-to-end delay bounds in heterogeneous
networks,” ACM Multimedia Systems, vol. 5, no. 3, pp. 157-163, 1997.
[An earlier version of this paper appeared in Proceedings of the Fifth International Workshop on
Network and Operating System Support for Digital Audio and Video (NOSSDAV '95), Durham, NH,
pp. 287-298, April 1995.]
28. C. Greenhalgh, S. Benford, and G. Reynard, “A QoS architecture for collaborative virtual
environments,” Proc. ACM Multimedia Conf., pp.121-130, 1999.
29. V. Jacobson, “Congestion avoidance and control,” ACM Computer Communication Review, vol. 18,
no. 4, pp. 314-329, August 1988. Online at: ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
30. R. Jain, The Art of Computer Systems Performance Analysis: Techniques for Experimental Design,
Measurement, Simulation, and Modeling. John Wiley & Sons, New York, NY, 1991.
31. C. Jin, D. Wei, S. H. Low, G. Buhrmaster, J. Bunn, D. H. Choe, R. L. A. Cottrell, J. C. Doyle, W.
Feng, O. Martin, H. Newman, F. Paganini, S. Ravot, and S. Singh, “FAST TCP: From Theory to
Experiments,” Submitted to IEEE Communications Magazine, April 1, 2003. Online at:
http://netlab.caltech.edu/FAST/publications.html
32. D. Kahneman, Attention and Effort. Prentice-Hall, Inc., Englewood Cliffs, NJ, 1973.
33. V. Kanodia, C. Li, A. Sabharwal, B. Sadeghi, and E. Knightly, “Distributed priority scheduling and
medium access in ad hoc networks,” Wireless Networks, vol. 8, no. 5, pp. 455-466, 2002.
34. R. Katz, “Adaptation and mobility in wireless information systems,” IEEE Personal Communications,
vol. 1, no. 1, pp. 6-17, 1994.
35. S. Keshav, An Engineering Approach to Computer Networking: ATM Networks, the Internet, and the
Telephone Network. Addison-Wesley Publ. Co., Reading, MA, 1997.
36. J. F. Kurose and K. W. Ross, Computer Networking: A Top-Down Approach Featuring the Internet. 3rd
edition. Pearson Education, Inc. (Addison-Wesley), Boston, MA, 2005.
Ivan Marsic • Rutgers University 144

37. E. D. Lazowska, J. Zahorjan, G. S. Graham, and K. C. Sevcik, Quantitative System Performance:

Computer System Analysis Using Queuing Network Models, Prentice-Hall, Inc., Englewood Cliffs, NJ,
1984. Online at: http://www.cs.washington.edu/homes/lazowska/qsp/
38. R. R.-F. Liao and A. T. Campbell, “A utility-based approach for quantitative adaptation in wireless
packet networks,” Wireless Networks, vol. 7, no. 5, pp. 541-557, 2001.
39. Y. Mao and L. K. Saul, “Modeling distances in large-scale networks by matrix factorization,”
Proceedings of the Second Internet Measurement Conference (IMC-04), pp. 278-287, Sicily, Italy,
2004. Online at: https://wiki.planet-lab.org/bin/view/Planetlab/AnnotatedBibliography
40. S. Mascolo, C. Casetti, M. Gerla, M. Y. Sanadidi, and R. Wang, “TCP Westwood: Bandwidth
estimation for enhanced transport over wireless links,” Proceedings of the 7th ACM International
Conference on Mobile Computing and Networking (MobiCom 2001), Rome, Italy, pp. 287-296,
August 2001.
41. M. L. Massie, B. N. Chun, and D. E. Culler, “The Ganglia distributed monitoring system: Design,
implementation, and experience,” Parallel Computing, vol. 30, no. 7, July 2004.
42. J. Nagle, “Congestion control in IP/TCP internetworks,” IETF Request for Comments 896, January
1984. Online at: http://www.rfc-editor.org/rfc/rfc896.txt
43. J. Nagle, “On packet switches with infinite storage,” IEEE Transactions on Communications, vol. 35,
no. 4, pp. 435-438, April 1987.
44. K. Nahrstedt and J. M. Smith, “The QoS broker,” IEEE Multimedia, vol. 2, no. 1, pp. 53-67, 1995.
45. K. Nahrstedt, D. Xu, D. Wichadakul, and B. Li, “QoS-aware middleware for ubiquitous and
heterogeneous environments,” IEEE Communications Magazine, vol. 39, no. 11, pp. 140-148, 2001.
46. B. D. Noble and M. Satyanarayanan, “Experience with adaptive mobile applications in Odyssey,”
Mobile Networks and Applications (MONET) (ACM / Kluwer Academic Publishers), vol. 4, pp. 245–
254, 1999.
47. J. Padhye, V. Firoiu, D. F. Towsley, and J. F. Kurose, “Modeling TCP Reno performance: A simple
model and its empirical validation,” IEEE/ACM Transactions on Networking, vol. 8, no. 2, pp. 133-
145, April 2000.
48. J. Padhye, V. Firoiu, D. F. Towsley, and J. F. Kurose, “Modeling TCP throughput: A simple model
and its empirical validation,” Proceedings of the ACM Conference on Applications, Technologies,
Architectures, and Protocols for Computer Communication (SIGCOMM '98), Vancouver, British
Columbia, Canada, pp. 303-314, August/September 1998.
49. A. Papoulis and S. U. Pillai, Probability, Random Variables and Stochastic Processes. 4th edition,
McGraw-Hill, New York, NY, 2001.
50. A. K. Parekh and R. G. Gallager, “A generalized processor sharing approach to flow control in
integrated services networks: The single-node case,” IEEE/ACM Transactions on Networking, vol. 1,
no. 3, pp. 344-357, June 1993.
51. A. K. Parekh and R. G. Gallagher, “A generalized processor sharing approach to flow control in
integrated services networks: The multiple node case,” IEEE/ACM Transactions on Networking, vol. 2,
no. 2, pp. 137-150, April 1994.
52. V. Paxson and M. Allman, “Computing TCP’s Retransmission Timer,” IETF Request for Comments
2988, November 2000. Online at: http://www.rfc-editor.org/rfc/rfc2988.txt
53. L. L. Peterson and B. S. Davie, Computer Networks: A Systems Approach. 3rd edition. Morgan
Kaufmann Publishers, San Francisco, CA, 2003.
54. R. Rajkumar, C. Lee, J. Lehoczky, and D. Siewiorek, “A resource allocation model for QoS
management,” Proceedings of the IEEE Real-Time Systems Symposium, pp.298-307, December 1997.
References 145

55. C. U. Saraydar, N. B. Mandayam, and D. J. Goodman, “Efficient power control via pricing in wireless
data networks,” IEEE Transactions on Communications, vol. 50, no. 2, pp. 291-303, February 2002.
56. A. Sears and J. A. Jacko, “Understanding the relationship between network quality of service and the
usability of distributed multimedia documents,” Human-Computer Interaction, vol. 15, pp. 43-68,
2000.
57. C. E. Shannon and W. Weaver, The Mathematical Theory of Communication. University of Illinois
Press, Urbana, IL, 1949.
58. S. Shenker, “Fundamental design issues for the future Internet,” IEEE Journal on Selected Areas in
Communications, vol. 13, no. 7, pp. 1176-1188, September 1995.
59. S. Shenker, “Making greed work in networks: A game-theoretic analysis of switch service disciplines,”
Proc. ACM SIGCOMM'94, pp. 47-57, 1994.
60. S. Shenker, C. Partridge, and R. Guerin, “Specification of Guaranteed Quality of Service,” IETF
Request for Comments 2212, September 1997. Online at: http://www.apps.ietf.org/rfc/rfc2212.html
61. W. R. Stevens, TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley Publ. Co., Reading,
MA, 1994.
62. W. R. Stevens, “TCP slow start, congestion avoidance, fast retransmit, and fast recovery algorithms,”
IETF Request for Comments 2001, January 1997. Online at: http://www.apps.ietf.org/rfc/rfc2001.html
63. D. E. Taylor, “Survey and taxonomy of packet classification techniques,” ACM Computing Surveys,
vol. 37, no. 3, pp. 238-275, September 2005.
64. S. Weinstein, “The mobile Internet: Wireless LAN vs. 3G cellular mobile,” IEEE Communications
Magazine, pp.26-28, February 2002.
65. A. Wolisz and F. H. P. Fitzek, “QoS support in wireless networks using simultaneous MAC packet
transmission (SMPT),” in ATS, April 1999.
66. R. D. Yates and D. J. Goodman, Probability and Stochastic Processes: A Friendly Introduction for
Electrical and Computer Engineers. 2nd edition, John Wiley & Sons, Inc., New York, NY, 2004.
67. Q. Zhang, W. Zhu, and Y.-Q. Zhang, “Resource allocation for multimedia streaming over the
Internet,” IEEE Transactions on Multimedia, vol. 3, no. 3, pp. 339-355, September 2001.
Acronyms and Abbreviations

3G — Third Generation IETF — Internet Engineering Task Force

ACK — Acknowledgement IntServ — Integrated Services
AIMD — Additive Increase/Multiplicative Decrease IP — Internet Protocol
AQM — Active Queue Management IPv4 — Internet Protocol version 4
AP — Access Point j.n.d. — just noticeable difference
AF — Assumed Forwarding Kbps — Kilo bits per second
ASCII — American Standard Code for Information LAN — Local Area Network
Interchange LCFS — Last Come First Served
AWGN — Additive White Gaussian Noise LS — Link State
BDPDR — Bounded Delay Packet Delivery Ratio MAC — Medium Access Control
BER — Bit Error Rate MANET — Mobile Ad-hoc Network
API — Application Programming Interface Mbps — Mega bits per second
ARQ — Automatic Repeat Request MPEG — Moving Picture Experts Group
bps — bits per second MSS — Maximum Segment Size
CBR — Constant Bit Rate MTU — Maximum Transmission Unit
CIDR — Classless Interdomain Routing NAK — Negative Acknowledgement
CORBA — Common Object Request Broker NAT — Network Address Translation
Architecture
NIC — Network Interface Card
CoS — Class of Service
PAN — Personal Area Network
CPU — Central Processing Unit
PC — Personal Computer
CTS — Clear To Send
PDA — Personal Digital Assistant
DBS — Direct Broadcast Satellite
pdf — probability distribution function
DCF — Distributed Coordination Function
pmf — probability mass function
DiffServ — Differentiated Services
PHB — Per-Hop Behavior
dupACK — Duplicate Acknowledgement
PtMP — Point-to-Multipoint
DV — Distance Vector
PtP — Point-to-Point
EF — Expedited Forwarding
QoS — Quality of Service
FCFS — First Come First Served
P2P — Peer-to-Peer
FDM — Frequency Division Multiplexing
RED — Random Early Detection
FEC — Forward Error Correction
RFC — Request For Comments
FIFO — First In First Out
RFID — Radio Frequency IDentification
FIRO — First In Random Out
RPC — Remote Procedure Call
FQ — Fair Queuing
RSSI — Receive(r) Signal Strength Index/Indication
FTP — File Transfer Protocol
RSVP — Resource ReSerVation Protocol
GBN — Go-Back-N
RTS — Request To Send
GPS — Generalized Processor Sharing
RTT — Round-Trip Time
GUI — Graphical User Interface
SIP — Session Initiation Protocol
HTML — HyperText Markup Language
SN — Sequence Number
HTTP — HyperText Transport Protocol
SNR — Signal-to-Noise Ratio
IEEE — Institute of Electrical and Electronics
Engineers SR — Selective Repeat

146
Acronyms and Abbreviations 147

SSTresh — Slow-Start Threshold W3C — World Wide Web Consortium

TCP — Transport Control Protocol WAN — Wide Area Network
TDM — Time Division Multiplexing WAP — Wireless Access Protocol
UDP — User Datagram Protocol WEP — Wired Equivalent Privacy
VBR — Variable Bit Rate WFQ — Weighted Fair Queuing
VLSI — Very Large Scale Integration Wi-Fi — Wireless Fidelity (synonym for IEEE 802.11)
VoIP — Voice over IP
Index

Connectionless service …
Numbers Connection-oriented service …
3G … Correctness …
802.3 IEEE standard. See Ethernet Countdown timer …
802.11 IEEE standard … Count to infinity problem …
Cumulative acknowledgement …

A
Access point … D
Acknowledgement … Datagram …
Active queue management … Delay …
Adaptive retransmission … propagation …
Adaptive video coding … queuing …
Additive increase … transmission …
Addressing … Demultiplexing
Ad hoc mobile network … Destination IP address …
Admission control … Differentiated services (DiffServ) …
Advertised window … Dijkstra’s algorithm …
Algorithm … Distance vector (DV) routing algorithm …
Alternating-bit protocol … Distributed computing …
Application … Duplicate acknowledgement …
Autonomic computing …
E
B Effective window …
Balance principle … Embedded processor …
Bandwidth … Emergent property, system …
Birth / death process … End-to-end …
Bit-by-bit round-robin … Error …
Black box … Event …
Blocking probability … Event-driven application …
Bottleneck router … Ethernet …
Broadcast … Expert rule …
Buffer …
Burst size … F
Fair resource allocation …
C Fairness index …
Capacity … Fast recovery …
Channel … Fast retransmission …
Compression, data … Fidelity …
Congestion avoidance … Firewall …
Congestion control … Flight size …

148
Index 149

Flow … Medium access control (MAC) …

control … Message …
soft state … Messaging …
Forward error correction (FEC) … Metadata …
Forwarding … Middleware …
Forwarding table … M/M/1 queue …
Frame … Modem …
Modular design …
G Multicast …
Go-back-N … Multimedia application …
Goodput … Multiplicative decrease …
Guaranteed service …
N
H Nagle’s algorithm …
H.323 … Naming …
Heuristics … Negative acknowledgement …
Hub … Network
local area network (LAN) …
wireless …
I
Implementation … Network programming …
Information theory … Node …
Input device … Non-work-conserving scheduler …
Integrated services (IntServ) …
Interarrival interval … O
Interface, software … Object, software …
Internet … Object Request Broker (ORB). See Broker pattern
IP telephony. See VoIP Offered load …
OMG (Object Management Group) …
Operation …
J
Jitter …
Just noticeable difference (j.n.d.) … P
Packet …
Packet-pair …
K
Kendall’s notation … Payload …
Keyword … Performance …
Pipelined reliable transfer protocol. See Protocol
Playout schedule …
L Poisson process …
Latency …
Layering … Policing …
architecture … Pollaczek-Khinchin (P-K) formula …
Leaky bucket … Port …
Link … Preamble …
Link-state (LS) routing algorithm … Preemptive scheduling …
Loss detection … Prioritization …
Process …
Program …
M Protocol …
Markov chain …
layering …
Max-min fairness …
Ivan Marsic • Rutgers University 150

OSI reference model … Signaling …

pipelined … Sliding-window protocol …
retransmission … Slow start …
transport layer … Socket, network …
Proxy … Source routing …
Spanning tree algorithm …
Q State
Quality of service … flow …
end-to-end … soft …
hard guarantees… State machine diagram …
soft guarantees … Stationary process …
Queue … Statistical multiplexing …
Queuing model ... Stop-and-wait …
Store-and-forward …
Streaming application …
R
Rate control scheme … Subnetwork …
Reactive application. See Event-driven application
Redundancy … T
Residual service time … TCP Reno …
Resource reservation … TCP Tahoe …
Retransmission … TCP Vegas …
RFID … Three-way handshake …
Round-robin scheduling … Throughput …
Round-trip time (RTT) … Timeliness …
Router … Timeout …
Routing Timer …
distance vector (DV) … Token bucket …
link state (LS) … Traffic
multicast … descriptor …
policy constraint … model …
protocol … Transmission round …
shortest path … Tunneling …
table …
Rule-based expert system … U
Unicast …
S User …
Scheduling … Utilization …
Segment …
Selective repeat … V
Self-similar traffic … Variable bit-rate …
Sensor … Videoconferencing …
Sequence number … Video-on-demand application …
Server … VoIP (Voice over IP) …
Service …
best-effort … W
model … Weighted-fair queuing …
QoS-based … Wi-Fi. See 802.11
Shortest path routing. See Routing Window …
Index 151

congestion …
X
flow control … xDSL …
size …
Wireless …
channel …
Y
network …
Work-conserving scheduler …
Z
…