Characterizing End-to-End Packet Reordering with UDP Traffic Sandra P. Tinta, Alexander E. Mohr † , Jennifer L. Wong Department of Computer Science, Stony Brook University Stony Brook, NY 11794-4400, USA stinta,amohr,[email protected]

Currently at Google, Washington

Abstract

rious packet retransmissions. For UDP-based applications such as VoIP, reordered packets that arrive after the playout deadline are considered lost. If RO is persistent during a VoIP session, the quality of the voice perception degrades. In this paper, the goal is to understand the characteristics of RO from an end-to-end perspective. We send packet pairs over UDP and analyze the behavior of reordered and in order packet pairs. Our focus is on identifying the characteristics on UDP-based applications. The differences between the in order and reordered packets give insight into the characteristics of RO and allow us to show that different source-destination pairs often observe extremely different RO rates; that packet RO occurs with diurnal cycles; that the size of transmitted packets can significantly impact the probability with which they will be reordered, and that there are two distinct time-scales manifested by RO.

Packet reordering (RO) is an Internet event that degrades the performance of both TCP and UDP-based applications. In this paper, we present an end-to-end measurement study of packet reordering of UDP traffic. The goal of our measurement study is to characterize packet reordering in the current Internet as it is reflected by PlanetLab infrastructure. Overall, our analysis shows that current UDP traffic reordering is consistent to prior 1990’s studies, despite increased Internet load and technology advancements, and it adds to the previous results by identifying additional reordering characteristics. More specifically, we show that packet reordering is asymmetric as well as temporal and site-dependent, packet size does influence the likelihood of reordering, that there exists a time-of-the-day dependency, and reordering primarily exists at two time-scales (a few milliseconds or multiple tens of milliseconds.)

2 Related Work One of the early end-to-end measurement studies that showed the occurrence of RO in the Internet was performed by Paxson in the early 1990’s [8]. Twenty thousand bulk transfers of 100-Kbyte each were used to observe RO at 35 participating sites. The percentages of RO observed on data packets was 2.0% and 0.3%, while 0.6% and 0.1% was observed on acknowledgements. Paxson categorized the cause of the RO observed as to be due to routing events Also, it was concluded that RO was site-dependent and had asymmetric behavior. Another influential end-to-end measurement study was done by Bennett et al. [2] which was made on Dec. 1997 and Jan. 1998. The measurements were performed on 140 nodes topologically close to the MAE-East exchange point. The traffic generated between the nodes consisted of five 56-byte bursts of ICMP-ping packets followed by back-toback burst of 50 ping-packets. The authors reported that more that 90% of the probing instances experienced RO; the results were obtained from two sets of tests. This study reported that RO was caused by local parallelism in Internet components.

1 Introduction Previous studies have reported statistics and characteristics of RO [1, 2, 5, 6, 7, 8]. However, it is important to reassess its status and determine if the evolution of the Internet has invalidated previous observations. Over the last few years, total Internet traffic has increased due to the demands of audio and video traffic, particularly due to the advent of new Internet applications that generate substantial amounts of traffic, such as iTunes, BitTorrent, and YouTube [3]. Other changing trends that could have impacted the presence of RO is the type of access technology used (i.e. dialup vs. broadband) and equipment upgrades that respond to traffic and service demands (i.e. faster forwarding routers to handle more traffic.) It is important to understand the behavior of RO because it is often detrimental for both, TCP and UDP based applications. At a TCP receiver, duplicate acknowledgements are generated when reordered packets are received. If RO is persistent, TCP performance quickly and continually degrades because of the decreased sending rate and the spu1

Two recent works by [5] and [6] focused on UDP flows and streaming traffic. In Gharai et al. [5], the measurement testbed consisted of three sites and it was placed very close to an access router. One minute UDP flows were generated using iperf at rates of 1Mbps, 10Mbps, 100Mbps and at 100Mbps intervals up to and including 900Mbps with packet sizes of 500, 1500 and 4500 bytes. It was found that 47% of the flows experienced at least one RO event, that the largest amount of RO in a given flow was 1.65%. Additionally, at higher rates smaller packets were more prone to RO because the sending inter-spacing time was small. Loguinov and Radha [6] studied the end-to-end dynamics of 16,000 10-minute sessions of real time streaming traffic from the perspective of dial-up connections.

M1 M2 M3 M4

Data Period 2 weeks 2 weeks 2 weeks 1 week

# Nodes 17 4 166 9

# Paths 196 12 1222 73

RO Events 2.4% 1.3% 0.01% 0.06%

Paths with No RO 16% 50% 84% 33%

