fling: A Flexible Ping for Middlebox Measurements

Abstract

Middleboxes in private networks have been known to change packets in many ways, making it hard to design protocol extensions that work for the large majority of Internet users. Addressing the need to know what such middleboxes do, we introduce a tool called fling ("flexible ping"). fling can carry out (almost) any kind of protocol dialogue between a server and a client based on a simple specification in a json and a pcap file, and identify what middleboxes do to the packets of the dialogue. This fills a gap in the state of the art, where other tools that control both ends of a path are either limited in some form or have to be updated for every new test. We present results from small-scale tests that prove the flexibility of fling, which is a prerequisite for our next step: development of a large-scale measurement platform.

On the usability of transport protocols other than TCP: A home gateway and internet path traversal study

“…Except for the SCTP multi-homing tests, for which we ran a specific SCTP test program 1 , the client and the server ran the fling tool. fling [13], which is available from http://fling-frontend.nntb.no, allows to test whether an arbitrary sequence of packets can be exchanged between a client and a server using pre-defined pcap and json files. This makes it easy to exchange sequences of packets that are crafted for a particular measurement purpose.…”

“…When a test is finished (or failed), paths are probed from both sides, similar to Tracebox [9], and the final client test result is submitted to the server via the HTTPS/TCP signaling channel. A detailed description of fling is given in [13].…”

Performance Analysis of WebRTC and SIP-based Audio and Video Communication Systems

“…A performance analysis of WebRTC and session initiation protocol (SIP) [14] for video conferencing was conducted in [15] and it wasfound that WebRTC provided a better call quality compared to SIP under the same network conditions. Other related works on the performance of WebRTC can be found in [17][18][19][20][21][22].…”

Investigating the Delay Impact of the DiffServ Code Point (DSCP)

“…In a previous study [2], we transmitted packets between 225 clients and 52 servers around the world using our flexible ping ("fling") measurement tool 1 [3], in order to see what happens when they carry a non-zero DSCP. Specifically, in addition to DSCP=0, we used three values that are important for WebRTC: CS1 (low-priority data), AF42 (multimedia conferencing) and EF (telephony).…”

“…On the other, a DSCP choice is not expected to have any effect whatsoever when the network is uncongested: it is only meant to influence how routers treat packets as they take them from their input queues and schedule them for transmission. However, congesting the Internet at a large scale from many vantage points is not usually a well accepted practice in measurement testbeds (in our case, we used the ARK 2 , PLANETLAB 3 and NORNET CORE 4 platforms). Thus, we are left with a choice of: i) doing smaller-scale measurements, or ii) trying to understand if the DSCP value had an effect even in conditions when the network may not have been congested.…”