Transcript 18-MidIIRev_1 - Computer Science Division

EECS 122:
Introduction to Computer Networks
Midterm II Review
Computer Science Division
Department of Electrical Engineering and Computer Sciences
University of California, Berkeley
Berkeley, CA 94720-1776
Katz, Stoica F04
Topics to be Covered







Transport Protocols
Congestion Control and Congestion Avoidance
concepts, TCP variants
QoS (Packet Scheduling) and Congestion Control
(RED) Mechanisms
Fluid Model and Token Bucket method
Essential DiffServ and IntServ Concepts
P&D: Sections 5.1, 5.2, 6.1- 6.3, 6.4.2, 6.5.1- 6.5.3
Project #2 Specification
Katz, Stoica F04
2
Topics to be Covered





Transport Protocols
Congestion Control and Congestion Avoidance
concepts, TCP variants
QoS (Packet Scheduling) and Congestion Control
(RED) Mechanisms
Fluid Model and Token Bucket method
Essential DiffServ and IntServ Concepts
Katz, Stoica F04
3
Transport Layer




Provide a way to decide which packets go to
which applications (multiplexing/demultiplexing)
Can provide more reliability, in order delivery, at
most once delivery
Can support messages of arbitrary length
Govern when hosts should send data  can
implement congestion and flow control
Katz, Stoica F04
4
UDP







User Datagram Protocol
Minimalist transport protocol
Same best-effort service model as IP
Messages up to 64KB
Provides multiplexing/demultiplexing to IP
Does not provide flow and congestion control
Application examples: video/audio streaming
Katz, Stoica F04
5
TCP






Transmission Control Protocol
Reliable, in-order, and at most once delivery
Messages can be of arbitrary length
Provides multiplexing/demultiplexing to IP
Provides congestion control and avoidance
Application examples: file transfer, chat
Katz, Stoica F04
6
TCP Service
1)
2)
Open connection
Reliable byte stream transfer from
(IPa, TCP Port1) to (IPb, TCP Port2)
•
3)
Indication if connection fails: Reset
Close connection
Katz, Stoica F04
7
Flow Control vs. Congestion Control



Flow control: regulates how much data can a
sender send without overflowing the receiver
Congestion control: regulates how much data
can a sender send without congesting the
network
Congestion: dropping packets into the network
due to buffer overflow at routers
Katz, Stoica F04
8
Congestion Window (cwnd)

Limits how much data can be in transit, i.e., how many
unacknowledged bytes can the sender send
AdvertisedWindow is used for flow control
MaxWindow = min(cwnd, AdvertisedWindow)
EffectiveWindow = MaxWindow – (LastByteSent – LastByteAcked)
LastByteAcked
LastByteSent
sequence number increases
Katz, Stoica F04
9
Topics to be Covered





Transport Protocols
Congestion Control and Congestion Avoidance
concepts, TCP variants
QoS (Packet Scheduling) and Congestion Control
(RED) Mechanisms
Fluid Model and Token Bucket method
Essential DiffServ and IntServ Concepts
Katz, Stoica F04 10
Why do You Care About Congestion
Control?


Otherwise you get to congestion collapse
How might this happen?
- Assume network is congested (a router drops packets)
- You learn the receiver didn’t get the packet
• Either by ACK or Timeout
- What do you do?
- Retransmit packet
- Still receiver didn’t get the packet (because it is dropped again)
- Retransmit again
- …. and so on …
- And now assume that everyone is doing the same!

Network will become more and more congested
- And this with duplicate packets rather than new packets!
Katz, Stoica F04
11
Solutions?


Increase buffer size. Why not?
Slow down
- If you know that your packets are not delivered because
network congestion, slow down

Questions:
- How do you detect network congestion? Use packet
loss as indication!
- By how much do you slow down?
Katz, Stoica F04 12
TCP: Slow Start


Goal: discover congestion quickly
How?
- Quickly increase cwnd until network congested  get a
rough estimate of the optimal size of cwnd:
- Whenever starting traffic on a new connection, or
whenever increasing traffic after congestion was
experienced:
• Set cwnd =1
• Each time a segment is acknowledged increment
cwnd by one (cwnd++).
Katz, Stoica F04 13
Slow Start Example


The congestion
window size
grows very
rapidly
TCP slows down
the increase of
cwnd when
cwnd >=
ssthresh
cwnd = 1
cwnd = 2
cwnd = 3
cwnd = 4
cwnd =
8
Katz, Stoica F04 14
Congestion Avoidance