Table 1. Summary of measurements.

4 Results and Discussion In this section, we report the observations drawn from the analysis of the data collected in our four measurement sessions. We report the percentages of reordering observed, daily trends, packet-size dependencies, prevalence, and time-scales of reodering.

3 Methodology

4.1

In order to perform our measurements, we deployed a packet-pair probing tool on 179 nodes at different PlanetLab sites and probed approximately 1500 different paths. Nodes were selected at random depending on their availability at the time of the measurements. Four measurement sessions allowed us to capture RO daily trends, packet-size dependencies, RO prevalence, and RO time-scales. Each measurement session, Mi , used a subset of the nodes for analysis: 17, 4, 166, and 9. In each session, probes are sent across a subset of paths between the nodes: 196, 12, 1222, and 73 for sessions M1 , M2 , M3 , and M4 respectively. Every node in the measurement sessions generated probes along a path and a log of the reception time-stamp was taken at the path receiver. The logger captured the timestamp observed at the application layer. The precision of the time-stamp was microseconds. Each probe consisted of a pair of UDP packets sent back-to-back at an interval of one second. Each packet had a sequence number embedded in its payload. A RO event occurs when the sequence in which the packets of a probe were received differed from the sequence in which packets of the probe were sent. M1 took place in Sept. 2007, the packets in the probes were of 40 bytes, and in average each node received 13 million probes over two weeks. M2 took place in Oct. 2007, the size of the packets in the probes where chosen randomly among 40, 80, 160, 350, 700, 1100, 1500 bytes every time a probe was sent, and in average each node received 1.8 million probes over a two week period. In Dec. 2008, Session M3 was traced. In this case, the size of the probes were the same as in M2 , and each node received 815 thousand probes on average for one day. Note that the data for this session was collected over two weeks varying daily the set of nodes used. Finally, M4 was performed in early Jan. 2009, the size of the probes were identical to M2 , and each node received 3.5 million probes on average during a one week observation.

Packet Reordering Statistics

The general statistics of RO observed in our four measurement sessions are shown in Table 1. In M1 we observed that 80% of the reordering events occurred in 30% of the paths while in M3 , 90% percent of the reordering events occurred in 2% of the paths. In M4 , 90% of the reordering events occurred in 30% of the paths. Overall, we observed that reordering occurs rarely and when it does, it is mostly exhibited consistently in a small percentages of the paths. This is clearly shown by M3 in which we probed the most paths and it accounted for the least reordering. We also observed that the percentage of reordering observed in different paths varies significantly, that the paths are asymmetric with respect to reordering, and that paths between nodes that are geographically distant (i.e nodes in different countries) exhibit greater percentages of reordering. Our observations reiterate the findings of previous measurement studies [8]. Measurement session M2 and M4 are spread apart about one year. Both sessions have a small subset of paths in common that we compared and we found that they do not have similar occurrence of RO. Paths that exhibited daily consistent reordering in M2 do not exhibit any in M4 and vice versa. We attribute this behavior to the inherent characteristics of the Internet. Routes, traffic loads, and network equipment change over time and that they can change the perceived end-to-end performance, in our case, the presence of reordering.

4.2

Packet Reordering and Packet Size

From the data collected in M2 , M3 , and M4 , we investigated to what extend packet size affected the amount of RO observed. As mentioned before, we used probes of various sizes in these sessions. We found that probes of all packet sizes experienced some RO, but probes with packets of smaller size were reordered more frequently. In session M1 , for instance, we only used 40-byte packets and this session experienced the most RO (2.4%). The following 2

15 %

Reordered

14 %

25 % Percentage

10 %

10 %

8% 6%

0%

Packet Reordering and Inter-Arrival Times

We also compare inter-arrival times of the packets from reordered and non-reordered probes. This was done with the aim of characterizing the scales at which a given application would observe reordered packets. Here, we present observations drawn from experiment M2 and M4 because various packet sizes were used, and the results are representative of our measurements. The data collected in each measurement was aggregated to characterize the reordering timescales. Because the inter-arrival times showed a long tail behavior, we draw our observations using the log-log CCDF, complementary CDF, to extract useful characteristics that were hidden otherwise. In general, different paths exhibited different interarrival time-scales. We broadly categorized these timescales in four tendencies. 3

8

