Documente Academic
Documente Profesional
Documente Cultură
Tom Anderson
1972
TELNET
RFC 318
1969
ARPANET
created
1970
1986
NNTP
1973
FTP
1977
MAIL
1982
TCP & IP
1984
DNS
RFC 454
RFC 733
RFC 883
1975
1980
1985
RFC 977
1990
1995
Multi-backbone
Internet
1992
MBONE
1995
Distance
Number of nodes
Performance
wire
Switch
or Hub
nodes
Hubs, switches
Inter-network:
Routers
Key tasks:
Key challenges:
Datagram forwarding
Virtual circuits
Routing goals
Compute best path
Routing alternatives
Spanning Tree (Ethernet)
B
C
A
D
E
10
B
C
A
D
E
E
1
E
F
1
F
G
11
2.
3.
B
C
A
D
E
a
XXXXX
A/2
B/1
Internet
14
A/2
B/3
XXX
Internet
update
15
A/4
B/3
XXX
Internet
update
16
A/4
B/5
XXX
Internet
update
17
18
19
Topology flooding
Each router identifies direct neighbors; put in
numbered link state packets (LSPs) and
periodically send to neighbors
20
1
10
2
5
2
21
1
10
10
2
5
5
2
22
1
8
14
5
2
23
1
8
13
5
2
24
1
8
5
2
25
1
8
5
2
26
Question
Does link state algorithm guarantee routing tables
are loop free?
27
Internet today
28
29
30
192.4.23, [3, 7]
192.4.23, [7]
31
Policy knobs
1. Selecting one of the multiple offered paths
192.168.1.3/24, [2, 4]
AS 2
AS 1
192.168.1.3/24, [3, 4]
AS 4
AS 3
192.168.1.3/24, [4, 1]
AS 4
AS 3
AS 1
192.168.1.3/24, [4, 1]
32
Customer
Customer
34
Example:
hot potato routing
35
BGP convergence
1
36
BGP Convergence
Why not link state routing in BGP?
37
BGP security
Extreme vulnerability to attacks and misconfigurations
38
Transport Challenge
IP: routers can be arbitrarily bad
Reliable Transmission
How do we send packets reliably?
Two mechanisms
Acknowledgements
Timeouts
Time
Timeout
Receiver
ACK lost
Timeout
Timeout
Timeout
Timeout
Timeout
Time
Timeout
Packet lost
Early timeout
Accept!
Reject!
Sender/Receiver State
sender
receiver
Sliding Window
Send Window
0 1
sent
acked
6
x
LFS
LAR
Receive Window
0 1
recvd
acked
NFE
6
x
LFA
Sender
Receiver
acks
Transport: Practice
Protocols
IP -- Internet protocol
UDP -- user datagram protocol
TCP -- transmission control protocol
RPC -- remote procedure call
HTTP -- hypertext transfer protocol
And a bunch more
Ports
Port is a mailbox that processes rent
Sockets
OS abstraction representing communication
endpoint
UDP Delivery
Application
process
Application
process
Application
process
Kernel
boundary
Ports
Message
Queues
DeMux
Packets arrive
1975
Three-way handshake
Raymond Tomlinson
In SIGCOMM 75
1983
BSD Unix 4.2
supports TCP/IP
1974
TCP described by
Vint Cerf and Bob Kahn
In IEEE Trans Comm
1982
TCP & IP
1986
Congestion
collapse
observed
1975
1980
1987
Karns algorithm
to better estimate
round-trip time
1985
1990
4.3BSD Reno
fast retransmit
delayed ACKs
1988
Van Jacobsons
algorithms
congestion avoidance
and congestion control
(most implemented in
4.3BSD Tahoe)
1990
1993
1994
ECN
(Floyd)
Explicit
Congestion
Notification
1994
1996
SACK TCP
(Floyd et al)
Selective
Acknowledgement
1996
Hoe
Improving TCP
startup
1996
1996
FACK TCP
(Mathis et al)
extension to SACK
2006
PCP
No message boundaries
Ports as application endpoints
Flow control
Connection setup
TCP Delivery
Application process
Application process
Write
bytes
Read
bytes
TCP
TCP
Send buffer
Receive buffer
Transmit segments
Segment
IP x.html
Segment Segment
offered window
(advertised by receiver)
usable window
1
sent and
acknowledged
10
11
12
Flow Control
What if sender process is faster than receiver
process?
Sending application
Receiving application
TCP
TCP
LastByteWritten
LastByteAcked
LastByteSent
= available buffer
LastByteRead
NextByteExpected
= buffer in use
LastByteRcvd
T=2
T=3
Stall due to
flow control
here
T=4
T=5
T=6
T=2
=acked
=sent
T=3
9
=advertised
T=4
T=5
T=6
Three-Way Handshake
Opens both directions for transfer
Active participant
(client)
Passive participant
(server)
+data
TCP Handshake in an
Uncooperative Internet
TCP Hijacking
Malicious attacker
weak form of
authentication
Server
TCP Handshake in an
Uncooperative Internet
TCP SYN flood
Malicious attacker
Server
Client
Server
HTTP on TCP
SYN
SYN+ACK
ACK
http get
ACK
http data
ACK
FIN
ACK
FIN
ACK
Bandwidth Allocation
How do we efficiently share network resources
among billions of hosts?
Congestion control
Sending too fast causes packet loss inside network ->
retransmissions -> more load -> more packet losses ->
Dont send faster than network can accept
Fairness
How do we allocate bandwidth among different users?
Each user should (?) get fair share of bandwidth
Congestion
Router
1.5-Mbps T1 link
Destination
Source
2
Fairness
Source
1
Router
Destination
1
Router
Source
2
Router
Destination
2
Source
3
The Problem
Original TCP sent full window of data
When links become loaded, queues fill up, and this
can lead to:
Slow start
quickly identify bottleneck capacity
Fast retransmit
Fast recovery
Additive increase
TCP Sawtooth
Oscillates around bottleneck bandwidth
Slow start
How do we find bottleneck bandwidth?
Slow Start
Quickly find the bottleneck bandwidth
Source
Router
100 Mbps
0.9 ms latency
Dest
10 Mbps
0 latency
80
Short flows
Sender
Receiver
acks
5
Timeout
2
1
1
1
1
2
5
Fast Retransmit
1
3
5
1
1
1
2
TCP Tahoe
Fast Retransmit
Slow Start + Congestion Avoidance + Fast
Retransmit
18
16
14
12
window 10
(in segs)
8
6
4
2
0
0
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
round-trip times
Fast Recovery
1
3
5
2
1
1
1
1
2
3
Fast Recovery
Slow Start + Congestion Avoidance + Fast
Retransmit + Fast Recovery
18
16
14
12
window 10
(in segs)
8
6
4
2
0
0
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
round-trip times
Why AIMD?
Two users competing for
bandwidth:
RTT?
Loss rate?
Packet size?
Receive window?
94
95
96
Bandwidth (Kbps)
median
average
2.5
7.5
10 12.5 15
Persistent connections
101
How?
102
buffer size
queueing discipline (FIFO, round robin, priorities)
drop policy -- Random Early Drop (RED)
Early congestion notification (ECN)
Weighted fair queueing
Explicit rate control
TCP Synchronization
Assumption for TCP equilibrium proof is that
routers drop fairly
What if routers buffers are always full?
Congestion Avoidance
TCP causes congestion as it probes for the
available bandwidth and then recovers from it
after the fact
Av erage
Tim e
MinThreshold
AvgLen
Incentive issue:
Flows jostle each other and hosts must play by the rules
Routers dont discriminate traffic from different sources
Fair Queuing
Flow 1
Flow 2
Round-robin
service
Flow 3
Flow 4
WFQ implication
What should the endpoint do, if it knows router is
using WFQ?
113
Traffic shaping
At enterprise edge, shape traffic:
Mechanism?
114
Window
loss
loss
loss
Channel
Capacity
Wasted capacity
Time
Observation
Question
Can endpoint congestion control be near optimal
with no change to the network?
Assume: cooperating endpoints
Probe is a request
Successful probe sets the sending rate
Rate
Probe
Time
Probe
Channel
Capacity
Probes
Send packet train spaced to mimic desired rate
Check packet dispersion at receiver
Successful probe:
Bottleneck Link
Sender
Receiver
Failed probe:
Sender
Receiver
}
}
Cross traffic
Dispersion
Probabilistic Accept
Randomly generate a slope consistent with the
observed data
time
Rate Compensation
Queues can still increase:
PCP solution
TCP Compatibility
TCP increases its rate regardless of queue size
Performance
User-level implementation
Percentage of flows
80
60
PCP
40
4-PCP
TCP
20
0
0
Transfer Time
Is PCP Cheating?
2000
1500
TCP w/4-PCP
TCP
1000
4-PCP
PCP
500
0
0
200
400
600
800
1000
Simple to build,
Weak assurances
Complex to build,
Strong assurances
Congestion
Avoid ance
Weighted Fair
Qu eu ing
Aggregate
Gu arantees
Differentiated
Services
Per Flow
Gu arantees
Integrated Services
Sampler,
A D
converter
Internet
Buffer,
D A
Speaker
Delay
Loss
Packets (%)
99%
50
100
Delay (milliseconds)
150
200
Sequence number
Packet
arrival
Packet
generation
Network
delay
Playback
Buffer
Time
Buffer before playout so that most late samples will have arrived
Bandwidth (MBps)
Flow A
Time (seconds)
Same average, but very different needs over time. One number. So how
do we describe bandwidth to the network?
Token Buckets
Common, simple descriptor
Use tokens to send bits
Average bandwidth is R bps
Maximum burst is B bits
Fill rate R
tokens/sec
Bucket size
B tokens
Sending
drains
tokens
2.
3.
4.
Sender 1
PATH
R
Sender 2
PATH
RESV
(merged) R
RESV
R
Receiv er A
RESV
Receiv er B
RSVP Issues
RSVP is receiver-based to support multicast apps
Only want to reserve resources at a router if they
are sufficient along the entire path
What if there are link failures and the route
changes?
What if there are sender/receiver failures?
Two-Tiered Architecture
Mark at Edge routers
(per flow state,
complex)
Core routers
stay simple
(no per-flow state,
few classes)
DiffServ Issues
How do ISPs provision?
Deploying QOS: