COMPUTER NETWORKS 21CS52

Module IV: Transport Layer

4. The Transport Service
A transport-layer protocol provides for logical communication between application
processes running on different hosts. Application processes use the logical communication
provided by the transport layer to send messages to each other, free from the worry of the
details of the physical infrastructure used to carry these messages.
Transport-layer protocols are implemented in the end systems but not in network
routers. On the sending side, the transport layer converts the application-layer messages it
receives from a sending application process into transport-layer packets, known as
transport-layer segments. This is done by breaking the application messages into smaller
chunks and adding a transport-layer header to each chunk to create the transport-layer
segment.

4.1.1. Services Provided to the Upper Layers

The goal of the transport layer is to provide efficient, reliable, and cost-effective data
transmission service to its users, normally processes in the application layer. To achieve this,
the transport layer makes use of the services provided by the network layer. The software
and/or hardware within the transport layer that does the work is called the transport entity.
The transport entity can be in the operating system kernel, in a library package bound into
network applications, in a separate user process, or even on the network interface card. The
(logical) relationship of the network, transport, and application layers is illustrated in Fig.
4-1.

Figure 4-1. The network, transport, and application layers.

Just as there are two types of network service, connection-oriented and

connectionless, there are also two types of transport service. The connection-oriented
transport service is like the connection-oriented network service in many ways. In both
cases, connections have three phases: establishment, data transfer, and release. Addressing
and flow control are also similar in both layers. Furthermore, the connectionless transport
service is also very similar to the connectionless network service.

1 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

However, certain services can be offered by a transport protocol even when the
underlying network protocol does not offer the corresponding service at the network layer.
For example, a transport protocol can offer reliable data transfer service to an application
even when the underlying network protocol is unreliable, that is, even when the network
protocol loses, garbles, or duplicates packets.

4.1.2. Transport Service Primitives

To allow users to access the transport service, the transport layer must provide some
operations to application programs, that is, a transport service interface. Each transport
service has its own interface. The transport interface is truly bare bones, but it gives the
essential flavor of what a connection-oriented transport interface must do. It allows
application programs to establish, use, and then release connections, which is sufficient for
many applications. To get an idea of what a transport service might be like, consider the five
primitives listed in Fig. 4-2.

Figure 4-2. The primitives for a simple transport service

A state diagram for connection establishment and release for these simple primitives
is given in Fig. 4-3.

Figure 4-3. A state diagram for a simple connection management scheme.

Transitions labeled in italics are caused by packet arrivals. The solid lines show
the client’s state sequence. The dashed lines show the server’s state sequence.

2 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

4.1.3. Berkeley Sockets

Sockets were first released as part of the Berkeley UNIX 4.2BSD software distribution in
1983. They quickly became popular. The primitives are now widely used for Internet
programming on many operating systems. The primitives are listed in Fig. 4-4.

Figure 4-4. The socket primitives for TCP

4.2. Elements of Transport Protocols
4.2.1. Addressing
When an application (e.g., a user) process wishes to set up a connection to a remote
application process, it must specify which one to connect to. The method normally used is
to define transport addresses to which processes can listen for connection requests. In the
Internet, these endpoints are called ports.
We will use the generic term TSAP (Transport Service Access Point) to mean a
specific endpoint in the transport layer. The analogous endpoints in the network layer (i.e.,
network layer addresses) are not-surprisingly called NSAPs (Network Service Access
Points). IP addresses are examples of NSAPs.
A possible scenario for a transport connection is as follows.
1. A mail server process attaches itself to TSAP 1522 on host 2 to wait for an incoming call.
2. An application process on host 1 wants to send an email message, so it attaches itself to
TSAP 1208 and issues a CONNECT request. The request specifies TSAP 1208 on host 1
as the source and TSAP 1522 on host 2 as the destination.
3. The application process sends over the mail message.
4. The mail server responds to say that it will deliver the message.
5. The transport connection is released.
Figure 4-5 illustrates the relationship between the NSAPs, the TSAPs, and a transport
connection. Application processes, both clients and servers, can attach themselves to a local
TSAP to establish a connection to a remote TSAP. These connections run through NSAPs on
each host, as shown. The purpose of having TSAPs is that in some networks, each computer
has a single NSAP, so some way is needed to distinguish multiple transport endpoints that
share that NSAP.

3 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

Figure 4-5. TSAPs, NSAPs, and transport connections.

4.2.2. Connection Establishment

