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