Previous studies have noted diurnal cycles on the traffic load of the Internet [9], and have observed that RO occurs at higher rates with higher traffic loads [2, 5]. In our study, we observed diurnal cycles in the occurrence of RO, with peaks around the middle of the day and with fewer occurrences around middle of the night. This time-of-the-day dependency was exhibited by the majority of paths when reordering was present. In M1 , which lasted for two weeks, we saw this behavior on 60% of the paths that exhibited reordering; a similar trend was observed in M2 . Since M3 was only collected for a day and M4 had little percentages of reordering, we were unable to characterize this behavior for those sessions. In Figure 2, a snapshot of seven days of this daily trend is illustrated. In 2(b), we see that regardless of packet size the recurrent daily behavior is present.

-0

Packet Reordering Patterns

10

7

-0

10

6

-0

10

2

1

/1

10

0

/1

10

9

/1

8

/0

7

/0

6

(b) Zoom showing per-size RO rates

Figure 2. RO diurnal cycles Inter-arrival times of reordered probes range from 0.04 to 0.2 milliseconds regardless of packet size. This behavior is observed in Figure 3(a). It serves to note that non-reordered probes exhibit different tendencies from reordered probes specially at the tails of the inter-arrival CCDF. 99.8% of the reordered probes have inter-arrival times up to 0.2 milliseconds while only 92% of the nonreordered packets have this inter-arrival time. Inter-arrival times of reordered probes range from 10 to 100 milliseconds. This inter-arrival time tendency, as shown in Figure 3(b), is peculiar and has not been reported in previous studies. First of all, we note that only three kinds of probes (160, 700, and 1500-byte) are reordered with a interarrival time close to 50 microseconds. For non-reordered probes, we see that the inter-arrival time of their packets is proportional to their packet size: the larger the packet the larger the inter-arrival time. This is expected since larger packets will take longer to be transmitted. However, this is not the case for reordered probes, where we see that the inter-arrival times of the packets are comparable regardless of their size. More interestingly, 40-byte packets seemed to be reordered with the largest time scales (the CCDF of this curve is the rightmost). It is clear that the reordered packets have consistent delays for this nature of reordering irrespective of the packet size. Inter-arrival times exhibit bimodal timescales: 0.04 to 0.2 and 20 to 100 milliseconds. This behavior is observed in Figure 4(a). We see that for small packets: 99.7%, 79%, and 70% of packets of size 40, 80, and 160 bytes , respectively, experienced reordering delays of less than 0.1 milliseconds, and 100% of the larger packets experience delays of more than 20 milliseconds. The CCDF of inter-arrival times of small packet sizes is bimodal in contrast to larger packet sizes. In this case we can say that perhaps two different kinds of reordering inflicts the traffic in this path. Inter-arrival times between non-reordered and reordered probes have the same distributions across all timescales (i.e. same CDF). This behavior is observed in Figure 4(b). We can see in this figure that non-reordered and reordered probes, with their respective packet size, have the same propagation delay. Inter-arrival times differ significantly across packet sizes, for instance packets of size 160 bytes

figures are representative of our measurements. In Figure 1, we show the percentages of RO for four different paths with respect to the packet size. In Figure 2(b), we also see that different packet sizes are reordered at different rates. The implication of smaller packets being reordered more often is that the performance of applications which use them, such as VoIP, will see reordering more often and thus its performance will be degraded more often.

4.4

/0

5

(a) Seven-day snapshot

Figure 1. RO rates vs. packet size

4.3

/0

/0

Packet Size(bytes)

10

1000 1200 1400

10

800

10

600

10

400

10

200

0%

10

0

15 %

5%

2%

0%

20 %

10 %

4%

5%

40 160 350 700 1100

30 %

12 %

Percentage

Reordering Percentage

France/Kansas France/Denmark Illinois/France Kansas/France

20 %

100

10

-1

10-1

10-2

10-2

CCDF

CCDF

100

-3

10

-4

10

10-5 10-6

102

10-3 10-4

40 R 40 N-R 700 R 700 N-R 1500 R 1500 N-R

10-5

103

104

105

10-6

106

the PlanetLab infrastructure. Four measurement sessions allowed us to capture reordering prevalence, daily trends, reordering packet size dependencies, and time-scales. As in previous measurement studies, we conclude that packet reordering is a rare event, and it occurs less than 3% of the time. Due to the dynamic behavior of the traffic in the Internet and the heterogeneity of the devices that comprise it, it is not surprising to note that reordering is not consistent across the paths that exhibited it. Instead, the presence of a site, either as source or destination, has shown to affect the reordering rates observed. We also observed a consistent daily periodicity of the reordering rates, suggesting a relationship between reordering and Internet traffic load which also exhibits a similar behavior [9]. In addition, packets of smaller sizes are reordered more frequently than larger packets. This has implications on UDP-based applications such as VoIP which use small packet sizes. Lastly, a reordered packet can be perceived at the receiver with different time-scales – four time-scale tendencies were captured in our measurements. In the end, our study confirms the behavior of reordering in the Internet and illustrates that UDP traffic reordering behavior follow the same trends as previous measurements studies. In addition, the observed results lead us to drive the development of the reordering properties into simulation models to produce better experimental platforms.