To solve the problem of connection establishment, Tomlinson (1975) introduced the three-
way handshake. This establishment protocol involves one peer checking with the other that
the connection request is indeed current. The normal setup procedure when host 1 initiates
is shown in Figure 4-6(a). Host 1 chooses a sequence number, x, and sends a CONNECTION
REQUEST segment containing it to host 2. Host 2 replies with an ACK segment
acknowledging x and announcing its own initial sequence number, y. Finally, host 1
acknowledges host 2’s choice of an initial sequence number in the first data segment that it
sends.
Now let us see how the three-way handshake works in the presence of delayed
duplicate control segments. In Figure 4-6(b), the first segment is a delayed duplicate
CONNECTION REQUEST from an old connection. The worst case is when both a delayed
CONNECTION REQUEST and an ACK are floating around in the subnet. This case is shown in
Figure 4-6(c). In both cases host 1 rejects host 2’s attempt to establish a connection, host 2
realizes that it was tricked by a delayed duplicate and abandons the connection.

Figure 4-6. Three protocol scenarios for establishing a connection using a

three-way handshake. CR denotes CONNECTION REQUEST. (a) Normal operation. (b) Old duplicate CONNECTION REQUEST
appearing out of nowhere. (c) Duplicate CONNECTION REQUEST and duplicate ACK.

4 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

4.2.3. Connection Release

Releasing a connection is easier than establishing one. There are two styles of terminating a
connection: asymmetric release and symmetric release. Asymmetric release is the way the
telephone system works: when one party hangs up, the connection is broken. Symmetric
release treats the connection as two separate unidirectional connections and requires each
one to be released separately.
Asymmetric release is abrupt and may result in data loss. Consider the scenario of
Figure 4-7. After the connection is established, host 1 sends a segment that arrives properly
at host 2. Then host 1 sends another segment. Unfortunately, host 2 issues a DISCONNECT
before the second segment arrives. The result is that the connection is released and data are
lost.

Figure 4-7. Abrupt disconnection with loss of data.

Symmetric release does the job when each process has a fixed amount of data to send
and clearly knows when it has sent it. In other situations, determining that all the work has
been done and the connection should be terminated is not so obvious. One can envision a
protocol in which host 1 says ‘‘I am done. Are you done too?’’ If host 2 responds: ‘‘I am done
too. Goodbye, the connection can be safely released.’’
In Figure 4-8(a), we see the normal case in which one of the users sends a DR
(DISCONNECTION REQUEST) segment to initiate the connection release. When it arrives,
the recipient sends back a DR segment and starts a timer, just in case its DR is lost. When
this DR arrives, the original sender sends back an ACK segment and releases the connection.
Finally, when the ACK segment arrives, the receiver also releases the connection.
If the final ACK segment is lost, as shown in Figure 4-8(b), the situation is saved by
the timer. When the timer expires, the connection is released anyway. Now consider the case
of the second DR being lost. The user initiating the disconnection will not receive the
expected response, will time out, and will start all over again.
In Figure 4-8(c), we see how this works, assuming that the second time no segments
are lost and all segments are delivered correctly and on time. Our last scenario, Figure 4-
8(d), is the same as Figure C except that now we assume all the repeated attempts to

5 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

retransmit the DR also fail due to lost segments. After N retries, the sender just gives up and
releases the connection. Meanwhile, the receiver times out and exits.

Figure 4-8. Four protocol scenarios for releasing a connection. (a) Normal
case of three-way handshake. (b) Final ACK lost. (c) Response lost. (d) Response lost and subsequent DRs lost.

4.2.4. Error Control and Flow Control

Error control is ensuring that the data is delivered with the desired level of reliability,
usually that all the data is delivered without any errors. Flow control is keeping a fast
transmitter from overrunning a slow receiver. The solutions that are used at the transport
layer are given below.
1. A frame carries an error-detecting code (e.g., a CRC or checksum) that is used to check if
the information was correctly received.
2. A frame carries a sequence number to identify itself and is retransmitted by the sender
until it receives an acknowledgement of successful receipt from the receiver. This is
called ARQ (Automatic Repeat reQuest).
3. There is a maximum number of frames that the sender will allow to be outstanding at
any time, pausing if the receiver is not acknowledging frames quickly enough. If this
maximum is one packet the protocol is called stop-and-wait. Larger windows enable
pipelining and improve performance on long, fast links.
4. The sliding window protocol combines these features and is also used to support
bidirectional data transfer.

6 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

