@techreport {23806,
	title = {Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay},
	number = {draft-briscoe-tsvwg-ecn-l4s-id-02},
	year = {2016},
	note = {(Work in Progress)},
	month = {10/2016},
	publisher = {IETF},
	abstract = {This specification defines the identifier to be used on IP packets for a new network service called low latency, low loss and scalable throughput (L4S).  It is similar to the original (or {\textquoteright}Classic{\textquoteright}) Explicit Congestion Notification (ECN).  {\textquoteright}Classic{\textquoteright} ECN marking was required to be equivalent to a drop, both when applied in the network and when responded to by a transport.  Unlike {\textquoteright}Classic{\textquoteright} ECN marking, for packets carrying the L4S identifier, the network applies marking more immediately and more aggressively than drop, and the transport response to each mark is reduced and smoothed relative to that for drop.  The two changes counterbalance each other so that the throughput of an L4S flow will be roughly the same as a {\textquoteright}Classic{\textquoteright} flow under the same conditions.  However, the much more frequent control signals and the finer responses to them result in ultra-low queuing delay without compromising link utilization, even during high load.  Examples of new active queue management (AQM) marking algorithms and examples of new transports (whether TCP-like or real-time) are specified separately.  The new L4S identifier is the key piece that enables them to interwork and distinguishes them from {\textquoteright}Classic{\textquoteright} traffic.  It gives an incremental migration path so that existing {\textquoteright}Classic{\textquoteright} TCP traffic will be no worse off, but it can be prevented from degrading the ultra-low delay and loss of the new scalable transports.},
	keywords = {Algorithms, Analysis, AQM, Congestion Avoidance, congestion control, Data Communication, Design, Evaluation, Internet, latency, networks, Performance, QoS, Scaling, tcp},
	url = {http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id},
	author = {De Schepper, Koen and Briscoe, Bob and Tsang, Ing-Jyh}
}
@inproceedings {DeSchepper16a:PI2,
	title = {PI2 : A Linearized AQM for both Classic and Scalable TCP},
	journal = {Proc. ACM CoNEXT 2016},
	year = {2016},
	month = {12/2016},
	pages = {105-119},
	publisher = {ACM},
	address = {New York, NY, USA},
	abstract = {This paper concerns the use of Active Queue Management (AQM) to reduce queuing delay. It offers insight into why it has proved hard for a Proportional Integral (PI) controller to remain both responsive and stable while controlling {\textquoteleft}Classic\&$\#$39; TCP flows, such as TCP Reno and Cubic. Due to their non-linearity, the controller\&$\#$39;s adjustments have to be smaller when the target drop probability is lower. The PI Enhanced (PIE) algorithm attempts to solve this problem by scaling down the adjustments of the controller using a look-up table. Instead, we control an internal variable that is by definition linearly proportional to the load, then post-process it into the required Classic drop probability---in fact we show that the output simply needs to be squared. This allows tighter control, giving responsiveness and stability better or no worse than PIE achieves, but without all its corrective heuristics.With suitable packet classification, it becomes simple to extend this PI2 AQM to support coexistence between Classic and Scalable congestion controls in the public Internet. A Scalable congestion control ensures sufficient feedback at any flow rate, an example being Data Centre TCP (DCTCP). A Scalable control is linear, so we can use the internal variable directly without any squaring, by omitting the post-processing stage.We implemented PI2 as a Linux qdisc to extensively test our claims using Classic and Scalable TCPs.\&nbsp;},
	keywords = {Algorithms, Analysis, AQM, Congestion Avoidance, congestion control, Data Communication, Design, Evaluation, Internet, latency, networks, Performance, QoS, Scaling, tcp},
	isbn = {978-1-4503-4297-1},
	doi = {10.1145/2999572.2999578},
	url = {http://dl.acm.org/citation.cfm?doid=2999572.2999578},
	author = {De Schepper, Koen and Bondarenko, Olga and Tsang, Ing-Jyh and Briscoe, Bob}
}
@inproceedings {Bondarenko16a:uld4all-demo,
	title = {Ultra-Low Delay for All: Live Experience, Live Analysis},
	journal = {Proc. ACM Multimedia Systems; Demo Session},
	year = {2016},
	month = {05/2016},
	pages = {33:1-33:4},
	publisher = {ACM},
	abstract = {This demo dramatically illustrates how replacing {\textquoteleft}Classic\&$\#$39; TCP congestion control (Reno, Cubic, etc.) with a {\textquoteleft}Scalable\&$\#$39; alternative like Data Centre TCP (DCTCP) keeps queuing delay ultra-low; not just for a select few light applications like voice or gaming, but even when a variety of interactive applications all heavily load the same (emulated) Internet access. DCTCP has so far been confined to data centres because it is too aggressive---it starves Classic TCP flows. To allow DCTCP to be exploited on the public Internet, we developed DualQ Coupled Active Queue Management (AQM), which allows the two TCP types to safely co-exist. Visitors can test all these claims. As well as running Web-based apps, they can pan and zoom a panoramic video of a football stadium on a touch-screen, and experience how their personalized HD scene seems to stick to their finger, even though it is encoded on the fly on servers accessed via an emulated delay, representing {\textquoteleft}the cloud\&$\#$39;. A pair of VR goggles can be used at the same time, making a similar point. The demo provides a dashboard so that visitors can not only experience the interactivity of each application live, but they can also quantify it via a wide range of performance stats, updated live. It also includes controls so visitors can configure different TCP variants, AQMs, network parameters and background loads and immediately test the effect.},
	keywords = {Algorithms, Analysis, AQM, Congestion Avoidance, congestion control, Data Communication, Design, Evaluation, Internet, latency, networks, Performance, QoS, Scaling, tcp},
	isbn = {978-1-4503-4297-1},
	doi = {10.1145/2910017.2910633},
	url = {http://www.bobbriscoe.net/projects/latency/uld4all-demo_mmsys.pdf},
	author = {Bondarenko, Olga and De Schepper, Koen and Tsang, Ing-Jyh and Briscoe, Bob and Petlund, Andreas and Griwodz, Carsten}
}
@techreport {23801,
	title = {Deployment of RITE mechanisms in use-case trial testbeds report},
	number = {D3.3},
	year = {2015},
	month = {11/2015},
	publisher = {RITE Eu FP7 Project 317700},
	keywords = {Algorithms, characterisation, co-ordination, congestion, Data Communication, Delay, Internet, metrics, networks, overhead, Performance, QoS, standardisation},
	url = {https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-public1.pdf},
	author = {Tsang, Ing-Jyh and Petlund, Andreas and Briscoe, Bob and Bondarenko, Olga and Others, Numerous},
	editor = {Tsang, Ing-Jyh}
}
@inproceedings {23496,
	title = {Internet Latency: Causes, Solutions and Trade-offs},
	journal = {EuCNC Special session on latency},
	year = {2015},
	month = {05/2015},
	abstract = {This paper is a digest of [1], an extensive survey discussing the merits of over 300 techniques for reducing Internet latency. It gives a broad overview of the causes, solutions, and trade-offs involved in reducing latency in the Internet. The overview covers key sources of delays and proposed solutions: due to the structural arrangement of the network, how network end-points interact, along the end-to-end path, related to link capacities, within end-hosts, and those that address multiple sources. Trade-offs are discussed in terms of the latency reduction different techniques provide versus their deployability},
	url = {https://riteproject.files.wordpress.com/2015/12/p548-hayes.pdf},
	author = {David Andrew {Hayes} and Tsang, Ing-Jyh and Ros, David and Petlund, Andreas and Briscoe, Bob}
}
@article {19168,
	title = {Reducing Internet Latency: A Survey of Techniques and their Merits},
	journal = {IEEE Communications Surveys and Tutorials},
	volume = {18},
	year = {2014},
	month = {10/2016},
	pages = {2149{\textendash}2196},
	publisher = {IEEE Communications Society},
	abstract = {Latency is increasingly becoming a performance bottleneck for Internet Protocol (IP) networks, but historically networks have been designed with aims of maximizing throughput and utilization. This article offers a broad survey of techniques aimed at tackling latency in the literature up to August 2014, and their merits. A goal of this work is to be able to quantify and compare the merits of the different Internet latency reducing techniques, contrasting their gains in delay reduction versus the pain required to implement and deploy them. We found that classifying techniques according to the sources of delay they alleviate provided the best insight into the following issues: 1) the structural arrangement of a network, such as placement of servers and suboptimal routes, can contribute significantly to latency; 2) each interaction between communicating endpoints adds a Round Trip Time (RTT) to latency, especially significant for short flows; 3) in addition to base propagation delay, several sources of delay accumulate along transmission paths, today intermittently dominated by queuing delays; 4) it takes time to sense and use available capacity, with overuse inflicting latency on other flows sharing the capacity; and 5) within end systems delay sources include operating system buffering, head-of-line blocking, and hardware interaction. No single source of delay dominates in all cases, and many of these sources are spasmodic and highly variable. Solutions addressing these sources often both reduce the overall latency and make it more predictable.},
	keywords = {Internet, latency, network},
	issn = {1553-877X},
	doi = {10.1109/COMST.2014.2375213},
	url = {http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true\&arnumber=6967689},
	author = {Briscoe, Bob and Brunstr{\"o}m, Anna and Petlund, Andreas and David Andrew {Hayes} and Ros, David and Tsang, Ing-Jyh and Gjessing, Stein and Fairhurst, Gorry and Griwodz, Carsten and Welzl, Michael}
}
@inproceedings {Briscoe13a:latency_survey_pos,
	title = {A Survey of Latency Reducing Techniques and their Merits},
	journal = {Proc. ISOC Workshop on Reducing Internet Latency},
	year = {2013},
	note = {(Position Paper)},
	month = {09/2013},
	keywords = {Algorithms, characterisation, co-ordination, congestion, Data Communication, Delay, Internet, metrics, networks, overhead, Performance, QoS, standardisation},
	url = {http://www.internetsociety.org/sites/default/files/pdf/accepted/16_rite-latency_survey_pos.pdf},
	author = {Briscoe, Bob and Brunstr{\"o}m, Anna and Ros, David and Petlund, Andreas and Tsang, Ing-Jyh and Gjessing, Stein and Fairhurst, Gorry}
}
