Chapter 3 - Transport Layer for VN Students

FACULTY OF INFORMATION TECHNOLOGY
MSc. Nguyen Cong Danh
CHAPTER 3
TRANSPORT LAYER

2
OUTLINE
1. Transport Services & Protocols
2. Multiplexing & Demultiplexing
3. Principle of Reliable Data Transfer
4. UDP – Connectionless Transport
5. TCP – Connection-Oriented Transport
6. TCP Flow Control
7. TCP Congestion Control

Faculty of Information Technology
1. TRANSPORT SERVICES
& PROTOCOLS

4
• Provide logical communication between app
processes running on different hosts
• Transport protocols run in end systems
oSend side: breaks app messages into
segments, passes to network layer
oRcv side: reassembles segments into
messages, passes to app layer
• More than one transport protocol available to
apps
o Internet: TCP and UDP
TRANSPORT SERVICES & PROTOCOLS

5
• Reliable, in-order delivery (TCP)
ocongestion control
oflow control
oconnection setup
• Unreliable, unordered delivery: UDP
ono-frills extension of “best-effort” IP
oprocess-to-process data delivery and error
checking—are the only two services that
UDP provides
• Services not available for IP protocol:
odelay guarantees
obandwidth guarantees
INTERNET TRANSPORT-LAYER PROTOCOLS

6
TCP vs UDP more details…
TCP service:
• Reliable transport between sending and
receiving process
• Flow control: sender won’t overwhelm receiver
• Congestion control: throttle sender when
network overloaded
• Does not provide: timing, minimum throughput
guarantee, security
• Connection-oriented: setup required between
client and server processes
UDP service:
• Unreliable data transfer between sending
and receiving process
• Does not provide: reliability, flow control,
congestion control, timing, throughput
guarantee, security, or connection setup,

2. MULTIPLEXING &
DEMULTIPLEXING

8
MULTIPLEXING/DEMULTIPLEXING
Transport protocols
(TCP, UDP)
Network protocol (IP)

9
HOW DEMULTIPLEXING WORKS
• Host receives IP packets
oEach packet has source IP address,
destination IP address
oEach packet carries one transport-
layer segment
oEach segment has source,
destination port number
• Host uses IP addresses & port numbers
to direct segment to appropriate socket
TCP/UDP segment format
Multiplexing = gathering data chunks at the source, encapsulating with header information, passing the
segment to the network layer
Demultiplexing = delivering the data in a transport-layer segment to the correct socket

10
COMMON PORTS

11
CONNECTIONLESS MULTIPLEXING & DEMULTIPLEXING
DatagramSocket serverSocket =
new DatagramSocket (6428);
transport
application
physical
link
network
P2
transport
application
physical
link
network
P1
DatagramSocket mySocket2 =
new DatagramSocket(9157);
source port: 9157
dest port: 6428
source port: 6428
dest port: 9157
• UDP socket must be specified by:
o destination IP address
o destination port X
• When host receives UDP segment:
o checks destination port X in
segment
o directs UDP segment to socket with
that port X
IP datagrams with same dest. port X, but
different source IP addresses and/or source
port numbers will be directed to same
socket at destination

12
CONNECTION-ORIENTED DEMUX
• TCP socket identified by 4-tuple:
osource IP address
osource port number
odest IP address
odest port number
• Demux: receiver uses all four values to
direct segment to appropriate socket
• Server host may support many
simultaneous TCP sockets:
oeach socket identified by its own 4-tuple
• Web servers have different sockets for each
connecting client
onon-persistent HTTP will have different
socket for each request

13
CONNECTION-ORIENTED DEMUX: EXAMPLE

4. UDP –
CONNECTIONLESS
TRANSPORT

15
UDP: USER DATAGRAM PROTOCOL
• “Best Effort” service, UDP
segments may be:
olost
odelivered out-of-order to app
• Connectionless:
ono handshaking between
UDP sender, receiver
oeach UDP segment handled
independently of others
• UDP use:
o streaming multimedia apps (loss
tolerant, rate sensitive)
o DNS
o SNMP
• Reliable transfer over UDP:
o add reliability at application layer
o application-specific error
recovery!

