Explicit Allocation of Best-Effort Service

1. Explicit Allocation of Best-Effort Service • Goal: Allocate different rates to different users during congestion • Can charge different prices to different users • Can identify non-responsive users at aggregation points • Can control bandwidth allocation at sender or receiver • Differential dropping algorithm at routers • Tagging algorithm for profile meters at edge devices • Consider TCP bulk-data transfers

2. Other Alternatives • Priority scheduling - does not have a mechanism for weighted service • Weighted Fair Queueing - may not scale at core routers with hundreds or thousands of flows • Tagging packets as in or out, and treat them differently - similar to CLP bit in ATM

3. Allocated-Capacity Framework • Define a service allocation profile for each user • Routers favor traffic that is within those service profiles • Tag packets as “in” or “out” • A congested router preferentially drop “out” packets • Packets from all users are aggregated into one FCFS queue • Different users with different profiles will have different numbers of “in” packets in the queue • Routers implement dropping scheme - don’t have to worry about packet re-ordering (and associated overhead or jitter) since FCFS is used • Profile Meters at the edge implement tagging

4. Design Issues • Policy meters at source side of network boundary • Checking meters at receiver side of network boundary • Profile meters toward the core only need to look at large aggregates • Decoupling of differential dropping inside the network and service allocation profiles at the edge • Only need to create a profile meter to adopt a new service • Different service models: - dedicated rate for a source-destination pair - aggregated commitment to a range of destinations or anywhere (PVN). In this case, enough resources have to be provisioned to support all users sending “in” traffic simultaneously to any destination - Becomes challenging for sources that are bursty or with rate fluctuations (like TCP) to which the profile must conform

5. More Design Issues • A range of service assurance should be provided • A higher assurance service will cost more • Statistically provisioned service allocation profiles do not describe a strict guarantee • Different users should be allowed to have different expectations • It is not necessary to separate out each individual flow, e.g., use a couple of queues for different levels of assurance. Within each queue, provide preferential treatment using “in” and “out” tags • Statistical assurance is a matter of provisioning • Receiver-controlled bandwidth allocation relies on TCP-ECN • If receiver’s profile is exceeded, packets with ECN bit set are left unchanged or dropped to notify sender to slow down • Problematic in presence of malicious users

6. Allocated Capacity for TCP Bulk Transfers • Service allocation profile: provides a specific (target) average throughput to anywhere with a range of RTTs • Provisioning: sum of all service allocation profiles sold to customers does not exceed the link speed • Want TCP to oscillate between 0.66 and 1.33 of target rate, in fast recovery (not slow start) • RIO: RED with in/out bit • Twin RED algorithms, one for “in” and one for “out” • Discriminates against “out” packets during congestion • min threshold for “out” is smaller than that of “in” • maxP for “out” is higher than that of “in” • max threshold for “out” is smaller than that of “in” • For an arriving “out” packet, use total avg queue length • In a well-provisioned network, “in” packets are never dropped

7. Profile Meters • Time-sliding window (TSW) tagger • TSW provides a smooth estimate of the TCP sending rate over a period of time • Tag packets as “out” once estimated average rate exceeds the target rate • TSW remembers a window length worth of past history • Approach 1: - If average rate exceeds target rate, tag packets as “out” with P = (avgrate - target)/target - Otherwise, tag packets as “in” • Approach 2 (used later): - Window length in the order of an RTT (short history) - Start tagging packets as “out” once peak of TCP sawtooth exceeds 1.33 target rate

8. Difficulties • If profile meter is not in host, it is difficult to set window length to an appropriate RTT • Connections with longer RTTs than the presumed value will fall slightly under expectations • If a burst of packets is tagged as “out”, this may force TCP into slow start • Solution: space out packets tagged as “out” by using a probabilistic function • To avoid these problems: - use profile meter in host - keep TCP in fast recovery using receiver-based control (where there are no drops) or using TCP-SACK

9. Observations • TCP has a bias against long RTT connections • TCP connections with same RTTs can get different throughput • RIO-TSW improves performance of long RTT connections by giving them slightly lower rate than the target • Receiver-based control avoids packet drops, resulting in TCP operating in fast recovery mode and hence better performance • If the profile is “to anywhere”, there is a range of “anywhere” that is feasible with high assurance • TCP-SACK can recover multiple losses in a window and remain in fast recovery ==> higher predictability • Policy meter in host can insure differential service for a much longer range of RTTs (need “checking” meter to catch hosts that are cheating)

10. To Conclude • Can detect non-responsive connections as having disproportional number of “out” packets being dropped • “average throughput to everywhere” is harder than “average throughput for a source-destination pair” • Design pushes most of the complexity to the edge of the network, making it scalable and flexible