Additive increase: starting from the rough estimate,
slowly increase cwnd to probe for additional available
bandwidth
Multiplicative decrease: cut congestion window size
aggressively if a timeout occurs
If cwnd > ssthresh then
each time a segment is acknowledged
increment cwnd by 1/cwnd (cwnd += 1/cwnd).
Katz, Stoica F04 15
Slow Start/Congestion Avoidance
Example
cwnd = 1

Assume that
ssthresh = 8
cwnd = 2
cwnd = 4
14
Cwnd (in segments)
12
10
cwnd = 8
8
6
ssthresh
4
2
cwnd = 9
0
0
t=
2
t=
4
t=
Roundtrip times
6
t=
cwnd = 10
Katz, Stoica F04 16
Putting Everything Together:
TCP Pseudocode
Initially:
cwnd = 1;
ssthresh = infinite;
New ack received:
if (cwnd < ssthresh)
/* Slow Start*/
cwnd = cwnd + 1;
else
/* Congestion Avoidance */
cwnd = cwnd + 1/cwnd;
Timeout:
/* Multiplicative decrease */
ssthresh = cwnd/2;
cwnd = 1;
Katz, Stoica F04 17
The big picture
cwnd
Timeout
Congestion
Avoidance
Slow Start
sstresh
Time
Katz, Stoica F04 18
Packet Loss Detection




Wait for Retransmission Time Out (RTO)
What’s the problem with this?
Because RTO is performance killer
In the BSD TCP implementation, RTO is usually
more than 1 second
- The granularity of RTT estimate is 500 ms
- Retransmission timeout is at least two times RTT

Solution: Don’t wait for RTO to expire
Katz, Stoica F04 19
Fast Retransmit

Resend a segment
after 3 duplicate ACKs
- Remember, a duplicate
ACK means that an outof sequence segment
was received

cwnd = 1
cwnd = 2
cwnd = 4
Notes:
- Duplicate ACKs due 3 duplicate
ACKs
packet reordering!
- If window is small don’t
get duplicate ACKs!
Katz, Stoica F04 20
Fast Recovery

After a fast-retransmit set cwnd to ssthresh/2
- i.e., don’t reset cwnd to 1


But when RTO expires still do cwnd = 1
Fast Retransmit and Fast Recovery 
implemented by TCP Reno; most widely used
version of TCP today
Katz, Stoica F04 21
Fast Retransmit and Fast Recovery
cwnd
Congestion
Avoidance
Slow Start
Fast retransmit

Time
Retransmit after 3 duplicated acks
- Prevent expensive timeouts


No need to slow start again
At steady state, cwnd oscillates around the
optimal cwnd size
Katz, Stoica F04 22
TCP Flavors

TCP-Tahoe
- cwnd =1 whenever drop is detected

TCP-Reno
- cwnd =1 on timeout
- cwnd = cwnd/2 on dupack

TCP-newReno
- TCP-Reno + improved fast recovery

TCP-Vegas, TCP-SACK
Katz, Stoica F04 23
TCP Vegas

Improved timeout mechanism

Decrease cwnd only for losses sent at current rate
- Avoids reducing rate twice

Congestion avoidance phase:
-
Compare Actual rate (A) to Expected rate (E)
If E-A > , decrease cwnd linearly
If E-A < , increase cwnd linearly
Rate measurements ~ delay measurements
See textbook for details!
Katz, Stoica F04 24
TCP-SACK

SACK = Selective Acknowledgements

ACK packets identify exactly which packets have
arrived

Makes recovery from multiple losses much easier
Katz, Stoica F04 25
Topics to be Covered





Transport Protocols: UDP, TCP and its many
variations
Congestion Control and Congestion Avoidance
concepts
QoS (Packet Scheduling) and Congestion Control
(RED) Mechanisms
Fluid Model and Token Bucket method
Essential DiffServ and IntServ Concepts
Katz, Stoica F04 26
Packet Scheduling

Decide when and what packet to send on output link
- Usually implemented at output interface of a router
flow 1
1
2
Classifier
flow 2
Scheduler
flow n
Buffer
management
Katz, Stoica F04 27
Goals of Packet Scheduling



Provide per flow/aggregate QoS guarantees in terms of
delay and bandwidth
Provide per flow/aggregate protection
Flow/Aggregate identified by a subset of following fields in
the packet header
-

