Transport Layer

Prepared by
Risala Tasin Khan
Professor
IIT, JU
Transport services and protocols
application
transport
provide logical communication network
data link
between app processes physical

running on different hosts

log
transport protocols run in end

ica
l
systems

en
d-
en
 send side: breaks app

d
tra
messages into segments,

ns
p
passes to network layer

or
t
 rcv side: reassembles application

segments into messages, transport

network

passes to app layer data link

physical

more than one transport

protocol available to apps
 Internet: TCP and UDP
Transport Layer 3-2
Transport vs. network layer
network layer: household analogy:
logical
communication 12 kids in Ann’s house sending
letters to 12 kids in Bill’s
between hosts house:
transport layer: • hosts = houses
logical • processes = kids
communication • app messages = letters in
between processes envelopes
 relies on, enhances, • transport protocol = Ann
network layer and Bill who demux to in-
services house siblings
• network-layer protocol =
postal service

Transport Layer 3-3

Internet transport-layer protocols
application
• reliable, in-order transport
network

delivery (TCP) data link

physical
network

• congestion control network data link

log
data link physical
physical

ica
• flow control network

l
en
data link
physical

d-
• connection setup

en
network

d
tra
data link
• unreliable, unordered physical

ns
p
network

or
delivery: UDP data link

t
physical
network

• no-frills extension of data link

physical
network
application
transport

“best-effort” IP data link

physical
network
data link
physical

• services not available:

• delay guarantees
• bandwidth guarantees
Transport Layer 3-4
Transport-Layer Services
• At the destination host, the transport layer receives segments from the network layer
just below.
• The transport layer has the responsibility of delivering the data in these segments to
the appropriate application process running in the host.
• a process (as part of a network application) can have one or more sockets, doors
through which data passes from the network to the process and through which data
passes from the process to the network.
• Thus the transport layer in the receiving host does not actually deliver data directly to
a process, but instead to an intermediary socket.
• Because at any given time there can be more than one socket in the receiving host,
each socket has a unique identifier.
• The format of the identifier depends on whether the socket is a UDP or a TCP socket
Cont….
• Now let’s consider how a receiving host directs an incoming transport-layer
segment to the appropriate socket.
• Each transport-layer segment has a set of fields in the segment for this
purpose. At the receiving end, the transport layer examines these fields to
identify the receiving socket and then directs the segment to that socket.
• This job of delivering the data in a transport-layer segment to the correct
socket is called demultiplexing.
• The job of gathering data chunks at the source host from different sockets,
encapsulating each data chunk with header information (that will later be
used in demultiplexing) to create segments, and passing the segments to the
network layer is called multiplexing.
• The transport layer in the middle host
in Figure must demultiplex segments
arriving from the network layer below
to either process P1 or P2 above;
• This is done by directing the arriving
segment’s data to the corresponding
process’s socket.
• The transport layer in the middle host
must also gather outgoing data from
these sockets, form transport-layer
segments, and pass these segments
down to the network layer.
How demultiplexing works
host receives IP datagrams 32 bits
 each datagram has source IP address,
destination IP address source port # dest port #
 each datagram carries one transport-layer
segment
 each segment has source, destination other header fields
port number
host uses IP addresses & port numbers
to direct segment to appropriate socket application
data
(payload)

TCP/UDP segment format

Transport Layer 3-8

How demultiplexing works
• Transport-layer multiplexing requires
• (1) that sockets have unique identifiers, and
• (2) that each segment have special fields that indicate the socket to which the
segment is to be delivered.
• These special fields are the source port number field and the destination port
number field.
• Each port number is a 16-bit number, ranging from 0 to 65535.
• The port numbers ranging from 0 to 1023 are called well-known port
numbers and are restricted, which means that they are reserved for use
by well-known application protocols such as HTTP (which uses port
number 80) and FTP (which uses port number 21).
 Connectionless demultiplexing
recall: created socket has  recall: when creating
host-local port #: datagram to send into UDP
DatagramSocket mySocket1 socket, must specify
= new  destination IP address
DatagramSocket(12534);
 destination port #

when host receives UDP IP datagrams with same

segment: dest. port #, but different
source IP addresses and/or
 checks destination port # source port numbers will
in segment be directed to same socket
 directs UDP segment to at dest
socket with that port #
Transport Layer 3-10
Purpose of Source Port #
• As shown in Figure , in the A-to-
B segment the source port
number serves as part of a
“return address”—when B wants
to send a segment back to A, the
destination port in the B-to-A
segment will take its value from
the source port value of the A-
to-B segment. (The complete
return address is A’s IP address
and the source port number.)
Connection-oriented demux
TCP socket identified by 4-tuple: server host may support
 source IP address many simultaneous TCP
 source port number sockets:
 dest IP address
 each socket identified by
 dest port number
