1. CMPE 252A: Computer Networks
Lecture 18
CMPE252A Fall 2003

2. Queue management
CMPE252A Fall 2003

3. Context Problem: traffic grows until it will fill the network.
Solutions:
End-hosts: congestion control (ex. TCP).
Routers: queueing policies (RED, FQ).
CMPE252A Fall 2003

4. What about application needs?
Different applications have different needs.
Non real-time versus real-time traffic.
Non-real time:
Loss sensitive.
Delay tolerant.
Real-time traffic has other needs:
QoS (quality of service): fixed bandwidth, low delay, low jitter.
CMPE252A Fall 2003

5. Taxonomy (revisited) Router-based versus e2e.
Routers: queueing, reservations, adaptive routing.
Hosts: e2e congestion control.
Reservations versus feedback.
Reservations: applications ask for resources (admission control: yes/no).
Feedback: hosts sends, routers tell to slow down.
CMPE252A Fall 2003

6. Queuing disciplines Implemented at routers. Allocates:
Every router implements some queueing discipline.
Allocates:
Bandwidth: which packets get transmitted.
Buffer space: which packets get dropped.
Affects latency experienced by packets.
Queuing delay.
CMPE252A Fall 2003

7. Managing router’s queue
Queue discipline:
Determines order in which packets are transmitted.
Drop policy:
Determines which packets get dropped.
Why needed?
CMPE252A Fall 2003

8. FIFO queuing
Queuing discipline: first-in-first-out (or FCFS: first-come-first-serve).
Drop discipline: tail of the FIFO queue is dropped when queue is full regardless of flow or importance.
FIFO implies drop tail.
CMPE252A Fall 2003

9. FIFO queuing (cont’d) Important distinction:
FIFO: scheduling discipline (which packet to serve next).
Drop-tail: drop policy (which packet to drop next).
CMPE252A Fall 2003

10. FIFO with drop tail Currently the most widely used in the Internet.
Leaves responsibility for congestion control out to network edges (e.g., TCP)
FIFO lets larger flows get more data through but shares congestion with others.
Does not separate between different flows.
No policing.
CMPE252A Fall 2003

11. Priority queuing Packets marked with priority.
Mark may be carried in the IP TOS field.
Routers implement multiple FIFO queues, one for each priority class.
Routers transmit high-priority packets first.
Within each priority, FIFO.
Some progress away from best effort.
But no guarantees…
CMPE252A Fall 2003

12. Problem with Priority Queuing
Starvation of queues with less priority.
Why?
What if users can set their own priorities at will?
Billing and accounting infrastructure.
Priority queuing used for routing updates.
CMPE252A Fall 2003

13. Fair Queuing Main idea:
Maintain separate queue for each flow currently flowing through router.
Router services queues in round-robin fashion.
If flow sends packets too quickly, its queue fills up.
After certain level, packets from misbehaving source get dropped.
CMPE252A Fall 2003

14. FQ illustration
Flow 1
Flow 2
I/P
O/P
Flow n
CMPE252A Fall 2003

15. Fair Queuing (FQ)
Router does not send explicit feedback to source - still needs e2e congestion control.
FQ isolates ill-behaved users by forcing users to share overload with themselves.
Still achieves statistical mux’ing - one flow can fill entire pipe if no contenders.
Link is never idle as long as there is at least one packet in queue: work-conserving.
CMPE252A Fall 2003

16. Some complications Packets are of different length.
We really need bit-by-bit round-robin.
FQ simulates bit-by-bit RR.
Not feasible to interleave bits!
FQ determines time packet would finish being transmitted if using bit-by-bit RR.
Uses this time to schedule packet transmission.
CMPE252A Fall 2003

17. Bit-by-bit RR
Suppose clock ticks when a bit is transmitted. For packet i:
Pi: length, Ai = arrival time, Si: begin transmit time, Fi: finish transmit time. Fi = Si+Pi.
Si depends on when router finished transmitting packet i-1.
Si = max(Fi-1, Ai)i.
Fi = max (Fi-1, Ai) + Pi.
CMPE252A Fall 2003

