Course: Network Protocols

 Lecturer : Hatem Al Sheibani

 Email: [email protected]

Grading Method

 Course work 20 %
 Midterm Exam 30 %
 Final Exam 50 %

References:
• Cisco CCENT-CCNA ICND1 100-101 Official Cert Guide
• Computer networking a top-down approach 6th edition

Network Protocols CN321

Chapter 1
Transport Layer

1
 Chapter 1: Transport Layer
our goals:
 understand  learn about Internet
principles behind transport layer protocols:
transport layer  UDP: connectionless
services: transport
 multiplexing,  TCP: connection-oriented
demultiplexing reliable transport
 reliable data transfer  TCP congestion control
 flow control
 congestion control

1-1

Transport services and protocols

application
transport
 Transport Layer protocols network
data link
provide logical communication between app physical

processes running on different hosts.

 more than one transport protocol available to
apps
 TCP and UDP

Transport layer responsibilities(TCP

&UDP):
application
 Segmenting Data (sender) transport
network
 Reassembling Segments(receiver) data link
physical
 Tracking conversations (session)
 Identifying the Applications
 Multiplexing and demultiplexing

1-2

2
 1-3

Internet transport-layer protocols

 TCP (Reliable) application
transport

in-order delivery network

data link
physical
congestion control network
network
data link
data link physical
 flow control physical
network

 connection setup data link

physical

network
data link
physical

 UDP (unreliable) network

data link
physical
unordered delivery(best network
data link application

effort) physical
network
data link
transport
network
physical data link

services not available: physical

 delay guarantees
 bandwidth guarantees

1-5

3
 TCP vs UDP

1-6

1-7

4
 Port Number Groups
The Internet Assigned Numbers Authority (IANA) is the standards body
responsible for assigning various addressing standards, including port numbers.
There are different types of port numbers:

Well-known Ports (Numbers 0 to 1023) - These numbers are reserved for

services and applications. They are commonly used for applications such as web
browsers, email clients, and remote access clients. By defining these well-known
ports for server applications, client applications can be programmed to request a
connection to that specific port and its associated service.

Registered Ports (Numbers 1024 to 49151) - These port numbers are

assigned by IANA to a requesting entity to use with specific processes or
applications. These processes are primarily individual applications that a user has
chosen to install, rather than common applications that would receive a well-
known port number. For example, Cisco has registered port 1985 for its Hot
Standby Routing Protocol (HSRP) process.

Dynamic or Private Ports (Numbers 49152 to 65535) - Also known as

ephemeral ports, these are usually assigned dynamically by the client’s OS when a
connection to a service is initiated. The dynamic port is then used to identify the
client application during communication.

1-8

Well-known Port numbers

1-9

10

5
 Multiplexing/demultiplexing
multiplexing at sender:
handle data from multiple demultiplexing at receiver:
sockets, add transport header use header info to deliver
(later used for demultiplexing) received segments to correct
socket

application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical

1-10

11

Multiplexing/ Demultiplexing

 host receives IP datagrams 32 bits

 each datagram has source IP source port # dest port #
address, destination IP
address
other header fields
 each datagram carries one
transport-layer segment
 each segment has source, application
destination port number data
 host uses IP addresses & (payload)
port numbers to direct
segment to appropriate
TCP/UDP segment format
socket

1-11

12

6
 Connectionless demux: example
DatagramSocket
DatagramSocket serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application (5775);
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: ?

dest port: 9157 dest port: ?

source port: 9157 source port: ?

dest port: 6428 dest port: ?
1-12

13

Connection-oriented demux
 TCP socket identified  server host may support
by 4-tuple: many simultaneous TCP
 source IP address sockets:
 source port number  each socket identified by
 dest IP address its own 4-tuple
 dest port number  web servers have
 demux: receiver uses different sockets for
all four values to direct each connecting client
segment to appropriate  non-persistent HTTP will
socket have different socket for
each request

1-13

14

7
 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 sockets 1-14

15

Connection-oriented demux: example

threaded server
application
application application
P4
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

1-15

16

8
 UDP: User Datagram Protocol [RFC 768]
 “no frills,” “bare bones”  UDP use:
Internet transport  streaming multimedia
protocol apps (loss tolerant, rate
 “best effort” service, sensitive)
UDP segments may be:  DNS
 lost  SNMP
 delivered out-of-order  reliable transfer over
to app
UDP:
 connectionless:
 add reliability at
 no handshaking application layer
between UDP sender,
receiver  application-specific error
recovery!
 each UDP segment
handled independently
of others
1-16

17

UDP: segment header

length, in bytes of
32 bits UDP segment,
source port # dest port # including header

length checksum
why is there a UDP?
 no connection
application establishment (which can
data add delay)
(payload)  simple: no connection
state at sender, receiver
 small header size
UDP segment format  no congestion control:
UDP can blast away as
fast as desired

1-17

18

9
 UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
sender: receiver:
 treat segment contents,  compute checksum of
including header fields, received segment
as sequence of 16-bit  check if computed
integers
checksum equals checksum
 checksum: addition field value:
(one’s complement
sum) of segment  NO - error detected
contents  YES - no error detected.
 sender puts checksum But maybe errors
value into UDP nonetheless? More later
checksum field ….
1-18

19

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

1-19

20

10
 TCP: Overview RFCs: 793,1122,1323, 2018, 2581

 point-to-point:  full duplex data:

 one sender, one receiver  bi-directional data flow
 reliable, in-order byte in same connection
steam:  MSS: maximum segment
size
 no “message
boundaries”  connection-oriented:
 pipelined:  handshaking (exchange
of control msgs) inits
 TCP congestion and sender, receiver state
flow control set window before data exchange
size
 flow controlled:
 sender will not
overwhelm receiver
1-20