its own 4-tuple
demux: receiver uses all four values
to direct segment to appropriate web servers have
socket different sockets for each
• In particular, and in contrast with UDP, connecting client
two arriving TCP segments with  non-persistent HTTP will
different source IP addresses or have different socket for
source port numbers will be directed each request
to two different sockets.
Transport Layer 3-12
Connection Oriented Demux (In details)
• The TCP server application has a “welcoming socket,” that waits for connection establishment requests from TCP
clients on a port number (say 12000).
• The TCP client creates a socket and sends a connection establishment request segment
• A connection-establishment request is nothing more than a TCP segment with destination port number 12000 and a
special connection-establishment bit set in the TCP header .
• The segment also includes a source port number that was chosen by the client.
• When the host operating system of the computer running the server process receives the incoming connection-
request segment with destination port 12000, it locates the server process that is waiting to accept a connection on
port number 12000.
• The transport layer at the server notes the following four values in the connection-request segment: (1) the source
port number in the segment, (2) the IP address of the source host, (3) the destination port number in the segment,
and (4) its own IP address.
• The newly created connection socket is identified by these four values; all subsequently arriving segments whose
source port, source IP address, destination port, and destination IP address match these four values will be
demultiplexed to this socket.
• With the TCP connection now in place, the client and server can now send data to each other.
 Connection-oriented demux: example

application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different
Transportsockets
Layer 3-14
UDP: User Datagram Protocol
• UDP does just about as little as a transport protocol can do.
• Aside from the multiplexing/demultiplexing function and some light error checking, it adds
nothing to IP. In fact, if the application developer chooses UDP instead of TCP, then the
application is almost directly talking with IP.
• UDP takes messages from the application process, attaches source and destination port
number fields for the multiplexing/demultiplexing service, adds two other small fields, and
passes the resulting segment to the network layer.
• The network layer encapsulates the transport-layer segment into an IP datagram and then
makes a best-effort attempt to deliver the segment to the receiving host.
• If the segment arrives at the receiving host, UDP uses the destination port number to deliver
the segment’s data to the correct application process.
• Note that with UDP there is no handshaking between sending and receiving transport-layer
entities before sending a segment. For this reason, UDP is said to be connectionless.
The reasons of choosing UDP over TCP
• Finer application-level control over what data is sent, and when:
• Under UDP, as soon as an application process passes data to UDP, UDP will package
the data inside a UDP segment and immediately pass the segment to the network
layer.
• TCP, on the other hand, has a congestion-control mechanism that throttles the
transport-layer TCP sender when one or more links between the source and
destination hosts become excessively congested.
• TCP will also continue to resend a segment until the receipt of the segment has
been acknowledged by the destination, regardless of how long reliable delivery
takes.
• Since real-time applications often require a minimum sending rate, do not want to
overly delay segment transmission, and can tolerate some data loss, TCP’s service
model is not particularly well matched to these applications’ needs.
The reasons of choosing UDP over
TCP(Cont..)
• No connection establishment:
• TCP uses a three-way handshake before it starts to transfer data. UDP just
blasts away without any formal preliminaries.
• Thus UDP does not introduce any delay to establish a connection.
• This is probably the principal reason why DNS runs over UDP rather than TCP
—DNS would be much slower if it ran over TCP. HTTP uses TCP rather than
UDP, since reliability is critical for Web pages with text.
• Small packet header overhead:
• The TCP segment has 20 bytes of header overhead in every segment, whereas
UDP has only 8 bytes of overhead.
UDP Segment Structure
• The application data occupies the data field of the UDP
segment.
• For example, for DNS, the data field contains either a query message
or a response message.
• The UDP header has only four fields, each consisting of two
bytes.
• the port numbers allow the destination host to pass the
application data to the correct process running on the
destination end system
• The length field specifies the number of bytes in the UDP
segment (header plus data).
• An explicit length value is needed since the size of the data
field may differ from one UDP segment to the next.
• The checksum is used by the receiving host to check whether
errors have been introduced into the segment.
UDP Checksum
• The UDP checksum provides for error detection.
• That is, the checksum is used to determine whether bits within the UDP segment
have been altered as it moved from source to destination.
• UDP at the sender side performs the 1s complement of the sum of all the 16-bit
words in the segment, with any overflow encountered during the sum being
wrapped around.
• This result is put in the checksum field of the UDP segment.
• As an example, suppose that we have the following three 16-bit words:
1. 0110011001100000
2. 0101010101010101
3. 1000111100001100
UDP Checksum(Cont..)
• The sum of first two of these 16-bit words is
0110011001100000
0101010101010101
1011101110110101
• Adding the third word to the above sum gives
1011101110110101
1000111100001100
0100101011000010
• Note that this last addition had overflow, which was wrapped around.
• The 1s complement is obtained by converting all the 0s to 1s and converting all the 1s to 0s.
• Thus the 1s complement of the sum 0100101011000010 is 1011010100111101, which becomes the
checksum.
• At the receiver, all four 16-bit words are added, including the checksum. If no errors are introduced into the
packet, then clearly the sum at the receiver will be 1111111111111111.
• If one of the bits is a 0, then we know that errors have been introduced into the packet.
Internet checksum: example