18. Bit-by-bit RR example Cannot preempt packet
F=5
F=8
Flow 1
Flow 2
Output
F=10
Both packets from flow 1
transmitted before flow 2
Packet.
F=10
Flow 1
(arriving)
Flow 2
(transmitting)
Output
F=2
Cannot preempt packet
currently being transmitted.
CMPE252A Fall 2003

19. FQ considerations
Link is never idle as long as there is at least one packet in queue.
Work-conserving.
Any bandwidth not used by one flow is automatically available to others.
If link fully loaded, each flow gets 1/n of bandwidth.
If flow tries to send more, its packets will take longer to be transmitted.
FQ guarantees minimum share of bandwidth to each flow; possibly more.
CMPE252A Fall 2003

20. Weighted FQ Weight assigned to each flow (queue).
Specifies how many bits to transmit each time queue serviced.
Way of treating flows differently than others.
Queues with larger weights will get more bandwidth.
WFQ described in terms of traffic classes.
E.g., use IP’s TOS bits to identify classes.
Allocate queue and weight for each class.
CMPE252A Fall 2003

21. FQ summary FQ can control congestion by monitoring flows.
Monitoring individual flows is hard in routers with many flows (e.g., backbone routers).
Flow aggregation is a possibility.
CMPE252A Fall 2003

22. FQ summary (cont’d) Widely available, rarely used. Pros: Cons:
Provides perfect isolation (fairness).
Handles non-responsive flows.
Cons:
Requires per-flow state—too expensive for core routers.
CMPE252A Fall 2003

23. Random early detection (RED)
[Floyd and Jacobson] early 90’s.
Active queue management.
Congestion avoidance.
Router monitors its queue.
If incipient congestion, drops packet.
Designed to work with TCP.
CMPE252A Fall 2003

24. Early detection Router drops packet(s) before queue gets full.
Dropping fewer packets earlier to avoid dropping more packets later.
Early random drop:
After a certain threshold, drop each arriving packet with some probability.
CMPE252A Fall 2003

25. Other options Random drop: Drop front:
Packet arriving when queue is full causes some random packet to be dropped
Drop front:
On full queue, drop packet at head of queue
CMPE252A Fall 2003

26. RED algorithm Maintain running average of queue length.
AvgLen=(1-weight)*AvgLen + weight*SampleLen
if AvgLen < minth, do nothing.
Low queuing, send packets through.
if AvgLen > maxth, drop packet.
Protection from misbehaving sources.
Else drop packet with probability p.
Implicitly notify sources of incipient congestion
CMPE252A Fall 2003

27. Average queue length Weighted running average.
AvgLen = (1-w)*AvgLen+w*SampleLen
Queue length measured for each packet arrival.
CMPE252A Fall 2003

28. Thresholds minth determined by the utilization requirement.
maxth set to twice minth.
CMPE252A Fall 2003

29. RED operation Min thresh Max thresh Average queue length
CMPE252A Fall 2003

30. Drop probability P(drop) 1.0 MaxP Avg length minthresh maxthresh
CMPE252A Fall 2003

31. Drop probability (cont’d)
Marking probability based on average queue length.
P = maxP*(AvgLen- minth) / (maxth - minth)
Dropping just based on AvgLen can lead to clustered marking.
Better to bias by history of unmarked packets.
Pb = P/(1 - count*P), where count counts number of new packets queued while AvgLen between thresholds.
CMPE252A Fall 2003

32. RED and flow isolation Problem: what to do with non-cooperative flows?
Fair queuing achieves isolation using per-flow state: expensive at backbone routers.
How can we isolate unresponsive flows without per-flow state?
CMPE252A Fall 2003

33. RED penalty box
High bandwidth flows experience proportionally larger amounts of packet loss.
With RED, monitor history of packet drops, identify flows that use disproportionate bandwidth.
Isolate and punish those flows.
CMPE252A Fall 2003