4.2.5. Multiplexing
Multiplexing, or sharing several conversations over connections, virtual circuits, and
physical links plays a role in several layers of the network architecture. In the transport
layer, the need for multiplexing can arise in several ways.
For example, if only one network address is available on a host, all transport
connections on that machine must use it. When a segment comes in, some way is needed to
tell which process to give it to. This situation, called multiplexing, is shown in Figure 4-9(a).
In this figure, four distinct transport connections all use the same network connection (e.g.,
IP address) to the remote host.
Multiplexing can also be useful in the transport layer for another reason. Suppose,
for example, that a host has multiple network paths that it can use. If a user needs more
bandwidth or more reliability than one of the network paths can provide, a way out is to
have a connection that distributes the traffic among multiple network paths on a round-
robin basis, as indicated in Figure 4-9(b). This method is called inverse multiplexing. With k
network connections open, the effective bandwidth might be increased by a factor of k. An
example of inverse multiplexing is SCTP (Stream Control Transmission Protocol), which can
run a connection using multiple network interfaces.

Figure 4-9. (a) Multiplexing. (b) Inverse multiplexing

4.2.6. Crash Recovery

If hosts and routers are subject to crashes or connections are long-lived, recovery from these
crashes becomes an issue. If the transport entity is entirely within the hosts, recovery from
network and router crashes is straightforward. The transport entities expect lost segments
all the time and know how to cope with them by using retransmissions. A more troublesome
problem is how to recover from host crashes. It may be desirable for clients to be able to
continue working when servers crash and quickly reboot. When it comes back up, its tables
are reinitialized, so it no longer knows precisely where it was.
To recover its previous status, the server might send a broadcast segment to all other
hosts, announcing that it has just crashed and requesting that its clients inform it of the
status of all open connections. Each client can be in one of two states: one segment
outstanding, S1, or no segments outstanding, S0.
7 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

Based on only this state information, the client must decide whether to retransmit
the most recent segment. If a crash occurs after the acknowledgement has been sent but
before the write has been fully completed, the client will receive the acknowledgement and
thus be in state S0 when the crash recovery announcement arrives. The client will therefore
not retransmit.
At this point you may be thinking: ‘‘That problem can be solved easily. All you must
do is reprogram the transport entity to first do the write and then send the
acknowledgement.’’ Try again. Imagine that the write has been done but the crash occurs
before the acknowledgement can be sent. The client will be in state S1 and thus retransmit,
leading to an undetected duplicate segment in the output stream to the server application
process.
No matter how the client and server are programmed, there are always situations
where the protocol fails to recover properly. The server can be programmed in one of two
ways: acknowledge first or write first. The client can be programmed in one of four ways:
always retransmit the last segment, never retransmit the last segment, retransmit only in
state S0, or retransmit only in state S1. This gives eight combinations, but as we shall see,
for each combination there is some set of events that makes the protocol fail.
Three events are possible at the server: sending an acknowledgement (A), writing to
the output process (W), and crashing (C). The three events can occur in six different
orderings: AC(W), AWC, C(AW), C(WA), WAC, and WC(A), where the parentheses are used
to indicate that neither A nor W can follow C (i.e., once it has crashed, it has crashed). Figure
4-10 shows all eight combinations of client and server strategies and the valid event
sequences for each one.

Figure 4-10. Different combinations of client and server strategies

4.3. Congestion Control

If the transport entities on many machines send too many packets into the network too
quickly, the network will become congested, with performance degraded as packets are
delayed and lost. Controlling congestion to avoid this problem is the combined
responsibility of the network and transport layers. Congestion occurs at routers, so it is
detected at the network layer. However, congestion is ultimately caused by traffic sent into

8 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

the network by the transport layer. The only effective way to control congestion is for the
transport protocols to send packets into the network more slowly.

4.3.1. Desirable Bandwidth Allocation

