Download Congestion control/Flow control

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

CAN bus wikipedia , lookup

Deep packet inspection wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Buffer overflow wikipedia , lookup

IEEE 1355 wikipedia , lookup

Internet protocol suite wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

UniPro protocol stack wikipedia , lookup

TCP congestion control wikipedia , lookup

Transcript
Outline
 TCP
 Congestion control
 Flow control
Transport Layer
3-1
Principles of Congestion Control
Congestion:
 informally: “too many sources sending too much
data too fast for network to handle”
 manifestations:
lost packets (buffer overflow at routers)
 long delays (queuing in router buffers)

Transport Layer
3-2
Causes/costs of congestion: scenario 1
 two senders, two
receivers
 one router,
infinite buffers
Host B
Host A
lout
lin : original data
unlimited shared output
link buffers
 large delays
when congested
Transport Layer
3-3
Causes/costs of congestion: scenario 2
 one router, finite buffers
 sender retransmission of lost packet
Host A
Host B
lin : original
data
l'in : original data, plus
retransmitted data
lout
finite shared output
link buffers
Transport Layer
3-4
Causes/costs of congestion: scenario 3
 four senders
 multihop paths
 timeout/retransmit
Q: what happens as number of
senders increase?
Host A
lin : original data
lout
l'in : original data, plus
retransmitted data
finite shared output
link buffers
Host B
Transport Layer
3-5
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-6
TCP Slow Start
Host B
RTT
Host A
time
Transport Layer
3-7
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-8
cwnd window size (in segments)
Popular “flavors” of TCP
TCP Reno
ssthresh
ssthresh
TCP Tahoe
Transmission round
Transport Layer
3-9
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-10
TCP Congestion Control
 Numerical example: Assume TCP Tahoe
 Initial ssthreshold = 14
 First loss occurrence after 9 transmissions. What
would be the current congestion window and
ssthreshold?
Transport Layer
3-11
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-12
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-13
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-14
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-15
UDP: more
 often used for streaming
multimedia apps
 loss tolerant
 rate sensitive
Length, in
bytes of UDP
segment,
including
header
32 bits
source port #
dest port #
length
checksum
Application
data
(message)
UDP segment format
Transport Layer 3-16