40 R 40 N-R 700 R 700 N-R 1500 R 1500 N-R 102

Inter-arrival time(microseconds)

103

104

105

106

Inter-arrival time(microseconds)

(a) CCDF of inter-arrival times

(b) CCDF of inter-arrival times

Figure 3. Inter-arrival times of RO probes: 40 µs to 200 µs (right), and 10 µs to 100 µs (left). RO rate observed in these paths was 1.5% and 0.014% respectively.

and 1500 bytes have inter-arrival times which differ by a factor of 10. Observing this kind of distribution is interesting because it defines a reordering model of the form of probabilistically flipping a packet and no extra delay added. One important assumption we make based on the use of back-to-back packet-pairs for probing is that packets in this kind of probes generally share links when traversing the Internet [4], and therefore are expected to exhibit similar delays. When a packet is reordered, the reordering source imposes an extra delay on the packet, but the magnitudes of the delays vary per source and the kind of reordering experienced by a packet. Our results generally report two ranges of reordering timescales. One timescale ranges from 0.04 to 0.2 milliseconds, while the other timescale ranges from 10 to 100 milliseconds. We found that very few of the nonreordered probes, less than 0.014%, are subject to the larger delays. Noting that the differences between the reordering timescales is significant, we believe the delays exhibited is specific to the cause of reordering. Further analysis needs to be performed to determine the reasons for these timescales. 100

100

10-1

10-1

-2

-4

10

-5

10

10-6

40 R 40 N-R 700 R 700 N-R 1500 R 1500 N-R 80 R 160 R 350 R 1100 R

102 103 104 105 106 Inter-arrival time(microseconds)

(a) CCDF of inter-arrival times

CCDF

CCDF

[1] J. Bellardo and S. Savage. Measuring packet reordering. In ACM SIGCOMM Workshop on Internet Measurement, pages 97–105, 2002. [2] J. C. R. Bennett, C. Partridge, and N. Shectman. Packet reordering is not pathological network behavior. IEEE/ACM Transactions in Networking, pages 789–798, 1999. [3] I. D. Corporation and W. Consortium. Internet timeline. http://www.infoplease.com, November 2007. [4] M. Crovella and B. Krishnamurty. Intenet Measurement: Infrastructure, Traffic and Applications. John Wiley and Sons Ltd., 2006. [5] L. Gharai, C. Perkins, and T. Lehman. Packet reordering, high speed networks and transport protocol performance. In ICCCN, pages 73– 78, 2004. [6] D. Loguinov and H. Radha. End-to-end Internet video traffic dynamics: Statistical study and analysis. In INFOCOM, volume 2, pages 723–732, 2002. [7] X. Luo and R. K. C. Chang. Novel approaches to end-to-end packet reordering measurement. In IMC, page 20, 2005. [8] V. Paxson. End-to-end Internet packet dynamics. IEEE/ACM Transactions in Networking, 7:277–292, 1999. [9] M. Roughan, A. Greenberg, C. Kalmanek, M. Rumsewicz, J. Yates, and Y. Zhang. Experience in measuring Internet backbone traffic variability: Models, metrics, measurements and meaning. In Proceedings of the International Teletraffic Congress, pages 379–388, 2003.

10-2

10

10-3

References

10-3 10-4 10-5 10-6

40 R 40 N-R 700 R 700 N-R 1500 R 1500 N-R 102

103

104

105

106

Inter-arrival time(microseconds)

(b) CCDF of inter-arrival times

Figure 4. Inter-arrival times of RO probes: bimodal tendency (right), and RO and non-RO probes share similar tendency (left). RO rate observed in these paths was 0.5% and 7.5% respectively.

5 Conclusion The results presented in this paper serve to characterize reordering of UDP traffic in the Internet reflected by 4

Characterizing End-to-End Packet Reordering ... - Research at Google

Previous studies have reported statistics and character- ... The percentages of RO observed on data ... the analysis of the data collected in our four measure-.

268KB Sizes 5 Downloads 253 Views

Recommend Documents

Automatically Learning Source-side Reordering ... - Research at Google
ordering rule on the development set. However, ... cal, to retranslate the development set, keeping the phrase table and .... web and 486 sentences from wiki; dev2: 1000 sen- tences from .... Table 6: Examples of top rules and their application.

Characterizing Task Usage Shapes in Google's ... - Research at Google
web search, web hosting, video streaming, as well as data intensive applications ... Permission to make digital or hard copies of all or part of this work for personal or ... source utilization for CPU, memory and disk in each clus- ter. Task wait ..

Characterizing the Errors of Data-Driven ... - Research at Google
they are easily ported to any domain or language in .... inference algorithm that searches over all possible ... the name of the freely available implementation.1.

Optimizing the update packet stream for web ... - Research at Google
Key words: data synchronization, web applications, cloud computing ...... A. Fikes, R. Gruber, Bigtable: A Distributed Storage System for Structured Data,. OSDI ...

handling packet loss in webrtc - Research at Google
real-time applications such as video conferencing. These applications are limited by the ... configured to wait for all necessary packets. Video quality is therefore ...

Mathematics at - Research at Google
Index. 1. How Google started. 2. PageRank. 3. Gallery of Mathematics. 4. Questions ... http://www.google.es/intl/es/about/corporate/company/history.html. ○.

Faucet - Research at Google
infrastructure, allowing new network services and bug fixes to be rapidly and safely .... as shown in figure 1, realizing the benefits of SDN in that network without ...

BeyondCorp - Research at Google
41, NO. 1 www.usenix.org. BeyondCorp. Design to Deployment at Google ... internal networks and external networks to be completely untrusted, and ... the Trust Inferer, Device Inventory Service, Access Control Engine, Access Policy, Gate-.

VP8 - Research at Google
coding and parallel processing friendly data partitioning; section 8 .... 4. REFERENCE FRAMES. VP8 uses three types of reference frames for inter prediction: ...

JSWhiz - Research at Google
Feb 27, 2013 - and delete memory allocation API requiring matching calls. This situation is further ... process to find memory leaks in Section 3. In this section we ... bile devices, such as Chromebooks or mobile tablets, which typically have less .

Yiddish - Research at Google
translation system for these language pairs, although online dictionaries exist. ..... http://www.unesco.org/culture/ich/index.php?pg=00206. Haifeng Wang, Hua ...

traits.js - Research at Google
on the first page. To copy otherwise, to republish, to post on servers or to redistribute ..... quite pleasant to use as a library without dedicated syntax. Nevertheless ...

sysadmin - Research at Google
On-call/pager response is critical to the immediate health of the service, and ... Resolving each on-call incident takes between minutes ..... The conference has.

Introduction - Research at Google
Although most state-of-the-art approaches to speech recognition are based on the use of. HMMs and .... Figure 1.1 Illustration of the notion of margin. additional ...

References - Research at Google
A. Blum and J. Hartline. Near-Optimal Online Auctions. ... Sponsored search auctions via machine learning. ... Envy-Free Auction for Digital Goods. In Proc. of 4th ...

BeyondCorp - Research at Google
Dec 6, 2014 - Rather, one should assume that an internal network is as fraught with danger as .... service-level authorization to enterprise applications on a.

Browse - Research at Google
tion rates, including website popularity (top web- .... Several of the Internet's most popular web- sites .... can't capture search, e-mail, or social media when they ..... 10%. N/A. Table 2: HTTPS support among each set of websites, February 2017.

Continuous Pipelines at Google - Research at Google
May 12, 2015 - Origin of the Pipeline Design Pattern. Initial Effect of Big Data on the Simple Pipeline Pattern. Challenges to the Periodic Pipeline Pattern.

Accuracy at the Top - Research at Google
We define an algorithm optimizing a convex surrogate of the ... as search engines or recommendation systems, since most users of these systems browse or ...

slide - Research at Google
Gunhee Kim1. Seil Na1. Jisung Kim2. Sangho Lee1. Youngjae Yu1. Code : https://github.com/seilna/youtube8m. Team SNUVL X SKT (8th Ranked). 1 ... Page 9 ...

1 - Research at Google
nated marketing areas (DMA, [3]), provides a significant qual- ity boost to the LM, ... geo-LM in Eq. (1). The direct use of Stolcke entropy pruning [8] becomes far from straight- .... 10-best hypotheses output by the 1-st pass LM. Decoding each of .

1 - Research at Google
circles on to a nD grid, as illustrated in Figure 6 in 2D. ... Figure 6: Illustration of the simultaneous rasterization of ..... 335373), and gifts from Adobe Research.

Condor - Research at Google
1. INTRODUCTION. During the design of a datacenter topology, a network ar- chitect must balance .... communication with applications and services located on.