Transport

Layer
Summary

Part A: Introduction
Part B: Socket
Part C: TCP
Part D: UDP
Part A: Introduction

The transport layer is an end-to-end layer – this means
that nodes within the subnet do not participate in
transport layer protocols – only the end hosts.


As with other layers, transport layer protocols send data
as a sequence of packets (segments).
2. Multiplexing (1)

The network layer provides communication between two
hosts.


The transport layer provides communication between
two processes running on different hosts.


A process is an instance of a program that is running on a
host.


There may be multiple processes communicating between
two hosts – for example, there could be a FTP session
and a Telnet session between the same two hosts.
3. Multiplexing (2)

The transport layer provides a way to multiplex /
demultiplex communication between various processes.


To provide multiplexing, the transport layer adds an
address to each segment indicating the source and
destination processes.


Note these addresses need only be unique locally on
a given host.


In TCP/IP these transport layer addresses are called
port-numbers.
4. Multiplexing (3)
The 5-tuple: (sending port, sending IP address, destination
port, destination IP address, transport layer protocol) uniquely
identifies a process-to-process connection in the Internet.
5. TPDU
• Nesting of Transport Protocol Data
Unit (TPDU), packets, and frames.
6. Connection Establishment

• How a user process in host 1

establishes a connection with a
time-of-day server in host 2.
7. Transport Service Primitives

• The primitives for a simple transport service.

8. Transport Service Primitives

connum = LISTEN (local)

connum = CONNECT(local, remote)
status = SEND (connum, buffer, bytes)
status = RECEIVE(connum, buffer,bytes)
status = DISCONNECT(connum)

• The primitives for a simple transport service.

Node

