Unit-IV

TRANSPORT LAYER
 UDP – Segment header
 Remote procedure call
 Real-time transport protocols
 TCP – service model
 Protocol, Segment header
 Connection establishment
 Connection release
 Sliding window
 Timer management
 Congestion control
 UNIT-IV
TRANSPORT LAYER
The Transport Service
• Services Provided to the Upper Layers
• Transport Service Primitives
• Berkeley Sockets
• It is the heart of the whole protocol hierarchy.
• Its task is to provide reliable, cost-effective data transport from the source
machine to the destination machine, independently of the physical network
or networks currently in use.
• In the following sections we will provide an introduction to the transport
service.
• We look at what kind of service is provided to the application layer.
• To make the issue of transport service more concrete, we will examine two
sets of transport layer primitives.
SERVICES PROVIDED TO THE UPPER LAYERS

• To achieve this goal, the transport layer makes use of the services
provided by the network layer.
• The hardware and/or software within the transport layer that does the
work is called the transport entity.
• The transport entity can be located in the operating system kernel, in a
separate user process, in a library package bound into network
applications, or conceivably on the network interface card.
 • The (logical) relationship of the network, transport, and application
layers is illustrated in next slide.

Services Provided to the Upper Layers.

• There are also two types of Network / Transport service.
• connection-oriented and
• connectionless
• In both cases, connections have three phases:
• establishment,
• data transfer, and
• release
Addressing and flow control are also similar in both layers
• The existence of the transport layer makes it possible for the transport
service to be more reliable than the underlying network service.
• Lost packets and garbled data can be detected and compensated for by the
transport layer.
• Furthermore, the transport service primitives can be implemented as calls
to library procedures in order to make them independent of the network
service primitives.
 • Application programmers can write code according to a standard set of
primitives and have these programs work on a wide variety of networks,
without having to worry about dealing with different subnet interfaces and
unreliable transmission.
• For this reason, many people have traditionally made a distinction between
layers 1 through 4 on the one hand and layer(s) above 4 on the other.
• The bottom four layers can be seen as the transport service provider,
whereas the upper layer(s) are the transport service user.
• This distinction of provider versus user has a considerable impact on the
design of the layers and puts the transport layer in a key position, since it
forms the major boundary between the provider and user of the reliable
data transmission service.
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.
• In this section, we will first examine a simple (hypothetical) transport
service and its interface.
• The transport service is similar to the network service, but there are also
some important differences.
• The main difference is that the network service is intended to model the
service offered by real networks, warts and all.
• Real networks can lose packets, so the network service is generally
unreliable.
• A second difference between the network service and transport service is
whom the services are intended for.
• The network service is used only by the transport entities. Few users write
their own transport entities, and thus few users or programs ever see the
bare network service.
• In contrast, many programs see the transport primitives. Consequently, the
transport service must be convenient and easy to use.
Transport Service Primitives:
To get an idea of what a transport service might be like, consider the five
primitives listed below.

The primitives for a simple transport service.

Transport Service Primitives (2)

The nesting of TPDUs, packets, and frames.
1.3 Berkeley Sockets:
The socket primitives for TCP.

2. Elements of Transport Protocols

• Addressing
• Connection Establishment
• Connection Release
• Flow Control and Buffering
• Multiplexing
• Crash Recovery
• The transport service is implemented by a transport protocol used between
the two transport entities.
• transport protocols resemble the data link protocols, Both have to deal
with error control, sequencing, and flow control, among other issues.
• significant differences between the two also exist. These differences are
due to major dissimilarities between the environments in which the two
protocols operate.
Transport Protocol

(a) Environment of the data link layer.

(b) Environment of the transport layer.

Difference b/n DLL & TL

• In the data link layer, it is not necessary for a router to specify which router
it wants to talk to-each outgoing line uniquely specifies a particular router.
• In the transport layer, explicit addressing of destinations is required.
• In data link layer, the process of establishing a connection over the wire of
is simple: the other end is always there.
• In the transport layer, initial connection establishment is more complicated,
as we will see.
• Another difference between the data link layer and the transport layer is
the potential existence of storage capacity in the subnet.
• A final difference between the data link and transport layers is Buffering
and flow control are needed in both layers
Addressing
TSAPs, NSAPs and transport connections.
Transport / network Service Access Point

• A possible scenario for a transport connection is as follows.

– A time of day server process on host 2 attaches itself to TSAP 1522 to
wait for an incoming call.
– An application process on host 1 wants to find out the time-of-day,
so it issues a CONNECT request specifying TSAP 1208 as the source
and TSAP 1522 as the destination.
 – This action ultimately results in a transport connection being
established between the application process on host 1 and server 1
on host 2.
– The application process then sends over a request for the time.
– The time server process responds with the current time.
– The transport connection is then released.

How a user process in host 1 establishes a connection with a time-of-day server

in host 2.

• It is known as the initial connection protocol. Instead of every conceivable

server listening at a well-known TSAP, each machine that wishes to offer
services to remote users has a special process server that acts as a proxy for
less heavily used servers.
• an alternative scheme is often used. In this model, there exists a special
process called a name server or sometimes a directory server.
Elements of Transport Protocols
• Addressing
• Connection Establishment
• Connection Release
• Flow Control and Buffering
• Multiplexing
• Crash Recovery

Connection Establishment
• Establishing a connection sounds easy, but it is actually surprisingly tricky.
• At first glance, it would seem sufficient for one transport entity to just send
a CONNECTION REQUEST TPDU to the destination and wait for a
CONNECTION ACCEPTED reply.
• The problem occurs when the network can lose, store, and duplicate
packets. This behavior causes serious complications.
• The problem is with delayed duplicates.
• Solutions:
• One way is to use throw-away transport addresses.
• Another possibility is to give each connection a connection identifier .
• transport entity to maintain a certain amount of history information
indefinitely.
• Instead, Rather than allowing packets to live forever within the subnet, we
must devise a mechanism to kill off aged packets that are still hobbling
about.
• If we can ensure that no packet lives longer than some known time, the
problem becomes somewhat more manageable.
• Packet lifetime can be restricted to a known maximum using one (or more)
of the following techniques:
• Restricted subnet design.
• includes any method that prevents packets from looping
• Putting a hop counter in each packet.
• Timestamping each packet.
 • The clock-based method solves the delayed duplicate problem for data
TPDUs, but for this method to be useful, a connection must first be
established.
• Since control TPDUs may also be delayed, there is a potential problem in
getting both sides to agree on the initial sequence number.
• To solve this problem, Tomlinson (1975) introduced the three-way
handshake.
• This establishment protocol does not require both sides to begin sending
with the same sequence number.

Three protocol scenarios for establishing a connection using a three-way

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

Elements of Transport Protocols

• Addressing
• Connection Establishment
• Connection Release
• Flow Control and Buffering
• Multiplexing
 • Crash Recovery

Connection Release
• 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 (sudden / unexpected) and may result in data loss.

Abrupt disconnection with loss of data.

 • One way is to use symmetric release, in which each direction is released
independently of the other one.
• Here, a host can continue to receive data even after it has sent a
DISCONNECT TPDU.
• Symmetric release does the job when each process has a fixed amount of
data to send and clearly knows when it has sent it.
• 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.

Connection Release
Asymmetric release is abrupt (sudden / unexpected) and may result in data loss.

Abrupt disconnection with loss of data.

 • One way is to use symmetric release, in which each direction is released
independently of the other one.
• Here, a host can continue to receive data even after it has sent a
DISCONNECT TPDU.
• Symmetric release does the job when each process has a fixed amount of
data to send and clearly knows when it has sent it.
• 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.

Connection Release (2)

 Unfortunately, this protocol does not always work.
 The two-army problem illustrates four scenarios of releasing using a three-
way handshake. While this protocol is not reliable, it is usually adequate.

Connection Release (3)

Four protocol scenarios for releasing a connection.
(a) Normal case of a three-way handshake.
(b) final ACK lost.
Connection Release (4)
Flow Control and Buffering
• let us now look at how connections are managed while they are in use.
• One of the key issues has come up before: flow control.
• The basic similarity is that in both layers a sliding window or other scheme
is needed on each connection to keep a fast transmitter from overrunning a
slow receiver.
• if the network service is unreliable, the sender must buffer all TPDUs sent.
• if the sender knows that the receiver always has buffer space, it need not
retain copies of the TPDUs it sends.
• However, if the receiver cannot guarantee that every incoming TPDU will
be accepted, the sender will have to buffer anyway.

(a) Chained fixed-size buffers. (b) Chained variable-sized buffers.

(c) One large circular buffer per connection.

• Figure 6-16 shows an example of how dynamic window management might