example: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Note: when adding numbers, a carryout from the most

significant bit needs to be added to the result

Transport Layer 3-21

Principles of Reliable Data Transfer
• With a reliable channel, no transferred data bits are corrupted
(flipped from 0 to 1, or vice versa) or lost, and all are delivered in the
order in which they were sent.
• It is the responsibility of a reliable data transfer protocol to
implement this service abstraction.
• This task is made difficult by the fact that the layer below the reliable
data transfer protocol may be unreliable.
• For example, TCP is a reliable data transfer protocol that is
implemented on top of an unreliable (IP) end-to-end network layer.
Reliable data transfer: getting started
we’ll:
• incrementally develop sender, receiver sides of
reliable data transfer protocol (rdt)
• consider only unidirectional data transfer
• but control info will flow on both directions!
• use finite state machines (FSM) to specify sender,
receiver event causing state transition
actions taken on state transition
state: when in this
“state” next state state state
uniquely determined 1 event
by next event 2
actions

Transport Layer 3-23

Finite State Machines
• A finite state machine or finite automaton is a
model of behavior composed of states, transitions
and actions.
• A state stores information about the past, i.e. it reflects
the input changes from the system start to the present
moment.
• A transition indicates a state change and is described by
a condition/event that would need to be fulfilled to
enable the transition.
• An action is a description of an activity that is to be
performed at a given moment.
 Building a Reliable Data Transfer Protocol
(Reliable Data Transfer over a Perfectly Reliable Channel: rdt1.0)
• We first consider the simplest case, in which the
underlying channel is completely reliable.
• The protocol itself, which we’ll call rdt1.0, is trivial.
• The finite-state machine (FSM) definitions for the rdt1.0
sender and receiver are shown in Figure.
• The FSM in Figure 1(a) defines the operation of the
sender, while the FSM in Figure 1(b) defines the
operation of the receiver.
• It is important to note that there are separate FSMs for
the sender and for the receiver.
• The sender and receiver FSMs in Figure 1 each have just
one state.
• The arrows in the FSM description indicate the transition
of the protocol from one state to another. (Since each
FSM in Figure 1 has just one state, a transition is
necessarily from the one state back to itself)
• The event causing the transition is shown above the
horizontal line labeling the transition, and the actions
taken when the event occurs are shown below the
horizontal line.
• The initial state of the FSM is indicated by the dashed
arrow.
• The sending side of rdt simply accepts data from the
upper layer via the rdt_send(data) event, creates a
packet containing the data (via the action
make_pkt(data)) and sends the packet into the channel.
• On the receiving side, rdt receives a packet from the
underlying channel via the rdt_rcv(packet) event,
removes the data from the packet (via the action
extract (packet, data)) and passes the data up to the
upper layer (via the action deliver_data(data)).
Reliable Data Transfer over a Channel
with Bit Errors: rdt2.0
• A more realistic model of the underlying channel is one in which bits in a
packet may be corrupted.
• Such bit errors typically occur in the physical components of a network as a
packet is transmitted, propagates, or is buffered.
• This message-dictation protocol uses both positive acknowledgments
(“OK”) and negative acknowledgments (“Please repeat that.”).
• These control messages allow the receiver to let the sender know what has
been received correctly, and what has been received in error and thus
requires repeating. In a computer network setting, reliable data transfer
protocols based on such retransmission are known as ARQ (Automatic
Repeat reQuest) protocols.
Cont…
• Fundamentally, three additional protocol capabilities are required in
ARQ protocols to handle the presence of bit errors:
• Error detection:
• First, a mechanism is needed to allow the receiver to detect when bit errors
have occurred.
• UDP uses the Internet checksum field for exactly this purpose.
• Error detection techniques require that extra bits (beyond the bits of original
data to be transferred) be sent from the sender to the receiver; these bits will
be gathered into the packet checksum field of the rdt2.0 data packet.
Cont….
• Receiver feedback:
• Since the sender and receiver are typically executing on different end systems, possibly
separated by thousands of miles, the only way for the sender to learn of the receiver’s view of
the world (in this case, whether or not a packet was received correctly) is for the receiver to
provide explicit feedback to the sender.
• The positive (ACK) and negative (NAK) acknowledgment replies in the message-dictation
scenario are examples of such feedback.
• Our rdt2.0 protocol will similarly send ACK and NAK packets back from the receiver to the
sender.
• In principle, these packets need only be one bit long; for example, a 0 value could indicate a
NAK and a value of 1 could indicate an ACK.
• Retransmission:
A packet that is received in error at the receiver will be retransmitted by the sender.
 rdt2.0: FSM specification