Efficiency and Power
It is to find a good allocation of bandwidth to the transport entities that are using the
network. A good allocation will deliver good performance because it uses all the available
bandwidth but avoids congestion, it will be fair across competing transport entities, and it
will quickly track changes in traffic demands.
An efficient allocation of bandwidth across transport entities will use all the network
capacity that is available. However, it is not quite right to think that if there is a 100-Mbps
link, five transport entities should get 20 Mbps each. They should usually get less than 20
Mbps for good performance.
For both goodput and delay, performance begins to degrade at the onset of
congestion. Intuitively, we will obtain the best performance from the network if we allocate
bandwidth up until the delay starts to climb rapidly. This point is below the capacity. To
identify it, Kleinrock (1979) proposed the metric of power, where
𝒑𝒐𝒘𝒆𝒓= 𝒅𝒆𝒍𝒂𝒚/𝒍𝒐𝒂𝒅
Max-Min Fairness
What a fair portion means for flows in a network? It is simple enough if N flows use a single
link, in which case they can all have 1/N of the bandwidth. But what happens if the flows
have different, but overlapping, network paths? For example, one flow may cross three links,
and the other flows may cross one link. The three-link flow consumes more network
resources.
It might be fairer in some sense to give it less bandwidth than the one-link flows. It
should certainly be possible to support more one-link flows by reducing the bandwidth of
the three-link flow. This point demonstrates an inherent tension between fairness and
efficiency.
The form of fairness that is often desired for network usage is max-min fairness. An
allocation is max-min fair if the bandwidth given to one flow cannot be increased without
decreasing the bandwidth given to another flow with an allocation that is no larger. That is,
increasing the bandwidth of a flow will only make the situation worse for flows that are less
well off.
Let us see an example. A max-min fair allocation is shown for a network with four
flows, A, B, C, and D, in Fig. 4-11. Each of the links between routers has the same capacity,
taken to be 1 unit, though in the general case the links will have different capacities. Three
flows compete for the bottom-left link between routers R4 and R5. Each of these flows
therefore gets 1/3 of the link. The remaining flow, A, competes with B on the link from R2
to R3. Since B has an allocation of 1/3, A gets the remaining 2/3 of the link. Notice that all
the other links have spare capacity. However, this capacity cannot be given to any of the

9 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

flows without decreasing the capacity of another, lower flow. For example, if more of the
bandwidth on the link between R2 and R3 is given to flow B, there will be less for flow A.
This is reasonable as flow A already has more bandwidth. However, the capacity of flow C
or D (or both) must be decreased to give more bandwidth to B, and these flows will have
less bandwidth than B. Thus, the allocation is max-min fair.

Figure 4-11. Max-min bandwidth allocation for four flows

Convergence

A final criterion is that the congestion control algorithm converges quickly to a fair and
efficient allocation of bandwidth. The discussion of the desirable operating point above
assumes a static network environment. However, connections are always coming and going
in a network, and the bandwidth needed by a given connection will vary over time too, for
example, as a user browses Web pages and occasionally downloads large videos.

Because of the variation in demand, the ideal operating point for the network varies
over time. A good congestion control algorithm should rapidly converge to the ideal
operating point, and it should track that point as it changes over time. If the convergence is
too slow, the algorithm will never be close to the changing operating point. If the algorithm
is not stable, it may fail to converge to the right point in some cases, or even oscillate around
the right point.

4.3.2. Regulating the Sending Rate

How do we regulate the sending rates to obtain a desirable bandwidth allocation? The
sending rate may be limited by two factors. The first is flow control, in the case that there is
insufficient buffering at the receiver. The second is congestion, in the case that there is
insufficient capacity in the network.

In Figure 4-12, we see this problem illustrated hydraulically. In Figure 4-12(a), we

see a thick pipe leading to a small-capacity receiver. This is a flow-control limited situation.
If the sender does not send more water than the bucket can contain, no water will be lost. In
Figure 4-12(b), the limiting factor is not the bucket capacity, but the internal carrying
capacity of the network. If too much water comes in too fast, it will back up and some will be
lost.

The way that a transport protocol should regulate the sending rate depends on the
form of the feedback returned by the network. Different network layers may return different

10 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

kinds of feedback. The feedback may be explicit or implicit, and it may be precise or
imprecise.

Figure 4-12. (a) A fast network feeding a low-capacity receiver. (b) A slow network feeding a high-capacity receiver.

An example of an explicit, precise design is when routers tell the sources the rate at
which they may send. Designs in the literature such as XCP (eXplicit Congestion Protocol)
operate in this manner. An explicit, imprecise design is the use of ECN (Explicit Congestion
Notification) with TCP. In this design, routers set bits on packets that experience congestion
to warn the senders to slow down, but they do not tell them how much to slow down.

In other designs, there is no explicit signal. FAST TCP measures the roundtrip delay
and uses that metric as a signal to avoid congestion. Finally, in the form of congestion control
most prevalent in the Internet today, TCP with drop-tail or RED routers, packet loss is
inferred and used to signal that the network has become congested.

There are many variants of this form of TCP, including CUBIC TCP, which is used in
Linux. Combinations are also possible. For example, Windows includes Compound TCP that
uses both packet loss and delay as feedback signals. These designs are summarized in Figure
4-13.

Figure 4-13. Signals of some congestion control protocols.

Chiu and Jain (1989) studied the case of binary congestion feedback and concluded
that AIMD (Additive Increase Multiplicative Decrease) is the appropriate control law (the
way in which the rates are increased or decreased) to arrive at the efficient and fair
operating point.

11 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