work in a datagram subnet with 4-bit sequence numbers.
 • Assume that buffer allocation information travels in separate TPDUs, as
shown, and is not piggybacked onto reverse traffic.

Flow Control and Buffering (2)

Dynamic buffer allocation. The arrows show the direction of transmission. An

ellipsis (…) indicates a lost TPDU.

• Potential problems with buffer allocation schemes of this kind can arise in
datagram networks if control TPDUs can get lost.
• Look at line 16. B has now allocated more buffers to A, but the allocation
TPDU was lost. Since control TPDUs are not sequenced or timed out, A is
now deadlocked.
• To prevent this situation, each host should periodically send control TPDUs
giving the acknowledgement and buffer status on each connection. That
way, the deadlock will be broken, sooner or later.
• When buffer space no longer limits the maximum flow, another bottleneck
will appear: the carrying capacity of the subnet.
 • If adjacent routers can exchange at most x packets/sec and there are k
disjoint paths between a pair of hosts, there is no way that those hosts can
exchange more than kx TPDUs/sec, no matter how much buffer space is
available at each end.
• If the sender pushes too hard (i.e., sends more than kx TPDUs/sec), the
subnet will become congested because it will be unable to deliver TPDUs as
fast as they are coming in.

Elements of Transport Protocols

• Addressing
• Connection Establishment
• Connection Release
• Flow Control and Buffering
• Multiplexing
• Crash Recovery

Multiplexing
• In the transport layer the need for multiplexing can arise in a number of
ways.
• For example, if only one network address is available on a host, all
transport connections on that machine have to use it.
• When a TPDU comes in, some way is needed to tell which process to give it
to. This situation, called upward multiplexing.
• Suppose, that a subnet uses virtual circuits internally and imposes a
maximum data rate on each one.
• If a user needs more bandwidth than one virtual circuit can provide, a way
out is to open multiple network connections and distribute the traffic
among them on a round-robin basis, as indicated in Fig. 6-17(b). This is
called downward multiplexing.
Elements of Transport Protocols
• Addressing
• Connection Establishment
• Connection Release
• Flow Control and Buffering
• Multiplexing
• Crash Recovery

Crash Recovery
Different combinations of client and server strategy.
 • In an attempt to recover its previous status, the server might send a
broadcast TPDU to all other hosts, announcing that it had 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 TPDU outstanding, S1, or no
TPDUs outstanding, S0.
• Based on only this state information, the client must decide whether to
retransmit the most recent TPDU.

The Internet Transport Protocols: UDP

• Introduction to UDP
• look at two applications of UDP.
• Remote Procedure Call
• The Real-Time Transport Protocol

The UDP header.

• The packet produced by the UDP is called a user datagram .

– Source port address. The source port address is the address of the
application program that has created the message.
– Destination port address. The destination port address is the address
of the application program that will receive the message.
– Total length. The total length field defines the total length of the
user datagram in bytes.
– Check sum. The check sum is a 16-bit field used in error detection.
• UDP can discover that an error has occurred; ICMP can then inform the
sender that a user datagram has been damaged and discarded.
 • It is probably worth mentioning explicitly some of the things that UDP does
not do.
– It does not do flow control, error control, or retransmission upon
receipt of a bad segment.
– All of that is up to the user processes.
• What it does do is provide an interface to the IP protocol with the added
feature of demultiplexing multiple processes using the ports.
• One area where UDP is especially useful is in client-server situations. Often,
the client sends a short request to the server and expects a short reply
back.

Remote Procedure Call

• In a certain sense, sending a message to a remote host and getting a reply
back is a lot like making a function call in a programming language.
• In both cases you start with one or more parameters and you get back a
result.
• Birrell and Nelson suggested was allowing programs to call procedures
located on remote hosts.
• 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 programmer. This technique is known
as RPC (Remote Procedure Call) and has become the basis for many
networking applications.
• 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.
The actual steps in making an RPC are shown in Fig. 6-24.
• 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 kernel sending the message from the client machine to the
server machine.
• Step 4 is the kernel 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.
The Real-Time Transport Protocol
• Client-server RPC is one area in which UDP is widely used.
• Another one is real-time multimedia applications.
• In particular, as Internet radio, Internet telephony, music-on-demand,
videoconferencing, video-on-demand, and other multimedia applications.
• 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.

(a) The position of RTP in the protocol stack. (b) Packet nesting.