34. RED Widely available, but not clear how widely it’s used. Advantages:
Provides more rapid feedback to TCP.
Lower queueing delays.
Potentially part of a solution to penalize bad flows.
CMPE252A Fall 2003

35. Problems with RED Potentially long response times.
May lead to excessive packet marking/drops.
Bursty traffic makes matters worse.
Solution: large buffer space at RED routers.
Problem?
RED has several parameters.
Hard to tune.
CMPE252A Fall 2003

36. Integrated and differentiated services
CMPE252A Fall 2003

37. Motivation Internet provides “best-effort” service.
OK for applications such as , file transfer.
Still OK for interactive applications like telnet, Web (?).
Definitely not OK for real-time services such as voice and video applications.
CMPE252A Fall 2003

38. Real-time applications
Applications sensitive to data timeliness.
Voice and video services as typical examples.
Industrial control.
Games.
Even data distribution with deadlines.
CMPE252A Fall 2003

39. Real-time application requirements
Need some assurance from network regarding timeliness guarantees.
Need new service model.
Applications with higher demands can make service requests to network.
Network can say “yes” or “no”.
In addition to best effort.
CMPE252A Fall 2003

40. QoS Quality of Service: Ability to treat traffic in different ways.
Provide different service levels.
CMPE252A Fall 2003

41. Application Taxonomy Real-time and non-real-time (elastic).
Real time: delay intolerant.
If sample of audio stream shows up at receiver after its playback time, it is useless.
Example elastic services: FTP, mail, Web browsing.
Benefit from short delays but don’t get unusable if delay increases.
Delay requirements vary: interactive (telnet) versus totally asynchronous ( ); FTP in the middle.
CMPE252A Fall 2003

42. Playback buffer
Add buffer at receiver to have some date in reserve before starting to playback.
Offset playback time by some constant.
Can we still run into problems?
For interactive applications, limits on how much delay can be added.
Conversation: 300ms.
CMPE252A Fall 2003

43. Real-time applications: Taxonomy
Loss, delay
tolerant
Intolerant
Non-adaptive
adaptive
Delay
Rate
CMPE252A Fall 2003

44. Real-time applications (1)
Loss tolerant?
Actual packet loss or packet was too late to be useful.
Audio/video stream.
Few losses are OK; too many losses make overall data incomprehensible.
Control applications are real-time loss-intolerant!
CMPE252A Fall 2003

45. Real-time applications (2)
Adaptability.
Adapting the playback point depending on delay experienced by packets over time: delay-adaptive applications.
Rate-adaptive: video applications.
Trade quality for bandwidth.
Adapt video coding algorithms appropriately.
CMPE252A Fall 2003

46. Internet service model
Best effort.
Adequate only for elastic applications.
Need for additional service models to support other classes of applications.
CMPE252A Fall 2003

47. QoS support Fine-grained. Coarse-grained.
QoS to individual applications/flows.
Integrated services.
QoS architecture developed by IETF.
RSVP.
Coarse-grained.
QoS to large classes of data or aggregate traffic.
Differentiated services.
Standardization by IETF.
CMPE252A Fall 2003

48. Supporting Real-Time Applications in and Integrated Services Packet Network…
[Clark92]
CMPE252A Fall 2003

49. Integrated services architecture
Flow specifications.
Reservations (includes reservation protocol).
Admission control based on flow description and current load.
Packet scheduling to follow through on reservation.
Traffic shaping at edges to fit reservation.
Some application adaptation to deal with variability inherent in work-conserving network.
CMPE252A Fall 2003

50. Types of network service
Guaranteed service.
For intolerant and rigid applications.
Predicted service.
For tolerant and adaptive applications.
E.g., vat: adjusts playback point according to network delay; reasonable as long as loss < 10%.
CMPE252A Fall 2003

51. Flow specifications
Set of information applications provide to network.
2 components:
Description of flow’s traffic characteristics (TSpec).
Description of service requested from network (RSpec).
CMPE252A Fall 2003

