0% found this document useful (0 votes)
21 views

Lecture

The document discusses the transport layer in networking. It compares the OSI and TCP/IP models, describing each layer. It covers important concepts like multiplexing, demultiplexing, connection-oriented vs connectionless transport, and reliable data transfer. The document also outlines the chapter on transport layer services and protocols.

Uploaded by

ochir.og
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views

Lecture

The document discusses the transport layer in networking. It compares the OSI and TCP/IP models, describing each layer. It covers important concepts like multiplexing, demultiplexing, connection-oriented vs connectionless transport, and reliable data transfer. The document also outlines the chapter on transport layer services and protocols.

Uploaded by

ochir.og
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 62

Transport Layer

Ante Prodan
School of Computer, Data and
Mathematical Sciences

1
Case Study Report
n Have you chosen your topic?
n Deadline by the end of the next week
n If you need a partner, I can list your name and
contact detail during the lecture and I can put
the list on screen during the break or in an
announcement that goes to everyone.
n This week tutorial is a good opportunity to find
partner and select your topic…
n Problem with your partner – report it
immediately.
2
Case Study Report
n Before submitting go through the checklist.
n ONLY ONE GROUP MEMBER SUBMITS YOUR
CASE STUDY REPORT

3
Housekeeping
n For your study use resources on vUWS
n Subject outline
n Lecture notes
n Study questions
n Multimedia
n URLs
n Video Resources accessible by using web links provided and
videos accessible via vUWS

4
Comparing OSI and TCP/IP
models
Layer OSI Model TCP/IP Model
I
7 Application M
6 Presentation Application P
5 Session O
R !!!
4 Transport Transport T
3 Network Internet A
2 Data link N
Link T
1 Physical
OSI: Open Systems Interconnection (OSI) model (ISO/IEC 7498-1)
TCP/IP: Internet protocol suite is the set of communications protocols used for
the Internet and similar networks (names of the layers from RFC 1122)
Encapsulation of application data
descending through the TCP/IP
layers
I
M
TCP TCP P
header data or O
R
T
A
N
T
Multiplexing / Demultiplexing

IMPORTANT 7
Important Concepts
n Logical communication between two processes.
n transport-layer protocol provides logical communication
between processes
n network-layer protocol provides logical communication
between hosts
n Multiplexing and demultiplexing
n Connectionless and connection-oriented
demultiplexing
n Reliable data transfer (RDT)
n Because packets can have bit errors as well as be lost, RDT
protocols are surprisingly complicated, requiring
acknowledgements, timers, checksums, sequence numbers,
and acknowledgement numbers.
n Pipelined reliable data transfer
n Flow control
n Congestion control
8
Chapter 3 outline
n 3.1 Transport-layer n 3.5 Connection-oriented
services transport: TCP
segment structure
3.2 Multiplexing and
n
n
reliable data transfer
demultiplexing
n

n flow control
n 3.3 Connectionless n connection management
transport: UDP
n 3.6 Principles of
n 3.4 Principles of reliable congestion control
data transfer
n 3.7 TCP congestion
control

9
Transport services and protocols
application
transport
n provide logical communication network
data link
between app processes running physical

on different hosts

lo
gi
ca
transport protocols run in end

le
n

nd
systems

-e
nd
n send side: breaks app

tr
a
messages into segments,

ns
po
passes to network layer

rt
n rcv side: reassembles application
transport
segments into messages, network
data link
passes to app layer physical

n more than one transport


protocol available to apps
n Internet: TCP and UDP

10
Internet transport-layer protocols
application

n reliable, in-order delivery transport


network
data link
(TCP) physical
network
data link
congestion control

lo
network
n physical

gi
data link

ca
physical
flow control

le
n

nd
connection setup

-e
n

nd
network

unreliable, unordered

tr
data link
n

a
physicalnetwork

ns
delivery: UDP data link

po
physical

rt
network
n no-frills extension of “best- data link
physical
application
network transport
effort” IP data link network
physical data link
n services not available: physical

n delay guarantees
n bandwidth guarantees

11
Multiplexing/demultiplexing
Demultiplexing at rcv host: Multiplexing at send host:
gathering data from multiple
delivering received segments
sockets, enveloping data with
to correct socket
header (later used for
demultiplexing)
= socket = process