16
WHY CHOSE UDP INSTEAD TCP?
• Real-time applications require
minimum delay
• No connection establishment
o No delay for connection
establishment
• No connection state
o Support more active client
• Small packet header overhead
o TCP: 20 bytes/segment
o UDP: 8 bytes/segment

17
UDP SEGMENT STRUCTURE
source port # dest port #
32 bits
application
data
(payload)
UDP segment format
length checksum
length, in bytes of
UDP segment,
including header
For error detection
 Receiving host checks whether
bits within the UDP segment have
been altered

18
UDP CHECKSUM
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
Sender:
• Treat segment contents,
including header fields, as
sequence of 16-bit integers
• Checksum: addition (one ’ s
complement sum) of segment
contents
• Sender puts checksum value
into UDP checksum field
Receiver:
• Compute checksum of received
segment
• Check if computed checksum
equals checksum field value:
oNO - error detected
oYES - no error detected. But
maybe errors nonetheless?
More later ….
UDP provides error checking  but does not do anything to recover from an error

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 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 0 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1 0 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
1 1 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
wraparound
sum
checksum
Note: when adding numbers, a carryout from the most significant bit needs to be added to the result

5. TCP – CONNECTION-
ORIENTED TRANSPORT

21
TCP: TRANSMISSION CONTROL PROTOCOL
• Point-to-point:
oOne sender, one receiver
• Reliable, in-order byte steam:
oNo “message boundaries”
• Pipelined:
oTCP congestion and flow
control set window size
• Full duplex data:
oBi-directional data flow in same connection
oMSS: maximum segment size
• Connection-oriented:
oHandshaking (exchange of control msgs) inits sender,
receiver state before data exchange
• Flow controlled:
oSender will not overwhelm receiver

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

23
TCP SEQUENCE NUMBERS, ACKs
• Sequence numbers:
o Byte stream “number” of first byte
in segment’s data
• Acknowledgements:
o Seq # of next byte expected from
other side
o Cumulative ACK
Q: How receiver handles out-of-order
segments?
sequence number
checksum
rwnd
urg pointer
incoming segment to sender
A
sent
ACKed
sent, not-
yet ACKed
(“in-
flight”)
usable
but not
yet sent
not
usable
window size
N
sender sequence number space
sequence number
checksum
rwnd
urg pointer
Outgoing segment from sender

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

25
TCP: CLOSING A CONNECTION
FIN_WAIT_2
CLOSE_WAIT
FINbit=1, seq=y
ACKbit=1; ACKnum=y+1
ACKbit=1; ACKnum=x+1
wait for server
close
can still
send data
can no longer
send data
LAST_ACK
CLOSED
TIMED_WAIT
timed wait
for 2*max
segment lifetime
CLOSED
FIN_WAIT_1 FINbit=1, seq=x
can no longer
send but can
receive data
clientSocket.close()
client state server state
ESTAB
ESTAB

26
SUPPLEMENT 6: TCP vs UDP CONNECTIONS

27
TCP RETRANSMISSION SCENARIOS
lost ACK scenario
Host B
Host A
Seq=92, 8 bytes of data
ACK=100
X
timeout
ACK=100
premature timeout
Host B
Host A
ACK=100
Seq=92, 8
bytes of data
timeout
ACK=120
ACK=120
SendBase=100
SendBase=120
SendBase=120
SendBase=92
SendBase=92
SendBase=100

28
TCP RETRANSMISSION SCENARIOS
X
cumulative ACK
Host B
Host A
ACK=100
timeout
ACK=120
SendBase=92
SendBase=120

29
3 DUPLICATE ACKs
X
fast retransmit after sender
receipt of triple duplicate ACK
Host B
Host A
ACK=100
timeout
ACK=100
ACK=100
ACK=100
• When a duplicate ACK is received the sender does not
know if it is because a TCP segment was lost or simply
that a segment was delayed and received out of order
at the receiver.
• If more than two duplicate ACKs are received by the
sender, it is a strong indication that at least one
segment has been lost.
• When three or more duplicate ACKs are received, the
sender does not even wait for a re-transmission time to
expire before re-transmitting the segment ( the sender
enters the congestion avoidance mode).