• As a consequence of this design, it is a little hard to say which layer RTP is

in.

• 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.

• In particular, there are no special guarantees about delivery, jitter, etc.

 • 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 to

approximate the missing value by interpolation.

• Retransmission is not a practical option since the retransmitted packet

would probably arrive too late to be useful.

• As a consequence, RTP has no flow control, no error control, no

acknowledgements, and no mechanism to request retransmissions.

The Real-Time Transport Protocol (2)

The RTP header.

• It consists of three 32-bit words and potentially some extensions.

• 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 format and meaning of the extension header are not defined. The only
thing that is defined is that the first word of the extension gives the length.

• The CC field tells how many contributing sources are present. It can be used
to , from 0 to 15 .

• The M bit is an application-specific 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 jitter.

• 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.

RTCP—The Real-time Transport Control Protocol

• RTP has a little sister protocol (little sibling protocol) called RTCP (Realtime
Transport Control Protocol). It is defined along with RTP in RFC 3550

• 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 (and give better quality) when the network is functioning well and to
cut back the data rate when there is trouble in the network.

• By providing continuous feedback, the encoding algorithms can be

continuously adapted to provide the best quality possible under the current
circumstances

The Internet Transport Protocols: TCP

• Introduction to TCP

• The TCP Service Model

• The TCP Protocol

• The TCP Segment Header

• TCP Connection Establishment

• TCP Connection Release

• TCP Connection Management Modeling

• TCP Transmission Policy

• TCP Congestion Control

• TCP Timer Management

• Wireless TCP and UDP

• Transactional TCP
Transitional TCP
The nine packets are as follows:

1. The client sends a SYN packet to establish a connection.

2. The server sends an ACK packet to acknowledge the SYN packet.

3. The client completes the three-way handshake.

4. The client sends the actual request.

5. The client sends a FIN packet to indicate that it is done sending.

6. The server acknowledges the request and the FIN.

7. The server sends the reply back to the client.

8. The server sends a FIN packet to indicate that it is also done.

9. The client acknowledges the server's FIN.

(a) RPC using normal TPC.

(b) RPC using T/TCP.

• The efficiency of RPC using UDP (just two messages) with the reliability of
TCP. The answer is: Almost.

• It can be done with an experimental TCP variant called T/TCP (Transactional

TCP).

• The central idea here is to modify the standard connection setup sequence
slightly to allow the transfer of data during setup. The T/TCP protocol is
illustrated in Fig. 6-40(b).

• The client's first packet contains the SYN bit, the request itself, and the FIN.
In effect it says: I want to establish a connection, here is the data, and I am
done.

• When the server gets the request, it looks up or computes the reply, and
chooses how to respond. If the reply fits in one packet, it gives the reply of
Fig. 6-40(b), which says: I acknowledge your FIN, here is the answer, and I
am done. The client then acknowledges the server's FIN and the protocol
terminates in three messages.

• TCP service is obtained by both the sender and 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 port is the
TCP name for a TSAP.

• Port numbers below 1024 are called well-known ports and are reserved for
standard services.

• All TCP connections are full duplex and point-to-point.

The TCP Service Model
Some assigned ports.

• A TCP connection is a byte stream, not a message stream.

• Message boundaries are not preserved end to end.

• 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 , or some other
way.

(a) Four 512-byte segments sent as separate IP datagrams.

(b) The 2048 bytes of data delivered to the application in a single READ CALL.
The TCP Segment Header

• Source port address. The source port address defines the application
program in the source computer.

• Destination port address. The destination port address defines the

application program in the destination computer.

• Sequence number. A stream of data from the application program may be

divided into two or more TCP segments. The sequence number field shows
the position of the data in the original data stream.

• Acknowledgement number.

• The 32-bit acknowledgement number is used to acknowledge the receipt of

data from the other communicating device.

• This number is valid only if the ACK bit in the control field(explained later) is
set. In this case, it defines the byte sequence number that is next expected.
• Header Length (HLEN).

• The four-bit HLEN field indicates the number of 32-bit (four-byte) words in
the TCP header.

• The four bits can define a number up to 15.This is multiplied by 4 to give

the total number of bytes in the header. Therefore, the size of the header
can be a maximum of 60 bytes (4x15).Since the minimum required size of
the header is 20 bytes, 40 bytes are thus available for the options section.

• Reserved. A six-bit field is reserved for future use.

• 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. This facility is in lieu of interrupt messages.

