@article {43417,
	title = {LGCC: A Novel High-Throughput and Low Delay Paradigm Shift in Multi-Hop Congestion Control},
	journal = {IEEE/ACM Transactions on Networking },
	year = {2023},
	month = {08/2023},
	pages = {1-16},
	publisher = { IEEE},
	abstract = {Technological advancements have provided wireless links with very high data rate capacity for 5G/6G mobile networks and WiFi 6, which will be widely deployed by 2025. However, the capacity can have substantial fluctuations, violating the assumption at the transport layer that the capacity is (almost) steady. In this paper, we present a general and efficient, yet deployable solution to this problem through a novel design empowered with a rich theory, allowing a significantly improved experience in using new technologies, especially mobile cellular services. We employ the well-known theory of food-chain models in biology, where a bottleneck link can be modeled as prey, while flows are predators. We extend this model to a chain of predators and preys to form a multi-hop congestion controller, called LGCC. Through simulation evaluation with real-life 5G traces we show the effectiveness of LGCC, compared with the state-of-the-art ABC (Accel-Brake Control). Our results show an order of magnitude bottleneck queuing delay decrease, with only a small decrease in throughput because LGCC tries to never exceed link capacities. LGCC{\textquoteright}s design can additionally open a new paradigm in stable multi-hop congestion control and flow aggregation.},
	keywords = {5G/6G, food chain, logistic growth, Multi-hop congestion control},
	issn = {1558-2566},
	doi = {10.1109/TNET.2023.3301291},
	url = {https://ieeexplore.ieee.org/document/10216921},
	author = {Teymoori, Peyman and Welzl, Michael and Hayes, David}
}
@article {27478,
	title = {Estimating an Additive Path Cost with Explicit Congestion Notification},
	journal = {IEEE Transactions on Control of Network Systems},
	volume = {8},
	year = {2021},
	note = {Currently published in early access on IEEExplore.},
	month = {06/2021},
	pages = {859--871},
	publisher = { IEEE},
	abstract = {Network Utility Maximization (NUM) is a well accepted theoretical framework that describes how congestion controls cooperate to achieve an ideal sending rate allocation, for given utility functions of senders and constraints of the network. These network constraints are expressed as a "cost{\textquoteright}{\textquoteright} in the framework. In practice, most congestion control mechanisms obtain feedback that is different from the framework{\textquoteright}s "cost{\textquoteright}{\textquoteright}. This paper focuses on Explicit Congestion Notification (ECN), which has been shown to be advantageous when it is available, e.g. with the popular Datacenter TCP (DCTCP) mechanism. However, different from the framework{\textquoteright}s cost, ECN marks are not additive. We present a practical solution to this problem. Our solution changes how end hosts interpret the ECN signal, while for the router side, a special configuration of RED is used.},
	issn = { 2325-5870},
	doi = {10.1109/TCNS.2021.3053179},
	url = {https://doi.org/10.1109/TCNS.2021.3053179},
	author = {Teymoori, Peyman and David Andrew {Hayes} and Welzl, Michael and Gjessing, Stein}
}
@misc {28154,
	title = {Update on SBD (RFC 8382)},
	howpublished = {The Internet Engineering Task Force, IETF 112},
	year = {2021},
	note = {https://datatracker.ietf.org/meeting/112/proceedings},
	publisher = {IETF},
	type = {Talk to the RMCAT working group},
	abstract = {Comparative evaluation of RFC 8382, comparing vanilla RFC 8382, RFC 8382 stats with dynamic online clustering, offline wavelet filtered cross-correlation, online adaption of the wavelet filtered cross-correlation. Concludes with recommendations for future work.},
	url = {https://datatracker.ietf.org/meeting/112/materials/slides-112-rmcat-update-on-sbd-00},
	author = {David Andrew {Hayes} and Welzl, Michael and Ferlin, Simone}
}
@article {27365,
	title = {Online Identification of Groups of Flows Sharing a Network Bottleneck},
	journal = {IEEE/ACM Transactions on Networking},
	volume = {28},
	number = {5},
	year = {2020},
	note = {Published in the Early Access area on IEEE Xplore.\&nbsp;\&nbsp;The content is final as presented with the exception of pagination andissue designation, which will be assigned when included in the future issue.},
	pages = {2229--2242},
	publisher = {IEEE/ACM},
	abstract = {Abstract{\textemdash}Most Internet hosts today support multiple access technologies and network interfaces. Multipath transport protocols, like MPTCP, are being deployed (e.g., in smartphones), allowing transparent simultaneous use of multiple links. Besides providing increased resilience to link failures, multipath trans- ports may better exploit available (aggregate) capacity across all interfaces. The safest way to ensure fairness is to assume that any subflows of a multipath end-to-end connection may share bottleneck links, but knowledge of non-shared bottlenecks could allow multipath senders to exploit more capacity without being unfair to other flows. The problem of reliably detecting the existence of (non)-shared bottlenecks is not trivial and is compounded by the fact that bottlenecks may change due to traffic dynamics. In this paper we focus on practical methods to reliably group flows that share, possibly dynamic, bottlenecks online and in a passive manner (i.e., without injecting measurement traffic). We introduce a novel dynamic clustering algorithm that we apply to update our previous shared bottleneck flow grouping (SBFG) method standardized by the IETF, based on delay statistics. We also adapt an offline SBFG method based on wavelet filters to enable it for online operation. These SBFG methods are evaluated by a simple testbed, rigorous simulation and real-world Internet experiments in a testbed comprised of multihomed hosts. Our results suggest that there is no clear winner, and selection of the {\textquotedblleft}best{\textquotedblright} SBFG method will have to consider tradeoffs regarding accuracy, lag, and application requirements.},
	keywords = {dynamic clustering, Internet congestion control, multipath congestion control., shared bottleneck detection},
	issn = {Print ISSN: 1063-6692, Electronic ISSN: 1558-2566},
	doi = { 10.1109/TNET.2020.3007346},
	author = {David Andrew {Hayes} and Welzl, Michael and Ferlin, Simone and Ros, David and Islam, Safiqul}
}
@article { ComNets2020,
	title = {On the Usability of Transport Protocols other than TCP: A Home Gateway and Internet Path Traversal Study},
	journal = {Computer Networks},
	volume = {173},
	year = {2020},
	month = {05/2020},
	publisher = {Elsevier},
	abstract = {Network APIs are moving towards protocol agility, where applications express their needs but not a static protocol binding, and it is up to the layer below the API to choose a suitable protocol. The IETF Transport Services (TAPS) Working Group is standardizing a protocol-independent transport API and offering guidance to implementers. Apple{\textquoteright}s recent {\textquotedblleft}Network.framework{\textquotedblright} is specifically designed to allow such late and dynamic binding of protocols. When the network stack autonomously chooses and configures a protocol, it must first test which protocols are locally available and which work end-to-end ({\textquotedblleft}protocol racing{\textquotedblright}). For this, it is important to know the set of available options, and which protocols should be tried first: Does it make sense to offer unchecked payload delivery, as with UDP-Lite? Is a UDP-based protocol like QUIC always a better choice, or should native SCTP be tried? This paper develops answers to such questions via (i) a NAT study in a local testbed, (ii) bidirectional Internet tests, (iii) a large scale Internet measurement campaign. The examined protocols are: SCTP, DCCP, UDP-Lite, UDP with a zero checksum and three different UDP encapsulations.},
	keywords = {DCCP, Internet, NAT, Protocol Testing, SCTP, UDP-Lite},
	issn = {1389-1286},
	doi = {10.1016/j.comnet.2020.107211},
	author = {Barik, Runa and Welzl, Michael and Fairhurst, Gorry and Dreibholz, Thomas and Elmokashfi, Ahmed and Gjessing, Stein}
}
@techreport {26310,
	title = {Estimating an Additive Path Cost with Explicit Congestion Notification (extended version)},
	number = {487},
	year = {2019},
	note = {Submitted 2018, awaiting completion of reviews},
	month = {03/2019},
	publisher = {University of Oslo},
	abstract = {Abstract{\textemdash}Network Utility Maximization (NUM) is a well accepted theoretical concept that describes how congestion controls could cooperate to achieve an ideal sending rate allocation, for given utility functions of senders and constraints of the network. These network constraints are expressed as a {\textquotedblleft}cost{\textquotedblright} in the framework. In practice, most congestion control mechanisms obtain feedback that is different from a {\textquotedblleft}cost{\textquotedblright}. This paper focuses on Explicit Congestion Notification (ECN), which has been shown to be quite advantageous when it is available, e.g. with the popular Datacenter TCP (DCTCP) mechanism. However, different from a cost, ECN marks are not additive. We present a practical solution to this problem. Our solution changes how end hosts interpret the ECN signal, while the router side can be implemented via an unusual configuration of RED parameters.},
	isbn = {978-82-7368-452-3},
	issn = {0806-3036},
	url = {https://heim.ifi.uio.no/michawe/research/publications/NUM-ECN_report_2019.pdf},
	author = {Teymoori, Peyman and David Andrew {Hayes} and Welzl, Michael and Gjessing, Stein}
}
@article { PEVA2019,
	title = {On the Utility of Unregulated IP DiffServ Code Point (DSCP) Usage by End Systems},
	journal = {Performance Evaluation},
	volume = {135},
	year = {2019},
	month = {08/2019},
	pages = {102036},
	publisher = {Elsevier},
	abstract = {DiffServ was designed to implement service provider quality of service (QoS) policies, where routers change and react upon the DiffServ Code Point\&nbsp;(DSCP) in the IP header. However, nowadays, applications are beginning to directly set the DSCP themselves, in the hope that this will yield a more appropriate service for their respective video, audio and data streams. WebRTC is a prime example of such an application. We present measurements, for both IPv4 and IPv6, of what happens to DSCP values along Internet paths after an end system has set them without any prior agreement between a customer and a service provider. We find that the DSCP is often changed or zeroed along the path, but detrimental effects from using the DSCP are extremely rare; moreover, DSCP values sometimes remain intact (potentially having an effect on traffic) for several AS hops. This positive result motivates an analysis of the potential latency impact from such DSCP usage, for which we present the first measurement results. We find that routers at approximately 3\% of more than 100,000 links differentiate between the WebRTC DSCP values (EF, AF42 and CS1) and consistently reduce delay in comparison with probes carrying a zero value (CS0) under congestion. In contrast, routers at around 2\% of these links increase the delay by a comparable amount under congestion, uniformly for EF, AF42 and CS1.},
	keywords = {DiffServ, DiffServ Code Point, latency, QoS, WebRTC},
	issn = {0166-5316},
	doi = {10.1016/j.peva.2019.102036},
	url = {https://doi.org/10.1016/j.peva.2019.102036},
	author = {Barik, Runa and Welzl, Michael and Elmokashfi, Ahmed and Dreibholz, Thomas and Islam, Safiqul and Gjessing, Stein}
}
@inproceedings {26000,
	title = {Can WebRTC QoS Work? A DSCP Measurement Study},
	journal = {2018 30th International Teletraffic Congress (ITC 30)},
	year = {2018},
	month = {09/2018},
	pages = {167-175},
	publisher = {IEEE Computer Society},
	address = {Vienna, Austria},
	abstract = {DiffServ was designed to implement service provider quality of service (QoS) policies, where ingress and egress routers change the DiffServ Code Point (DSCP) in the IP header. However, nowadays, applications are beginning to directly set the DSCP themselves, in the hope that this will yield a more appropriate service for their respective video, audio and data streams. WebRTC is a prime example of such an application.
As a first step towards understanding whether "WebRTC QoS works", we measured, for both IPv4 and IPv6, what happens to DSCP values along Internet paths. Our study is based on end-to-end measurements from 160 IPv4 and 65 IPv6 geographically spread controlled probe clients to 34 IPv4 and 18 IPv6 servers respectively. Clearly, when the DSCP value is changed, the net result may not be what the application desired. We find that this happens often, and conclude with recommendations on how to improve WebRTC and other applications using the DSCP.},
	keywords = {DSCP, Egress, Fling, Ingress, Measurement},
	isbn = {978-0-9883045-5-0},
	doi = {10.1109/ITC30.2018.00034},
	author = {Barik, Runa and Welzl, Michael and Elmokashfi, Ahmed and Dreibholz, Thomas and Gjessing, Stein}
}
@inproceedings {25844,
	title = {ctrlTCP: Reducing Latency through Coupled, Heterogeneous Multi-Flow TCP Congestion Control},
	journal = {21st IEEE Global Internet Symposium (GI 2018)},
	year = {2018},
	note = {In conjunction with IEEE INFOCOM, Honolulu, HI, USA},
	month = {04/2018},
	publisher = {IEEE},
	address = {Honolulu, HI, USA},
	doi = {10.1109/INFCOMW.2018.8406887},
	url = {https://www.duo.uio.no/handle/10852/71297},
	author = {Islam, Safiqul and Welzl, Michael and Hiorth, Kristian and David Andrew {Hayes} and Armitage, Grenville and Gjessing, Stein}
}
@misc {Simula.simula.3058,
	title = {Shared Bottleneck Detection for Coupled Congestion Control for RTP Media},
	howpublished = {RFC 8382},
	year = {2018},
	note = {Internet Engineering Task Force (IETF)Request for Comments: 8382Category: ExperimentalISSN: 2070-1721},
	month = {06/2018},
	publisher = {RFC Editor},
	type = {IETF RFC},
	edition = {Internet Requests for Comments},
	abstract = {This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed},
	issn = {2070-1721},
	doi = {10.17487/RFC8382},
	url = {https://www.rfc-editor.org/info/rfc8382},
	author = {David Andrew {Hayes} and Ferlin, Simone and Welzl, Michael and Hiorth, Kristian}
}
@inproceedings {25278,
	title = {Alternative Backoff: Achieving Low Latency and High Throughput with ECN and AQM},
	journal = {IFIP Networking},
	year = {2017},
	note = {Best Paper Award},
	publisher = {IFIP},
	abstract = {A number of recently proposed Active Queue Management (AQM) mechanisms instantiate shallow buffers with burst tolerance to minimise the time that packets spend enqueued at a bottleneck. However, shallow buffering causes noticeable TCP performance degradation as a path{\textquoteright}s underlying round trip time (RTT) heads above typical intra-country levels. Using less-aggressive multiplicative backoffs in TCP can compensate for shallow bottleneck buffering. AQM mechanisms may either drop packets or mark them using Explicit Congestion Notification (ECN), depending on whether the sender marked packets as ECN-capable. While a drop may therefore stem from any type of queue, an ECN-mark indicates that an AQM mechanism has done its job, and therefore the queue is likely to be shallow. We propose ABE: {\textquotedblleft}Alternative Backoff with ECN{\textquotedblright}, which consists of enabling ECN and letting individual TCP senders back off less aggressively in reaction to ECN-marks from AQM-enabled bottlenecks. Using controlled testbed experiments with standard NewReno and CUBIC flows, we show significant performance gains in lightly-multiplexed scenarios, without losing the delay-reduction benefits of deploying AQM. ABE is a sender-side-only modification that can be deployed across networks incrementally (requiring no flag-day) and offers a compelling reason to deploy and enable ECN across the Internet.},
	keywords = {AQM, congestion control, ECN, low latency, tcp},
	url = {http://dl.ifip.org/db/conf/networking/networking2017/1570335770.pdf},
	author = {Khademi, Naeem and Armitage, Grenville and Welzl, Michael and Zander, Sebastian and Fairhurst, Gorry and Ros, David}
}
@inproceedings {barik2017fling,
	title = {fling: A Flexible Ping for Middlebox Measurements},
	journal = {2017 29th International Teletraffic Congress (ITC 29)},
	volume = {1},
	year = {2017},
	pages = {134{\textendash}142},
	publisher = {IEEE},
	author = {Welzl, Michael and Elmokashfi, Ahmed and Gjessing, Stein and Islam, Safiqul}
}
@article {25372,
	title = {NEAT: A Platform- and Protocol-Independent Internet Transport API},
	journal = {IEEE Communications Magazine},
	volume = {55},
	year = {2017},
	month = {06/2017},
	pages = {46-54},
	publisher = {IEEE},
	abstract = {The sockets Applications Programming Interface (API) has become the standard way that applications access the transport services offered by the Internet Protocol stack. This paper presents NEAT, a user-space library that can provide an alternate transport API. NEAT allows applications to request the service they need using a new design that is agnostic to the specific choice of transport protocol underneath. This not only allows applications to take advantage of common protocol machinery, but also eases introduction of new network mechanisms and transport protocols. The paper describes the components of the NEAT library and illustrates the important benefits that can be gained from this new approach. NEAT is a software platform for developing advanced network applications that was designed in accordance with the standardization efforts on Transport Services (TAPS) in the Internet Engineering Task Force (IETF), but its features exceed the envisioned functionality of a TAPS system.},
	issn = {0163-6804},
	doi = {https://doi.org/10.1109/MCOM.2017.1601052},
	author = {Khademi, Naeem and Ros, David and Welzl, Michael and Bozakov, Zdravko and Brunstr{\"o}m, Anna and Fairhurst, Gorry and Grinnemo, Karl-Johan and David Andrew {Hayes} and Hurtig, Per and Jones, Tom and Mangiante, Simone and T{\"u}xen, Michael and Weinrank, Felix}
}
@article {24989,
	title = {De-ossifying the Internet transport layer: A survey and future perspectives},
	journal = {IEEE Communications Surveys and Tutorials},
	year = {2016},
	month = {11/2016},
	publisher = {IEEE},
	abstract = {It is widely recognized that the Internet transport layer has become ossified, where further evolution has become hard or even impossible. This is a direct consequence of the ubiquitous deployment of middleboxes that hamper the deployment of new transports, aggravated further by the limited flexibility of the Application Programming Interface (API) typically presented to applications. To tackle this problem, a wide range of solutions have been proposed in the literature, each aiming to address a particular aspect. Yet, no single proposal has emerged that is able to enable evolution of the transport layer. In this work, after an overview of the main issues and reasons for transport-layer ossification, we survey proposed solutions and discuss their potential and limitations. The survey is divided into five parts, each covering a set of point solutions for a different facet of the problem space: 1) designing middleboxproof transports, 2) signaling for facilitating middlebox traversal, 3) enhancing the API between the applications and the transport layer, 4) discovering and exploiting end-to-end capabilities, and 5) enabling user-space protocol stacks. Based on this analysis, we then identify further development needs towards an overall solution. We argue that the development of a comprehensive transport layer framework, able to facilitate the integration and cooperation of specialized solutions in an application-independent and flexible way, is a necessary step toward making the Internet transport architecture truly evolvable. To this end, we identify the requirements for such a framework and provide insights for its development.},
	keywords = {API, middleboxes, protocol-stack ossification, transport protocols, user-space networking stacks},
	issn = {1553-877X},
	doi = {https://doi.org/10.1109/COMST.2016.2626780},
	author = {Papastergiou, Georgios and Fairhurst, Gorry and Ros, David and Brunstr{\"o}m, Anna and Grinnemo, Karl-Johan and Hurtig, Per and Khademi, Naeem and T{\"u}xen, Michael and Welzl, Michael and Damjanovic, Dragana and Mangiante, Simone}
}
@inproceedings {24964,
	title = {Even Lower Latency, Even Better Fairness:Logistic Growth Congestion Control in Datacenters},
	journal = {The 41st IEEE Conference on Local Computer Networks (LCN)},
	year = {2016},
	note = {Dubai, UAE. November 7-10.},
	month = {11/2016},
	pages = {10--18},
	publisher = {IEEE},
	abstract = {Datacenter transport has attracted much recent interest, however, most proposed improvements require changing the datacenter fabric, which hinders their applicability and deployability over commodity hardware. In this paper, we present a novel congestion controller, Logistic Growth Control (LGC), for datacenters which does not require changes to the datacenter fabric. LGC uses a similar ECN marking as in DCTCP, but adapts to congestion using the logistic growth\&nbsp; function. This function has been proven to have nice characteristics including stability, convergence, fairness, and scalability, which are very appealing for\&nbsp; congestion control. As a result, our LGC mechanism operates in the datacenter network in a more stable and fair manner, leading to less queuing and latency. LGC also behaves better than DCTCP, and it converges to the fair share of the bottleneck link capacity irrespective of the Round-Trip-Time (RTT). We discuss the stability and fairness of LGC using a fluid model, and show its performance improvement with simulations.},
	isbn = {978-1-5090-2054-6},
	doi = {10.1109/LCN.2016.12},
	author = {Teymoori, Peyman and David Andrew {Hayes} and Welzl, Michael and Gjessing, Stein}
}
@inproceedings {24643,
	title = {Feedback in Recursive Congestion Control},
	journal = {Computer Performance Engineering: 13th European Workshop on Performance Engineering, EPEW 2016, Proceedings},
	volume = {9951},
	year = {2016},
	note = {Chios, Greece, October 5-7},
	month = {09/2016},
	pages = {109--125},
	publisher = {Springer International Publishing},
	edition = {Lecture Notes in Computer Science},
	address = {Cham},
	abstract = {In recursive network architectures such as RINA or RNA, it is\&nbsp;natural for multiple layers to carry out congestion control. \&nbsp;These\&nbsp;layers can be stacked in arbitrary ways and provide more ways to\&nbsp;use feedback than before (which of the many controllers along an\&nbsp;end-to-end path should be notified?). This in turn raises concerns\&nbsp;regarding stability and performance of such a system of interacting\&nbsp;congestion control mechanisms. In this paper, we report on a\&nbsp;\&nbsp;first analysis of feedback methods in recursive networks that we\&nbsp;carried out using a fluid model with a packet queue\&nbsp;approximation. We find that the strict pushback feedback based on\&nbsp;queue size can have stability issues, but robust control can be\&nbsp;achieved when each congestion controller receives feedback\&nbsp;from all sources of congestion within and below its layer.\&nbsp;},
	isbn = {978-3-319-46433-6},
	doi = {10.1007/978-3-319-46433-6_8},
	url = {http://dx.doi.org/10.1007/978-3-319-46433-6_8},
	author = {David Andrew {Hayes} and Teymoori, Peyman and Welzl, Michael},
	editor = {Fiems, Dieter and Paolieri, Marco and Platis, Agapios}
}
@inproceedings {24926,
	title = {How to say that you{\textquoteright}re special: Can we use bits in the IPv4 header?},
	journal = {Proceedings of the 2016 Applied Networking Research Workshop},
	year = {2016},
	author = {Barik, Runa and Welzl, Michael and Elmokashfi, Ahmed}
}
@inproceedings {24287,
	title = {LISA: A Linked Slow-Start Algorithm for MPTCP},
	journal = {IEEE  International Conference on Communications (ICC)},
	year = {2016},
	month = {05/2016},
	author = {Barik, Runa and Welzl, Michael and Ferlin, Simone and Alay, {\"O}zg{\"u}}
}
@inproceedings {24965,
	title = {Managing real-time media flows through a flow state exchange},
	journal = {NOMS 2016  IEEE/IFIP Network Operations and Management Symposium},
	year = {2016},
	month = {04/2016},
	pages = {112--120},
	abstract = {When multiple congestion controlled flows traverse the same network path, their resulting rate is usually an outcome of their competition at the bottleneck. The WebRTC / RTCWeb suite of standards for inter-browser communication is required to allow prioritization. This is addressed by our previously presented mechanism for coupled congestion control, called the Flow State Exchange (FSE). Here, we present our first simulation results using two mechanisms that have been proposed for IETF standardization: Google Congestion Control (GCC) and Network-Assisted Dynamic Adaptation (NADA). These two mechanisms exhibit aspects that allow us to use a simpler \&ldquo;passive\&rdquo; algorithm in our FSE. Passive coupling allows a less time-constrained request-response style of signaling between congestion control mechanisms and the FSE, which enables the FSE to run as a stand-alone management tool.},
	doi = {10.1109/NOMS.2016.7502803},
	author = {Islam, Safiqul and Welzl, Michael and David Andrew {Hayes} and Gjessing, Stein}
}
@inproceedings {23813,
	title = {Revisiting Congestion Control for Multipath TCP with Shared Bottleneck Detection},
	journal = {IEEE International Conference on Computer Communications (INFOCOM)},
	year = {2016},
	month = {04/2016},
	pages = {2419-2427},
	publisher = {IEEE},
	address = {San Francisco, California/U.S.A.},
	abstract = {Multipath TCP (MPTCP) enables the simultaneous usage of multiple links for bandwidth aggregation, better resource utilization and improved reliability. Its coupled congestion control intends to reap the increased bandwidth of multiple links, while avoiding to be more aggressive than regular TCP flows on every used link. We argue that this leads to a very conservative behavior when paths do not share a bottleneck. Therefore, in this paper, we first quantify the penalty of the coupled congestion control for the links that do not share a bottleneck. Then, in order to overcome this penalty, we design and implement a practical shared bottleneck detection (SBD) algorithm for MPTCP, namely MPTCP-SBD. Through extensive emulations, we show that MPTCP-SBD outperforms all currently deployed MPTCP coupled congestion controls by accurately detecting bottlenecks resulting in throughput gains of up to 30\% in the absence of shared bottlenecks while remaining fair to TCP in shared bottlenecks scenarios. We complement the emulation results with real-network experiments justifying it is safeness for deployment.},
	keywords = {congestion control, coupled congestion control, Multi-Path TCP (MPTCP), shared bottleneck detection},
	isbn = {978-1-4673-9953-1},
	doi = {10.1109/INFOCOM.2016.7524599},
	author = {Ferlin, Simone and Alay, {\"O}zg{\"u} and Dreibholz, Thomas and David Andrew {Hayes} and Welzl, Michael}
}
@techreport {abe-caia-2015,
	title = {Alternative Backoff: Achieving Low Latency and High Throughput with ECN and AQM},
	year = {2015},
	month = {07/2015},
	publisher = {Centre for Advanced Internet Architectures (CAIA), Swinburne University of Technology},
	address = {Melbourne, Australia},
	abstract = {CoDel and PIE are recently proposed Active Queue Management (AQM) mechanisms that minimize the time packets spend enqueued at a bottleneck, instantiating shallow, 5 ms to 20 ms buffers with short-term packet burst tolerance. However, shallow buffering causes noticeable TCP performance degradation when a path{\textquoteright}s underlying round trip time (RTT) heads above 60ms to 80ms (not uncommon with cross-continental and inter-continental traffic). Using less-aggressive multiplicative backoffs is known to compensate for shallow bottleneck buffering. We propose ABE: {\textquotedblleft}Alternative Backoff with ECN{\textquotedblright}, which consists of enabling Explicit Congestion Notification (ECN) and letting individual TCP senders use a larger multiplica- tive decrease factor in reaction to ECN-marks from AQM- enabled bottlenecks. Using a mix of experiments, theory and simulations with standard NewReno and CUBIC flows, we show significant performance gains in lightly- multiplexed scenarios, without losing the delay-reduction benefits of deploying CoDel or PIE. ABE is a sender- side-only modification that can be deployed incrementally (requiring no flag-day) and offers a compelling reason to deploy and enable ECN across the Internet.},
	url = {http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf},
	author = {Khademi, Naeem and Welzl, Michael and Armitage, Grenville and Kulatunga, Chamil and Ros, David and Fairhurst, Gorry and Gjessing, Stein and Zander, Sebastian}
}
@article {19183,
	title = {An Evaluation of Tail Loss Recovery Mechanisms for TCP},
	journal = {SIGCOMM Comput. Commun. Rev.},
	volume = {45},
	year = {2015},
	pages = {5{\textendash}11},
	publisher = {ACM},
	address = {New York, NY, USA},
	abstract = {Interactive applications do not require more bandwidth to go faster. Instead, they require less latency. Unfortunately, the current design of transport protocols such as TCP limits possible latency reductions. In this paper we evaluate and compare different loss recovery enhancements to fight tail loss latency. The two recently proposed mechanisms "RTO Restart" (RTOR) and "Tail Loss Probe" (TLP) as well as a new mechanism that applies the logic of RTOR to the TLP timer management (TLPR) are considered. The results show that the relative performance of RTOR and TLP when tail loss occurs is scenario dependent, but with TLP having potentially larger gains. The TLPR mechanism reaps the benefits of both approaches and in most scenarios it shows the best performance.},
	keywords = {congestion control, latency, packet loss, recovery, tcp},
	issn = {0146-4833},
	doi = {10.1145/2717646.2717648},
	url = {http://doi.acm.org/10.1145/2717646.2717648},
	author = {Rajiullah, Mohammad and Hurtig, Per and Brunstr{\"o}m, Anna and Petlund, Andreas and Welzl, Michael}
}
@misc {23700,
	title = {An Evaluation of Tail Loss Recovery Mechanisms for TCP},
	year = {2015},
	publisher = {ACM},
	address = {New York, NY, USA},
	keywords = {congestion control, latency, packet loss, recovery, tcp},
	doi = {10.1145/2717646.2717648},
	url = {http://doi.acm.org/10.1145/2717646.2717648},
	author = {Rajiullah, Mohammad and Hurtig, Per and Brunstrom, Anna and Petlund, Andreas and Welzl, Michael}
}
@misc {23701,
	title = {A Linked Slow-Start Algorithm for MPTCP},
	year = {2015},
	month = {10/2015},
	address = {http://www.ietf.org/id/draft-barik-mptcp-lisa-00.xml},
	abstract = {This document describes the LISA (Linked Slow-Start Algorithm) for\&nbsp;\&nbsp;Multipath TCP (MPTCP). Currently during slow-start, subflows behave like\&nbsp;independent TCP flows making MPTCP behave unfairly to cross-traffic and\&nbsp;causing more congestion in the bottleneck, which yields more losses among\&nbsp;the MPTCP subflows. LISA couples the initial windows (IW) of MPTCP subflows during the initial slow-start phase to remove this adverse behavior.\&nbsp;},
	author = {Barik, Runa and Ferlin, Simone and Welzl, Michael}
}
@inproceedings {aqm-eval-gi-symposium,
	title = {The New AQM Kids on the Block: An Experimental Evaluation of CoDel and PIE},
	journal = {17th IEEE Global Internet Symposium},
	year = {2014},
	month = {04/2014},
	publisher = {IEEE},
	address = {Toronto},
	abstract = {Active Queue Management (AQM) design has again come into the spotlight of network operators, vendors and OS developers. This reflects the growing concern and sensitivity about the end-to-end latency perceived by today{\textquoteright}s Internet users. CoDel and PIE are two AQM mechanisms that have recently been presented and discussed in the IRTF and the IETF as solutions for keeping latency low. To the best of our knowledge, they have so far only been evaluated or compared against each other using default parameter settings, which naturally presents a rather limited view of their operational range. We set thus to perform a broader experimental evaluation using real-world implementations in a wired testbed. We have in addition compared them with a decade-old variant of RED called Adaptive RED, which shares with CoDel and PIE the goal of {\textquoteleft}{\textquoteleft}knob-free{\textquoteright}{\textquoteright} operation. Surprisingly, in several instances results were favorable towards Adaptive RED.
},
	doi = {http://dx.doi.org/10.1109/INFCOMW.2014.6849173},
	author = {Khademi, Naeem and Ros, David and Welzl, Michael}
}
@inproceedings {Simula.simula.2768,
	title = {Practical Passive Shared Bottleneck Detection Using Shape Summary Statistics},
	journal = {39th Annual IEEE Conference on Local Computer Networks},
	year = {2014},
	pages = {150--158},
	publisher = {IEEE},
	type = {Conference},
	keywords = {Conference},
	doi = {10.1109/LCN.2014.6925767},
	author = {David Andrew {Hayes} and Ferlin, Simone and Welzl, Michael}
}
@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}
}
@article {ledbat-comm-letters,
	title = {Assessing LEDBAT{\textquoteright}s Delay Impact},
	journal = {IEEE Communications Letters},
	volume = {17},
	year = {2013},
	month = {05/2013},
	pages = {1044-1047},
	publisher = {IEEE},
	author = {Welzl, Michael}
}
@inproceedings {Simula.simula.618,
	title = {Multimedia-Unfriendly TCP Congestion Control and Home Gateway Queue Management},
	journal = {MMSys {\textquoteright}11 Proceedings of the second annual ACM conference on Multimedia systems},
	year = {2011},
	month = {February},
	pages = {35-44},
	publisher = {ACM},
	type = {Conference},
	address = {New York},
	abstract = {Consumer broadband services are increasingly a mix of TCP-based and UDP-based applications, often with quite distinct requirements for interactivity and network performance. Consumers can experience degraded service when application traffic collides at a congestion point between home LANs, service provider edge networks and fractional-Mbit/sec {{\textquoteleft}}broadband{\textquoteright} links. We illustrate two key issues that arise from the impact of TCP-based data transfers on real-time traffic (such as VoIP or online games) sharing a broadband link. First, well-intentioned modifications to traditional TCP congestion control can noticeably increase the latencies experienced by VoIP or online games. Second, superficially-similar packet dropping rules in broadband gateways can induce distinctly different packet loss rates in VoIP and online game traffic. Our observations provide cautionary guidance to researchers who model such traffic mixes, and to vendors implementing equipment at either end of consumer links.},
	isbn = {978-1-4503-0518-1},
	author = {Stewart, Lawrence and David Andrew {Hayes} and Armitage, Grenville and Welzl, Michael and Petlund, Andreas},
	editor = {Ketan Mayer-Pate {Claypool} and Ali C. {Begen}}
}
@techreport {IETF_RFC6077:iccrg-open-research,
	title = {Open Research Issues in Internet Congestion Control},
	number = {6077},
	year = {2011},
	month = {02/2011},
	publisher = {Internet Research Task Force},
	type = {Request for Comments},
	keywords = {Algorithms, Architecture, congestion control, Data Communication, Denial of Service, Fairness, Internet, networks, Resource Sharing, Security, Stability},
	url = {http://tools.ietf.org/html/rfc6077},
	author = {Papadimitriou, Dimitri and Welzl, Michael and Scharf, Michael and Briscoe, Bob},
	editor = {Papadimitriou, Dimitri}
}