To argue this case, they constructed a graphical argument for the simple case of two
connections competing for the bandwidth of a single link. The graph in Figure 4-14 shows
the bandwidth allocated to user 1 on the x-axis and to user 2 on the y-axis.

When the allocation is fair, both users will receive the same amount of bandwidth.
This is shown by the dotted fairness line. When the allocations sum to 100%, the capacity of
the link, the allocation is efficient. This is shown by the dotted efficiency line. A congestion
signal is given by the network to both users when the sum of their allocations crosses this
line. The intersection of these lines is the desired operating point, when both users have the
same bandwidth and all the network bandwidth is used.

Figure 4-14. Additive and multiplicative bandwidth adjustments

Now consider the case that the users additively increase their bandwidth allocations
and then multiplicatively decrease them when congestion is signaled. This behavior is the
AIMD control law, and it is shown in Figure 4-15. The path traced by this behavior does
converge to the optimal point that is both fair and efficient. This convergence happens no
matter what the starting point, making AIMD broadly useful.

Figure 4-15. Additive Increase Multiplicative Decrease (AIMD) control law.

4.4. The Internet Transport Protocols: UDP

4.4.1. Introduction to UDP
The Internet protocol suite supports a connectionless transport protocol called UDP (User
Datagram Protocol). UDP provides a way for applications to send encapsulated IP datagrams
without having to establish a connection. UDP transmits segments consisting of an 8-byte
header followed by the payload. The header is shown in Figure 4-16.
12 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

Figure 4-16: UDP Header Format

• The two ports serve to identify the endpoints within the source and destination
machines.
• The UDP length field includes the 8-byte header and the data. The minimum length
is 8 bytes, to cover the header. The maximum length is 65,515 bytes, which is lower
than the largest number that will fit in 16 bits because of the size limit on IP packets.
• An optional Checksum is also provided for extra reliability. Its checksums the header,
the data, and a conceptual IP pseudo header.
4.4.2. Remote Procedure Call
When a process on machine 1 calls a procedure on machine 2, the calling process on 1 is
suspended and execution of the called procedure takes place on 2. Information can be
transported from the caller to the callee in the parameters and can come back in the
procedure result. No message passing is visible to the application programmer. This
technique is known as RPC (Remote Procedure Call) and has become the basis for many
networking applications. Traditionally, the calling procedure is known as the client and the
called procedure is known as the server.

The idea behind RPC is to make a remote procedure call look as much as possible like
a local one. In the simplest form, to call a remote procedure, the client program must be
bound with a small library procedure, called the client stub, that represents the server
procedure in the client’s address space. Similarly, the server is bound with a procedure
called the server stub. These procedures hide the fact that the procedure call from the client
to the server is not local.

The actual steps in making an RPC are shown in Fig. 4-17. Step 1 is the client calling
the client stub. This call is a local procedure call, with the parameters pushed onto the stack
in the normal way. Step 2 is the client stub packing the parameters into a message and
making a system call to send the message. Packing the parameters is called marshaling. Step
3 is the operating system sending the message from the client machine to the server
machine. Step 4 is the operating system passing the incoming packet to the server stub.
Finally, step 5 is the server stub calling the server procedure with the unmarshaled
parameters. The reply traces the same path in the other direction

In terms of transport layer protocols, UDP is a good base on which to implement RPC.
Both requests and replies may be sent as a single UDP packet in the simplest case and the
operation can be fast. DNS requests and replies are also sent through UDP.

13 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

Figure 4-17. Steps in making a remote procedure call. The stubs are shaded.

4.4.3. Real-time Transport Protocol

Client-server RPC is one area in which UDP is widely used. Another one is for real-time
multimedia applications. As Internet radio, Internet telephony, music-on-demand,
videoconferencing, video-on-demand, and other multimedia applications became more
commonplace, people have discovered that each application was reinventing the same real-
time transport protocol. It gradually became clear that having a generic real-time transport
protocol for multiple applications would be a good idea. Thus was RTP (Real-time Transport
Protocol) born. The basic function of RTP is to multiplex several real-time data streams onto
a single stream of UDP packets. The UDP stream can be sent to a single destination
(unicasting) or to multiple destinations (multicasting).

Because RTP just uses normal UDP, its packets are not treated specially by the
routers unless some normal IP quality-of-service features are enabled. There are no special
guarantees about delivery, and packets may be lost, delayed, corrupted, etc. The RTP format
contains several features to help receivers work with multimedia information.

