@article {27785,
	title = {Measuring Roaming in Europe: Infrastructure and Implications on Users{\textquoteright} QoE},
	journal = {IEEE Transactions on Mobile Computing},
	year = {2021},
	publisher = {IEEE},
	author = {Mandalari, A. and Lutu, Andra and Custura, Ana and Ali Safari {Khatouni} and Alay, {\"O}zg{\"u} and Bagnulo, Marcelo and Bajpai, V. and Brunstr{\"o}m, Anna and Ott, Joerg and trevisan, martino and mellia, marco and Fairhurst, Gorry}
}
@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}
}
@inproceedings {26044,
	title = {Experience: Implications of Roaming in Europe},
	journal = {Proceedings of the 24th Annual International Conference on Mobile Computing and Networking},
	year = {2018},
	pages = {179-189},
	publisher = {ACM},
	address = {New Delhi, India},
	isbn = {978-1-4503-5903-0},
	doi = {10.1145/3241539.3241577},
	author = {Anna Maria {Mandalari} and Lutu, Andra and Custura, Ana and ali safari {Khatouni} and Alay, {\"O}zg{\"u} and Bagnulo, Marcelo and Bajbai, Vaibhav and Brunstr{\"o}m, Anna and Ott, Joerg and mellia, marco and Fairhurst, Gorry}
}
@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}
}
@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 {24987,
	title = {Operating ranges, tunability and performance of CoDel and PIE},
	journal = {Computer Communications},
	volume = {103},
	year = {2017},
	month = {05/2017},
	pages = {74-82},
	publisher = {Elsevier},
	abstract = {Bufferbloat is excessive delay due to the accumulation of packets in a router\&rsquo;s oversized queues. CoDel and PIE are two recent Active Queue Management (AQM) algorithms that have been proposed to address bufferbloat by reducing the queuing delay while trying to maintain a high bottleneck utilization. This paper fills a gap by outlining what are the operating ranges, that is the network characteristics (in terms of round-trip times and bottleneck capacity), for which these algorithms achieve their design goals. This new approach to the problem lets us identify deployment scenarios where both AQM schemes result in poor performance when used with default parameters. Because PIE and CoDel have been proposed with RED\&rsquo;s deployment issues in mind, it was essential to evaluate to what extent we can tune them to achieve various trade-offs and let them control the queuing delay outside their default operating range. We find that, by appropriate tuning (1) the amount of buffering can easily be controlled with PIE, (2) the Round Trip Time (RTT) sensitivity of CoDel can be reduced. Also, we observe there is more correlation between the congestion level, the achieved queuing delay and the targeted delay with CoDel than with PIE. This paper therefore concludes there is no single overall best AQM scheme, as each scheme proposes a specific trade-off.},
	keywords = {AQM, Bufferbloat, CoDel, congestion control, PIE},
	doi = {http://dx.doi.org/10.1016/j.comcom.2016.07.013},
	author = {Kuhn, Nicolas and Ros, David and Amadou Baba {Bagayoko} and Kulatunga, Chamil and Fairhurst, Gorry and Khademi, Naeem}
}
@inproceedings {25398,
	title = {Path Transparency Measurements from the Mobile Edge with PATHspider},
	journal = {IEEE/IFIP Mobile Network Measurements Workshop},
	year = {2017},
	publisher = {IEEE},
	doi = {10.23919/TMA.2017.8002922},
	author = {Iain R. {Learmonth} and Lutu, Andra and Fairhurst, Gorry and Ros, David and Alay, {\"O}zg{\"u}},
	editor = {mellia, marco and Halepovic, Emir and Malone, David}
}
@misc {24440,
	title = {AQM for ISPs - decision maker video},
	year = {2016},
	publisher = {Reducing Internet Transport Latency},
	address = {RITE website},
	abstract = {This video is directed at decision makers in Network operators and equipment manufacturers. It contains a to-the-point explanation of some key technologies that needs to go into the Internet to reach the next evolutionary step.},
	keywords = {AQM, Internet latency, ISP},
	url = {https://videopress.com/v/WskDNI5r},
	author = {Briscoe, Bob and Petlund, Andreas and Ahmed, Iffat and Fairhurst, Gorry and Brunstr{\"o}m, Anna and Ros, David}
}
@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}
}
@misc {24995,
	title = {NEAT {\textendash} A New, Evolutive API and Transport-Layer Architecture for the Internet},
	year = {2016},
	month = {06/2016},
	address = { 12th Swedish National Computer Networking Workshop (SNCNW 2016), Sundsvall, Sweden, June 1-2, 2016},
	keywords = {application-aware networking, Internet architecture, ossification, transport API, transport layer},
	doi = {https://doi.org/10.5281/zenodo.55588},
	author = {Grinnemo, Karl-Johan and Jones, Tom and Fairhurst, Gorry and Ros, David and Brunstr{\"o}m, Anna and Hurtig, Per}
}
@inproceedings {24530,
	title = {Towards a Flexible Internet Transport Layer Architecture},
	journal = {IEEE LANMAN},
	year = {2016},
	publisher = {IEEE},
	abstract = {There is a growing concern that the Internet transport layer has become less adaptive to the requirements of new applications, and that further evolution has become very difficult. This is because a fundamental assumption no longer holds: it can no longer be assumed that the transport layer is only in the scope of end-hosts. The success of TCP and UDP and the ubiquity of middleboxes have led to ossification of both the network infrastructure and the API presented to applications. This has led to the development of workarounds and point solutions that fail to cover many facets of the problem. To address this issue, this paper identifies requirements for a new transport layer and then proposes a conceptual architecture that we argue is both flexible and evolvable. This new architecture requires that applications interface to the transport at a higher abstraction level, where an application can express communication preferences via a new richer API. Protocol machinery can use this information to decide which of the available transport protocols is used. By placing the protocol machinery in the transport layer, the new architecture can allow for new protocols to be deployed and enable evolution of the transport layer.},
	keywords = {application-aware networking, Internet architecture, ossification, transport API, transport layer},
	isbn = {978-1-4673-9882-4},
	issn = {1944-0375},
	doi = {https://doi.org/10.1109/LANMAN.2016.7548846},
	author = {Grinnemo, Karl-Johan and Jones, Tom and Fairhurst, Gorry and Ros, David and Brunstr{\"o}m, Anna and Hurtig, Per}
}
@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}
}
@inproceedings {bufferbloat-eucnc,
	title = {Tackling Bufferbloat in Capacity-limited Networks},
	journal = {Proceedings of EuCNC 2015},
	year = {2015},
	address = {Paris},
	abstract = {Over-provisioned network buffers, often at the Internet edge, induce large queuing delay and high latency; this issue is known as Bufferbloat. In response to this, a set of recently proposed Active Queue Management (AQM) algorithms attempt to reduce standing queues, while maintaining the bottleneck utilisation at an acceptable level. This paper assesses the performance of two AQM schemes (CoDel and FQ-CoDel) over capacity-limited networks with large Round-Trip Time (RTT). In such settings, these AQM schemes have difficulty controlling the buffering level, resulting in both momentarily high queuing delay and low bottleneck utilisation, even if the methods are claimed to be insensitive to link rates and round-trip delays. We explore this issue and show that it is possible to adapt the parameterisation of CoDel and FQ-CoDel to offer a higher bottleneck utilisation while maintaining a low queuing delay. We present experiments over an emulated test bed and a satellite network to confirm that our new parameterisation improves the download time of moderate-size files and reduces the latency for capacity-limited and large-RTT networks.},
	keywords = {AQM, Bufferbloat, CoDel, Rural Broadband},
	author = {Kulatunga, Chamil and Kuhn, Nicolas and Fairhurst, Gorry and Ros, David}
}
@inproceedings {Simula.simula.2810,
	title = {Performance Evaluation of Congestion Window Validation for DASH Transport},
	journal = {Proceeding of the 24th ACM Workshop on Network and Operating Systems Support for Digital Audio and Video},
	year = {2014},
	publisher = {ACM},
	type = {Annual},
	abstract = {A recent proposed update to TCP congestion control, TCP-newCWV, has targeted congestion control for rate-limited applications. These methods need to be explored in the context of rate-adaptive applications, such as DASH. The new method enables a client to exploit the persistence of a DASH connection and enables the DASH server to rapidly resume transmission of a series of video segments using a single TCP connection. Another technique, called {\textquoteright}Pacing{\textquoteright} smoothes DASH bursts when there is no TCP ACK clock, and is shown to significantly reduce burst loss. These two methods in combination can increase the application performance. This paper investigates the effect of implementing these techniques on a DASH flow in different congestion scenarios and whether the method can promote better capacity sharing while minimizing the latency experienced by other flows sharing a common network bottleneck. The results confirm that newCWV with Pacing provides a benefit as a platform for DASH transport.},
	doi = {10.1145/2578260.2578275},
	author = {Nazir, Sajid and Hossain, Ziaul and Secchi, Raffaello and Broadbent, Matthew and Petlund, Andreas and Fairhurst, Gorry},
	editor = {Wei Tsang {Ooi}}
}
@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}
}