• 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 (which it might otherwise do for efficiency).
• The RST bit is used to reset a connection that has become confused due to
a host crash or some other reason. It is also used to reject an invalid
segment or refuse an attempt to open a connection.

• 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, so it has SYN = 1 and

ACK = 1.

• In essence the SYN bit is used to denote CONNECTION REQUEST and

CONNECTION ACCEPTED, with the ACK bit used to distinguish between
those two possibilities.

• The FIN bit is used to release a connection.

• It specifies that the sender has no more data to transmit.

• Both SYN and FIN segments have sequence numbers and are thus
guaranteed to be processed in the correct order.

• Window size. The window is a 16-bit field that defines the size of the sliding
window.

• Checksum. The checksum is a 16-bit field used in error detection.

• Urgent pointer. This is the last required field in the header. Its value is valid
only if the URG bit in the control field is set. In this case, the sender is
informing the receiver that there are urgent data in the data portion of the
segment. This pointer defines the end of urgent data and the start of
normal data.

• Options and padding. The remainder of the TCP header defines the
optional fields. They are used to convey additional information to the
receiver or for alignment purposes.
The TCP Segment Header (2)
The pseudoheader included in the TCP checksum.

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, either
specifying a specific source or nobody in particular.

• 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 data (e.g., a
password). 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
 (a) TCP connection establishment in the normal case.

(b) Simultaneous connection establishment on both sides.

TCP Connection Release

• Each simplex connection is released independently of its sibling.

• 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.

• To avoid the two-army problem, timers are used.

 • If a response to a FIN is not forthcoming within two maximum packet
lifetimes, the sender of the FIN releases the connection.

• The other side will eventually notice that nobody seems to be listening to it
any more and will time out as well.

TCP Connection Management Modeling

TCP Connection Management Modeling (2)

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 by the event causing
it and the action resulting from it, separated by a slash.
• When the window is 0, the sender may not normally send segments, with
two exceptions. First, urgent data may be sent, for example, to allow the
user to kill the process running on the remote machine. Second, the sender
may send a 1-byte segment to force the receiver to reannounce the next
byte expected and the window size. This packet is called a window probe.

• The TCP standard explicitly provides this option to prevent deadlock if a

window update ever gets lost.

• One approach that many TCP implementations use to optimize Bandwidth

situation is called delayed acknowledgements.

• The idea is to delay acknowledgements and window updates for up to 500

msec in the hope of acquiring some data on which to hitch a free ride.
• Although delayed acknowledgements reduce the load placed on the
network by the receiver, a sender that sends multiple short packets (e.g.,
41-byte packets containing 1 byte of data) is still operating inefficiently. A
way to reduce this usage is known as Nagle’s algorithm (Nagle, 1984)

• What Nagle suggested is simple: when data come into the sender in small
pieces, just send the first piece and buffer all the rest until the first piece is
acknowledged.

• Then send all the buffered data in one TCP segment and start buffering
again until the next segment is acknowledged.

• That is, only one short packet can be outstanding at any time.

• If many pieces of data are sent by the application in one round-trip time,
Nagle’s algorithm will put the many pieces in one segment, greatly reducing
the bandwidth used.

• The algorithm additionally says that a new segment should be sent if

enough data have trickled in to fill a maximum segment.

• A more subtle problem is that Nagle’s algorithm can sometimes interact

with delayed acknowledgements to cause a temporary deadlock: the
receiver waits for data on which to piggyback an acknowledgement, and
the sender waits on the acknowledgement to send more data. This
interaction can delay the downloads of Web pages. Because of these
problems, Nagle’s algorithm can be disabled

• Another problem that can degrade TCP performance is the Silly

window syndrome (Clark, 1982). This problem occurs when data are
passed to the sending TCP entity in large blocks, but an interactive
application on the receiving side reads data only 1 byte at a time.

• Clark's solution is to prevent the receiver from sending a window update

for 1 byte.
 • Instead it is forced to wait until it has a decent amount of space available
and advertise that instead.

• Specifically, the receiver should not send a window update until it can
handle the maximum segment size it advertised when the connection was
established or until its buffer is half empty, whichever is smaller

• Nagle’s algorithm and Clark’s solution to the silly window syndrome are
complementary.

• Nagle was trying to solve the problem caused by the sending application
delivering data to TCP a byte at a time.