1. Each packet sent in an RTP stream is given a number one higher than its predecessor.
This numbering allows the destination to determine if any packets are missing. If a
packet is missing, the best action for the destination to take is up to the application. It
may be to skip a video frame if the packets are carrying video data, or to approximate
the missing value by interpolation if the packets are carrying audio data.
2. Each RTP payload may contain multiple samples, and they may be coded any way that
the application wants. For example, a single audio stream may be encoded as 8-bit PCM
samples at 8 kHz using delta encoding, predictive encoding, GSM encoding, MP3
encoding, and so on. RTP provides a header field in which the source can specify the
encoding.
3. Another facility many real-time applications need is timestamping. The idea here is to
allow the source to associate a timestamp with the first sample in each packet. This
mechanism allows the destination to do a small amount of buffering and play each
sample the right number of milliseconds after the start of the stream, independently of
when the packet containing the sample arrived.

14 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

The RTP header is illustrated in Fig. 4-18. It consists of three 32-bit words and potentially
some extensions.

Figure 4-18. The RTP header

• The first word contains the Version field, which is already at 2.

• The P bit indicates that the packet has been padded to a multiple of 4 bytes. The last
padding byte tells how many bytes were added.
• The X bit indicates that an extension header is present.
• The CC field tells how many contributing sources are present, from 0 to 15.
• The M bit is an application-specific marker bit. It can be used to mark the start of a
video frame, the start of a word in an audio channel, or something else that the
application understands.
• The Payload type field tells which encoding algorithm has been used (e.g.,
uncompressed 8-bit audio, MP3, etc.). The Sequence number is just a counter that is
incremented on each RTP packet sent. It is used to detect lost packets.
• The Timestamp is produced by the stream’s source to note when the first sample in
the packet was made. This value can help reduce timing variability called jitter at the
receiver by decoupling the playback from the packet arrival time.
• The Synchronization source identifier tells which stream the packet belongs to. It is
the method used to multiplex and demultiplex multiple data streams onto a single
stream of UDP packets. Finally, the Contributing source identifiers, if any, are used
when mixers are present in the studio.
4.4.4. RTCP—The Real-time Transport Control Protocol
RTP has a little sister protocol called RTCP (Realtime Transport Control Protocol). It handles
feedback, synchronization, and the user interface. It does not transport any media samples.
The first function can be used to provide feedback on delay, variation in delay or jitter,
bandwidth, congestion, and other network properties to the sources. This information can
be used by the encoding process to increase the data rate when the network is functioning
well and to cut back the data rate when there is trouble in the network. The Payload type
field is used to tell the destination what encoding algorithm is used for the current packet,
making it possible to vary it on demand.

15 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

RTCP also handles interstream synchronization. The problem is that different

streams may use different clocks, with different granularities and different drift rates. RTCP
can be used to keep them in sync. Finally, RTCP provides a way for naming the various
sources (e.g., in ASCII text). This information can be displayed on the receiver’s screen to
indicate who is talking now.

4.4.5. Playout with Buffering and Jitter Control

Once the media information reaches the receiver, it must be played out at the right time. In
general, this will not be the time at which the RTP packet arrived at the receiver because
packets will take slightly different amounts of time to transit the network. Even if the
packets are injected with exactly the right intervals between them at the sender, they will
reach the receiver with different relative times. This variation in delay is called jitter. Even
a small amount of packet jitter can cause distracting media artifacts, such as jerky video
frames and unintelligible audio, if the media is simply played out as it arrives.
The solution to this problem is to buffer packets at the receiver before they are played
out to reduce the jitter. As an example, in Fig. 4-19 we see a stream of packets being
delivered with a substantial amount of jitter. Packet 1 is sent from the server at t = 0 sec and
arrives at the client at t = 1 sec. Packet 2 undergoes more delay and takes 2 sec to arrive. As
the packets arrive, they are buffered on the client machine.
At t = 10 sec, playback begins. Currently, packets 1 through 6 have been buffered so
that they can be removed from the buffer at uniform intervals for smooth play. In the general
case, it is not necessary to use uniform intervals because the RTP timestamps tell when the
media should be played.
Unfortunately, we can see that packet 8 has been delayed so much that it is not
available when its play slot comes up. There are two options. Packet 8 can be skipped and
the player can move on to subsequent packets. Alternatively, playback can stop until packet
8 arrives, creating an annoying gap in the music or movie. In a live media application like a
voice-over-IP call, the packet will typically be skipped. Live applications do not work well on
hold. In a streaming media application, the player might pause. This problem can be
alleviated by delaying the starting time even more, by using a larger buffer. For a streaming
audio or video player, buffers of about 10 seconds are often used to ensure that the player
receives all the packets (that are not dropped in the network) in time. For live applications
like videoconferencing, short buffers are needed for responsiveness.

