@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}
}
@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 {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}}
}
@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}
}