source/destination IP address (32 bits)
source/destination port number (16 bits)
protocol type (8 bits)
type of service (8 bits)
Examples:
-
All packets from machine A to machine B
All packets from Berkeley
All packets between Berkeley and MIT
All TCP packets from EECS-Berkeley
Katz, Stoica F04 28
Random Early Detection (RED)

Basic premise:
- Router should signal congestion when the queue first
starts building up (by dropping a packet)
- But router should give flows time to reduce their
sending rates before dropping more packets

Therefore, packet drops should be:
- Early: don’t wait for queue to overflow
- Random: don’t drop all packets in burst, but space
drops out
Katz, Stoica F04 29
RED Advantages

High network utilization with low delays

Average queue length small, but capable of absorbing
large bursts

Many refinements to basic algorithm make it more
adaptive (requires less tuning)
Katz, Stoica F04 30
Explicit Congestion Notification

Rather than drop packets to signal congestion,
router can send an explicit signal

Explicit congestion notification (ECN):
- Instead of optionally dropping packet, router sets a bit in
the packet header
- If data packet has bit set, then ACK has ECN bit set

Backward compatibility:
- Bit in header indicates if host implements ECN
- Note that not all routers need to implement ECN
Katz, Stoica F04 31
ECN Advantages

No need for retransmitting optionally dropped
packets

No confusion between congestion losses and
corruption losses
Katz, Stoica F04 32
Topics to be Covered





Transport Protocols: UDP, TCP and its many
variations
Congestion Control and Congestion Avoidance
concepts
QoS (Packet Scheduling) and Congestion Control
(RED) Mechanisms
Fluid Model and Token Bucket method
Essential DiffServ and IntServ Concepts
Katz, Stoica F04 33
Token Bucket and Arrival Curve

Parameters
- r – average rate, i.e., rate at which tokens fill the bucket
- b – bucket depth
- R – maximum link capacity or peak rate (optional parameter)


A bit is transmitted only when there is an available token
Arrival curve – maximum number of bits transmitted within an
interval of time of size t
r bps
Arrival curve
bits
slope r
b*R/(R-r)
b bits
slope R
<= R bps
time
regulator
Katz, Stoica F04 34
Source Traffic Characterization


Arrival curve – maximum amount of bits transmitted
during an interval of time Δt
Use token bucket to bound the arrival curve
bps
bits
Arrival curve
time
Δt
Katz, Stoica F04 35
Source Traffic Characterization: Example
Arrival curve – maximum amount of bits transmitted
during an interval of time Δt
Use token bucket to bound the arrival curve


bits
(R=2,b=1,r=1)
Arrival curve
2
5
4
bps
3
2
2
1
1
0
1
2
3
4
5
time
1
3
4
Δt
Katz, Stoica F04 36
QoS Guarantees: Per-hop Reservation

End-host: specify
- the arrival rate characterized by token-bucket with parameters (b,r,R)
- the maximum maximum admissible delay D, no losses

Router: allocate bandwidth ra and buffer space Ba such that
- no packet is dropped
- no packet experiences a delay larger than D
slope ra
slope r
bits
Arrival curve
b*R/(R-r)
R
D
Ba
Katz, Stoica F04 37
Packet Scheduling and
Fair Queuing



Make sure that at any time the flow receives at
least the allocated rate ra
The canonical example of such scheduler:
Weighted Fair Queueing (WFQ)
Implements max-min fairness: each flow receives
min(ri, f) , where
- ri – flow arrival rate
- f – link fair rate (see next slide)

Weighted Fair Queueing (WFQ) – associate a
weight with each flow
Katz, Stoica F04 38
Fluid Flow System: Example

link
Red flow has packets
backlogged between time 0
and 10
- Backlogged flow  flow’s
queue not empty


flows
weights
Other flows have packets
continuously backlogged
All packets have the same size
0
2
4
6
8
5
1
10
1
1
1
15
Katz, Stoica F04 39
1
Packet System: Example
Service
in fluid flow
system
0

2
4
6
8
10
Select the first packet that finishes in the fluid flow system
Packet
system
0
2
4
6
8
10
Katz, Stoica F04 40
Example: Problem 6.14 (a)
link capacity (C) = 1; packet size = 1
A
Arrival
patterns
wall clock
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15
B
C
A,4
A,6
A,7
A,9
A,1
A,2
Fluid
B,2
B,6
B,8
B,11
B,12
C,2 C,3
C,5
C,6
C,7
system C,1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
A,10
B,15
C,8
19 20 21 wall clock
Packet
system
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 wall clock
Katz, Stoica F04 41
Solution: Virtual Time