rdt_send(data)
sndpkt = make_pkt(data, checksum) receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L
call from
below
sender
rdt_rcv(rcvpkt) && isACK (rcvpkt)=Most recent packet has rdt_rcv(rcvpkt) &&
been received correctly notcorrupt(rcvpkt)
extract(rcvpkt,data)
It is important to note that when the sender is in the wait-for-ACK-or-NAK deliver_data(data)
state, it cannot get more data from the upper layer; that is, the rdt_send() udt_send(ACK)
event cannot occur;
Transport Layer 3-30
rdt2.0: operation with no errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L call from
below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Transport Layer 3-31

rdt2.0: error scenario
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L call from
below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Transport Layer 3-32

rdt2.0 has a fatal flaw!
what happens if handling duplicates:
ACK/NAK corrupted? • sender retransmits current pkt
• sender doesn’t know what if ACK/NAK corrupted
happened at receiver! • sender adds sequence number
• can’t just retransmit: to each pkt
possible duplicate • receiver discards (doesn’t
deliver up) duplicate pkt

stop and wait

sender sends one packet,
then waits for receiver
response
Transport Layer 3-33
handling corrupted ACKs or NAKs
• Add enough checksum bits to allow the sender not only to detect, but also to
recover from, bit errors. This solves the immediate problem for a channel that can
corrupt packets but not lose them.
• Or the sender simply can resend the current data packet when it receives a
garbled ACK or NAK packet. This approach, however, introduces duplicate packets
into the sender-to-receiver channel.
• A simple solution to this new problem (and one adopted in almost all existing data
transfer protocols, including TCP) is to add a new field to the data packet and have
the sender number its data packets by putting a sequence number into this field.
• The receiver then need only check this sequence number to determine whether or
not the received packet is a retransmission.
Performance Problem of rdt3
• To appreciate the performance impact of this stop-and-wait behavior, consider an idealized case of two hosts, one
located on the West Coast of the United States and the other located on the East Coast
• The speed-of-light round-trip propagation delay between these two end systems, RTT, is approximately 30 milliseconds.
• Suppose that they are connected by a channel with a transmission rate, R, of 1 Gbps (109 bits per second).
• With a packet size, L, of 1,000 bytes including both header fields and data, the time needed to actually transmit the
packet into the 1 Gbps link is

• With stop-and-wait protocol, if the sender begins sending the packet at t = 0, then at t = L/R = 8
microseconds, the last bit enters the channel at the sender side.
• The packet then makes its 15-msec cross-country journey, with the last bit of the packet emerging at
the receiver at t = RTT/2 + L/R = 15.008 msec.
• The receiver can send an ACK as soon as the last bit of a data packet is received, the ACK emerges back at the
sender at t = RTT + L/R = 30.008 msec.
• At this point, the sender can now transmit the next message.
• Thus, in 30.008 msec, the sender was sending for only 0.008 msec
rdt3.0: stop-and-wait operation (problem)
sender receiver
first packet bit transmitted, t = 0
last packet bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK

ACK arrives, send next

packet, t = RTT + L / R

U L/R .008
sender = = = 0.00027
RTT + L / R 30.008

Transport Layer 3-36

Pipelined protocols
pipelining: sender allows multiple, “in-flight”, yet-
to-be-acknowledged pkts
• range of sequence numbers must be increased
• buffering at sender and/or receiver

two generic forms of pipelined protocols: go-Back-N,

selective repeat
Transport Layer 3-37
Pipelined protocols: overview
Go-back-N: Selective Repeat:
• sender can have up to N • sender can have up to N
unacked packets in unack’ed packets in
pipeline pipeline
• receiver only sends • receiver sends individual
cumulative ack ack for each packet
• doesn’t ack packet if
there’s a gap
• sender has timer for • sender maintains timer for
oldest unacked packet each unacked packet
• when timer expires, • when timer expires,
retransmit all unacked retransmit only that
packets unacked packet

Transport Layer 3-38