P3 P1
P1 P2 P4 application
application application

transport transport transport

network network network

link link link

physical physical physical

host 2 host 3
host 1
12
How demultiplexing works

32 bits

n host receives IP datagrams source port # dest port #


n each datagram has source

IP address, destination IP other header fields


address
n each datagram carries 1

transport-layer segment
application
n each segment has source,
data
destination port number
(message)
n host uses IP addresses & port
numbers to direct segment to
appropriate socket TCP/UDP segment format

13
Connectionless demultiplexing
n When host receives UDP
n Create sockets with port segment:
numbers: n checks destination port
DatagramSocket mySocket1 = number in segment
new DatagramSocket(12534); n directs UDP segment to
DatagramSocket mySocket2 = socket with that port
new DatagramSocket(12535); number
n UDP socket identified by n IP datagrams with
two-tuple: different source IP
addresses and/or source
(dest IP address, dest port number) port numbers directed to
same socket

14
Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);

P2 P1
P1
P3

SP: 6428 SP: 6428


DP: 9157 DP: 5775

SP: 9157 SP: 5775


client DP: 6428 DP: 6428 Client
server
IP: A IP: C IP:B

SP provides “return address”

15
Connection-oriented demux
n TCP socket identified n Server host may
by 4-tuple: support many
n source IP address simultaneous TCP
n source port number sockets:
n dest IP address n each socket identified
n dest port number by its own 4-tuple
n recv host uses all n Web servers have
four values to direct different sockets for
segment to each connecting client
appropriate socket n non-persistent HTTP
will have different
socket for each request 16
Connection-oriented demux (cont)

P1 P4 P5 P6 P2 P1P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157


client DP: 80 DP: 80 Client
server
IP: A S-IP: A
IP: C S-IP: B IP:B
D-IP:C D-IP:C

SP: Source Port S-IP: Source IP address


DP: Destination Port D-IP: Destination IP address
17
Connection-oriented demux: Threaded Web
Server

P1 P4 P2 P1P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157


client DP: 80 DP: 80 Client
server
IP: A S-IP: A
IP: C S-IP: B IP:B
D-IP:C D-IP:C

18
TCP Multiplexing Service
• Multiple processes within a host can
simultaneously access the network via a
single TCP entity.
• Each process within a host which uses TCP
services is identified with a port.
• A port, when concatenated with an IP address,
forms a socket, which is unique throughout the
internet.
• Service by TCP is provided by means of a
logical connection between a pair of sockets.
19
TCP Multiplexing Service
As an example, the diagram on the next slide
shows three hosts A, B and C connected over the
internet. The multiplexing service of TCP would
enable a process X, say in host A to establish a
connection to a process Y in host B. This might
involve use of port 2 in A and port 1 in B. At the
same time a process P in B could establish a
connection to a process Q in A using port 2
of B and port 1 of A. Finally, a process M in A might
establish a link to a process N in host C using ports
3 of A and 1 of C.
20
TCP Multiplexing Service

Thus multiple users or processes


within a host can employ
simultaneously the services of
TCP to exchange data with remote
processes.

21
TCP Multiplexing Service

22
https://etc.ch/XqKn
Question 1

When sharing a communication channel by two


or more users/devices _______ is necessary.

(a) Modulation
(b) Encoding
(c) Code division
(d) Demultiplexing

23
Chapter 3 outline
n 3.1 Transport-layer n 3.5 Connection-oriented
services transport: TCP
n 3.2 Multiplexing and n segment structure
demultiplexing n reliable data transfer
flow control
n 3.3 Connectionless n

connection management
transport: UDP n

n 3.6 Principles of
n 3.4 Principles of reliable
congestion control
data transfer
n 3.7 TCP congestion
control

24
UDP: User Datagram Protocol [RFC
768]
n “no frills,” “bare bones”
Internet transport protocol Why is there a UDP?
n “best effort” service, UDP n no connection establishment
segments may be: (which can add delay)
n lost
n simple: no connection state
at sender, receiver
n delivered out of order to

app n small segment header


n connectionless: n no congestion control: UDP
can blast away as fast as
n no handshaking between
desired
UDP sender, receiver
n each UDP segment
handled independently of
others

