@article {26427,
	title = {Low-Latency Scheduling in MPTCP},
	journal = {IEEE Transactions on Networking},
	volume = {27},
	year = {2019},
	month = {02/2019},
	publisher = {ACM IEEE},
	author = {Hurtig, Per and karl johan {grinnemo} and Brunstr{\"o}m, Anna and Ferlin, Simone and Alay, {\"O}zg{\"u} and Kuhn, Nicolas}
}
@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}
}
@inproceedings { ANRW2017,
	title = {A NEAT Way to Browse the Web},
	journal = {Proceedings of the Applied Networking Research Workshop~(ANRW)},
	year = {2017},
	note = {Demo Presentation},
	month = {07/15/2017},
	publisher = {IEEE},
	address = {Praha/Czech Republic},
	abstract = {There is a growing concern that the Internet transport layer has become ossified in the face of emerging novel applications, and that further evolution has become very difficult. The NEAT system is a novel and evolvable transport system that decouples applications from the underlying transport layer and network services. In so doing, it facilitates dynamic transport selection. This demo shows how the NEAT system is able to dynamically select the most appropriate transport solution for the Mozilla Firefox web browser.},
	keywords = {NEAT, ossification, SCTP, tcp, Transport Selection, Transport Service},
	url = {https://irtf.org/anrw/2017/anrw17-final13.pdf},
	author = {Weinrank, Felix and Grinnemo, Karl-Johan and Bozakov, Zdravko and Brunstr{\"o}m, Anna and Dreibholz, Thomas and Hurtig, Per and Khademi, Naeem},
	editor = {T{\"u}xen, Michael}
}
@inproceedings {24988,
	title = {On the Cost of Using Happy Eyeballs for Transport Protocol Selection},
	journal = {Applied Networking Research Workshop (ANRW)},
	year = {2016},
	month = {07/2016},
	pages = {45-51},
	publisher = {ACM},
	abstract = {Concerns have been raised in the past several years that introducing new transport protocols on the Internet has become increasingly difficult, not least because there is no agreed-upon way for a source end host to find out if a transport protocol is supported all the way to a destination peer. A solution to a similar problem\&mdash;finding out support for IPv6\&mdash;has been proposed and is currently being deployed: the Happy Eyeballs (HE) mechanism. HE has also been proposed as an efficient way for an application to select an appropriate transport protocol. Still, there are few, if any, performance evaluations of transport HE. This paper demonstrates that transport HE could indeed be a feasible solution to the transport support problem. The paper evaluates HE between TCP and SCTP using TLS encrypted and unencrypted traffic, and shows that although there is indeed a cost in terms of CPU load to introduce HE, the cost is relatively small, especially in comparison with the cost of using TLS encryption. Moreover, our results suggest that HE has a marginal impact on memory usage. Finally, by introducing caching of previous connection attempts, the additional cost of transport HE could be significantly reduced.},
	keywords = {CPU load, Happy Eyeballs, memory usage, SCTP, tcp, TLS, Transport-protocol selection},
	isbn = {978-1-4503-4443-2},
	doi = {https://doi.org/10.1145/2959424.2959437},
	url = {https://irtf.org/anrw/2016/anrw16-final27.pdf},
	author = {Papastergiou, Georgios and Grinnemo, Karl-Johan and Brunstr{\"o}m, Anna and Ros, David and T{\"u}xen, Michael and Khademi, Naeem and Hurtig, Per}
}
@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}
}
@article {24302,
	title = {Is Multi-Path Transport Suitable for Latency Sensitive Traffic?},
	journal = {Computer Networks (COMNET)},
	volume = {105},
	year = {2016},
	month = {08/2016},
	pages = {1-21},
	publisher = {Elsevier},
	abstract = {This paper assesses whether multi-path communication can help latency-sensitive applications to satisfy the requirements of their users.\&nbsp; We consider Concurrent Multi-path Transfer for SCTP (CMT-SCTP) and Multi-path TCP (MPTCP) and evaluate their proficiency in transporting video, gaming, and web traffic over combinations of WLAN and 3G interfaces. To ensure the validity of our evaluation, several experimental approaches were used including simulation, emulation and live experiments. When paths are symmetric in terms of capacity, delay and loss rate, we find that the experienced latency is significantly reduced, compared to using a single path. Using multiple asymmetric paths does not affect latency -- applications do not experience any increase or decrease, but might benefit from other advantages of multi-path communication. In the light of our conclusions, multi-path transport is suitable for latency-sensitive traffic and mature enough to be widely deployed.},
	keywords = {CMT-SCTP, Internet, latency, MPTCP, Multi-Path Communication, transport protocols},
	doi = {10.1016/j.comnet.2016.05.008},
	author = {Yedugundla, Kiran and Ferlin, Simone and Dreibholz, Thomas and Alay, {\"O}zg{\"u} and Kuhn, Nicolas and Hurtig, Per and Brunstr{\"o}m, Anna}
}
@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}
}
@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}
}
@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 {24123,
	title = { Reducing Latency for Linux Transport},
	howpublished = {Linux Conference Europe 2015},
	year = {2015},
	publisher = {Linux Foundation},
	type = {Technical presentation},
	address = {San Fransico, Ca, US},
	abstract = {Linux networking, and especially Linux TCP has seen a lot of development recently. In the Reducing Internet Transport Latency (RITE) EU project, one of the goals is to develop networking technology that enables lower latency transport available to the public and industry, and Linux is at the centre of this focus. Prototypes implemented in the Linux kernel includes keeping the congestion window appropriately open for bursty traffic (newCWV) [1], Faster retransmissions for application limited flows (RTO restart and TLP restart) [2], Redundant bundling to avoid retransmissions for thin streams [3] and bringing hybrid delay-based congestion control to the Linux kernel for less queue buildup in bottlenecks [4]. Our talk will present these latency enhancements in the Kernel.[1] http://bit.ly/1KVKeyb[2] http://bit.ly/1FkmGvL[3] http://bit.ly/1ejYIvC[4] http://bit.ly/1HOwZhU},
	keywords = {latency, Linux, network, Transport},
	url = {http://sched.co/3xWk},
	author = {Petlund, Andreas and Hurtig, Per}
}
@inproceedings {23538,
	title = {Reducing Transport Latency using Multi-path Protocols},
	journal = {European Conference on Networks and Communications (EuCNC)},
	year = {2015},
	author = {Hurtig, Per and Alay, {\"O}zg{\"u} and Ferlin, Simone and Yedugundla, Kiran}
}
@techreport {23802,
	title = {RITE recommended use parameters report},
	number = {D3.4},
	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-d3-4.pdf},
	author = {Hurtig, Per and Briscoe, Bob and Petlund, Andreas and Others, Numerous},
	editor = {Hurtig, Per}
}