Go-Back-N (GBN)
• Go-Back-N is an instance of the Automatic Repeat-request (ARQ) Protocol,
in which the sending process continues to send a number of frames specified
by a window size even without receiving an ACK packet from the receiver.
• The receiver process keeps track of the sequence number of the next frame it
expects, and sends it with every ACK it sends.
• If a frame from the sender does not reach the receiver, the receiver will stop
acknowledging received frames.
• The sender after sending all of the frames will detect that all of the frames
since the first lost frame are outstanding, and will go back to sequence
number of the last ACK it received and fill its window starting with that
frame and continue the process over again.
Go-Back-N protocol
• Concept
• Introduce a window of size n
• Can inject n packets into net before hearing an ACK
• Sliding window
• Label each packet with a sequence number
• A window is a collection of adjacent sequence numbers
• The size of the collection is the sender’s window size
• Sender has to buffer all unacknowledged packets, because they may require
retransmission.
• Receiver may be able to accept out-of-order packets, but only up to its buffer limits.
• The sender needs to set timers in order to know when to retransmit a packet that may
have been lost
Go-Back-N: sender
• k-bit seq # in pkt header
• “window” of up to N, consecutive unack’ed pkts allowed

 ACK(n): ACKs all pkts up to, including seq # n - “cumulative

ACK”
 may receive duplicate ACKs (see receiver)
 timer for oldest in-flight pkt
 timeout(n): retransmit packet n and all higher seq # pkts in
window
Transport Layer 3-41
 GBN in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
send pkt3 Xloss receive pkt1, send ack1
012345678
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
pkt 2 timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5

Transport Layer 3-42

Selective Repeat
• A selective-repeat protocols avoid unnecessary retransmissions by having the sender
retransmit only those packets that it suspects were received in error (that is, were lost or
corrupted) at the receiver.
• This individual, as needed, retransmission will require that the receiver individually
acknowledge correctly received packets.
• A window size of N will again be used to limit the number of outstanding, unacknowledged
packets in the pipeline.
• However, unlike GBN, the sender will have already received ACKs for some of the packets in
the window.
• The SR receiver will acknowledge a correctly received packet whether or not it is in order.
• Out-of-order packets are buffered until any missing packets (that is, packets with lower
sequence numbers) are received, at which point a batch of packets can be delivered in order
to the upper layer.
Selective repeat: sender, receiver windows

Transport Layer 3-44

 Selective repeat
sender receiver
pkt n in [rcvbase, rcvbase+N-1]
data from above:
 send ACK(n)
if next available seq # is in window, send pkt
 out-of-order: buffer
otherwise it is either buffered or returned to the upper layer for later transmission
in-order: deliver (also

timeout(n):
deliver buffered, in-order
Timers are again used to protect against lost packets. pkts), advance window to
However, each packet must now have its own logical timer, since
next not-yet-received
only pkttransmitted
a single packet will be
on timeout.
ACK(n):
pkt n in [rcvbase-N,rcvbase-1]
 ACK(n)
mark pkt n as received
 If the packet’s sequence number is equal to sendbase, theotherwise:
window base is moved forward to the
unacknowledged packet with the smallest sequence number.  ignore
If the window moves and there are untransmitted packets with sequence numbers that now fall within the
window, these packets are transmitted.

Transport Layer 3-45

 Selective repeat in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
send pkt3 Xloss receive pkt1, send ack1
012345678
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5 receive pkt4, buffer,
send ack4
record ack3 arrived receive pkt5, buffer,
send ack5
pkt 2 timeout
012345678 send pkt2
012345678 record ack4 arrived
012345678 rcv pkt2; deliver pkt2,
record ack5 arrived
012345678 pkt3, pkt4, pkt5; send ack2

Q: what happens when ack2 does not arrive?

Transport Layer 3-47