• Clark was trying to solve the problem of the receiving application sucking
the data up from TCP a byte at a time. Both solutions are valid and can
work together.

• The goal is for the sender not to send small segments and the receiver not
to ask for them.

• Acknowledgements can be sent only when all the data up to the byte
acknowledged have been received. This is called a cumulative
acknowledgement.

TCP Transmission Policy (2)

Silly window syndrome.

TCP Timer Management

• TCP uses multiple timers (at least conceptually) to do its work.

– Retransmission timer.

– Persistence timer

– Keepalive timer

• When a segment is sent, a retransmission timer is started.

• If the segment is acknowledged before the timer expires, the timer is

stopped.

• If, on the other hand, the timer goes off before the acknowledgement
comes in, the segment is retransmitted.

• The question that arises is: How long should the timeout interval be?

• RTO (Retransmission Time Out)- When a segment is sent, a retransmission

timer is started. If the segment is acknowledged before the timer expires,
the timer is stopped.

As Shown in Figure (a) Probability density of acknowledgement arrival times in

the data link layer.

• Since acknowledgements are rarely delayed in the data link layer (due to
lack of congestion), the absence of an acknowledgement at the expected
time generally means either the frame or the acknowledgement has been
lost.

• If the timeout is set too short, say, T1 in Figure (b), unnecessary

retransmissions will occur, clogging the Internet with useless packets.
 • If it is set too long (e.g., T2), performance will suffer due to the long
retransmission delay whenever a packet is lost. Furthermore, the mean and
variance of the acknowledgement arrival distribution can change rapidly
within a few seconds as congestion builds up or is resolved.

• RTTVAR (Round-Trip Time Variation) that is updated using the formula

RTTVAR = β RTTVAR + (1 − β) |SRTT − R |

• This is an EWMA as before, and typically β = 3/4.

• The retransmission timeout, RTO, is set to be

RTO = SRTT + 4 × RTTVAR

Persistence timer
• It is designed to prevent the following deadlock.
• The receiver sends an acknowledgement with a window size of 0, telling the
sender to wait. Later, the receiver updates the window, but the packet with
the update is lost. Now both the sender and the receiver are waiting for
each other to do something.
• When the persistence timer goes off, the sender transmits a probe to the
receiver. The response to the probe gives the window size. If it is still zero,
the persistence timer is set again and the cycle repeats. If it is nonzero, data
can now be sent.

Keepalive timer
• When a connection has been idle for a long time, the keepalive timer may
go off to cause one side to check whether the other side is still there.
• If it fails to respond, the connection is terminated.
TCP Congestion Control
• A transport protocol using an AIMD (Additive Increase Multiplicative
Decrease) control law in response to binary congestion signals from the
network would converge to a fair and efficient bandwidth allocation.
• TCP congestion control is based on implementing this approach using a
window and with packet loss as the binary signal.
• To do so, TCP maintains a congestion window whose size is the number of
bytes the sender may have in the network at any time.
• The corresponding rate is the window size divided by the round-trip time of
the connection.
• TCP adjusts the size of the window according to the AIMD rule.
• Before discussing how TCP reacts to congestion, let us first describe what it
does to try to prevent congestion from occurring in the first place.
• When a connection is established, a suitable window size has to be chosen.
• The receiver can specify a window based on its buffer size.
• If the sender sticks to this window size, problems will not occur due to
buffer overflow at the receiving end, but they may still occur due to
internal congestion within the network.
• The below figure shows what happens when a sender on a fast network
(the 1- Gbps link) sends a small burst of four packets to a receiver on a slow
network (the 1- Mbps link) that is the bottleneck or slowest part of the
path. Initially the four packets travel over the link as quickly as they can be
sent by the sender. At the router, they are queued while being sent
because it takes longer to send a packet over the slow link than to receive
the next packet over the fast link. But the queue is not large because only a
small number of packets were sent at once. Note the increased length of
the packets on the slow link. The same packet, of 1 KB say, is now longer
because it takes more time to send it on a slow link than on a fast one.
 • the acknowledgements return to the sender at about the rate that packets
can be sent over the slowest link in the path. This is precisely the rate that
the sender wants to use.
• If it injects new packets into the network at this rate, they will be sent as
fast as the slow link permits, but they will not queue up and congest any
router along the path.
• This timing is known as an ack clock. It is an essential part of TCP. By using
an ack clock, TCP smoothes out traffic and avoids unnecessary queues at
routers.
• A second consideration is that the AIMD rule will take a very long time to
reach a good operating point on fast networks if the congestion window is
started from a small size.