Figure 4-19. Smoothing the output stream by buffering packets

16 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

4.5. The Internet Transport Protocols: TCP

4.5.1. Introduction to TCP
TCP (Transmission Control Protocol) was specifically designed to provide a reliable end-to-
end byte stream over an unreliable internetwork. An internetwork differs from a single
network because different parts may have wildly different topologies, bandwidths, delays,
packet sizes, and other parameters. TCP was designed to dynamically adapt to properties of
the internetwork and to be robust in the face of many kinds of failures.

4.5.2. The TCP Service Model

TCP service is obtained by both the sender and the receiver creating end points, called
sockets. Each socket has a socket number (address) consisting of the IP address of the host
and a 16-bit number local to that host, called a port.
A socket may be used for multiple connections at the same time. In other words, two
or more connections may terminate at the same socket. Connections are identified by the
socket identifiers at both ends.
Port numbers below 1024 are reserved for standard services that can usually only
be started by privileged users (e.g., root in UNIX systems). They are called well-known ports.
For example, HTTP protocol have the port number 80. Other ports from 1024 through
49151 can be registered with IANA for use by unprivileged users, but applications can and
do choose their own ports.
All TCP connections are full duplex and point-to-point. Full duplex means that traffic
can go in both directions at the same time. Point-to-point means that each connection has
exactly two end points. TCP does not support multicasting or broadcasting.
A TCP connection is a byte stream, not a message stream. For example, if the sending
process does four 512-byte writes to a TCP stream, these data may be delivered to the
receiving process as four 512-byte chunks, two 1024-byte chunks, one 2048-byte chunk.

4.5.3. The TCP Protocol

A key feature of TCP, and one that dominates the protocol design, is that every byte on a TCP
connection has its own 32-bit sequence number. Separate 32-bit sequence numbers are
carried on packets for the sliding window position in one direction and for
acknowledgements in the reverse direction. The sending and receiving TCP entities
exchange data in the form of segments. A TCP segment consists of a fixed 20-byte header
(plus an optional part) followed by zero or more data bytes.
Two limits restrict the segment size. First, each segment, including the TCP header,
must fit in the 65,515-byte IP payload. Second, each link has an MTU (Maximum Transfer
Unit). Each segment must fit in the MTU at the sender and receiver so that it can be sent and
received in a single, unfragmented packet. In practice, the MTU is generally 1500 bytes (the
Ethernet payload size) and thus defines the upper bound on segment size.

17 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

However, it is still possible for IP packets carrying TCP segments to be fragmented

when passing over a network path for which some link has a small MTU. If this happens, it
degrades performance and causes other problems.
Instead, modern TCP implementations perform path MTU discovery by using the
technique outlined in RFC 1191. This technique uses ICMP error messages to find the
smallest MTU for any link on the path. TCP then adjusts the segment size downwards to
avoid fragmentation.
The basic protocol used by TCP entities is the sliding window protocol with a
dynamic window size. When a sender transmits a segment, it also starts a timer. When the
segment arrives at the destination, the receiving TCP entity sends back a segment bearing
an acknowledgement number equal to the next sequence number it expects to receive and
the remaining window size. If the sender’s timer goes off before the acknowledgement is
received, the sender transmits the segment again.

4.5.4. The TCP Segment Header

Every segment begins with a fixed-format, 20-byte header. The fixed header may be
followed by header options. After the options, if any, up to 65,535 − 20 − 20 = 65,495 data
bytes may follow, where the first 20 refer to the IP header and the second to the TCP header.
Segments without any data are legal and are commonly used for acknowledgements and
control messages. It is illustrated in Figure 4-20.
• The Source port and Destination port fields identify the local end points of the
connection. A TCP port plus its host’s IP address forms a 48-bit unique end point. The
source and destination end points together identify the connection. This connection
identifier is called a 5 tuple because it consists of five pieces of information: the
protocol (TCP), source IP and source port, and destination IP and destination port.
• The Sequence number and Acknowledgement number fields perform their usual
functions. Note that the latter specifies the next in-order byte expected, not the last
byte correctly received. It is a cumulative acknowledgement because it summarizes
the received data with a single number.
• The TCP header length tells how many 32-bit words are contained in the TCP header.
This information is needed because the Options field is of variable length, so the
header is, too. Next comes a 4-bit field that is not used.
• Now come eight 1-bit flags. CWR and ECE are used to signal congestion when ECN
(Explicit Congestion Notification) is used. ECE is set to signal an ECN-Echo to a TCP
sender to tell it to slow down when the TCP receiver gets a congestion indication
from the network. CWR is set to signal Congestion Window Reduced from the TCP
sender to the TCP receiver so that it knows the sender has slowed down and can stop
sending the ECN-Echo.
• URG is set to 1 if the Urgent pointer is in use. The Urgent pointer is used to indicate a
byte offset from the current sequence number at which urgent data are to be found.