The TCP Connection
• TCP is said to be connection-oriented because before one application process can
begin to send data to another, the two processes must first “handshake” with each
other—that is, they must send some preliminary segments to each other to establish
the parameters of the ensuing data transfer.
• A TCP connection provides a full-duplex service: If there is a TCP connection between
Process A on one host and Process B on another host, then application layer data can
flow from Process A to Process B at the same time as application layer data flows
from Process B to Process A.
• A TCP connection is also always point-to-point, that is, between a single sender and a
single receiver.
• So-called “multicasting”—the transfer of data from one sender to many receivers in a single
send operation—is not possible with TCP.
• With TCP, two hosts are company and three are a crowd!
How TCP Works
• Suppose a process running in one host wants to initiate a connection with another process in
another host.
• The process that is initiating the connection is called the client process, while the other process is
called the server process.
• The client application process first informs the client transport layer that it wants to establish a
connection to a process in the server.
• TCP in the client then proceeds to establish a TCP connection with TCP in the server.
• For this the client first sends a special TCP segment;
• the server responds with a second special TCP segment;
• and finally the client responds again with a third special segment.
• The first two segments carry no payload, that is, no application-layer data; the third of these
segments may carry a payload.
• Because three segments are sent between the two hosts, this connection-establishment procedure
is often referred to as a three-way handshake
TCP Segment Structure
• The TCP segment consists of header fields and a data field.
• The data field contains a chunk of application data.
• The MSS (Max. Segment Size) limits the maximum size of a segment’s
data field.
• When TCP sends a large file, such as an image as part of a Web page,
it typically breaks the file into chunks of size MSS (except for the last
chunk, which will often be less than the MSS).
TCP Segment Structure (Cont…)
• The TCP header includes source and destination
port numbers, which are used for
multiplexing/demultiplexing data from/to upper-
layer applications.
• Also, the header includes a checksum field.
• A TCP segment header also contains the
following fields:
• The 32-bit sequence number field and the 32-bit
acknowledgment number field are used by the TCP
sender and receiver in implementing a reliable data
transfer service, as discussed below.
• The 16-bit receive window field is used for flow
control. it is used to indicate the number of bytes that
a receiver is willing to accept.
• The 4-bit header length field specifies the length of
the TCP header in 32-bit words.
• The TCP header can be of variable length due to the
TCP options field. (Typically, the options field is
empty, so that the length of the typical TCP header is
20 bytes.)
TCP Segment Structure (Cont…)
• The optional and variable-length options field is used
when a sender and receiver negotiate the maximum
segment size (MSS) or as a window scaling factor for use in
high-speed networks.
• The flag field contains 6 bits.
• The ACK bit is used to indicate that the value carried in the
acknowledgment field is valid; that is, the segment
contains an acknowledgment for a segment that has been
successfully received.
• The RST, SYN, and FIN bits are used for connection setup
and teardown.
• Setting the PSH bit indicates that the receiver should pass
the data to the upper layer immediately.
• Finally, the URG bit is used to indicate that there is data in
this segment that the sending-side upper-layer entity has
marked as “urgent.” The location of the last byte of this
urgent data is indicated by the 16-bit urgent data pointer
field.
• TCP must inform the receiving-side upper-layer entity
when urgent data exists and pass it a pointer to the end of
the urgent data.
Sequence Numbers and Acknowledgment
Numbers
• TCP views data as an unstructured, but ordered, stream of bytes.
• TCP’s use of sequence numbers reflects this view in that sequence numbers are over the stream of
transmitted bytes and not over the series of transmitted segments.
• The sequence number for a segment is therefore the byte-stream number of the first byte in the
segment.
• Suppose that a process in Host A wants to send a stream of data to a process in Host B over a TCP
connection.
• The TCP in Host A will implicitly number each byte in the data stream.
• Suppose that the data stream consists of a file consisting of 500,000 bytes, that the MSS is 1,000 bytes, and
that the first byte of the data stream is numbered 0.
• TCP constructs 500 segments out of the data stream.
• The first segment gets assigned sequence number 0, the second segment gets assigned sequence number
1,000, the third segment gets assigned sequence number 2,000, and so on.
• Each sequence number is inserted in the sequence number field in the header of the appropriate TCP segment.
Cont…
• Now let’s consider acknowledgment numbers. These are a little trickier than
sequence numbers.
• As TCP is full-duplex, so that Host A may be receiving data from Host B while it sends
data to Host B (as part of the same TCP connection).
• Each of the segments that arrive from Host B has a sequence number for the data
flowing from B to A.
• The acknowledgment number that Host A puts in its segment is the sequence
number of the next byte Host A is expecting from Host B.
• Suppose that Host A has received all bytes numbered 0 through 535 from B and
suppose that it is about to send a segment to Host B.
• Host A is waiting for byte 536 and all the subsequent bytes in Host B’s data stream.
• So Host A puts 536 in the acknowledgment number field of the segment it sends to B.
TCP seq. numbers, ACKs
Host A Host B

User
types
‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
host ACKs
receipt
of echoed
‘C’ Seq=43, ACK=80

simple telnet scenario

Transport Layer 3-55