Key Observation: while the finish times of packets may
change when a new packet arrives, the order in which
packets finish doesn’t!
- Only the order is important for scheduling

Solution: instead of the packet finish time maintain the
number of rounds needed to send the remaining bits of
the packet (virtual finishing time)
- Virtual finishing time doesn’t change when the packet arrives

System virtual time – index of the round in the bit-by-bit
round robin scheme
Katz, Stoica F04 42
Example: Problem 6.14 (a)
V(t) virtual
system
time
1/3
3
1/2
2.5
C – link capacity
N(t) – total weight of
backlogged
flows
V (t )
C

t
N (t )
1/3
1.5
1/2
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 wall clock
A,4
A,6
A,7
A,9
A,10
A,1
A,2
B,2
B,6
B,8
B,11
B,12
B,15
C,1
C,2 C,3
C,5
C,6
C,7
C,8
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 wall clock
Katz, Stoica F04 43
Properties of WFQ

Guarantee that any packet is transmitted within
packet_lengt/link_capacity of its transmission time
in the fluid flow system
- Can be used to provide guaranteed services

Achieve max-min fair allocation
- Can be used to protect well-behaved flows against
malicious flows
Katz, Stoica F04 44
What You Need to Know

Basic concepts
-

Arrival & service curve
Token-bucket specification
System virtual time / finish virtual time
WFQ properties
Link sharing requirements and challenges
Bandwidth-delay coupling problem
Mechanisms:
- WFQ implementation in the fluid flow & packet system

You don’t need to know
- Details of WF2Q
- How service curve works
Katz, Stoica F04 45
Topics to be Covered





Transport Protocols: UDP, TCP and its many
variations
Congestion Control and Congestion Avoidance
concepts
QoS (Packet Scheduling) and Congestion Control
(RED) Mechanisms
Fluid Model and Token Bucket method
Essential DiffServ and IntServ Concepts
Katz, Stoica F04 46
Differentiated Services

Some traffic should get better treatment
- Application requirements: interactive vs. bulk transfer
- Economic arrangements: first-class versus coach

What kind of better service could you give?
- Measured by drops, or delay (and drops)

How do you know which packets to give better service?
- Bits in packet header
Katz, Stoica F04 47
Advantages of DiffServ

Very simple to implement

Can be applied at different granularities
- Flows
- Institutions
- Traffic types

Marking can be done at edges or by hosts

Allows easy peering (bilateral SLAs)
Katz, Stoica F04 48
Disadvantages of DiffServ

Service is still “best effort”, just a “better” class of
best effort
- Except for EF, which has terrible efficiency
- All traffic accepted (within SLAs)

Some applications need better than this
- Certainly some apps need better service than today’s
Internet delivers
- But perhaps if DiffServ were widely deployed premium
traffic would get great service (recall example)
Katz, Stoica F04 49
Integrated Services

Attempt to integrate service for “real-time”
applications into the Internet

Known as IntServ

Total, massive, and humiliating failure
- 1000s of papers
- IETF standards
- and STILL no deployment ...
Katz, Stoica F04 50
Resource Reservation Protocol:
RSVP





Establishes end-to-end reservations over a
datagram network
Designed for multicast (which will be covered
later)
Sources: send TSpec
Receivers: respond with RSpec Network
Network: responds to reservation requests
Katz, Stoica F04 51
Advantages of IntServ

Precise QoS delivered at flow granularities
- Good service, given exactly to who needs it

Decisions made by hosts
- Who know what they need
- Not by organizations, egress/ingress points, etc.

Fits multicast and unicast traffic equally well
Katz, Stoica F04 52
Disadvantages of IntServ

Scalability: per-flow state, classification, etc.
-

Goofed big time
Aggregation/encapsulation techniques can help
Can overprovision big links, per-flow ok on small links
Scalability can be fixed, but no second chance
Economic arrangements:
- Need sophisticated settlements between ISPs
- Right now, settlements are primitive (barter)

User charging mechanisms: need QoS pricing
Katz, Stoica F04 53
What You Need to Know

Three kinds of QoS approaches
- Link sharing, DiffServ, IntServ

Some basic concepts:
-

Differentiated dropping versus service priority
Per-flow QoS (IntServ) versus per-aggregate QoS (DiffServ)
Admission control: parameter versus measurement
Control plane versus data plane
Controlled load versus guaranteed service
Codepoints versus explicit signaling
Various mechanisms:
- Playback points
- Token bucket
- RSVP PATH/RESV messages
Katz, Stoica F04 54