Telecomunicazioni - Sapienza
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
University of
Roma “Sapienza”
Telecomunicazioni
Docente: Andrea Baiocchi
DIET - Stanza 107, 1° piano palazzina “P. Piga”
Via Eudossiana 18
E-mail: andrea.baiocchi@uniroma1.it
Corso di Laurea in Ingegneria Gestionale
a.a. 2017/2018
Optimization…
Optimum is hard to achieve; near optimum is usually good
enough.
[proverb]
Non faciunt meliorem equum aurei freni.
[latin proverb]
Aliud aliis videtur optimum.
[M.T. Cicerone]
Tout est pour le mieux dans le meilleur des mondes possible.
[“Candide”, Voltaire]
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiProgramma
1. SERVIZI E RETI DI TELECOMUNICAZIONE
2. ARCHITETTURE DI COMUNICAZIONE
3. MODI DI TRASFERIMENTO
4. FONDAMENTI DI COMUNICAZIONI
5. MULTIPLAZIONE E ACCESSO MULTIPLO
6. LO STRATO DI COLLEGAMENTO
7. LO STRATO DI RETE IN INTERNET
8. LO STRATO DI TRASPORTO IN INTERNET
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Part of the slides are adapted
from companion material of
Chapter 3 (Transport layer) of the
book:
Computer Networking: A Top Down
Approach
4th edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2007.
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiOutline
● 3.1 Transport-layer services
● 3.2 Multiplexing and demultiplexing
● 3.3 Connectionless transport: UDP
● 3.4 Connection-oriented transport: TCP
● 3.5 Principles of congestion control
● 3.6 TCP congestion control
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Application architectures
● Client-server
● Peer-to-peer (P2P)
● Hybrid of client-server and P2P
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiClient-server architecture
server:
● always-on host
● permanent IP address
● server farms for scaling
clients:
● communicate with server
client/server
● may be intermittently
connected
● may have dynamic IP
addresses
● do not communicate directly
with each other
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Pure P2P architecture
● no always-on server
● arbitrary end systems
directly communicate
● peers are intermittently peer-peer
connected and change IP
addresses
Highly scalable but
difficult to manage
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiHybrid of client-server and P2P
Skype
● voice-over-IP P2P application
● centralized server: finding address of remote party:
● client-client connection: direct (not through server)
Instant messaging
● chatting between two users is P2P
● centralized service: client presence detection/location
● user registers its IP address with central server
when it comes online
● user contacts central server to find IP addresses
of buddies
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
What transport service does an
application need?
Data loss Throughput
● some apps (e.g., audio) can ● some apps (e.g.,
tolerate some loss multimedia) require
● other apps (e.g., file minimum amount of
transfer, ssh) require 100% throughput to be
“effective”
reliable data transfer
Delays and timing ● other apps (“elastic apps”)
make use of whatever
● some apps (e.g.,
throughput they get
Internet telephony,
interactive games) Security
require low delay to be ● Authentication,
“effective” encryption, data integrity,
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi …Transport service requirements of
common applications
Application Data loss Throughput Time Sensitive
file transfer no loss elastic no
e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
instant messaging no loss elastic yes and no
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Processes communicating
● Process: program running within Client process:
a host.
● within same host, two processes
process that initiates
communicate using inter-process communication
communication (defined by OS).
Server process:
● processes in different hosts
communicate by exchanging process that waits to be
messages contacted
● to receive messages, process ● Note: applications with
must have identifiers P2P architectures have
client processes &
● host device has unique 32-bit IP
server processes
address
● Q: does IP address of host
suffice for identifying the
process?
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiAddressing processes
● A: No, many processes can be running on same host
● identifier includes both IP address and port numbers
associated with process on host.
● Example port numbers:
● HTTP server: 80
● Mail server: 25
● to send HTTP message to gaia.cs.umass.edu web server:
● IP address: 128.119.245.12
● Port number: 80
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Socket
● process sends/receives messages to/from its socket
● socket analogous to door
● sending process relies on transport infrastructure on other side
of door which brings message to socket at rcv process
● socket: service access point between application process
and end-end-transport protocol (UCP or TCP)
controlled by
controlled by
process process application
application
socket developer
developer socket
controlled by TCP with
TCP with controlled by
operating buffers, buffers, operating
internet system
system variables variables
host or host or
server server
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiInternet transport protocols services
TCP service: UDP service:
● connection-oriented: setup ● unreliable data transfer
required between client and between sending and
server processes receiving process
● reliable transport between ● does not provide: connection
sending and receiving process setup, reliability, flow
● flow control: sender won’t control, congestion control,
overwhelm receiver timing, throughput
● congestion control: throttle guarantee, or security
sender when network overloaded
● does not provide: timing, minimum
throughput guarantees, security
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Internet apps: application and
transport protocols
Application Underlying
Application layer protocol transport protocol
e-mailSMTP [RFC 2821] TCP
remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transferFTP [RFC 959] TCP
streaming multimedia HTTP (eg Youtube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) typically UDP
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiTransport vs. network layer
● network layer: logical communication
between hosts
● transport layer: logical communication
between processes
● relies on and enhances network layer services
● more than one transport protocol available to
applications
● Internet: TCP and UDP
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Outline
● 3.1 Transport-layer services
● 3.2 Multiplexing and demultiplexing
● 3.3 Connectionless transport: UDP
● 3.4 Connection-oriented transport: TCP
● 3.5 Principles of congestion control
● 3.6 TCP congestion control
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiMultiplexing/demultiplexing
Demultiplexing at rcv host: Multiplexing at send host:
delivering received segments gathering data from multiple
to correct socket sockets, enveloping data with
header (later used for
demultiplexing)
= socket = process
application P3 P1
P1 application P2 P4 application
transport transport transport
network network network
link link link
physical physical physical
host 2 host 3
host 1
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
How demultiplexing works
● host receives IP datagrams
● each datagram has 32 bits
● source IP address source port # dest port #
● destination IP address
● each datagram carries 1 other header fields
transport-layer segment
● each segment has application
● Source port number data
● Destination port number (message)
● host uses IP addresses & port
numbers to direct segment to TCP/UDP segment format
appropriate socket
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiConnectionless demultiplexing
● Create sockets with port numbers:
DatagramSocket mySocket1 = new DatagramSocket(12534);
DatagramSocket mySocket2 = new DatagramSocket(12535);
● UDP socket identified by two-tuple:
(dest IP address, dest port number)
● When host receives UDP segment:
● checks destination port number in segment
● directs UDP segment to socket with that port number
● IP datagrams with different source IP addresses and/
or source port numbers directed to same socket
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
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
Server
DP: 6428 Client
IP: A IP: C IP:B
SP provides “return address”
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiConnection-oriented demux
● TCP socket identified by 4-tuple:
● source IP address
● source port number
● dest IP address
● dest port number
● rcv host uses all four values to direct segment to
appropriate socket
● Server host may support many simultaneous TCP sockets:
● each socket identified by its own 4-tuple
● e.g. Web servers have different sockets for each connecting
client
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Connection-oriented demux (cont)
P4
P1 T3 T2 T1 P2 P1P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157 SP: 9157
client DP: 80
server
DP: 80 Client
S-IP: A S-IP: B
IP: A D-IP:C IP: C D-IP:C
IP:B
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiOutline
● 3.1 Transport-layer services
● 3.2 Multiplexing and demultiplexing
● 3.3 Connectionless transport: UDP
● 3.4 Principles of reliable data transfer
● 3.5 Connection-oriented transport: TCP
● 3.6 Principles of congestion control
● 3.7 TCP congestion control
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
UDP: User Datagram Protocol
[RFC 768]
● “no frills,” “bare bones”
Internet transport Why is there a UDP?
protocol ● no connection establishment
● “best effort” service, UDP (which can add delay)
segments may be: ● simple: no connection state
● lost at sender, receiver
● delivered out of order to app
● small segment header
● no congestion control: UDP
● connectionless:
can blast away as fast as
● no handshaking between UDP desired
sender, receiver
● each UDP segment handled
independently of others
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiUDP datagram
● often used for streaming
multimedia apps 32 bits
● loss tolerant Length, in source port # dest port #
● rate sensitive bytes of UDP length checksum
segment,
● other UDP uses including
header
● DNS
Application
● reliable transfer over
data
UDP: add reliability at
(message)
application layer
● application-specific
UDP segment format
error recovery!
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Outline
● 3.1 Transport-layer services
● 3.2 Multiplexing and demultiplexing
● 3.3 Connectionless transport: UDP
● 3.4 Connection-oriented transport: TCP
● 3.5 Principles of congestion control
● 3.6 TCP congestion control
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiTCP: Overview
RFCs: 793, 1122, 1323, 2018, 2581
● point-to-point: ● full duplex data:
● one sender, one receiver ● bi-directional data flow in
same connection
● connection-oriented: ● MSS: maximum segment
● handshaking (exchange of size
control msgs) init’s sender, ● flow controlled:
receiver state before data
exchange
● sender will not overwhelm
receiver
● reliable, in-order, ● congestion controlled:
pipelined byte stream
● Adaptive sender window
data transfer:
● no “message boundaries”
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
TCP segment structure
32 bits
URG: urgent data counting
(generally not used)
source port # dest port #
by bytes
sequence number
ACK: ACK # of data
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UA P R S F Receive window
# bytes
(generally not used) checksum Urg data pnter
rcvr willing
RST, SYN, FIN: Options (variable length) to accept
connection estab
(setup, teardown
commands) application
Internet data
checksum (variable length)
(as in UDP)
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiTCP reliable data transfer
● TCP creates rdt service on top of IP’s unreliable service
● Pipelined segments
● Cumulative acks
● TCP uses single retransmission timer
● Retransmissions are triggered by:
● timeout events
● duplicate acks
● Time-out period often relatively long: retx delay can be
reduced if lost segments are detected via duplicate ACKs.
● Sender often sends many segments back-to-back
● If segment is lost, there will likely be many duplicate ACKs.
● If sender receives 3 ACKs for the same data, it supposes that
segment after ACKed data was lost:
● fast retransmit: resend segment before timer expires
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
TCP features
● Retransmission scenarios
● Time-out estimation (RTO)
● Flow control
● Connection management
● Nagle’s algorithm
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiTCP: 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
a
timeout
ta
=100
ACK
00
X K =1 120
AC ACK=
loss
Seq=9 Seq=9
2, 8 b 2, 8 b
ytes d Sendbase ytes d
ata ata
Seq=92 timeout
= 100
SendBase
0
= 120 K =12
=100 AC
ACK
SendBase
SendBase
= 100
= 120 premature timeout
time time
lost ACK scenario
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
TCP: retransmission scenarios
Host A Host B
Seq=9
2, 8 b
ytes d
ata
=100
timeout
Seq=1 ACK
00, 20
bytes
data
X
loss
SendBase =120
ACK
= 120
time
Cumulative ACK scenario
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi(a) Ambiente del livello di data link
(b) Ambiente del livello di trasporto
34 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
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
● but RTT varies until ACK receipt
● too short: premature
● ignore retransmissions
timeout ● SampleRTT will vary, want
● unnecessary estimated RTT “smoother”
retransmissions ● average several recent
● too long: slow reaction measurements, not just
to segment loss current SampleRTT
● Add margin to account for
SampleRTT fluctuations
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiTCP Round Trip Time and Timeout
EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT
● Exponential weighted moving average
● influence of past sample decreases exponentially fast
● typical value: α = 0.125
DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT|
● Estimate of standard deviation
● typical value: β = 0.25
TimeoutInterval = EstimatedRTT + 4*DevRTT
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Example RTT estimation
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
300
250
RTT (milliseconds)
200
150
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
SampleRTT Estimated RTT
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiFlow control vs congestion control
38 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
TCP Flow Control
● receive side of TCP connection has a receive buffer
● speed-matching service: matching the send rate to
the receiving app’s drain rate
● app process may be slow at reading from buffer
flow control
sender won’t overflow receiver’s buffer
by transmitting too much, too fast
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiTCP Flow control: how it works
● Rcvr advertises spare room by including value of
RcvWindow in segments
● Sender limits unACKed data to RcvWindow
● guarantees receive buffer doesn’t overflow
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Flow control: example
Finestra iniziale 1400 ottetti Pronto a ricevere 1400 ottetti
1000 1001 2400 2401 SN = 10 1000 1001 2400 2401
01 (200)
SN = 12
01 (400)
Ricevuti 600 ottetti
1000 1601 2400 2401 disponibilità per altri 1000 ottetti
SN = 16
01 (200)
1600 1601 2600 2601
SN = 18
1000 2001 2400 2401 01 (200) 000 Ricevuti ulteriori 400 ottetti
=1
1 ;W
60 1600 1601 2001 2600 2601
Finestra incrementata di 200 ottetti A =1
1600 1601 2001 2600 2601
SN = 20
01 (200)
Finestra esaurita SN = 22
01 (200)
1600 1601 2600 2601 SN = 24
01 (200)
Ricevuti ulteriori 600 ottetti
disponibilità per altri 1400 ottetti
Finestra incrementata di 1400 otteti ; W = 14
00 2600 2601 4000 4001
A = 2601
2600 2601 4000 4001
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiTCP Connection Management
● TCP “connection” is established before exchanging data
segments to initialize TCP variables:
● seq. #s
● buffers, flow control info (e.g. RcvWindow)
Three way handshake:
Step 1: client host sends TCP SYN segment to server
● specifies initial seq #
● no data
Step 2: server host receives SYN, replies with SYNACK segment
● server allocates buffers
● specifies server initial seq. #
Step 3: client receives SYNACK, replies with ACK segment, which may
contain data
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Instaurazione di una connessione TCP
(a) caso normale; (b) instaurazione simultanea da entrambi i lati.
43 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi!45
Purposes of 3-way handshake of TCP
● It allows a server to test that the client really is at the address it
claims to be using.
● It synchronizes use of sequence numbers.
● It has come to be used by middleboxes (including NATs and firewalls)
to initiate storage of connection state.
It allows
●
nal, but has not been the two
fully edited. endpoints
Content to prior
may change agree on the
to final use of Citation
publication. protocol options. DOI
information:
4.2375213, IEEE
● It Communications
allows both Surveys & Tutorials
endpoints to estimate the current round trip time
before sending data. 11
● It allows a connection to detect congestive loss in each direction using
an off-path a minimal size packet.
en the end-● It allows
TCP but hasconnection
not been fully edited.initialisation
the client to
n accepted for publication in a future issue of this journal,
shut
10.1109/COMST.2014.2375213, IEEE down any duplicate
Communications connections the server
Content may change prior to final publication. Citation information: DO
Surveys & Tutorials
without
ignalling to unwittingly opens in cases when a client’s opening packet with TFO was duplicated.
11
[67]). Once
ischecks
can incurare TCP
latency communicating with an off-path TFO TCP connection initialisation
le.
) to This
discovercan a viable candidate
1 RTT path between the end- 1 RTTwithout
e.g. Session Initiation Protocol (SIP [66]), signalling to with TFO
e delay can
nteractive Connection Establishment (ICE [67]). Once
l before
candidates theare discovered, connectivity checks are TCP !46
TFO
diatoflow, thisthat a candidate path is viable. This can
TFO -
delayTCP[68]. The Fast delay can Open
determine 1 RTT 1 RTT
nnotappreciable
or a flow
been tohandshaking
fully edited. Content may change prior to final publication. Citation information: DOI
gated by starting ICE connectivity
EEE Communications Surveys & Tutorials checks before the
SIP, instead
ng completes negotiation to set up the media flow, this
11
didate
discovery paths
can reduce the overall latency for a flow to
ome
nththedelays
media can also be mitigated using P2PSIP, instead
ntral SIP server [69]. When multiple candidate
TCP connection laterpaths
initialisation resumed connection
re potential
d- ICE may be used to minimize latency on the media
nd,
without with TFO TFOlater resumed connection
istocan incur additional delay, waiting for more potential
ce to be validated). 0 RTT TFO
tes
f-path relay
re cases the
TCP 0 RTT
me TCPresultant path requires an off-path
1 RTT TFO relay TCP
ersal
an Using
1 RTT
n application layer intermediary, e.g. Traversal
1 RTT Using 1 RTT
an
media relay
around NAT (TURN [70]). A TURN media relay
he
ypackets
his pathtoand follow a longer than necessary path and
dditional latency in the media/data path [68, 69]. Well-
,to69].relays
media Well- (e.g. at network borders) can significantly
ad
ignificantlyof routing over a longer path. TURN
time
the overhead
hs
time
so
ath.be TURN
used to impose a policy, e.g. in a corporate
dia
ment. legend: a loop around multiple arrows represents
later resumed connection
aial corporate
ast opening of TCP connections TFO
messages that can be sent in the same packet
legend: a loop around multiple arrows represents
current TCP standard requires a TCP0 connection
RTT to Fig. 7. TCP Fast Open (TFO) saves a round trip when resuming a connection.
ay TCP messages that can be sent in the same packet
th a three-way
1 RTT handshake that adds a round trip of
ng
efore the server can receive any request data.
ay
nnection to Fig.handshake
traditional three-way
nd 7. TCP Fastserves
Openmultiple
(TFO)pur-
saves This
a round tripawhen
allows serverresuming
to verifyathat connection.
an earlier valid handshake
und
not
ll- all trip
of of
which were originally intended: had been completed. A client that sends an opening (SYN)
ta. a server to test that the client really is at the packet with a TFO cookie can include application data in that
allows
ly
time
dress it claims to be using;
RN packet, which the receiving endpoint can pass straight to the
ultiple pur- This allows
synchronizes use of sequence numbers;
ate a server to verify that an(represented
application earlier validby thehandshake
loop1 in Fig. 7 joining the SYNLa macchina a stati finiti per la gestione di
una connessione TCP
● La linea continua
spessa è il
percorso normale
per un client.
● La linea
tratteggiata
spessa è il
percorso normale
per un server.
● Le linee sottili
rappresentano
eventi insoliti.
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
TCP connection setup and closing
client server client server
Setup data
close
channel SYN FIN
from client
Setup
to server K
SY NAC data ACK
close
channel FIN
ACK from
server to
timed wait
ACK
client
Connection
established
closed
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiNagle’s algorithm (RFC 896)
if there is new data to send
● if the window size >= MSS and available data
is >= MSS
● send complete MSS segment now
● else
● if there is unconfirmed data still in the pipe
● enqueue data in the buffer until an acknowledge is
received
● else
● send data immediately
● end if
● end if
end if
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Outline
● 3.1 Transport-layer services
● 3.2 Multiplexing and demultiplexing
● 3.3 Connectionless transport: UDP
● 3.4 Connection-oriented transport: TCP
● 3.5 Principles of congestion control
● 3.6 TCP congestion control
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiPrinciples 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)
● related to “fairness” concept
● a top-10 problem!
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Causes/costs of congestion: scenario 1
Host A
λin : original data λout
● two senders, two
receivers unlimited shared output
Host B
one router, infinite
link buffers
●
buffers
● no retransmission
● large delays
when congested
● maximum
achievable
throughput
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiCauses/costs of congestion: scenario 2
● one router, finite buffers
● sender retransmission of lost packet
Host A λin : original data λout
λ'in : original data, plus
retransmitted data
Host B finite shared output
link buffers
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Causes/costs of congestion: scenario 3
● four senders Q: what happens as λ and
in
● multihop paths λ increase ?
in
● timeout/retransmit
Host A λout
λin : original data
λ'in : original data, plus
retransmitted data
finite shared output
link buffers
Host B
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiCauses/costs of congestion: scenario 3
Ho λ
st
A o
ut
Ho
st
B
Another “cost” of congestion:
● when packet dropped, any “upstream” transmission
capacity used for that packet was wasted!
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Goodput e ritardo in funzione del
traffico inviato
55 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiApproaches for congestion control
● REACTIVE
● probe the network by pushing more and more traffic in
● detect congestion (e.g., packet loss)
● react by throttling the source
● PROACTIVE
● At connection set-to send TRAFFIC_SPEC
● Allocate resources along the path, if available, else deny
connection
● Check source traffic against TRAFFIC_SPEC (policing)
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Reactive congestion control: how?
● Two broad approaches to realize reactive
congestion control:
● End-end congestion control
● no explicit feedback from network
● congestion inferred from end-system observed loss, delay
● approach taken by TCP
● Network-assisted congestion control
● routers provide feedback to end systems
● single bit indicating congestion (e.g., TCP/IP ECN)
● explicit rate sender should send at
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiSegnali di alcuni protocolli di controllo
della congestione
59 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Outline
● 3.1 Transport-layer services
● 3.2 Multiplexing and demultiplexing
● 3.3 Connectionless transport: UDP
● 3.4 Principles of reliable data transfer
● 3.5 Connection-oriented transport: TCP
● 3.6 Principles of congestion control
● 3.7 TCP congestion control
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiTCP congestion control
● Sending rate of TCP entity is controlled by the tx
window
WTX = min{Rcv_wnd,cwnd*MSS}
● For a window size of W, full rate is R=W/RTT
● cwnd = congestion window is an internal variable of TCP
sending entity; it is measured in MSS units
● MSS = Maximum Segment Size, negotiated at connection
setup, max length of a segment in bytes
● Basic idea
● EXPAND cwnd to grab more capacity
● SHRINK cwnd if congestion detected
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
!62
The TCP entities point of view
TCP sender TCP receiver
TCP connection
IP IPUna raffica di pacchetti da una sorgente e
l’ack clock di ritorno.
62 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Bottleneck model
Data Bottleneck
segments link
cwnd
TCP ACKs TCP
sender receiver
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiCongestion avoidance (AIMD)
● Approach: increase transmission rate (window size),
probing for usable bandwidth, until loss occurs
● additive increase: increase cwnd by 1 MSS every RTT
until loss detected
● Increase cwnd by 1 when cwnd segments have been acked
● multiplicative decrease: cut cwnd in half after loss
congestion
● But cnwd drops to 1window
MSS if timeout occurs.
congestion window size
24 Kbytes
Saw tooth
16 Kbytes
behavior: probing
for bandwidth
8 Kbytes
time
time
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Slow Start
● When connection begins,
cwnd = 1 MSS Host A Host B
● Example: if MSS = 1500 one segm
ent
bytes & RTT = 200 msec,
RTT
then initial rate is 60 kbps
two segm
● Available bandwidth may be ents
>> MSS/RTT
● desirable to quickly ramp up four segm
to respectable rate ents
● When connection begins,
increase rate exponentially
fast until first loss event
time
● cwnd is increased by one on
every ACK
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiSlow start threshold (ssthresh) Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi CC in TCP Tahoe 66 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012 Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
CC in TCP Reno
67 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
TCP sender congestion control
State Event TCP Sender Action Commentary
Slow Start ACK receipt for cwnd = cwnd + MSS, Resulting in a doubling of
(SS) previously If (cwnd > ssthresh) CongWin every RTT
unacked data set state to “CA”
Congestion ACK receipt for cnwd = cwnd+MSS/cwnd Additive increase, resulting in
Avoidance previously increase of CongWin by 1
(CA) unacked data MSS every RTT
SS or CA Loss event ssthresh = cwnd/2, Fast recovery, multiplicative
detected by triple cwnd = ssthresh, decrease. cwnd will not drop
duplicate ACK Set state to “CA” below 1 MSS.
SS or CA Timeout ssthresh = cwnd/2, Enter slow start
cwnd = 1 MSS,
Set state to “SS”
SS or CA Duplicate ACK Increment duplicate ACK cwnd and ssthresh not
count for segment being changed
acked
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiTCP throughput (1/2)
● What’s the average throughout of TCP?
● Ignore slow start
TH = averageW / averageRTT
● Let Wloss be the window size when loss occurs.
● Wloss=C*T+B, with C bottleneck capacity,
B=bottleneck buffer size, T=RTTbase
● Just after loss, window drops to Wini=Wloss/2
● Average W = (Wini+Wloss)/2 = 3Wloss/4
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
TCP throughput (2/2)
● The RTT when loss occurs is T+B/C
● The RTT just after loss, when the congestion
window is halved, is T (if the buffer empties)
● Average RTT = (T+T+B/C)/2 = T+B/(2C)
B
W 0.75(CT + B) 1+ CT
TH = = B
= 1.5 B
RT T T + 2C 2+ CT
● Full capacity if B=CT
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiOutput fairness
● Output fairness: same values of throughput
● Many different definitions for fairness
● Proportional fairness
● Max-min fairness
TCP connection 1
bottleneck
TCP
router
connection 2
capacity R
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
Allocazione di banda max-min per
quattro flussi
56 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea BaiocchiLa variazione dell’allocazione di banda nel tempo
57 Tanenbaum, Wetherall, Reti di calcolatori © Pearson 2012
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi
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
Telecomunicazioni - a.a. 2017/2018 - Prof. Andrea Baiocchi!77
A 40 anni ci si sente
finalmente davvero giovani…
!78
A 40 anni ci si sente
finalmente davvero giovani…
..ma è troppo tardi! ;)You can also read
