Computer Networks: Mechanisms for Quality of Service

1. Computer Networks:Mechanisms for Quality of Service Ivan Marsic Rutgers University Chapter 5 - Mechanisms for Quality-of-Service

2. Mechanisms forQuality-of-Service Chapter 5

3. Topic:Scheduling  Max-Min Fair Share  Fair Queuing (FQ)  Weighted Fair Queuing (WFQ)

4. Why Scheduling? • To prevent aggressive or misbehaving sources from overtaking network resources • To provide preferential service to packets from preferred sources

5. Scheduler

6. Scheduler Design Concerns • Classification policy for forming the queues: • Priority based • Source identity based • Flow identity based (source-destination pair) • … • Scheduling policy for taking packets into service: • Round robin • Work conserving vs. Non-work conserving

7. Fair Share of a Resource

8. Max-Min Fair Share (1)

9. Max-Min Fair Share (2)

10. Max-Min Fair Share (3)

11. Max-Min Fair Share

12. Example 5.1: Max-Min Fair Share

13. Example 5.1: Max-Min Fair Share available capacity of the link is C = 1 Mbps = 1,000,000 bits/sec Weighted Max-Min Fair Share: Source weights : w1 = 0.5, w2 = 2, w3 = 1.75, and w4 = 0.75

14. Implementing MMFS with Packets • Problem: Packets are of different length, arrive randomly, and must be transmitted atomically, as a whole • Packets cannot be split in pieces to satisfy the MMFS bandwidth allocation • Solution: Fair Queuing (FQ)

15. Example: Airport Check-in

16. Bit-by-bit GPS FQ: Run an imaginary GPS simulation, to find when packet transmission would be finished if its bits could be transmitted one-by-one

17. Bit-by-bit GPS (a) (b)

18. Bit-by-bit GPS -- Example

19. GPS Round Number vs. Time

20. Example 5.3: GPS Round Numbers

21. Example 5.3: GPS Round Numbers (Cont’d) 0 16,384 @1 0 4,096 @3 3 16,384 @2 3 8,192 @4 6 4,096 @3 12 4,096 @3

22. Example 5.3: Fair Queuing

23. Example 4.4: Fair Queuing (1)

24. Example 4.4: Fair Queuing (2b)

25. Topic:Policing  Leaky Bucket Algorithm

26. Delay Magnitude & Variability

27. Leaky Bucket

28. Topic:Active Queue Management Random Early Detection (RED) Explicit Congestion Notification (ECN)

29. Why Active Queue Management

30. Random Early Detection (RED)

31. Random Early Detection (RED) (5.4) AverageQLen(t) = (1) AverageQLen(t1) MeasuredQLen(t) (5.5) (5.6)

32. Random Early Detection (RED)

33. Explicit Congestion Notification (ECN) ECN details: RFC 3168 Want: avoid dropping packets as a way of notifying the senders of congestion Need: avoid sending direct messages to senders because it makes congestion worse Solution: piggyback notifications to sender on DATA packets flowing to receiver; receiver will piggyback notifications to ACKs

34. Explicit Congestion Notification (ECN) (a) Router needs to notify the TCP sender of incipient congestion, so it piggybacks an ECN notification on the data packet. The TCP receiver should send the ECN notification back to the sender, piggybacked on the ACK packet. • Routers work only with IP (not TCP), so … • Need to modify IP header format to support [router  receiver]ECN notifications • Need to modify TCP header format to support [receiver  sender] ECN notifications

35. Explicit Congestion Notification (ECN) Not enough to modify the IP header format: The Sender would not know if the ECN notification is for the Sender or for the Receiver; It would not matter if both data and ACK packets travelled over the same path, because it would be relevant for both. But, packets may take different paths, so Sender must know if the ECN is for itself or Receiver. Having two bits, one for “forward” (data) path and one for “reverse” (ACK) path would not solve the problem, because routers cannot distinguish “forward/reverse” – the distinction makes sense only to the TCP layer (not available on routers)! Therefore, must modify TCP header format to allow the Receiver to notify the Sender

36. IPv4 Header

37. Modify IP Header Format for ECN • Need two bits: • One for the congested router to notify the Sender of an incipient congestion • One for the Sender to notify routers that it is ECN capable(because otherwise the router’s notification would not make difference) • Note: If routers applied ECN regardless of whether Senders are ECN-capable, then non-ECN-capable senders get a free ride (no packets dropped when congestion, just ECN bit set!) and would not have incentive to upgrade to ECN • So, apply RED to packets from non-ECN-capable senders

38. IPv4 Packet Header + ECN Field (a) ECN Field 14 15 ECT CE 0 0 = Not-ECT 0 1 = ECT(1) 1 0 = ECT(0) 1 1 = CE, cong. experienced E C T C E

39. Detecting a Misbehaving Node Sender can alternate between the ECT(0) / ECT(1) codepoints to discover if a misbehaving node (another router or Receiver) is erasing the CE codepoint. The misbehaving node would not be repeatedly able to correctly reconstruct the Sender’s ECT dodepoint. More likely, repeated erasure of the CE codepoint would be soon discovered by the Sender. () But then how can the congested router notify the Receiver about the congestion? -- The router cannot distinguish between “Sender” and “Receiver”– for it all IP packets are just IP packets!? Note that RFC 3168 does not say that misbehaving node detection is based on a simple reflection of ECT() codepoints by the Receiver. Instead, it only says: “The ECN nonce allows the development of mechanisms for the sender to probabilistically verify that network elements are not erasing the CE codepoint…”

40. TCP Header

41. Modify TCP Header 8 9 C W R E C E (b) CWR = Sender informs Receiver that CongWin reduced ECE = ECN echo, Receiver informs Sender when CE received

42. Explicit Congestion Notification (ECN) () The congested router cannot notify the Receiver about the congestion using “pure” ACK packets, because they must use codepoint “00,” indicates a not-ECT-capable source An ECT codepoint is set in packets transmitted by the sender to indicate that ECN is supported by the transport entities for these packets. An ECN-capable router detects impending congestion and detects that an ECT codepoint is set in the packet it is about to drop. Instead of dropping the packet, the router chooses to set the CE codepoint in the IP header and forwards the packet. The receiver receives the packet with the CE codepoint set, and sets the ECN-Echo flag in its next TCP ACK sent to the sender. The sender receives the TCP ACK with ECN-Echo set, and reacts to the congestion as if a packet had been dropped. The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag. 1 2 3 4 5

43. Topic:Multiprotocol Label Switching (MPLS)  Constraint-based routing  Traffic engineering  Virtual private networks (VPNs)

44. MPLS Operation: Supporting Tunnels

45. How Is MPLS Switching Different From IP Forwarding? • MPLS labels are simple integer numbers • IP addresses are hierarchically structured (dotted decimal notation) • Matching MPLS labels is simpler because they are fixed length; can be directly indexed into an array • IP network prefixes are variable length; require search for a longest match • MPLS switching table needs to have entries only for the adjacent routers • IP forwarding table needs to have entries for all network prefixes in the world!

46. Label Switched Path

47. MPLS Protocol Layering Network layer

48. MPLS Label Format

49. MPLS Label Format

50. Label Bindings, LIB, and LFIB LSR