Download lecture - CUNY.edu

outline
 TCP
 segment structure
 reliable data transfer
 flow control
 congestion control
Transport Layer
3-1
TCP Flow Control
 receive side of TCP
connection has a
receive buffer:
(currently)
TCP data application
IP
unused buffer
(in buffer)
process
datagrams
space
flow control
sender won’t overflow
receiver’s buffer by
transmitting too much,
too fast
 speed-matching
service: matching
send rate to receiving
application’s drain rate
 app process may be
slow at reading from
buffer
Transport Layer
3-2
TCP Flow control: how it works
(currently)
TCP data application
IP
unused buffer
(in buffer)
process
datagrams
space
rwnd
RcvBuffer
(suppose TCP receiver
discards out-of-order
segments)
 unused buffer space:
 receiver: advertises
unused buffer space by
including rwnd value in
segment header
 sender: limits # of
unACKed bytes to rwnd

guarantees receiver’s
buffer doesn’t overflow
= rwnd
= RcvBuffer-[LastByteRcvd LastByteRead]
Transport Layer
3-3
Next: Principles of Congestion Control
Transport Layer
3-4
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 (queuing in router buffers)
Transport Layer
3-5
Causes/costs of congestion
Q: what happens as number of
senders increase?
 four senders
 multihop paths
 Loss/timeout/retransmit
Host A
lin : original data
lout
l'in : original data, plus
retransmitted data
finite shared output
link buffers
Host B
Transport Layer
3-6
TCP congestion control: cwnd
 goal: TCP sender should transmit as fast as possible,
but without congesting network

Q: how to find rate just below congestion level
 each TCP sender sets its own rate, called congestion
window (cwnd) based on implicit feedback:
 ACK: segment received (a good thing!),
 network not congested
 so increase sending rate
 lost segment: assume loss due to congested
network, so decrease sending rate
Transport Layer
3-7
TCP Slow Start
Host B
RTT
Host A
time
Transport Layer
3-8
TCP: congestion avoidance
Increasing sending rate:
 How far would the
doubling of cwnd go?
 Till, it reaches a
threshold
 After that it increases
linearly
What if a loss happens?
 Decrease sending rate
 Set the threshold
value to half of
current cwnd
 loss: decrease cwnd to
1 and start the slowstart again
Transport Layer
3-9
cwnd window size (in segments)
Popular “flavors” of TCP
TCP Reno
ssthresh
ssthresh
TCP Tahoe
Transmission round
Transport Layer 3-10
Summary: TCP Congestion Control
 when cwnd < ssthresh, sender in slow-start
phase, window grows exponentially.
 when cwnd >= ssthresh, sender is in congestion-
avoidance phase, window grows linearly.
 when loss/timeout occurs, ssthresh set to
cwnd/2, cwnd set to 1
Transport Layer
3-11
UDP
 multimedia apps often do not use TCP
 do not want rate throttled by congestion control
 instead use UDP:
 pump audio/video at constant rate, tolerate packet loss
Transport Layer 3-12
UDP: User Datagram Protocol [RFC 768]
 “no frills,” “bare bones”
Internet transport
protocol
 “best effort” service, UDP
segments may be:
 lost
 delivered out of order
to app
 connectionless:
 no handshaking between
UDP sender, receiver
 each UDP segment
handled independently
of others
Why is there a UDP?
 no connection
establishment (which can
add delay)
 simple: no connection state
at sender, receiver
 small segment header
 no congestion control: UDP
can blast away as fast as
desired
Transport Layer 3-13
UDP: more
 often used for streaming
multimedia apps
 loss tolerant
 rate sensitive
Length, in
bytes of UDP
segment,
including
header
 other UDP uses
 DNS
 SNMP
 reliable transfer over UDP:
add reliability at
application layer
 application-specific
error recovery!
32 bits
source port #
dest port #
length
checksum
Application
data
(message)
UDP segment format
Transport Layer 3-14