@techreport {25062,
	title = {Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture},
	number = {draft-briscoe-tsvwg-l4s-arch-01},
	year = {2017},
	note = {(Work in Progress)},
	month = {03/2017},
	publisher = {Internet Engineering Task Force},
	abstract = {This document describes the L4S architecture for the provision of a new service that the Internet could provide to eventually replace best efforts for all traffic: Low Latency, Low Loss, Scalable throughput (L4S).\&nbsp; It is becoming common for all (or most) applications being run by a user at any one time to require low latency.\&nbsp; However, the only solution the IETF can offer for ultra-low queuing delay is Diffserv, which only favours a minority of packets at the expense of others.\&nbsp; In extensive testing the new L4S service keeps average queuing delay under a millisecond for all applications even under very heavy load, without sacrificing utilization; and it keeps congestion loss to zero.\&nbsp; It is becoming widely recognized that adding more access capacity gives diminishing returns, because latency is becoming the critical problem.\&nbsp; Even with a high capacity broadband access, the reduced latency of L4S remarkably and consistently improves performance under load for applications such as interactive video, conversational video, voice, Web, gaming, instant messaging, remote desktop and cloud-based apps (even when all being used at once over the same access link).\&nbsp; The insight is that the root cause of queuing delay is in TCP, not in the queue.\&nbsp; By fixing the sending TCP (and other transports) queuing latency becomes so much better than today that operators will want to deploy the network part of L4S to enable new products and services. Further, the network part is simple to deploy - incrementally with zero-config.\&nbsp; Both parts, sender and network, ensure coexistence with other legacy traffic.\&nbsp; At the same time L4S solves the long-recognized problem with the future scalability of TCP throughput.This document describes the L4S architecture, briefly describing the different components and how the work together to provide the aforementioned enhanced Internet service.},
	keywords = {Algorithms, Analysis, AQM, Congestion Avoidance, congestion control, Data Communication, Design, Evaluation, Internet, latency, networks, Performance, QoS, Scaling, tcp},
	url = {https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch},
	author = {Briscoe, Bob and De Schepper, Koen and Bagnulo, Marcelo}
}
@techreport {23797,
	title = {DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput},
	number = {draft-briscoe-tsvwg-aqm-dualq-coupled-00},
	year = {2016},
	note = {(Work in Progress)},
	month = {10/2016},
	publisher = {Internet Engineering Task Force},
	abstract = {Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---throughput starves. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification defines {\textquoteleft}DualQ Coupled Active Queue Management (AQM)\&$\#$39; to allow scalable congestion controls like DCTCP to safely co-exist with classic Internet traffic. The Coupled AQM ensures that a flow runs at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but without inspecting transport layer flow identifiers. When tested in a residential broadband setting, DCTCP achieved sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and {\textquoteleft}Classic\&$\#$39; broadband Internet traffic, without compromising the performance of the Classic traffic. The solution also reduces network complexity and eliminates network configuration.},
	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-aqm-dualq-coupled},
	author = {De Schepper, Koen and Briscoe, Bob and Bondarenko, Olga and Tsang, Inton}
}
@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}
}
@techreport {25063,
	title = {Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Problem Statement},
	number = {draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-02},
	year = {2016},
	note = {(Work in Progress)},
	month = {07/2016},
	publisher = {Internet Engineering Task Force},
	abstract = {This document motivates a new service that the Internet could provide to eventually replace best efforts for all traffic: Low Latency, Low Loss, Scalable throughput (L4S).\&nbsp; It is becoming common for all (or most) applications being run by a user at any one time to require low latency.\&nbsp; However, the only solution the IETF can offer for ultra-low queuing delay is Diffserv, which only favours a minority of packets at the expense of others.\&nbsp; In extensive testing the new L4S service keeps average queuing delay under a millisecond for all applications even under very heavy load, without sacrificing utilization; and it keeps congestion loss to zero.\&nbsp; It is becoming widely recognized that adding more access capacity gives diminishing returns, because latency is becoming the critical problem.\&nbsp; Even with a high capacity broadband access, the reduced latency of L4S remarkably and consistently improves performance under load for applications such as interactive video, conversational video, voice, Web, gaming, instant messaging, remote desktop and cloud-based apps (even when all being used at once over the same access link).\&nbsp; The insight is that the root cause of queuing delay is in TCP, not in the queue.\&nbsp; By fixing the sending TCP (and other transports) queuing latency becomes so much better than today that operators will want to deploy the network part of L4S to enable new products and services. Further, the network part is simple to deploy - incrementally with zero-config.\&nbsp; Both parts, sender and network, ensure coexistence with other legacy traffic.\&nbsp; At the same time L4S solves the long-recognized problem with the future scalability of TCP throughput.This document explains the underlying problems that have been preventing the Internet from enjoying such performance improvements. It then outlines the parts necessary for a solution and the steps that will be needed.},
	keywords = {Algorithms, Analysis, AQM, Congestion Avoidance, congestion control, Data Communication, Design, Evaluation, Internet, latency, networks, Performance, QoS, Scaling, tcp},
	url = {https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem},
	author = {Briscoe, Bob and De Schepper, Koen and Bagnulo, Marcelo}
}
@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 {23805,
	title = {{\textquoteleft}Data Center to the Home{\textquoteright}:  Ultra-Low  Latency for All},
	year = {2015},
	month = {06/2015},
	publisher = {RITE Project},
	keywords = {Algorithms, Analysis, AQM, Congestion Avoidance, congestion control, Data Communication, Design, Evaluation, Internet, latency, networks, Performance, QoS, Scaling, tcp},
	url = {http://riteproject.eu/publications/},
	author = {De Schepper, Koen and Bondarenko, Olga and Tsang, Inton and Briscoe, Bob}
}
@techreport {23798,
	title = {Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay},
	year = {2015},
	note = {(Work in Progress)},
	month = {10/2015},
	publisher = {IETF},
	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-00},
	author = {De Schepper, Koen and Tsang, Inton}
}
@techreport {23803,
	title = {Insights from Curvy RED (Random Early Detection)},
	year = {2015},
	month = {05/2015},
	publisher = {BT},
	keywords = {Algorithms, Analysis, AQM, Congestion Avoidance, congestion control, Data Communication, Design, Internet, networks, Performance, QoS, Scaling, tcp},
	url = {http://www.bobbriscoe.net/projects/latency/credi_tr.pdf},
	author = {Briscoe, Bob}
}
@techreport {23804,
	title = {Scaling TCP{\textquoteright}s Congestion Window for Small Round Trip Times},
	number = {TR-TUB8-2015-002},
	year = {2015},
	month = {05/2015},
	publisher = {BT},
	keywords = {Algorithms, Analysis, AQM, Congestion Avoidance, congestion control, Data Communication, Design, Internet, networks, Performance, Scaling, tcp},
	url = {http://www.bobbriscoe.net/projects/latency/sub-mss-w.pdf},
	author = {Briscoe, Bob and De Schepper, Koen}
}
@article {Briscoe15g:uld4all_jour-ietf,
	title = {Ultra-Low Delay for All},
	journal = {IETF Journal},
	volume = {11},
	year = {2015},
	month = {11/2015},
	pages = {20{\textendash}21},
	publisher = {Internet Society},
	keywords = {Algorithms, Analysis, AQM, Congestion Avoidance, congestion control, Data Communication, Design, Evaluation, Internet, latency, networks, Performance, QoS, Scaling, tcp},
	url = {http://www.internetsociety.org/publications/ietf-journal-november-2015/ultra-low-delay-for-all},
	author = {Briscoe, Bob}
}
@inproceedings {mascots,
	title = {Modeling and Analysis of Opportunistic Routing in Multi-hop Wireless Networks},
	journal = {Modelling, Analysis Simulation of Computer and Telecommunication Systems (MASCOTS), 2014 IEEE 22nd International Symposium on},
	year = {2014},
	month = {Sept},
	pages = {337-344},
	publisher = {IEEE},
	keywords = {Analysis, Analytical models, broadcast nature, candidate selection algorithm, communication reliability, data packet delivery, Equations, ExNT, expected number-of-transmissions, link delivery probability, Markov chain, Markov processes, Mathematical model, Modeling, multihop wireless networks, network resources, network topology, next-hop forwarder, Opportunistic Routing, opportunistic routing analysis, opportunistic routing modeling, OR, packet forwarding, radio networks, re-transmission maximum number, Routing, Telecommunication network reliability, telecommunication network routing, telecommunication network topology, Topology, Wireless Networks},
	issn = {1526-7539},
	doi = {10.1109/MASCOTS.2014.49},
	author = {Darehshoorzadeh, A. and Maria Isabel {Sanchez} and Boukerche, A.}
}