Application
9. Protocol Stacks
AP Creates a new end point; allocates
table space for it within the transport
layer
Socket
interface
Identification of application (port #)

Transport
Network Identifies the node
Data Link Frames

NA

NIC card; identified by NIC card address

PART B: SOCKET

• Software interface designed to communicate

between the user program and TCP/IP protocol
stack
• Implemented by a set of library function calls
• Socket is a data structure inside the program
• Both client and server programs communicate
via a pair of sockets
2. Socket Framework
Application Program User Space

Socket Layer Kernel Space

TCP UDP

IP

Physical Network
(driver)
3. Socket Families
There are several significant socket
domain families:
Internet Domain Sockets (AF_INET)
-implemented via IP addresses
and port numbers
Unix Domain Sockets (AF_UNIX)
-implemented via filenames (think
“named pipe”)
Novell IPX (AF_IPX)
AppleTalk DDS (AF_APPLETALK)
4. Type of Socket

• Stream (SOCK_STREAM) Uses TCP protocol.

Connection-oriented service

• Datagram (SOCK_DGRAM) Uses UDP protocol.

Connectionless service

• Raw (SOCK_RAW) Used for testing

5. Creating a Socket
#include <sys/types.h>
#include <sys/socket.h>
int socket(int domain, int type, int protocol);

• domain is one of the Protocol Families (PF_INET,

PF_UNIX, etc.)

• type defines the communication protocol semantics,

usually defines either:
– SOCK_STREAM: connection-oriented stream (TCP)
– SOCK_DGRAM: connectionless, unreliable (UDP)

• protocol specifies a particular protocol, just set this to 0 to

accept the default
 6. TCP Client/Server
SERVER

C re a t e s o c k e t

b in d a p o rt t o t h e
socket

C L IE N T
lis t e n f o r in c o m in g
C re a t e s o c k e t
c o n n e c t io n s

accept an
c o n n e c t t o s e rv e r's
in c o m in g
p o rt
c o n n e c t io n

re a d f ro m t h e w rit e t o t h e
c o n n e c t io n c o n n e c t io n

lo o p lo o p

w rit e t o t h e re a d f ro m t h e
c o n n e c t io n c o n n e c t io n

c lo s e c o n n e c t io n
7. TCP Server
• Sequence of calls

sock_init() Create the socket

bind() Register port with the system

listen() Establish client connection

accept() Accept client connection

read/write read/write data

close() shutdown
8. TCP Client
• Sequence of calls

sock_init () Create socket

connect() Set up connection

write/read write/read data

close() Shutdown
9. Server Side Socket Details
SERVER

C reate socket
int socket(int dom ain, int type, int protocol)
sockfd = socket(P F _IN E T , S O C K _S T R E A M , 0);

bind a port to the int bind(int sockfd, struct sockaddr *server_addr, socklen_t length)
socket
bind(sockfd, & server, sizeof(server));

listen for incom ing int listen( int sockfd, int num _queued_requests)
connections
listen( sockfd, 5);

accept an
incom ing
int accept(int sockfd, struct sockaddr *incom ing_address, socklen_t length)
connection new fd = accept(sockfd, & client, sizeof(client)); /* B LO C K S */

read from the int read(int sockfd, void * buffer, size_t buffer_size)
connection
read(new fd, buffer, sizeof(buffer));

write to the int w rite(int sockfd, void * buffer, size_t buffer_size)

connection
w rite(new fd, buffer, sizeof(buffer));
 10. Client Side Socket Details
C LIE N T

C reate socket
int socket(int dom ain, int type, int protocol)
sockfd = socket(P F _IN E T , S O C K _S T R E A M , 0);

connect to S erver int connect(int sockfd, struct sockaddr *server_address, socklen_t length)
socket
connect(sockfd, & server, sizeof(server));

write to the int w rite(int sockfd, void * buffer, size_t buffer_size)

connection
w rite(sockfd, buffer, sizeof(buffer));

read from the int read(int sockfd, void * buffer, size_t buffer_size)
connection
read(sockfd, buffer, sizeof(buffer));
11. UDP Clients and Servers
• Connectionless clients and servers create a socket using
SOCK_DGRAM instead of SOCK_STREAM

• Connectionless servers do not call listen() or accept(), and usually do

not call connect()

• Since connectionless communications lack a sustained connection,

several methods are available that allow you to specify a destination
address with every call:
– sendto(sock, buffer, buflen, flags, to_addr, tolen);
– recvfrom(sock, buffer, buflen, flags, from_addr,
fromlen);
12. UDP Server
• Sequence of
calls
sock_init() Create socket

bind() Register port with the system

recfrom/sendto Receive/send data

close() Shutdown
13. UDP Client
• Sequence of calls

socket_init() Create socket

sendto/recfrom send/receive data

close() Shutdown
14. Socket
Programming
Example:
Internet File
Server
6-6-1

• Client code
using sockets.
15. Socket
Programming
Example:
Internet File
Server (2)

• Server code
using
PART C: TCP
2. Introduction

• connection oriented.
• full duplex.

TCP Services:
• Reliable transport
• Flow control
• Congestion control

UDP does not provide any of these services

3. Flow of TCP Segments
4. TCP Services (1)

TCP converts the unreliable, best effort service of IP into a

reliable service, i.e., it ensures that each segment is
delivered correctly, only once, and in order.

Converting an unreliable connection into a reliable

connection is basically the same problem we have
considered at the data link layer, and essentially the same
solution is used:

TCP numbers each segment and uses an ARQ protocol

to recover lost segments.

Some versions of TCP implement Go Back N and other

versions implement Selective Repeat.
5. TCP Services (2)
However, there are a few important differences between the transport
layer and the data link layer.

 At the data link layer, we viewed an ARQ protocol as being operated

between two nodes connected by a point-to-point link.

 At the transport layer, this protocol is implemented between two

hosts connected over network.

 Packets can arrive out-of-order, and packets may also be stored

in buffers within the network and then arrive at much later times.

 The round-trip time will change with different connections and

connection establishment is more complicated.
6. TCP Header
7. Sample TCP Packet
8. TCP Connection Establishment
Active participant Passive participant
(client) (server)
SYN,
Seque
nceNu
m=
x

u m= y,
q ue nceN
CK , Se nt = x+1
A e
SYN+ ow le dgm
Ackn
ACK,
Ackno
wledg
ment =y+1
9. Closing a TCP Connection (1)

client server
• client closes socket:
close
FIN
clientSocket.close();

• Step 1: client end system ACK

sends TCP FIN control close
FIN
segment to server

• Step 2: server receives

timed wait
ACK

FIN, replies with ACK. Closes

connection, sends FIN.
closed
10. Closing a TCP Connection (2)

• Step 3: client receives FIN,

replies with ACK. client server
– Enters “timed wait” - will closing
respond with ACK to FIN

received FINs
• Step 4: server, receives ACK. ACK
closing
Connection closed.
FIN
• Note: with small modification,
can handle simultaneous FINs.

timed wait
ACK

closed

closed
11. TCP Transmission Policy

• Window management in TCP.

12. Flow Control and Congestion Control (1)

In a network, it is often desirable to limit the rate at which a

source can send traffic into the subnet.

If this is not done and sources send at too high of a rate,

then buffers within the network will fill-up resulting in long
delays and eventually packets being dropped.

Moreover as packets gets dropped, retransmission may

occur, leading to even more traffic.

When sources are not regulated this can lead to

congestion collapse of the network, where very little traffic
is delivered to the destination.
13. Flow Control and Congestion
Control (2)

Two different factors can limit the rate at which a

source sends data.

 the inability of the destination to accept new data.

Techniques that address this are referred to as
flow control.

 the number of packets within the subnet.

Techniques that address this are referred to as
congestion control.
14. Flow Control and Congestion
Control (3)

Flow control and congestion control can be addressed at the

transport layer, but may also be addressed at other layers.

For example, some DLL protocols perform flow control on

each link. And some congestion control approaches
are done at the network layer.

Both flow control and congestion control are part of TCP.

15. Congestion (1)
Congestion arises when the total load on the network becomes too large. This
leads to queues building up and to long delays (recall the M/G/1 model).
If
sources retransmit messages, then this can lead to even more congestion and
eventually to congestion collapse. This is illustrated in the figure below.
Notice, as the offered load increase, the number of packets delivered at first
increases, but at high enough loads, this rapidly decreases.
16. Congestion (2)
Notice, as the offered load increase, the number of packets delivered at
first increases, but at high enough loads, this rapidly decreases.
17. Approaches to Congestion Control
(1)
Congestion control may be addressed at both the
network level and the transport layer.

At the network layer possible approaches include

Packet dropping  when a buffer becomes full a router can

drop waiting packets - if not coupled with some other
technique, this can lead to greater congestion through
retransmissions.

Packet scheduling  certain scheduling policies may

help in avoiding congestion - in particular scheduling can
help to isolate users that are transmitting at a high rate.
18. Approaches to Congestion Control
(2)

Dynamic routing  when a link becomes congested,

change the routing to avoid this link - this only helps up
to a point (eventually all links become congested) and
can lead to instabilities

Admission control/Traffic policing - Only allow

connections in if the network can handle them and
make sure that admitted sessions do not send at too
high of a rate - only useful for connection-oriented
networks.
19. Approaches to Congestion Control
(3)
An approach that can be used at either the network or
transport layers is

Rate control  this refers to techniques where the

source rate is explicitly controlled based on feedback
from either the network and/or the receiver.

For example, routers in the network may send a

source a "choke packet" upon becoming congested.
When receiving such a packet, the source should
lower it rate.
20. Approaches to Congestion Control
(4)
These approaches can be classified as either
"congestion avoidance" approaches, if they try to
prevent congestion from ever occurring, or as
"congestion recovery" approaches, if they wait until
congestion occurs and then react to it. In general, “better
to prevent than to recover."

Different networks have used various combinations of all

these approaches.

Traditionally, rate control at the transport layer has

been used in the Internet, but new approaches are
beginning to be used that incorporate some of the network
layer techniques discussed above.
21. Congestion Control in TCP
TCP implements end-to-end congestion control. TCP
detects congestion via the ACK's from the sliding-window
ARQ algorithm used for providing reliable service.

When the source times out before receiving an ACK,

the most likely reason is because a link became
congested. TCP uses this as an indication of congestion.
In this case, TCP will slow down the transmission rate.

TCP controls the transmission rate of a source by

varying the window size used in the sliding window
protocol.
22. TCP Flow control versus Congestion Control

•
23. Slow Start
• Initial CW = 1. sender receiver
• After each ACK, CW += 1;
• Continue until: one s e gm
ent

RTT
– Loss occurs OR
– CW > slow start two segm
en ts
threshold
• Then switch to congestion
four segm
avoidance ents
• If we detect loss, cut CW in half
• Exponential increase in window
size per RTT
time
24. Congestion Avoidance

Until (loss) {
after CW packets ACKed:
CW += 1;
}
ssthresh = CW/2;
Depending on loss type:
SACK/Fast Retransmit:
CW/= 2; continue;
Course grained timeout:
CW = 1; go to slow start.

(This is for TCP Reno/SACK: TCP

Tahoe always sets CW=1 after a loss)
 25. How are losses recovered?
• Say packet is lost (data or ACK!)
sender receiver
• Coarse-grained Timeout:
– Sender does not receive ACK after Seq=9
2, 8 b
some period of time y t es d
at a
– Event is called a retransmission time-
out (RTO)

timeout
=1 00
– RTO value is based on estimated ACK
round-trip time (RTT) X
– RTT is adjusted over time using loss
exponential weighted moving Seq=9
average: 2, 8 b
y t es d
at a
RTT = (1-x)*RTT + (x)*sample
(x is typically 0.1)
=10 0
First done in TCP Tahoe ACK

time
lost ACK scenario
 26. Fast Retransmit
• Receiver expects N, gets N+1:

– Immediately sends ACK(N) sender receiver

– This is called a duplicate ACK
– Does NOT delay ACKs here! ACK 3000
– Continue sending dup ACKs for each
S E Q =3 0 0
subsequent packet (not N) 0, size=10
00
S E Q =4 0 0 X
• 0
Sender gets 3 duplicate ACKs:
S E Q =5 0 0
– Infers N is lost and resends 0
– 3 chosen so out-of-order packets don’t S E Q =6 0 0
0
trigger Fast Retransmit accidentally
– Called “fast” since we don’t need to ACK 3000
wait for a full RTT ACK 3000
ACK 3000
S E Q =3 0 0
0, size=10
00

time
Introduced in TCP Reno
TCP Connection Management Modeling

The states used in the TCP connection

management finite state machine.
TCP Connection Management Modeling (2)
PART D: UDP
• UDP (User Datagram Protocol)  unreliable,
connectionless; No TCP’s flow control;
applications where prompt delivery more
important than accurate delivery (speech,
video, …)
• (Metaphor: postal service)
2. UDP (2)

Datagram protocol  it does not have to establish a

connection to another machine before sending data.

1. Takes the data an application provides,

2. Packs it into a UDP packet
3. Hands it to the IP layer.
4. The packet is then put on the wire, and
that is where it ends.

There is no way to guarantee that

the packet will reach its destination.
3. UDP Packet
Basically all UDP provides is a multiplexing capability on top of IP.

The length field gives the length of the entire packet including the header.

The checksum is calculated on the entire packet

(and also on part of the IP header).

Calculating the checksum is optional, and if an error is detected the packet

may be discarded or may be passed on to the application with an error flag.