Round-Trip Time Estimation and Timeout
• TCP, like our rdt protocol, uses a timeout/retransmit mechanism to recover from lost segments.
• The sample RTT, denoted SampleRTT, for a segment is the amount of time between when the segment
is sent (that is, passed to IP) and when an acknowledgment for the segment is received.
• Instead of measuring a SampleRTT for every transmitted segment, most TCP implementations take only
one SampleRTT measurement at a time.
• That is, at any point in time, the SampleRTT is being estimated for only one of the transmitted but currently
unacknowledged segments, leading to a new value of SampleRTT approximately once every RTT.
• Also, TCP never computes a SampleRTT for a segment that has been retransmitted;
• it only measures SampleRTT for segments that have been transmitted once
• Obviously, the SampleRTT values will fluctuate from segment to segment due to congestion in the
routers and to the varying load on the end systems
• In order to estimate a typical RTT, it is therefore natural to take some sort of average of the SampleRTT
values.
• TCP maintains an average, called EstimatedRTT, of the SampleRTT values.
• In addition to having an estimate of the RTT, it is also valuable to have a measure of the variability of the
RTT. The RTT variation, DevRTT, is therefore an estimate of how much SampleRTT typically deviates
from EstimatedRTT
Setting and Managing the Retransmission
Timeout Interval
• Given values of EstimatedRTT and DevRTT, what value should be used for TCP’s timeout interval?
• Clearly, the interval should be greater than or equal to EstimatedRTT, or unnecessary
retransmissions would be sent.
• But the timeout interval should not be too much larger than EstimatedRTT; otherwise, when a
segment is lost, TCP would not quickly retransmit the segment, leading to large data transfer
delays.
• It is therefore desirable to set the timeout equal to the EstimatedRTT plus some margin.
• The margin should be large when there is a lot of fluctuation in the SampleRTT values;
• it should be small when there is little fluctuation.
• The value of DevRTT should thus come into play here.
• All of these considerations are taken into account in TCP’s method for determining the
retransmission timeout interval:
• TimeoutInterval = EstimatedRTT + 4 • DevRTT
Reliable Data Transfer
• TCP creates a reliable data transfer service on top of IP’s unreliable best effort service.
• TCP’s reliable data transfer service ensures that the data stream that a process reads out of its TCP receive
buffer is uncorrupted, without gaps, without duplication, and in sequence; that is, the byte stream is exactly
the same byte stream that was sent by the end system on the other side of the connection.
• There are three major events related to data transmission and retransmission in the TCP sender:
1. data received from application above;
2. timer timeout;
3. and ACK receipt.
• Upon the occurrence of the first major event, TCP receives data from the application, encapsulates the data
in a segment, and passes the segment to IP.
• Note that if the timer is already not running for some other segment, TCP starts the timer when the
segment is passed to IP. (It is helpful to think of the timer as being associated with the oldest
unacknowledged segment.)
• The expiration interval for this timer is the TimeoutInterval, which is calculated from EstimatedRTT and
DevRTT
• The second major event is the timeout.
• TCP responds to the timeout event by retransmitting the segment that caused the timeout. TCP
then restarts the timer.
• The third major event that must be handled by the TCP sender is the arrival of an
acknowledgment segment (ACK) from the receiver (more specifically, a segment
containing a valid ACK field value).
• On the occurrence of this event, TCP compares the ACK value y with its variable SendBase.
• The TCP state variable SendBase is the sequence number of the oldest unacknowledged byte. (Thus
SendBase–1 is the sequence number of the last byte that is known to have been received correctly
and in order at the receiver.)
• As indicated earlier, TCP uses cumulative acknowledgments, so that y acknowledges the receipt of
all bytes before byte number y.
• If y > SendBase then the ACK is acknowledging one or more previously unacknowledged segments.
• Thus the sender updates its SendBase variable
A Few Interesting Scenarios (Scenario One)
• Host A sends one segment to Host B.
• Suppose that this segment has sequence number
92 and contains 8 bytes of data.
• After sending this segment, Host A waits for a
segment from B with acknowledgment number
100.
• Although the segment from A is received at B, the
acknowledgment from B to A gets lost.
• In this case, the timeout event occurs, and Host A
retransmits the same segment. Of course, when
Host B receives the retransmission, it observes from
the sequence number that the segment contains
data that has already been received.
• Thus, TCP in Host B will discard the bytes in the
retransmitted segment.
A Few Interesting Scenarios (Scenario Two)
• In a second scenario, shown in Figure, Host A sends two
segments back to back.
• The first segment has sequence number 92 and 8 bytes of
data, and the second segment has sequence number 100
and 20 bytes of data.
• Suppose that both segments arrive intact at B, and B sends
two separate acknowledgments for each of these segments.
• The first of these acknowledgments has acknowledgment
number 100; the second has acknowledgment number 120.
• Suppose now that neither of the acknowledgments arrives
at Host A before the timeout.
• When the timeout event occurs, Host A resends the first
segment with sequence number 92 and restarts the timer.
• As long as the ACK for the second segment arrives before
the new timeout, the second segment will not be
retransmitted.
A Few Interesting Scenarios (Scenario Three)
• In a third and final scenario, suppose Host
A sends the two segments, exactly as in the
second example.
• The acknowledgment of the first segment
is lost in the network, but just before the
timeout event, Host A receives an
acknowledgment with acknowledgment
number 120.
• Host A therefore knows that Host B has
received everything up through byte 119;
so Host A does not resend either of the
two segments.
Self-Study
1. Doubling the Timeout Interval
2. Fast Retransmit
3. Go-Back-N or Selective Repeat
Flow Control
• TCP provides a flow-control service to its applications to eliminate the
possibility of the sender overflowing the receiver’s buffer.
• Flow control is thus a speed-matching service—matching the rate at which
the sender is sending against the rate at which the receiving application is
reading.
• TCP provides flow control by having the sender maintain a variable called the
receive window.
• Informally, the receive window is used to give the sender an idea of how
much free buffer space is available at the receiver.
• Because TCP is full-duplex, the sender at each side of the connection
maintains a distinct receive window
Cont…
• Suppose that Host A is sending a large file to Host B over a TCP connection.
• Host B allocates a receive buffer to this connection; denote its size by RcvBuffer.
• From time to time, the application process in Host B reads from the buffer. Define
the following variables:
• LastByteRead: the number of the last byte in the data stream read from the buffer by the
application process in B
• LastByteRcvd: the number of the last byte in the data stream that has arrived from the
network and has been placed in the receive buffer at B
• Because TCP is not permitted to overflow the allocated buffer, we must have
LastByteRcvd – LastByteRead ≤ RcvBuffer
• The receive window, denoted rwnd is set to the amount of spare room in the buffer:
rwnd = RcvBuffer – [LastByteRcvd – LastByteRead]
• Host B tells Host A how much spare room it has in the
connection buffer by placing its current value of rwnd in the
receive window field of every segment it sends to A.
• Initially, Host B sets rwnd = RcvBuffer.
• Note that to pull this off, Host B must keep track of several
connection-specific variables.
• Host A in turn keeps track of two variables, LastByteSent
and LastByteAcked.
• Note that the difference between these two variables,
LastByteSent – LastByteAcked, is the amount of
unacknowledged data that A has sent into the connection.
• By keeping the amount of unacknowledged data less than
the value of rwnd, Host A is assured that it is not
overflowing the receive buffer at Host B.
•
Problem with this scheme
• Suppose Host B’s receive buffer becomes full so that rwnd = 0.
• After advertising rwnd = 0 to Host A, also suppose that B has nothing to send to A.
• Now consider what happens.
• As the application process at B empties the buffer, TCP does not send new segments with new rwnd
values to Host A; indeed, TCP sends a segment to Host A only if it has data to send or if it has an
acknowledgment to send.
• Therefore, Host A is never informed that some space has opened up in Host B’s receive buffer—Host A
is blocked and can transmit no more data!
• To solve this problem, the TCP specification requires Host A to continue to send segments
with one data byte when B’s receive window is zero.
• These segments will be acknowledged by the receiver.
• Eventually the buffer will begin to empty and the acknowledgments will contain a nonzero
rwnd value
TCP Connection Management
• Suppose a process running in one host (client) wants to initiate a connection with another
process in another host (server).
• The client application process first informs the client TCP that it wants to establish a
connection to a process in the server.
• The TCP in the client then proceeds to establish a TCP connection with the TCP in the server in
the following manner:
Step 1:
• The client-side TCP first sends a special TCP segment to the server-side TCP. This special segment contains
no application-layer data. But one of the flag bits in the segment’s header, the SYN bit, is set to 1.
• For this reason, this special segment is referred to as a SYN segment.
• In addition, the client randomly chooses an initial sequence number (client_isn) and puts this number in
the sequence number field of the initial TCP SYN segment.
• This segment is encapsulated within an IP datagram and sent to the server.
Cont…
Step 2:
• Once the IP datagram containing the TCP SYN segment arrives at the server host the server
extracts the TCP SYN segment from the datagram, allocates the TCP buffers and variables to
the connection, and sends a connection-granted segment to the client TCP.
• This connection-granted segment also contains no application layer data.
• However, it does contain three important pieces of information in the segment header.
• First, the SYN bit is set to 1.
• Second, the acknowledgment field of the TCP segment header is set to client_isn+1.
• Finally, the server chooses its own initial sequence number (server_isn) and puts this value in the
sequence number field of the TCP segment header.
• This connection-granted segment is saying, in effect, “I received your SYN packet to start a
connection with your initial sequence number, client_isn. I agree to establish this connection.
My own initial sequence number is server_isn.”
• The connection granted segment is referred to as a SYNACK segment.
Cont….
• Step 3:
• Upon receiving the SYNACK segment, the client also allocates buffers and variables to the connection.
• The client host then sends the server yet another segment; this last segment acknowledges the server’s
connection-granted segment.
• The SYN bit is set to zero, since the connection is established.
• This third stage of the three-way handshake may carry client-to-server data in the segment payload.
• Once these three steps have been completed, the client and server hosts can send segments
containing data to each other.
• In each of these future segments, the SYN bit will be set to zero.
• Note that in order to establish the connection, three packets are sent between the two hosts.
• For this reason, this connection establishment procedure is often referred to as a three-way
handshake
 TCP 3-way handshake

client state server state

LISTEN LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
received SYNACK(x)
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1, ACKnum=y+1
client-to-server data
received ACK(y)
indicates client is live
ESTAB

Transport Layer 3-71