0% found this document useful (0 votes)
7 views35 pages

Chapter 3 B

Uploaded by

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

Chapter 3 B

Uploaded by

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

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

2581

 point-to-point:  full duplex data:


 one sender, one  bi-directional data flow
receiver in same connection
 reliable, in-order byte  MSS: maximum

steam: segment size


 no “message  connection-oriented:
boundaries”  handshaking (exchange
 pipelined: of control msgs) init’s
sender, receiver state
 TCP congestion and flow
before data exchange
control set window size
 flow controlled:
 send
application & receive buffers
w rites data
application
reads data
 sender will not
sock et sock et
door
TCP TCP
door overwhelm receiver
send buffer receive buffer
segm ent

3: Transport Layer 3b-1


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 (not segments!)
U A Pnumber
head not
PSH: push data now len used
R S F rcvr window size
(generally not used) # bytes
checksum ptr urgent data
rcvr willing
RST, SYN, FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

3: Transport Layer 3b-2


TCP seq. #’s and ACKs
Seq. #’s:
Host A Host B
 byte stream
“number” of first User Seq=4
2, A C
byte in segment’s types K=79,
da t a =
‘C’ ‘C’
data host ACKs
ACKs: receipt of

C ‘C’, echoes
 seq # of next byte , d a ta = ‘
3
9 , A CK=4 back ‘C’
expected from e q =7
S
other side
 cumulative ACK host ACKs
receipt Seq=4
Q: how receiver handles of echoed 3, ACK
=80
out-of-order segments ‘C’
 A: TCP spec doesn’t
say, - up to
implementor time
simple telnet scenario

3: Transport Layer 3b-3


TCP: reliable data transfer
event: data received
from application above simplified sender, assuming
create, send segment •one way data transfer
•no flow, congestion
control
event: timer timeout for
wait
wait
segment with seq # y
for
for
event
event retransmit segment

event: ACK received,


with ACK # y
ACK processing

3: Transport Layer 3b-4


TCP: 00 sendbase = initial_sequence number
01 nextseqnum = initial_sequence number
02

