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

2. Announcements Midterm: 11.06. Covers up to multicast transport.
No cheat sheets.
Solutions for hw 1 posted.
Graded project 1.
CMPE252A Fall 2003

3. Announcements Hw 2 posted: due on 11.18. Electronic submission only.
Only pdf, ps, or txt ill be accepted.
No office hours tomorrow.
Make-up office hours today after class.
Nov. 11 is a university holiday!!!
CMPE252A Fall 2003

4. Today Finish queue management. Integrated and differentiated services.
CMPE252A Fall 2003

5. Queue management
CMPE252A Fall 2003

6. So far… FIFO (assumes drop tail). Priority queue. Fair queuing.
Weighted fair queuing.
CMPE252A Fall 2003

7. Other drop disciplines
Random drop:
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

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

9. 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

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

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

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

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

14. 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

15. 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

16. 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

17. 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

18. 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

19. BLUE
Approach:
Does not rely on average queue size as congestion indicator.
BLUE uses packet loss and link utilization history.
CMPE252A Fall 2003

20. BLUE overview Single marking probability, pm.
Controls packet drops/marked.
If packets are getting dropped, increase pm.
Or alternatively, if queue goes beyond certain value.
Else, decrease pm.
Update interval: interval between 2 successive updates.
Amount by which pm is increased or decreased.
CMPE252A Fall 2003

21. BLUE algorithm
Upon packet loss (or queue length above threshold) event:
If ((now - last_update) > freeze_time)
Pm = pm + pm_increase.
last_update = now.
Upon link idle event:
Pm = pm - pm_decrease.
CMPE252A Fall 2003

22. Setting BLUE’s parameters
freeze_time should be based on the RTT.
pm_increase and pm_decrease set to allow pm to adapt to macroscopic changes in load.
Over “typical links”,
10ms<freeze_time<500ms,
pm_increase and pm_decrease set to allow pm to range from 0 to 1 on the order of 5 to 30 s.
CMPE252A Fall 2003

23. BLUE versus RED BLUE is simpler than RED. Simulation experiments.
Lower loss rates.
Lower buffer requirements.
Better link utilization.
More experiments?
More complex topologies.
Background traffic, etc.
CMPE252A Fall 2003

24. Integrated and differentiated services
CMPE252A Fall 2003

25. 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

26. 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

27. 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

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

29. 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

30. 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

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

32. 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

33. 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

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

35. 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

36. 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

37. Integrated services Body of work developed by the IETF around 1995-97.
Service class specifications.
RSVP.
CMPE252A Fall 2003

38. Service classes Guaranteed service. Intolerant applications.
Network guarantees no packet arrives later than a certain delay bound.
Delay bound guarantees: application can set its playback point.
CMPE252A Fall 2003

39. Service classes (cont’d)
Controlled load.
Tolerant, adaptive applications.
Run well on networks not highly loaded.
Adapt accordingly.
E.g., vat: adjusts playback point according to network delay; reasonable as long as loss < 10%.
Emulate lightly loaded network.
Use WFQ: isolate controlled from other traffic.
CMPE252A Fall 2003

40. 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

41. Token bucket filter How to describe how bandwidth varies over time.
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

42. 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 immediately; else must wait for tokens to accumulate.
CMPE252A Fall 2003

43. 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

44. 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

45. 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

46. 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

47. Admission control
When new flow, look at Rspec and Tspec and decide whether to admit or reject.
Look at network 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

48. Reservation protocol: RSVP
Upper layer protocols and applications
IP service interface IP
ICMP
IGMP
RSVP
Link layer service interface
Link layer modules
CMPE252A Fall 2003

49. RSVP Used on connectionless networks.
Relies on soft state: reservations must be refreshed and do not have to be explicitly deleted.
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

50. Role of RSVP Rides on top of unicast/multicast routing protocols.
Carries resource requests all the way through the network.
At each hop, router tries to allocate necessary resources and sets up reservation. Informs requester if failure.
Receivers refresh reservation periodically.
CMPE252A Fall 2003

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

52. Making a reservation Receivers make reservation.
Before making a 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

53. 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

54. 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

55. RSVP and Multicast Reservation merging at routers.
If multiple senders, receivers need to merge Tspec’s.
Merging is application-specific.
RSVP has different reservation styles.
CMPE252A Fall 2003

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

57. Packet classifying and scheduling
Each arriving packet at router must be:
Classified: associated with correct 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