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

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

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

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

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

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

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

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

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)

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