25
UDP: more
32 bits
n often used for streaming
multimedia apps Length, in source port # dest port #
n loss tolerant bytes of UDP length checksum
segment,
n rate sensitive
including
n other UDP uses header
n DNS
n SNMP
Application
data
n reliable transfer over UDP:
(message)
add reliability at application
layer
n application-specific error
UDP segment format
recovery!

26
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in
transmitted segment
Sender: Receiver:
n treat segment contents as n compute checksum of received
sequence of 16-bit integers segment
n checksum: addition (1’s n check if computed checksum
complement sum) of equals checksum field value:
segment contents n NO - error detected

n sender puts checksum n YES - no error detected.

value into UDP checksum But maybe errors


field nonetheless? More later ….

27
Internet Checksum Example
n Note
n When adding numbers, a carryout from the

most significant bit needs to be added to


the result
n 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

28
Chapter 3 outline
n 3.1 Transport-layer n 3.5 Connection-oriented
services transport: TCP
n segment structure
n 3.2 Multiplexing and
n reliable data transfer
demultiplexing
n flow control
n 3.3 Connectionless n connection management
transport: UDP
n 3.6 Principles of
n 3.4 Principles of reliable congestion control
data transfer
n 3.7 TCP congestion
control

29
Principles of Reliable data transfer
n important in app., transport, link layers
n top-10 list of important networking topics!

n characteristics of unreliable channel will determine


complexity of reliable data transfer protocol (rdt)
30
Principles of Reliable data transfer
n important in app., transport, link layers
n top-10 list of important networking topics!

n characteristics of unreliable channel will determine


complexity of reliable data transfer protocol (rdt)
31
Principles of Reliable data transfer
n important in app., transport, link layers
n top-10 list of important networking topics!

n characteristics of unreliable channel will determine


complexity of reliable data transfer protocol (rdt) 32
Reliable data transfer: getting started
rdt_send(): called from above, deliver_data(): called by
(e.g., by app.). Passed data to rdt to deliver data to upper
deliver to receiver upper layer

send receive
side side

udt_send(): called by rdt, rdt_rcv(): called when packet


to transfer packet over arrives on rcv-side of channel
unreliable channel to receiver

33
Reliable data transfer: getting started
We’ll:
n incrementally develop sender, receiver sides of

reliable data transfer protocol (rdt)


n consider only unidirectional data transfer

n but control info will flow on both directions!


n use finite state machines (FSM) to specify
sender, receiver
event causing state transition
actions taken on state transition
state: when in this
state state
“state” next state event
1 2
uniquely actions
determined by next
event
34
Rdt1.0: reliable transfer over a reliable channel

n underlying channel perfectly reliable


n no bit errors
n no loss of packets
n separate FSMs for sender, receiver:
n sender sends data into underlying channel
n receiver read data from underlying channel

Wait for rdt_send(data) Wait for rdt_rcv(packet)


call from call from extract (packet,data)
above packet = make_pkt(data) below deliver_data(data)
udt_send(packet)

sender receiver

35
Rdt2.0: channel with bit errors

n underlying channel may flip bits in packet


n checksum to detect bit errors
n the question: how to recover from errors:
n acknowledgements (ACKs): receiver explicitly tells sender that
pkt received OK
n negative acknowledgements (NAKs): receiver explicitly tells
sender that pkt had errors
n sender retransmits pkt on receipt of NAK
n new mechanisms in rdt2.0 (beyond rdt1.0):
n error detection
n receiver feedback: control msgs (ACK,NAK) rcvr->sender

36
rdt2.0: FSM specification
rdt_send(data)
snkpkt = 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
sender below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK) 37
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)
38
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)
39
rdt2.0 has a fatal flaw!
What happens if ACK/NAK Handling duplicates:
corrupted? n sender retransmits current
n sender doesn’t know what happened at pkt if ACK/NAK garbled
receiver! n sender adds sequence
n can’t just retransmit: possible duplicate number to each pkt
n receiver discards (doesn’t
deliver up) duplicate pkt

stop and wait


Sender sends one packet,
then waits for receiver
response