52. Token bucket filter
How to describe bandwidth characteristics of sources.
How bandwidth varies over time.
Also useful for admission control purposes.
Described by 2 parameters:
Token rate r: rate tokens placed in bucket.
Bucket depth B: capacity of bucket (burst size).
CMPE252A Fall 2003

53. Token bucket filter operation
Tokens are placed in bucket at rate r.
Sending a packet of size P bytes uses P tokens.
If bucket has P tokens, packet sent at max rate, else must wait for tokens to accumulate.
CMPE252A Fall 2003

54. Token bucket operation
tokens
tokens
tokens
overflow
Packet
Packet
Not enough
tokens - wait for
tokens to
Accumulate.
If enough tokens,
packet goes through;
tokens removed.
CMPE252A Fall 2003

55. TB characteristics On the long run, rate is limited to r.
On the short run, a burst of size B can be sent.
Amount of traffic entering at interval T is bounded by:
traffic = B + r*T
CMPE252A Fall 2003

56. Token bucket specs Assume flows send data as individual bytes. BW
Flow B 2
Flow A: generates data at steady
rate of 1 MBps.
r = 1 MBps, B=1 byte. 1
Flow A 1 2 3
Time
Flow B: sends at average rate of
1MBps.
r = 1 MBps, B=1Mbyte.
CMPE252A Fall 2003

57. Possible token bucket uses
Shaping, policing, marking.
Delay packets from entering net (shaping).
Drop packets that arrive without tokens (policing).
Let all packets passing through, mark ones without tokens.
Network drops packets without tokens in time of congestion.
CMPE252A Fall 2003

58. Admission control
When new flow, look at Rspec and Tspec and decide whether to admit or reject.
Look at available resources.
No disruption to currently admitted flows.
Different from policing!
Applied on per-packet basis.
Make sure flow conforms to its Tspec.
CMPE252A Fall 2003

59. RSVP Used on connectionless networks.
Relies on soft state: reservations must be refreshed and do not have to be explicitly deleted. Why?
Aims to support multicast as effectively as unicast flows - multicast applications good candidates for real-time.
Receiver-oriented approach.
Typically, more receivers than senders.
Receivers have different requirements.
CMPE252A Fall 2003

60. Role of RSVP Rides on top of unicast/multicast routing protocols.
Carries resource requests through network.
At each hop consults admission control and sets up reservation. Informs requester if failure.
CMPE252A Fall 2003

61. Upper layer protocols and applications
RSVP in the stack
Upper layer protocols and applications IP
ICMP
IGMP
RSVP
Link layer modules
CMPE252A Fall 2003

62. Changing reservation
Receiver-oriented approach and soft state make it easy to modify reservation.
Modification sent with periodic refresh.
CMPE252A Fall 2003

63. Making a reservation Before making reservation, receiver must know:
Type of traffic sender will send (Tspec).
Path sender’s packets will follow.
Both can be accomplished by sending PATH messages.
Router remembers reverse path.
CMPE252A Fall 2003

64. PATH messages PATH messages carry sender’s Tspec.
Routers note the direction PATH messages arrived and set up reverse path to sender.
Receivers send RESV messages that follow reverse path and setup reservations.
If reservation cannot be made, receiver gets an error.
Otherwise, reservation installed at every router.
Receiver refreshes state with RESV every 30s.
CMPE252A Fall 2003

65. Soft State
Routing protocol makes routing changes, RSVP adjusts reservation state.
PATH messages generated every 30s.
In absence of route or membership changes, periodic PATH and RESV messages refresh established reservation state.
When change, new PATH messages follow new path, new RESV messages set reservation.
Non-refreshed state times out automatically.
CMPE252A Fall 2003

66. RSVP and Multicast
For multiple receivers, reservation merging at routers.
Example: receiver A requests delay less than 200ms; RESV message hits router that already has reservation for delay less than 100ms.
If multiple senders, receivers need to merge Tspec’s.
Merging is application-specific.
RSVP has different reservation styles.
CMPE252A Fall 2003