reliable 03 loop (forever) {


04
05
switch(event)
event: data received from application above

data 06
07
create TCP segment with sequence number nextseqnum
start timer for segment nextseqnum
08 pass segment to IP
transfer 09
10
nextseqnum = nextseqnum + length(data)
event: timer timeout for segment with sequence number y
11 retransmit segment with sequence number y
12 compue new timeout interval for segment y
Simplified 13 restart timer for sequence number y
14 event: ACK received, with ACK field value of y
TCP 15 if (y > sendbase) { /* cumulative ACK of all data up to y */
sender 16 cancel all timers for segments with sequence numbers < y
17 sendbase = y
18 }
19 else { /* a duplicate ACK for already ACKed segment */
20 increment number of duplicate ACKs received for y
21 if (number of duplicate ACKS received for y == 3) {
22 /* TCP fast retransmit */
23 resend segment with sequence number y
24 restart timer for segment y
25 }
26 } /* end of loop forever */
3: Transport Layer 3b-5
TCP ACK generation [RFC 1122, RFC
2581]

Event TCP Receiver action


in-order segment arrival, delayed ACK. Wait up to 500ms
no gaps, for next segment. If no next segment,
everything else already ACKed send ACK

in-order segment arrival, immediately send single


no gaps, cumulative ACK
one delayed ACK pending

out-of-order segment arrival send duplicate ACK, indicating seq. #


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

arrival of segment that immediate ACK if segment starts


partially or completely fills gap at lower end of gap

3: Transport Layer 3b-6


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

Seq=9 Seq=9
2, 8 b 2, 8 b
y t es d y t es d
at a

Seq=92 timeout
at a Seq=
100,
20 b y
t es d

Seq=100 timeout
timeout

ata
100
A CK=
0
10
X CK
A AC
=
K =120
loss
Seq=9 Seq=9
2, 8 b 2, 8 b
y t es d y t es d
at a at a

=1 20
K
=10 0 AC
ACK

time time
lost ACK scenario premature timeout,
cumulative ACKs

3: Transport Layer 3b-7


TCP Flow Control
flow control receiver: explicitly
sender won’t informs sender of
overrun (dynamically
receiver’s buffers by changing) amount of
transmitting too free buffer space
much,  RcvWindow field
RcvBuffer = size or too fast Buffer
TCP Receive in TCP segment
RcvWindow = amount of spare room in Buffer sender: keeps the
amount of
transmitted, unACKed
data less than most
recently received
RcvWindow

receiver buffering
3: Transport Layer 3b-8
TCP Round Trip Time and
Timeout
Q: how to set TCP Q: how to estimate RTT?
timeout value?  SampleRTT: measured time
 longer than RTT from segment transmission
until ACK receipt
 note: RTT will vary
 ignore retransmissions,
 too short: premature
cumulatively ACKed
timeout
segments
 unnecessary
 SampleRTT will vary, want
retransmissions
estimated RTT “smoother”
 too long: slow
 use several recent
reaction to segment
measurements, not just
loss
current SampleRTT

3: Transport Layer 3b-9


TCP Round Trip Time and
Timeout
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
 Exponential weighted moving average
 influence of given sample decreases exponentially
fast
 typical value of x: 0.1
Setting the timeout
 EstimtedRTT plus “safety margin”
 large variation in EstimatedRTT -> larger safety margin

Timeout = EstimatedRTT + 4*Deviation


Deviation = (1-x)*Deviation +
x*|SampleRTT-EstimatedRTT|

3: Transport Layer 3b-10


TCP Connection Management

Recall: TCP sender, receiver Three way


establish “connection”
before exchanging data
handshake:
segments
 initialize TCP variables:
Step 1: client end system
sends TCP SYN control
 seq. #s
segment to server
 buffers, flow control info
 specifies initial seq #
(e.g. RcvWindow)
 client: connection initiator Step 2: server end system
Socket clientSocket = new receives SYN, replies with
Socket("hostname","port
SYNACK control segment
number");
 server: contacted by client
 ACKs received SYN
Socket connectionSocket =  allocates buffers
welcomeSocket.accept();  specifies server->
receiver initial seq. #
3: Transport Layer 3b-11
TCP Connection Management (cont.)

Closing a connection: client server

client closes socket: close


FIN
clientSocket.close();

Step 1: client end system


ACK
sends TCP FIN control close
segment to server FIN

Step 2: server receives FIN,

timed wait
ACK
replies with ACK. Closes
connection, sends FIN.

closed

3: Transport Layer 3b-12


TCP Connection Management (cont.)

Step 3: client receives FIN, client server


replies with ACK.
closing
FIN
 Enters “timed wait” - will
respond with ACK to
received FINs
ACK
closing
Step 4: server, receives ACK. FIN
Connection closed.

Note: with small


timed wait
ACK
modification, can handly
simultaneous FINs. closed

closed

3: Transport Layer 3b-13


TCP Connection Management
(cont)

TCP server
lifecycle

TCP client
lifecycle

3: Transport Layer 3b-14


Principles of Congestion Control

Congestion:
 informally: “too many sources sending too
much data too fast for network to handle”
 different from flow control!
 manifestations:
 lost packets (buffer overflow at routers)
 long delays (queueing in router buffers)
 a top-10 problem!

3: Transport Layer 3b-15


Causes/costs of congestion: scenario
1
 two senders, two
receivers
 one router,
infinite buffers
 no
retransmission

 large delays
when congested
 maximum
achievable
throughput

3: Transport Layer 3b-16


Causes/costs of congestion: scenario
2
 one router, finite buffers
 sender retransmission of lost packet

3: Transport Layer 3b-17


Causes/costs of congestion: scenario
2
 always:  =  (goodput)
in out
 > out
 “perfect” retransmission only when loss:
in

 retransmission of delayed (not lost) packet makes
in

larger (than perfect case) for same
out

“costs” of congestion:
 more work (retrans) for given “goodput”
 unneeded retransmissions: link carries multiple copies of
pkt 3: Transport Layer 3b-18
Causes/costs of congestion: scenario
3
 four senders

Q: what happens as
 multihop paths in

and
 timeout/retransmit in
increase ?

3: Transport Layer 3b-19


Causes/costs of congestion: scenario
3

Another “cost” of congestion:


 when packet dropped, any “upstream
transmission capacity used for that packet was
wasted!
3: Transport Layer 3b-20
Approaches towards congestion
control
Two broad approaches towards congestion
control:
End-end congestion Network-assisted
control: congestion control:
 no explicit feedback from  routers provide feedback
network to end systems
 congestion inferred from  single bit indicating
end-system observed congestion (SNA,
loss, delay DECbit, TCP/IP ECN,
 approach taken by TCP ATM)
 explicit rate sender
should send at

3: Transport Layer 3b-21


Case study: ATM ABR congestion
control
ABR: available bit RM (resource
rate: management) cells:
 “elastic service”  sent by sender, interspersed
 if sender’s path with data cells
 bits in RM cell set by switches
“underloaded”:
 sender should use (“network-assisted”)
 NI bit: no increase in rate
available bandwidth
 if sender’s path
(mild congestion)
 CI bit: congestion
congested:
indication
 sender throttled to
 RM cells returned to sender
minimum
by receiver, with bits intact
guaranteed rate

3: Transport Layer 3b-22


Case study: ATM ABR congestion
control

 two-byte ER (explicit rate) field in RM cell


 congested switch may lower ER value in cell
 sender’ send rate thus minimum supportable rate on path

 EFCI bit in data cells: set to 1 in congested switch


 if data cell preceding RM cell has EFCI set, sender sets CI bit
in returned RM cell

3: Transport Layer 3b-23


TCP Congestion Control
 end-end control (no network assistance)
 transmission rate limited by congestion window size, Congwin,
over segments:

Congwin

 w segments, each with MSS bytes sent in one


RTT:
w * MSS
throughput = Bytes/sec
RTT

3: Transport Layer 3b-24


TCP congestion control:
 “probing” for usable  two “phases”
bandwidth:  slow start
 ideally: transmit as  congestion avoidance
fast as possible  important variables:
(Congwin as large as
 Congwin
possible) without loss
 increase Congwin until
 threshold: defines
loss (congestion) threshold between
two slow start phase,
 loss: decrease
congestion control
Congwin, then begin
phase
probing (increasing)
again

3: Transport Layer 3b-25


TCP Slowstart
Host A Host B
Slowstart algorithm one s e gm
ent

RTT
initialize: Congwin = 1
for (each segment ACKed) two segm
en ts
Congwin++
until (loss event OR
four segm
CongWin > threshold) ents

 exponential increase (per RTT)


in window size (not so slow!)
 loss event: timeout (Tahoe time
TCP) and/or or three duplicate
ACKs (Reno TCP)

3: Transport Layer 3b-26


TCP Congestion Avoidance
Congestion avoidance
/* slowstart is over */
/* Congwin > threshold */
Until (loss event) {
every w segments ACKed:
Congwin++
}
threshold = Congwin/2
Congwin = 1
1
perform slowstart

1: TCP Reno skips slowstart (fast


recovery) after three duplicate ACKs
3: Transport Layer 3b-27
AIMD
TCP Fairness
TCP congestion
avoidance: Fairness goal: if N TCP
 AIMD: additive sessions share same
increase, bottleneck link, each
multiplicative should get 1/N of link
decrease capacity
 increase window by TCP connection 1
1 per RTT
 decrease window
by factor of 2 on
loss event
bottleneck
TCP
router
connection 2
capacity R

3: Transport Layer 3b-28


Why is TCP fair?
Two competing sessions:
 Additive increase gives slope of 1, as throughout increases
 multiplicative decrease decreases throughput proportionally

R equal bandwidth share


Connection 2 throughput

loss: decrease window by factor of 2


congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase

Connection 1 throughput R

3: Transport Layer 3b-29


TCP latency modeling
Q: How long does it take Notation, assumptions:
to receive an object  Assume one link between
from a Web server after client and server of rate
sending a request? R
 TCP connection  Assume: fixed congestion
establishment window, W segments
 data transfer delay  S: MSS (bits)
 O: object size (bits)
 no retransmissions (no
Two cases to consider:loss, no corruption)
 WS/R > RTT + S/R: ACK for first segment in
window returns before window’s worth of
data sent
 WS/R < RTT + S/R: wait for ACK after sending
window’s worth of data sent 3: Transport Layer 3b-30
TCP latency Modeling K:= O/WS

Case 1: latency = 2RTT + O/R Case 2: latency = 2RTT + O/R


+ (K-1)[S/R + RTT - WS/R]

3: Transport Layer 3b-31


TCP Latency Modeling: Slow Start
 Now suppose window grows according to slow start.
 Will show that the latency of one object of size O is:

O  S S
Latency 2 RTT   P  RTT    ( 2 P  1)
R  R R

where P is the number of times TCP stalls at server:

P min{Q, K  1}

- where Q is the number of times the server would stall


if the object were of infinite size.

- and K is the number of windows that cover the object.

3: Transport Layer 3b-32


TCP Latency Modeling: Slow Start (cont.)
initiate TC P
connection
Example:
request
O/S = 15 segments object
first w indow
= S /R

K = 4 windows R TT
second w indow
= 2S /R
Q=2
third w indow
= 4S /R
P = min{K-1,Q} = 2

Server stalls P=2 times.


fourth w indow
= 8S /R

com plete
object transm ission
delivered
tim e at
tim e at server
client

3: Transport Layer 3b-33


TCP Latency Modeling: Slow Start (cont.)
S
 RTT time from when server starts to send segment
R
until server receives acknowledgement
initiate TC P
connection

S
2k  1 time to transmit the kth window request
R object
first w indow
= S /R


S k 1 S 
R TT
second w indow

 R  RTT  2 stall time after the kth window = 2S /R


R 
third w indow
= 4S /R

P
O
latency   2 RTT   stallTime p
fourth w indow
= 8S /R
R p 1
P
O S S
  2 RTT   [  RTT  2k  1 ]
R k 1 R R object
com plete
transm ission
delivered
O S S
  2 RTT  P[ RTT  ]  ( 2 P  1) tim e at
tim e at
server
R R R client

3: Transport Layer 3b-34


Chapter 3: Summary
 principles behind
transport layer services:
 multiplexing/ Next:
demultiplexing  leaving the network
 reliable data transfer “edge” (application
 flow control transport layer)
 congestion control  into the network
 instantiation and “core”
implementation in the
Internet
 UDP
 TCP

3: Transport Layer 3b-35

You might also like