21

TCP segment structure

32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UAP R S F receive window
(generally not used) # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

1-21

22

11
 TCP seq. numbers, ACKs
outgoing segment from sender
sequence numbers: source port # dest port #
sequence number
byte stream “number” of acknowledgement number

first byte in segment’s checksum

rwnd
urg pointer
data window size
acknowledgements: N

seq # of next byte

expected from other side sender sequence number space
cumulative ACK
sent sent, not- usable not
ACKed yet ACKed but not usable
(“in- yet sent
Note: flight”)
Sequence numbers is Byte incoming segment to sender
source port # dest port #
sequence number
acknowledgement number
A rwnd
checksum urg pointer

1-22

23

TCP seq. numbers, ACKs(example)

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

1-23

24

12
 TCP round trip time, timeout
Q: how to set TCP Q: how to estimate RTT?
timeout value?  SampleRTT: measured
time from segment
 longer than RTT transmission until ACK
 but RTT varies receipt
 too short: premature  ignore retransmissions
timeout, unnecessary  SampleRTT will vary, want
retransmissions estimated RTT “smoother”
 average several recent
 too long: slow reaction measurements, not just
to segment loss current SampleRTT

1-24

25

TCP round trip time, timeout

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 exponential weighted moving average
 influence of past sample decreases exponentially fast
 typical value:  = 0.125 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

RTT (milliseconds)

300

250
RTT (milliseconds)

200

sampleRTT
150

EstimatedRTT

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
time (seconds) 1-25
SampleRTT Estimated RTT

26

13
 TCP round trip time, timeout
 timeout interval: EstimatedRTT plus “safety margin”
 large variation in EstimatedRTT -> larger safety margin
 estimate SampleRTT deviation from EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25)

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”

1-26

27

TCP reliable data transfer

 TCP creates rdt service
on top of IP’s unreliable
service
 pipelined segments
 cumulative acks let’s initially consider
 single retransmission simplified TCP sender:
timer  ignore duplicate acks
 retransmissions  ignore flow control,
triggered by: congestion control
 timeout events
 duplicate acks

1-27

28

14
 TCP sender events:
data rcvd from app: timeout:
 create segment with  retransmit segment
seq # that caused timeout
 seq # is byte-stream  restart timer
number of first data ack rcvd:
byte in segment  if ack acknowledges
 start timer if not previously unacked
already running segments
 think of timer as for  update what is known
oldest unacked to be ACKed
segment
 start timer if there are
 expiration interval: still unacked segments
TimeOutInterval

1-28

29

TCP: retransmission scenarios

Host A Host B Host A Host B

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

timeout

ACK=100
X
ACK=100
ACK=120

Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data
SendBase=120
ACK=100
ACK=120

SendBase=120

lost ACK scenario premature timeout

1-29

30

15
 TCP: retransmission scenarios
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

ACK=100
timeout

X
ACK=120

Seq=120, 15 bytes of data

cumulative ACK
1-30

31

TCP fast retransmit

 time-out period often
relatively long: TCP fast retransmit
 long delay before if sender receives 3
resending lost packet ACKs for same data
 detect lost segments ((““triple
triple duplicate
duplicate ACKs
ACKs””),
via duplicate ACKs. resend unacked
 sender often sends segment with smallest
many segments back- seq #
to-back
 likely that unacked
 if segment is lost, there segment lost, so don’t
will likely be many wait for timeout
duplicate ACKs.

1-31

32

16
 TCP fast retransmit
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data
X

timeout ACK=100
ACK=100
ACK=100
ACK=100
Seq=100, 20 bytes of data

fast retransmit after sender

receipt of triple duplicate ACK
1-32

33

TCP flow control

application
application may process
remove data from application
TCP socket buffers ….
TCP socket OS
receiver buffers
… slower than TCP
receiver is delivering
(sender is sending) TCP
code

IP
flow control code
receiver controls sender, so
sender won’t overflow
receiver’s buffer by transmitting from sender
too much, too fast
receiver protocol stack

1-33

34

17
 TCP flow control
 receiver “advertises” free
buffer space by including to application process
rwnd value in TCP header
of receiver-to-sender
segments RcvBuffer buffered data
 RcvBuffer size set via
socket options (typical default rwnd free buffer space
is 4096 bytes)
 many operating systems
autoadjust RcvBuffer TCP segment payloads
 sender limits amount of
unacked (“in-flight”) data to receiver-side buffering
receiver’s rwnd value
 guarantees receive buffer
will not overflow
1-34

35

Connection Management
before exchanging data, sender/receiver “handshake”:
 agree to establish connection (each knowing the other willing
to establish connection)
 agree on connection parameters

application application

connection state: ESTAB connection state: ESTAB

connection variables: connection Variables:
seq # client-to-server seq # client-to-server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
at server,client at server,client

network network

Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
1-35

36

18
 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

1-36

37

TCP 3-way handshake: FSM

closed

Socket connectionSocket =
welcomeSocket.accept();

L Socket clientSocket =
SYN(x) newSocket("hostname","port
number");
SYNACK(seq=y,ACKnum=x+1)
create new socket for SYN(seq=x)
communication back to client listen

SYN SYN
rcvd sent

SYNACK(seq=y,ACKnum=x+1)
ESTAB ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
L

1-37

38

19
 TCP: closing a connection
 client, server each close their side of connection
 send TCP segment with FIN bit = 1
 respond to received FIN with ACK
 on receiving FIN, ACK can be combined with own FIN
 simultaneous FIN exchanges can be handled

1-38

39

TCP: closing a connection

client state server state
ESTAB ESTAB
clientSocket.close()

FIN_WAIT_1 can no longer FINbit=1, seq=x

send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close

LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime

CLOSED

1-39

40

20