18 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

• The ACK bit is set to 1 to indicate that the Acknowledgement number is valid. If ACK
is 0, the segment does not contain an acknowledgement, so the Acknowledgement
number field is ignored.
• The PSH bit indicates PUSHed data. The receiver is hereby kindly requested to deliver
the data to the application upon arrival and not buffer it until a full buffer has been
received. The RST bit is used to abruptly reset a connection that has become confused
due to a host crash or some other reason.
• The SYN bit is used to establish connections. The connection request has SYN = 1 and
ACK = 0 to indicate that the piggyback acknowledgement field is not in use. The
connection reply does bear an acknowledgement, however, so it has SYN = 1 and
ACK = 1.
• The FIN bit is used to release a connection. It specifies that the sender has no more
data to transmit.
• Flow control in TCP is handled using a variable-sized sliding window. The Window
size field tells how many bytes may be sent starting at the byte acknowledged.
• A Checksum is also provided for extra reliability. It checksums the header, the data,
and a conceptual pseudo header in the same way as UDP.
• The Options field provides a way to add extra facilities not covered by the regular
header.

Figure 4-20. The TCP header

4.5.5. TCP Connection Establishment

Connections are established in TCP by means of the three-way handshake. To establish a
connection, one side, say, the server, passively waits for an incoming connection by
executing the LISTEN and ACCEPT primitives in that order. The other side, say, the client,
executes a CONNECT primitive, specifying the IP address and port to which it wants to
connect, the maximum TCP segment size it is willing to accept, and optionally some user

19 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

data. The CONNECT primitive sends a TCP segment with the SYN bit on and ACK bit off and
waits for a response.

When this segment arrives at the destination, the TCP entity there checks to see if
there is a process that has done a LISTEN on the port given in the Destination port field. If
not, it sends a reply with the RST bit on to reject the connection. The sequence of TCP
segments sent in the normal case is shown in Fig. 4-21(a). If two hosts simultaneously
attempt to establish a connection between the same two sockets, the sequence of events is
as illustrated in Fig. 4-21(b). The result of these events is that just one connection is
established, not two, because connections are identified by their end points.

Figure 4-21. (a) TCP connection establishment in the normal case. (b) Simultaneous connection
establishment on both sides.

4.5.6. TCP Connection Release

To release a connection, either party can send a TCP segment with the FIN bit set, which
means that it has no more data to transmit. When the FIN is acknowledged, that direction is
shut down for new data. Data may continue to flow indefinitely in the other direction,
however. When both directions have been shut down, the connection is released. Normally,
four TCP segments are needed to release a connection: one FIN and one ACK for each
direction. However, it is possible for the first ACK and the second FIN to be contained in the
same segment, reducing the total count to three.

4.5.7. TCP Connection Management Modeling

The steps required to establish and release connections can be represented in a finite state
machine with the 11 states listed in Figure 4-22. In each state, certain events are legal. When
a legal event happens, some action may be taken. If some other event happens, an error is
reported.

Each connection starts in the CLOSED state. It leaves that state when it does either a
passive open (LISTEN) or an active open (CONNECT). If the other side does the opposite
one, a connection is established and the state becomes ESTABLISHED. Connection release
can be initiated by either side. When it is complete, the state returns to CLOSED.
20 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology
COMPUTER NETWORKS 21CS52

Figure 4-22. The states used in the TCP connection management finite state machine.

The finite state machine itself is shown in Figure 4-23. The common case of a client actively
connecting to a passive server is shown with heavy lines—solid for the client, dotted for the
server. The lightface lines are unusual event sequences. Each line in Figure 4-23 is marked
by an event/action pair. The event can either be a user-initiated system call (CONNECT,
LISTEN, SEND, or CLOSE), a segment arrival (SYN, FIN, ACK, or RST), or, in one case, a
timeout of twice the maximum packet lifetime. The action is the sending of a control segment
(SYN, FIN, or RST) or nothing, indicated by —. Comments are shown in parentheses.

Figure 4-23. TCP connection management finite state machine. The heavy solid line is the normal path for a client. The
heavy dashed line is the normal path for a server. The light lines are unusual events. Each transition is labeled with the
event causing it and the action resulting from it, separated by a slash.

21 Dr. Kala Venugopal, Associate Professor, Dept. of ISE, Acharya Institute of Technology