0% found this document useful (0 votes)
33 views44 pages

Transport Layer - Part 2

Transport layer second part for computer science major

Uploaded by

Song Hyo yoo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
33 views44 pages

Transport Layer - Part 2

Transport layer second part for computer science major

Uploaded by

Song Hyo yoo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 44

Chapter 3

Transport
Layer
Part 2

Computer Networking: A
Top-Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
Transport Layer: 3-1
Transport layer: roadmap
Note: Video lectures by the authors of the textbook are available on YouTube.
https://www.youtube.com/@JimKurose

Previous Lecture Today’s Lecture

 Transport-layer services  Reliable data transfer


• Losses, ACKs
 Multiplexing and demultiplexing • Pipelined data transfer

 Connection-oriented transport: TCP


 Connectionless transport: UDP

 Principles of congestion control

 TCP congestion control Transport Layer: 3-2


rdt3.0: channels with errors and loss
Video Lecture: https://www.youtube.com/watch?v=vxgH6r-II2Q

Channel assumption: underlying channel can lose packets


(data, ACKs) i.e. frames can be dropped in a network.
• checksum, sequence #s, ACKs, retransmissions will be of help …
but not quite enough

Q: How do humans handle lost sender-to-


receiver words in conversation?
They repeat the undelivered messages!
Transport Layer: 3-3
rdt3.0: channels with errors and loss
Approach: sender waits “reasonable” amount of time for ACK
 retransmits if no ACK received in this time
 if pkt (or ACK) just delayed (not lost):
• retransmission will be duplicate, but seq #s already handles this!
• receiver must specify seq # of packet being ACKed
 use countdown timer to interrupt after “reasonable” amount of
time
timeout

Transport Layer: 3-4


rdt3.0 in action (Stop-and-wait version)

sender receiver sender receiver


send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack0 send ack0 ack0 send ack0
rcv ack0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
loss
ack1 send ack1
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no loss rcv pkt0
ack0 send ack0

(b) packet loss Transport Layer: 3-5


rdt3.0 in action
sender receiver
sender receiver send pkt0
pkt0
rcv pkt0
send pkt0 pkt0 send ack0
ack0
rcv pkt0 rcv ack0
ack0 send ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1 send ack1
rcv pkt1 ack1
ack1 send ack1
X timeout
loss resend pkt1
pkt1 rcv pkt1
timeout
resend pkt1 pkt1
rcv pkt1 rcv ack1 (detect duplicate)
send pkt0 pkt0 send ack1
(detect duplicate)
ack1 send ack1 ack1 rcv pkt0
rcv ack1 rcv ack1 send ack0
send pkt0 pkt0 (ignore) ack0
rcv pkt0
ack0 send ack0 pkt1

(c) ACK loss (d) premature timeout/ delayed ACK


Transport Layer: 3-6
Performance of rdt3.0 (stop-and-wait)

 U sender: utilization – fraction of time sender busy sending

 example: 1 Gbps link, 15 ms prop. delay, 8000 bit packet


• time to transmit packet into channel:
L 8000 bits
Dtrans = R = = 8 microsecs
109 bits/sec

Transport Layer: 3-7


rdt3.0: stop-and-wait operation
sender receiver
first packet bit transmitted, t = 0

first packet bit arrives


RTT last packet bit arrives, send ACK

ACK arrives, send next


packet, t = RTT + L / R

Transport Layer: 3-8


rdt3.0: stop-and-wait operation
sender receiver

L/R L/R
Usender =
RTT + L / R
.008 RTT
=
30.008
= 0.00027

 rdt 3.0 protocol performance stinks!


 Protocol limits performance of underlying infrastructure (channel)

Transport Layer: 3-9


rdt3.0: pipelined protocols operation
pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged
packets
• range of sequence numbers must be increased
• buffering at sender and/or receiver

Transport Layer: 3-10


Pipelining: increased utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R

first packet bit arrives


RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
3-packet pipelining increases
utilization by a factor of 3!

U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008

Transport Layer: 3-11


Go-Back-N: sender
 sender: “window” of up to N, consecutive transmitted but unACKed pkts
• k-bit seq # in pkt header

 cumulative ACK: ACK(n): ACKs all packets up to, including seq # n


• on receiving ACK(n): move window forward to begin at n+1
 timer for oldest in-flight packet
 timeout(n): retransmit packet n and all higher seq # packets in window
Transport Layer: 3-12
Go-Back-N: receiver
 ACK-only: always send ACK for correctly-received packet so far, with
highest in-order seq #
• may generate duplicate ACKs
• need only remember rcv_base
 on receipt of out-of-order packet:
• can discard (don’t buffer) or buffer: an implementation decision
• re-ACK pkt with highest in-order seq #
Receiver view of sequence number space:
received and ACKed

… … Out-of-order: received but not ACKed