67. PATH and RESV messages R R R R Sender 1 Sender 2 PATH RESV (merged)
receiver 1 R
RESV
receiver 2
CMPE252A Fall 2003

68. Packet classifying and scheduling
Each arriving packet at router must be:
Classified: associated with the application reservation.
Fields: source + destination address, protocol number, source + destination port.
Associated to adequate traffic class.
Scheduled: managed in the queue so that it receives the requested service.
Queue management.
WFQ for guaranteed service traffic.
CMPE252A Fall 2003

69. Differentiated services
(Diffserv)
CMPE252A Fall 2003

70. Diffserv Alternative to integrated services.
Integrated services allocate resources to individual flows.
Diffserv: allocates resources to small number of traffic classes.
Between int-serv and best effort: provides probabilistic guarantees.
Premium, assured, and best effort.
CMPE252A Fall 2003

71. Analogy Airline service: first class, coach.
Various restrictions on coach as a function of payment.
Best-effort expected to make up bulk of traffic, but revenue from first class important to economic base (will pay for more plentiful bandwidth overall).
CMPE252A Fall 2003

72. Types of service Premium service: (type P) Assured service: (type A)
Admitted based on peak rate.
Conservative.
Unused premium goes to best effort.
Assured service: (type A)
Based on expected capacity usage profiles.
Traffic unlikely to be dropped if user maintains profile.
Out-of-profile traffic marked.
CMPE252A Fall 2003

73. Comparison to Int-Serv
No need for reservations: just mark packets.
Packet marking can be at “edges”.
Edges: administrative boundaries.
Faster core routers.
Much less signaling.
Much simpler overall system.
CMPE252A Fall 2003

74. Who sets “premium” bit? Set bit when entering an AS. Boundary router.
Edge ISP router marks packets arriving on its interfaces.
Based on service agreement.
May mark only some packets.
Up to a maximum rate.
Other packets as best effort.
CMPE252A Fall 2003

75. Premium traffic flow Company A ISP Packets in premium
flows have bit set
Premium packet flow
restricted to R bytes/sec
internal
router
ISP
host
border
router
first hop
router
border
router
Unmarked
packet flow
CMPE252A Fall 2003

76. What do routers do?
IETF currently standardizing set of procedures for routers: per-hop behaviors (PHBs).
CMPE252A Fall 2003

77. Per-hop behaviors (PHBs)
Define behavior of individual routers.
Multiple behaviors - need more than one bit in the header.
Six bits from IP TOS field are taken for Diffserv code points (DSCP).
CMPE252A Fall 2003

78. Expedited forwarding (EF)
EF packets are forwarded with minimal delay and loss (up to the capacity of the router).
Arrival rate of EF packets < router’s forwarding rate.
Router also needs to forward other packets!
Rate limiting of EF packets achieved by configuring routers at edge of administrative domain to allow certain maximum EF rate.
EF behavior:
Strict priority.
WFQ between EF and all other packets.
CMPE252A Fall 2003

79. Assured Forwarding (AF)
Evolved from RED with In and Out (RIO), or “Weighted RED”.
Similar to RED, but with two separate probability curves.
“In” and “Out” (of profile).
“Out” class has lower Minthresh, so packets are dropped from this class first.
As average queue length increases, “in” packets are dropped.
Profile marking done by edge router.
CMPE252A Fall 2003

80. RIO drop probabilities
P(drop)
1.0
MaxP
AvgLen
Minout
Minin
Maxout
Maxin
CMPE252A Fall 2003

81. Integrated services Pros: Cons:
Good match for real-time traffic (ex. VOIP).
Perfect for VPNs (ISPs can sell “virtual pipes”).
Cons:
Too much state for backbone routers.
Not widely deployed
CMPE252A Fall 2003

82. Differentiated Services
Pros:
Easy to implement and fast (no per-flow state).
ISPs can charge extra for preferred.
Cons:
No guarantees.
CMPE252A Fall 2003