Slow Start Algorithm

• The sender then sends the initial window. The packets will take a round-trip
time to be acknowledged. For each segment that is acknowledged before
the retransmission timer goes off, the sender adds one segment’s worth of
bytes to the congestion window. Plus, as that segment has been
acknowledged, there is now one less segment in the network. The upshot is
that every acknowledged segment allows two more segments to be sent.
The congestion window is doubling every roundtrip time.
 • This algorithm is called slow start, but it is not slow at all—it is exponential
growth—except in comparison to the previous algorithm that let an entire
flow control window be sent all at once.

Slow start from an initial congestion window of one segment.

• To keep slow start under control, the sender keeps a threshold for the
connection called the slow start threshold. Initially this value is set
arbitrarily high, to the size of the flow control window, so that it will not
limit the connection.
• TCP keeps increasing the congestion window in slow start until a timeout
occurs or the congestion window exceeds the threshold.
• Whenever a packet loss is detected, for example, by a timeout, the slow
start threshold is set to be half of the congestion window and the entire
process is restarted.
• Additive increase is shown in below figure, for the same situation as slow
start. At the end of every RTT, the sender’s congestion window has grown
enough that it can inject an additional packet into the network.
Additive increase from an initial congestion window of one segment

• Drawback: Timeouts are relatively long because they must be conservative.

After a packet is lost, the receiver cannot acknowledge past it, so the
acknowledgement number will stay fixed, and the sender will not be able to
send any new packets into the network because its congestion window
remains full.
• This condition can continue for a relatively long period until the timer fires
and the lost packet is retransmitted. At that stage, TCP slow starts again.
• There is a quick way for the sender to recognize that one of its packets has
been lost. As packets beyond the lost packet arrive at the receiver, they
trigger acknowledgements that return to the sender.
• These acknowledgements bear the same acknowledgement number. They
are called duplicate acknowledgements.
 • TCP somewhat arbitrarily assumes that three duplicate acknowledgements
imply that a packet has been lost. The identity of the lost packet can be
inferred from the acknowledgement number as well.
• It is the very next packet in sequence. This packet can then be
retransmitted right away, before the retransmission timeout fires.
• This heuristic is called fast retransmission.
• Fast recovery is a temporary mode that aims to maintain the ack clock
running with a congestion window that is the new threshold, or half the
value of the congestion window at the time of the fast retransmission.

sawtooth pattern of additive increase

• The upshot of this heuristic is that TCP avoids slow start, except when the
connection is first started and when a timeout occurs.
• The latter can still happen when more than one packet is lost and fast
retransmission does not recover adequately.
• Instead of repeated slow starts, the congestion window of a running
connection follows a sawtooth pattern of additive increase (by one
segment every RTT) and multiplicative decrease (by half in one RTT).
• This is exactly the AIMD rule that we sought to implement.
Slow start followed by Additive increase in TCP Tahoe.

The sawtooth behavior is shown in below figure.

Fast recovery and the sawtooth pattern of TCP Reno.

• The cumulative acknowledgement number does not provide the
information of which packets have arrived and which packets have been
lost.
• A simple fix is the use of SACK (Selective ACKnowledgements), which lists
up to three ranges of bytes that have been received. With this information,
the sender can more directly decide what packets to retransmit and track
the packets in flight to implement the congestion window.
• When the sender and receiver set up a connection, they each send the
SACK permitted TCP option to signal that they understand selective
acknowledgements.

The Future of TCP

• The first issue with TCP is : TCP does not provide the transport semantics
that all applications want. For example, some applications want to send
messages or records whose boundaries need to be preserved. Other
 applications work with a group of related conversations, such as a Web
browser that transfers several objects from the same server.
• Still other applications want better control over the network paths that
they use. TCP with its standard sockets interface does not meet these
needs well.
• Essentially, the application has the burden of dealing with any problem not
solved by TCP.
• This has led to proposals for new protocols that would provide a slightly
different interface. Two examples are SCTP (Stream Control Transmission
Protocol), defined in RFC 4960, and SST (Structured Stream Transport)
(Ford, 2007).
• The second issue is congestion control.
• The signal might be round-trip time, which grows when the network
becomes congested, as is used by FAST TCP (Wei et al., 2006). Other
approaches are possible too, and time will tell which is the best.