ABE Providing a Low Delay within Best Effort.ppt

ABE: Providing a Low Delay within Best Effort P. Hurley, M. Kara, J. Le Boudec, and P. Thiran ICA, Swiss Federal Institute of Technology, Lausanne, Switzerland Sprint ATL, California Department of Computer Science, University of Leeds, UK IEEE Network Magazine May/June 2001 Introduction Multimedia applications can perform well under a wide-range of loss (with repair) Delay often the major impediment for interactive MM applications Internet is “best-effort” with one QoS of traffic for all DiffServ requires monitoring of classes Want to keep it simple, but add support for delay sensitive MM traffic ? Alternative Best Effort (ABE) Outline Introduction (done) The ABE Service (next) Implementation Simulation Results Related Work Conclusions Outline Introduction (done) The ABE Service Definition (next) Green does not hurt blue Router requirements Inter-working and Migration Implementation Simulation Results Related Work Conclusions Definition ABE packets are either green or blue (Neutral colors, green for “go”) Application chooses to make packets green Default is blue (most applications) Green packets get low, bounded delay Green does not hurt blue Blue has same or better throughput even if green traffic All ABE packets in same best-effort class Traditional congestion control All blue gets more throughput than all green Possible Packet Coloring Strategy Discussion Interactive applications send mix of blue and green “Probe” packets to determine region Traditional applications send all blue Care more about throughput Note, says nothing about TCP-friendly Still same problem as with best-effort Green makes it no worse since doesn’t hurt blue Backbones have low delay, so likely ABE in peripheral routers Delay bound offered depends upon hops Assume 2-6 low-speed hops Delay 100-150 msec total, maybe 50 for network Per-hop delay about 5-20 msec Outline Introduction (done) The ABE Service Definition (done) Green does not hurt blue (next) Router requirements