6. TCP FLOW CONTROL

31
TCP SLIDING WINDOW – SENDER SIDE
Not sent Sent, no ACK ACKed Free
Sending buffer at the sender:
Old data sent that has already been ACKed
(Could as well be marked as free space)
New data sent to transport layer
by application, but not yet sent
Free buffer space where application can
write new data to be sent

32
Data that has been sent, but not ACKed
Also called the Sending window
This is the sliding window (yes, it slides!)
This data can not be sent yet, as
the sliding window in this example
has a maximum size of 10

33
ACTION: An ACK of the oldest sent packet arrives
• The window slides so that the left border is in line
with the oldest outstanding ACK
• The unsent segments that fit within the window
are sent

34
• The data is placed in free buffer slots
ACTION: The application has more data to send

35
• Older sent but un-ACKed segments are now
considered to be ACKed
ACTION: An ACK arrives in the middle of the window
• The window slides and unsent segments within
the window are sent
• The window shrinks by one segment as there is
no more than 9 segments outstanding

36
• The data is placed in free buffer slots
ACTION: The application has more data to send
• As the window is currently 9 segments wide,
it can grow by one segment
• The new data that fits within the window is sent

37
• The ACK is silently ignored
ACTION: An ACK of already ACKed segments arrives

38
TCP FLOW CONTROL
application
process
TCP socket
receiver buffers
TCP
code
IP
code
application
OS
receiver protocol stack
application may
remove data from
TCP socket buffers ….
… slower than
TCP
receiver is
delivering
(sender is
sending)
from sender
receiver controls sender, so
sender won’t overflow
receiver’s buffer by transmitting
too much, too fast
flow control
The idea is that a node receiving data will send
some kind of feedback to the node sending the
data to let it know about its current condition.

39
TCP FLOW CONTROL
• Receiver “advertises” free buffer space by
including rwnd value in TCP header of
receiver-to-sender segments (aka. in ACK)
oRcvBuffer is the receive buffer. It’s size
set via socket options (typical default is
4096 bytes)
oMany operating systems auto adjust
RcvBuffer
• Sender limits amount of unacked (“in-flight”)
data sent to receiver based on the rwnd
value
• Guarantees receive buffer will not overflow
buffered data
free buffer space
rwnd
RcvBuffer
TCP segment payloads
to application process
receiver-side buffering
TCP provides flow control by having the sender maintain a variable called the receive window (rwnd).

7. TCP CONGESTION
CONTROL

41
INTRODUCTION TO CONGESTION CONTROL
Congestion:
• Informally: “too many sources sending too
much data too fast for network to handle”
• Different from flow control!
• Manifestations:
oLost packets (buffer overflow at routers)
oLong delays (queueing in router buffers)
TCP Congestion Control:
• Basic idea: each source determines how
much capacity is available to a given flow in
the network.  Each sender limits the rate!
oRaises 3 questions:
- How does TCP limit the rate?
- How does TCP sender perceive that
there is congestion on the path?
- What algorithm should the sender
use to change ites send rate?
• ACKs are used to “pace” the transmission of
packets such that TCP is “self-clocking”

42
TCP CONGESTION CONTROL ALGORITHMS
• Some TCP congestion Control algorithms:
o Tahoe
 Slow Start
 Congestion Avoidance
 Fast Retransmit
o Reno
 Fast Recovery
o Vegas
 New Congestion Avoidance
o RED
o REM
o SACK
o FACK…
Slow Start
Congestion
Avoidance
Fast
Retransmit/
Fast
Recovery

Chapter 3 - Transport Layer for VN Students

Recommended

Recommended

More Related Content

Similar to Chapter 3 - Transport Layer for VN Students

Similar to Chapter 3 - Transport Layer for VN Students (20)

Recently uploaded

Recently uploaded (20)

Chapter 3 - Transport Layer for VN Students

Editor's Notes