40
Chapter 3 outline
n 3.1 Transport-layer n 3.5 Connection-oriented
services transport: TCP
segment structure
3.2 Multiplexing and
n
n
reliable data transfer
demultiplexing
n

n flow control
n 3.3 Connectionless n connection management
transport: UDP
n 3.6 Principles of
n 3.4 Principles of reliable congestion control
data transfer
n 3.7 TCP congestion
control

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

n point-to-point: n full duplex data:


n one sender, one receiver n bi-directional data flow in
n reliable, in-order byte same connection
steam: n MSS: maximum segment
size
n no “message boundaries”
n connection-oriented:
n pipelined:
n handshaking (exchange of
n TCP congestion and flow control msgs) init’s
control set window size sender, receiver state
n send & receive buffers before data exchange
n flow controlled:
application application
socket
writes data reads data
socket n sender will not overwhelm
door
TCP
send buffer
TCP
receive buffer
door
receiver
segment

42
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
UA P R S F Receive window
(generally not used) # bytes
checksum Urg data pnter
rcvr willing
RST, SYN, FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

43
TCP seq. #’s and ACKs
Seq. #’s: Host A Host B
n byte stream User Seq=4
2, ACK
“number” of first types =79, d
ata = ‘C’
‘C’
byte in segment’s host ACKs
data receipt of
C ’ ‘C’, echoes
ACKs: , data = ‘
3
CK=4 back ‘C’
=79, A
n seq # of next byte S eq

expected from other


host ACKs
side receipt Seq=4
n cumulative ACK of echoed 3, ACK
=80
‘C’
Q: how receiver handles
out-of-order segments
n A: TCP spec doesn’t time
say, - up to simple telnet scenario
implementor
44
Chapter 3 outline
n 3.1 Transport-layer n 3.5 Connection-oriented
services transport: TCP
n 3.2 Multiplexing and n segment structure
demultiplexing n reliable data transfer
n flow control
n 3.3 Connectionless
connection management
transport: UDP
n

n 3.6 Principles of
n 3.4 Principles of reliable
congestion control
data transfer
n 3.7 TCP congestion
control

45
TCP reliable data transfer
n TCP creates rdt n Retransmissions are
service on top of IP’s triggered by:
unreliable service n timeout events
n Pipelined segments n duplicate acks

n Cumulative acks n Initially consider


simplified TCP
n TCP uses single
sender:
retransmission timer
n ignore duplicate
acks
n ignore flow control,
congestion control
46
TCP sender events:
data rcvd from app: timeout:
n Create segment with n retransmit segment that

seq # caused timeout


n seq # is byte-stream n restart timer

number of first data Ack rcvd:


byte in segment n If acknowledges
n start timer if not already previously unacked
running (think of timer segments
as for oldest unacked n update what is known to
segment) be acked
n expiration interval: n start timer if there are
TimeOutInterval outstanding segments

47
TCP: retransmission scenarios
Host A Host B Host A Host B

Seq=9 Seq=9
2, 8 b 2, 8 b
ytes d ytes d
ata Seq= ata

Seq=92 timeout
100,
20 by
tes d
ata
timeout

C K =100
A 0
10
X C K
A AC
=
K =120
loss
Seq=9 Seq=9
2, 8 b
2, 8 b
ytes d Sendbase ytes d
ata
ata
= 100

Seq=92 timeout
SendBase
= 120 =120
K
C K =100 AC
A

SendBase
= 100 SendBase
= 120 premature timeout
time time
lost ACK scenario 48
TCP retransmission scenarios
(more)
Host A Host B

Seq=9
2, 8 b
ytes d
ata

100

timeout
Seq=1 K =
00, 20 AC
bytes
data
X
loss

SendBase =120
A CK
= 120

time
Cumulative ACK scenario

49
Chapter 3 outline
n 3.1 Transport-layer n 3.5 Connection-oriented
services transport: TCP
n segment structure
n 3.2 Multiplexing and
n reliable data transfer
demultiplexing
n flow control
n 3.3 Connectionless n connection management
transport: UDP
n 3.6 Principles of
n 3.4 Principles of reliable congestion control
data transfer
n 3.7 TCP congestion
control

50
TCP Flow Control
flow control
sender won’t overflow
n receive side of TCP receiver’s buffer by
connection has a transmitting too much,
receive buffer: too fast