rcv_base
Not received
Transport Layer: 3-13
Go-Back-N 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 (re)send ack1
012345678 pkt4
rcv ack1, send receive pkt4, discard,
pkt5 (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-14


Selective repeat: the approach
 pipelining: multiple packets in flight
 receiver individually ACKs all correctly received packets
• buffers packets, as needed, for in-order delivery to upper layer
 sender:
• maintains (conceptually) a timer for each unACKed pkt
• timeout: retransmits single unACKed packet associated with timeout
• maintains (conceptually) “window” over N consecutive seq #s
• limits pipelined, “in flight” packets to be within this window

Transport Layer: 3-15


Selective repeat: sender, receiver windows

Transport Layer: 3-16


Selective repeat: sender and receiver
sender receiver
data from above: packet n in [rcvbase, rcvbase+N-1]
 if next available seq # in  send ACK(n)
window, send packet  out-of-order: buffer
timeout(n):  in-order: deliver (also deliver
buffered, in-order packets),
 resend packet n, restart timer
advance window to next not-yet-
ACK(n) in [sendbase,sendbase+N-1]: received packet
 mark packet n as received packet n in [rcvbase-N,rcvbase-1]
 ACK(n)
 if n smallest unACKed packet,
advance window base to next otherwise:
unACKed seq #  ignore

Transport Layer: 3-17


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

Q: what happens when ack2 arrives?

Transport Layer: 3-18


Chapter 3: roadmap
 Transport-layer services
 Multiplexing and demultiplexing
 Connectionless transport: UDP
 Principles of reliable data transfer
 Connection-oriented transport: TCP
• segment structure
• reliable data transfer
• flow control
• connection management
 Principles of congestion control
 TCP congestion control
Transport Layer: 3-19
TCP: overview RFCs: 793,1122, 2018, 5681, 7323

 point-to-point:  cumulative ACKs


• one sender, one receiver  pipelining:
 reliable, in-order byte • TCP congestion and flow control
steam: set window size
• no “message boundaries"  connection-oriented:
 full duplex data: • handshaking (exchange of control
• bi-directional data flow in messages) initializes sender,
same connection receiver state before data exchange
• MSS: maximum segment size  flow controlled:
• sender will not overwhelm receiver

Transport Layer: 3-20


TCP segment structure
32 bits

source port # dest port # segment seq #: counting


ACK: seq # of next expected sequence number bytes of data into bytestream
byte; A bit: this is an ACK (not segments!)
acknowledgement number
length (of TCP header) head not
len used C EUAP R SF receive window flow control: # bytes
Internet checksum checksum Urg data pointer receiver willing to accept

options (variable
C, E: congestion notification length)
TCP options
application data sent by
RST, SYN, FIN: connection data application into
management (variable length) TCP socket

Transport Layer: 3-21


TCP sequence 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 data checksum


rwnd
urg pointer

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
Q: how receiver handles out-of- (“in-flight”) yet sent

order segments outgoing segment from receiver

• A: TCP spec doesn’t say, - up


source port # dest port #
sequence number

to implementor acknowledgement number


A rwnd
checksum urg pointer
Transport Layer: 3-22
TCP Sequence numbers
Sending Side:
 Seq# is the first byte number of the payload
 Len = size of the payload.

Receiving Side:
 Ack# generated by the receiver equal last byte
number in the payload it received plus 1.

 As TCP connections are full duplex, both sides


will update the seq# and Ack# fields
accordingly.
Transport Layer: 3-23
TCP sequence numbers, ACKs
Assume data = ‘C’ is only one byte long.
Host A Host B

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

simple telnet scenario Transport Layer: 3-24


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

Transport Layer: 3-25


TCP Sender (simplified)
event: data received from event: timeout
application  retransmit segment that
 create segment with seq # caused timeout
 restart timer
 seq # is byte-stream number
of first data byte in segment
event: ACK received
 start timer if not already
 if ACK acknowledges
running
• think of timer as for oldest
previously unACKed segments
unACKed segment • update what is known to be
ACKed
• expiration interval:
TimeOutInterval • start timer if there are still
unACKed segments
Transport Layer: 3-26
TCP Receiver: ACK generation [RFC 5681]

Event at receiver TCP receiver action


arrival of in-order segment with delayed ACK. Wait up to 500ms
expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK

arrival of in-order segment with immediately send single cumulative


expected seq #. One other ACK, ACKing both in-order segments
segment has ACK pending

arrival of out-of-order segment immediately send duplicate ACK,


higher-than-expect seq. # . indicating seq. # of next expected byte
Gap detected

arrival of segment that immediate send ACK, provided that


partially or completely fills gap segment starts at lower end of gap

Transport Layer: 3-27


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
timeout

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

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


SendBase=100 bytes of data send cumulative
SendBase=120 ACK for 120
ACK=100
ACK=120

SendBase=120

lost ACK scenario premature timeout

Transport Layer: 3-28


TCP: retransmission scenarios
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data


ACK=100
X
ACK=120

Seq=120, 15 bytes of data

cumulative ACK
covers for earlier
lost ACK
Transport Layer: 3-29
TCP fast retransmit
Host A Host B
TCP fast retransmit
if sender receives 3 additional
ACKs for same data (“triple Se q= 9
2, 8 by
Seq= data tes of
duplicate ACKs”), resend unACKed 100, 2
data
0 b yt e
s of
segment with smallest seq # X
 likely that unACKed segment lost,
=100
so don’t wait for timeout ACK

timeout
=100
ACK
CK =100
A
= 10 0
Receipt of three duplicate ACKs ACK

indicates 3 segments received Seq=100, 20 bytes of data

after a missing segment – lost


segment is likely. So retransmit!

Transport Layer: 3-30


Chapter 3: roadmap
 Transport-layer services
 Multiplexing and demultiplexing
 Connectionless transport: UDP
 Principles of reliable data transfer
 Connection-oriented transport: TCP
• segment structure
• reliable data transfer
• flow control
• connection management
 Principles of congestion control
 TCP congestion control
Transport Layer: 3-31
TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster than data from TCP socket


buffers
application layer removes TCP socket
data from socket buffers? receiver buffers

TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers code

from sender

receiver protocol stack

Transport Layer: 3-32


TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster than data from TCP socket


buffers
application layer removes TCP socket
data from socket buffers? receiver buffers

TCP
code

receive window
flow control: # bytes
receiver willing to accept. IP
code
It controls the window size
of the server.

from sender

receiver protocol stack

Transport Layer: 3-33


TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster than data from TCP socket


buffers
application layer removes TCP socket
data from socket buffers? receiver buffers

TCP
flow control code

receiver controls sender, so


sender won’t overflow IP
code
receiver’s buffer by
transmitting too much, too fast
from sender

receiver protocol stack

Transport Layer: 3-34


TCP flow control
 TCP receiver “advertises” free buffer
space in rwnd field in TCP header to application process
• RcvBuffer size set via socket
options (typical default is 4096 bytes) RcvBuffer buffered data
• many operating systems auto-adjust
RcvBuffer
rwnd free buffer space

 sender limits amount of unACKed


(“in-flight”) data to received rwnd TCP segment payloads

 guarantees receive buffer will not TCP receiver-side buffering


overflow

Transport Layer: 3-35


flow control: # bytes receiver willing to accept

TCP flow control


 TCP receiver “advertises” free buffer space in
receive window
rwnd field in TCP header
• RcvBuffer size set via socket options (typical
default is 4096 bytes)
• If the max payload in sent tcp segments is 1000
bytes, then sender can send at max 4 unacked
segments (Window size = 4) 8!
• Sender’s Window size for RecvBuffer = 8192?
• many operating systems auto-adjust RcvBuffer
 sender limits amount of unACKed (“in-flight”) TCP segment format

data to received rwnd


 guarantees receive buffer will not overflow
Transport Layer: 3-36
TCP 3-way handshake
Server state
serverSocket = socket(AF_INET,SOCK_STREAM)
Client state serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept()
LISTEN
clientSocket.connect((serverName,serverPort)) 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-37


Closing a TCP 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

Transport Layer: 3-38


Chapter 3: roadmap
 Transport-layer services
 Multiplexing and demultiplexing
 Connectionless transport: UDP
 Principles of reliable data transfer
 Connection-oriented transport: TCP
 Principles of congestion control
 TCP congestion control
 Evolution of transport-layer
functionality
Transport Layer: 3-39
TCP congestion control: AIMD
 approach: senders can increase sending rate until packet loss
(congestion) occurs, then decrease sending rate on loss event
Additive Increase Multiplicative Decrease
increase sending rate by 1 cut sending rate in half at
maximum segment size every each loss event
RTT until loss detected
TCP sender Sending rate

AIMD sawtooth
behavior: probing
for bandwidth

time Transport Layer: 3-40


TCP AIMD: more
Multiplicative decrease detail: sending rate is
 Cut in half on loss detected by triple duplicate ACK (TCP Reno)
 Cut to 1 MSS (maximum segment size) when loss detected by
timeout (TCP Tahoe)

Why AIMD?
 AIMD – a distributed, asynchronous algorithm – has been
shown to:
• optimize congested flow rates network wide!
• have desirable stability properties

Transport Layer: 3-41


TCP congestion control: details
sender sequence number space
cwnd

last byte
ACKed sent, but not- available but
yet ACKed not used
(“in-flight”) last byte sent

 TCP sender limits transmission: LastByteSent- LastByteAcked < cwnd


 cwnd is dynamically adjusted in response to observed
network congestion (implementing TCP congestion control)
Transport Layer: 3-42
TCP slow start
Host A Host B
 when connection begins,
increase rate exponentially
until first loss event:
one s e gm
ent

RTT
• initially cwnd = 1 MSS two segm
en ts
• double cwnd every RTT
• done by incrementing cwnd
for every ACK received four segm
ents

 summary: initial rate is


slow, but ramps up
exponentially fast time

Transport Layer: 3-43


Transport layer: Summary

 Reliable data transfer


 Transport-layer services • Losses, ACKs
• Pipelined data transfer

 Multiplexing and demultiplexing


 Connection-oriented transport: TCP

 Connectionless transport: UDP


 Principles of congestion control

 TCP congestion control

Transport Layer: 3-44

You might also like