n speed-matching
service: matching
the send rate to the
receiving app’s drain
n app process may be rate
slow at reading from
buffer
51
TCP Flow control: how it works
n Rcvr advertises spare
room by including
value of RcvWindow
in segments
(Suppose TCP receiver n Sender limits
discards out-of-order unACKed data to
segments) RcvWindow
n spare room in buffer n guarantees receive
= RcvWindow buffer doesn’t
overflow
= RcvBuffer-
[LastByteRcvd -
LastByteRead] 52
https://etc.ch/XqKn
Question 2
n Which one of the protocols listed below can prevent
buffer overflow (overrun)?
(a) UDP
(b) HTTP
(c) DNS
(d) TCP

53
Chapter 3 outline
n 3.1 Transport-layer n 3.5 Connection-oriented
services transport: TCP
n 3.2 Multiplexing and n segment structure
demultiplexing n reliable data transfer
flow control
3.3 Connectionless
n
n
connection management
transport: UDP n

n 3.6 Principles of
n 3.4 Principles of reliable
congestion control
data transfer
n 3.7 TCP congestion
control

54
TCP Connection Management

Recall: TCP sender, receiver Three way handshake:


establish “connection” before
exchanging data segments Step 1: client host sends TCP SYN
n initialize TCP variables: segment to server
n specifies initial seq #
n seq. #s
n no data
n buffers, flow control info
(e.g. RcvWindow) Step 2: server host receives SYN,
n client: connection initiator replies with SYNACK segment
Socket clientSocket = new
Socket("hostname","port
n server allocates buffers
n specifies server initial seq.
number");
#
n server: contacted by client
Socket connectionSocket =
Step 3: client receives SYNACK,
welcomeSocket.accept(); replies with ACK segment,
which may contain data
55
TCP Connection Management (cont.)

client server
Closing a connection: close
FIN
client closes socket:
clientSocket.close();
A CK
close
Step 1: client end system FIN
sends TCP FIN control
segment to server

timed wait
A CK

Step 2: server receives FIN,


replies with ACK. Closes
connection, sends FIN. closed

56
TCP Connection Management (cont.)

client server

Step 3: client receives FIN, closing


FIN
replies with ACK.
n Enters “timed wait” - will
respond with ACK to A CK
closing
received FINs FIN

Step 4: server, receives ACK.

timed wait
Connection closed. A CK

closed
Note: with small modification,
can handle simultaneous
FINs. closed

57
Chapter 3 outline
n 3.1 Transport-layer n 3.5 Connection-oriented
services transport: TCP
n 3.2 Multiplexing and n segment structure
demultiplexing n reliable data transfer
n flow control
n 3.3 Connectionless
connection management
transport: UDP
n

n 3.6 Principles of
n 3.4 Principles of reliable
congestion control
data transfer
n 3.7 TCP congestion
control

58
Principles of Congestion Control
Congestion:
n informally: “too many sources sending too
much data too fast for network to handle”
n different from flow control!
n manifestations:
n lost packets (buffer overflow at routers)

n long delays (queueing in router buffers)

n a top-10 problem!

59
TCP congestion control: additive
increase, multiplicative decrease

n Approach: increase transmission rate (window size),


probing for usable bandwidth, until loss occurs
n additive increase: increase CongWin by 1 MSS every

RTT until loss detected


n multiplicative decrease: cut CongWin in half after

loss congestion
window

congestion window size


24 Kbytes

Saw tooth
behavior: probing
16 Kbytes

for bandwidth
8 Kbytes

time
time

60
https://etc.ch/XqKn
Question 3
At which devices TCP congestion control detection is
implemented?

(a) at the end hosts


(b) at the path routers
(c) at all of the network interfaces
(d) everywhere on the Internet

61
External links
n Protocols at Transport Layer
n https://www.youtube.com/watch?v=Vdc8TCESIg8
n UDP
n http://www.youtube.com/watch?v=77VVjODrJiQ&feature=related
n TCP
n https://www.youtube.com/watch?v=FdwNzb1CQPg
n http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowContr
ol.htm
n http://www.youtube.com/watch?v=7Z-h9SZZ22g

62

You might also like