Project Report: Network Pulse Network

Wei Wang (#998133951) and Yuan Feng (#996622347) {2,487 words}

I. I NTRODUCTION Depicting a global picture of the Internets current status is quite costly: a set of computers have to be purchased and deployed around the world to conduct the measurement. Our application, Network Pulse, serves a costless approach for network measurement. We advocate to use iPhones to probe the global Internet. Our motivations reside in the facts that: rst, almost all iPhone users are connected to the Internet; second, at present there are more than 21 million of iPhone users; third, iPhone users are distributed inherently across the world. In particular, we are interested in measuring the round-trip time (RTT) and packet loss rate (PLR) of target websites browsed by people around the world. Our application sends out probe packets periodically to a target website, and measure the RTT and PLR based on the received feedbacks. The application then submits the measured results to the dedicated server, which will in turn send back a statistics summarizing the global measurements by analyzing all collected submissions. This project report focuses on the measurement part only, leaving the data presentation part to our partner team. II. O VERALL D ESIGN Network Pulse adopts the canonical client-server architecture. The clients are running on iPhones, and periodically exchange information with the dedicated application server built on Google App Engine. Fig. 1 shows a detailed block diagram of our app. It describes a typical interaction cycle between a client and the server. A client starts to probe the Internet by sending out probe packets, HTTP requests for RTT and ICMP packets (ping) for PLR specically. Once the response packets are received, the client starts to analyze those feedback information and extract useful statistics in its Probing Manager module (see Fig. 1). After accumulating enough statistics, a client submits a summarized probing report, together with its geographical location, to the server through the Google App Engine Comm. module. At the same time, clients can also retrieve the global measurement results processed from the server and direct them to the Statistics Presentation Manager module, which presents the result in a user-friendly way to users. The client repeats the processes above probing, reporting, retrieving, and presenting until the app is terminated by the user. III. F UNCTIONALITIES AND S CREEN S HOTS For this project, two measurements (RTT and PLR) regarding the interested website are supported in the client application. Also, the client can submit the measured results to the application server, from which it can retrieve the global measurement results collected from other iPhones around the world. A. The Client Since we are focusing on the network part, we adopt a simplied UI. As shown in Fig. 2a, the main menu offers two options, probing the network and retrieving the measurement statistics from the server. When the Probing button is pressed, the iPhone starts measuring the interested websites by sending out probe packets periodically (25s interval time for RTT and 5s for PLR).

Mobile Client
User Interface

Mobile Client Mobile Client ... Mobile Client Google App Engine Submit Report Get Global Results

Geo Detection Probing Manager

Statistics Presentation Manager

RTT Detection

PLR Detection

Google App Engine Comm. Module

iOS Network Framework HTTP Packets Ping Packets

Feedback Packets

Website #1

Website #2

...

Fig. 1.

The block diagram of Network Pulse.

The user will see the latest probing results, i.e., RTT and PLR, measured by her iPhone from a simple UI shown in Fig. 2b. For simplicity, the current implementation measures six predened websites located in six different cities, but the user can also change to probe her interested website if she wishes. The measured RTT and PLR as well as the iPhones geographical location will also be submitted to the app server for further statistics. As illustrated in Fig. 2b, such uploading process is observed in the log window, where the measurement has been successfully reported to the server.

Log Window: see log messages.

Latest Probing Results: RTT is 55.65ms without lost packet so far. The results are based on the latest probing from this iPhone to the dedicated websites in Toronto.

(a) The main menu.

Fig. 2.

(b) The UI of network probing.

The UI of network probing.

The user can also have a general picture of the global statistics collected from other iPhones around the world. By pressing the Statistics button, the user will see a list of websites. As shown in Fig. 3a, six websites are measured at the current implementation. The user can choose

(a) The menu of the measured websites.

(b) The RTT of the selected website.

(c) The PLR of the selected website.

Fig. 3.

The UI of retrieving network statistics.

any of them and will be directed to a view of detailed statistics, where a tab in the bottom is used for switching between RTT and PLR, as shown in Fig. 3b and 3c, respectively. Meanwhile, the iPhone will connect to the server and retrieve the global statistics regarding the selected website. The measurements collected from the same city are clustered and averaged, with the result shown as an entry of the list. Since the only client is located in Toronto, we only see the statistics averaged over her reports, as depicted in Fig. 3b and Fig. 3c. The working ow of RTT and PLR measurements are given in Fig. 4 and Fig. 5, respectively.

Target website
HTTP-POST requrest ACK

Parse URL

Construct HTTP message

Setting up CFReadStream

CFReadStreamOpen
RTT

Next round

Client (based on CFNetwork)

StartTimer

PauseTimer

RTT report

OK

Server (based on Google App Engine)

Fig. 4.

The working ow of RTT measurement.

Target website
ICMP ICMP packet 1 packet 2 ICMP packet 5

...
Parse URL Construct ICMP packet Setting up CFSocket Open CFSocket

...

ACK1

ACK2

ACK5

Next round

Client (based on CFNetwork)

PLR report (Rx/Tx = 5/5) OK

Server (based on Google App Engine)

Fig. 5.

The working ow of PLR measurement. Five ICMP packets will be sent for each PLR probing.

B. The Cloud Server The main task of the application server is to collect probing results from clients all over the world, and to feed the global statistics back to them. Our application server is based on Google App Engine, for it provides a persistent yet highly scalable and distributed database interface, called datastore, for data storage and retrieval.
HTTP POST Request
{ "SubmitReport", { "geoPt": 43.6525, -79.3817 "rtt": 103.912 "lost": 10 } }

Google App Engine

GAE WSGI

HTTP POST Request

{

Mobile Client

"GetAverage", { "WebsiteID": 3 } }

RequestHandler.post()

HTTP Response
{ "result":"OK", "error": null }

RPCHandler.dispatch()

RPCMethods.SubmitReport()

RPCMethods.GetAverage()

HTTP Response
{ "Location":"Toronto" "rtt": 39.26 "lost": 7 }

Fig. 6.

The architecture of application servers.

Fig. 6 shows the working ow inside the server. We take the example when a user asks for the global statistics for a website, the data ow of which is shown by solid lines in the gure. The client sends out an HTTP POST request and the ID of the interested website, indicating that

the users purpose is to retrieve the global statistics regarding to that website. This request is then directed by the RPCHandler.dispatch function to GetAverage function in this example.07/04/11 The2:57 PM Data Viewer - Network Pulse Google App Engine then informs the user the averaged RTT and PLR via an HTTP Response yuan.feng86@gmail.com | My Account | Help | Sign out message. Application: networkpulse My Applications One of the important tasks for the server is to maintain all collected reports submitted by clients, and to update the datastore whenever a new report is submitted. Fig. 7 shows the Query Create screenshot of the table maintained by our servers. Each row of the table represents a kinds asReport of 0:00:03 ago By kind: report.
1 Report

Report Entities in Empty Namespace

Prev 20 1-20 Next 20 ID/Name id=26338 geoHash dpz837kd6ch7x geoPt 43.6525,79.3817 43.6525,79.3817 43.6525,79.3817 43.6525,79.3817 43.6525,79.3817 43.6525,79.3817 43.6525,location agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

lost 0.0

rtt 510.361

timestamp 2011-04-05 14:09:11.434275 2011-04-05 14:09:15.745996 2011-04-05 14:09:40.526186 2011-04-05 14:10:28.169376 2011-04-05 14:10:33.369815 2011-04-05

website agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATIM
Website: name=2

id=26339

dpz837kd6ch7x

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

0.0

785.855

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATYM
Website: name=6

id=26340

dpz837kd6ch7x

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

0.0

319.192

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATEM
Website: name=1

id=26343

dpz837kd6ch7x

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

0.0

1440.318

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATMM
Website: name=3

id=26344

dpz837kd6ch7x

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

0.0

1073.882

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATYM
Website: name=6
07/04/11 3:35 PM agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATEM

Data Viewer - Network Pulse

id=26345

dpz837kd6ch7x

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw

Fig. 7. Location: id=42102

14:10:50.551968 The screenshot of the Report table. 2011-04-05

0.0

1947.5

Website: name=1

My Applications 79.3817 Website: name=3 Location: id=42102 Another important task for the application server is to get 14:12:20.711984 the average measurement results agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA 43.6525,2011-04-05 agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATIM Create of Query different websites. To be the averaged RTT and PLR computed id=26347 dpz837kd6ch7x gw specic, the server will return 0.0 1570.636 79.3817 14:12:50.401178 Website: name=2 Location: id=42102 in By the recent hour for each location. The server maintains a table called Snapshot, the screenshot Snapshot kinds as of 0:00:22 ago kind: agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA 43.6525,2011-04-05 agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATMM id=26348 dpz837kd6ch7x gw 0.0 735.8719 of which is shown 79.3817 in Fig. 8. 14:12:52.102592 Website: name=3 Location: id=42102

id=26346 networkpulse dpz837kd6ch7x Application: 1

yuan.feng86@gmail.com | My Account | Help | Sign out agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw 0.0 780.093

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATMM

Snapshot Entities in Empty Namespace

id=26349 dpz837kd6ch7x Prev 20 1-20 Next 20 43.6525,79.3817

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

0.0

816.03

2011-04-05 14:12:53.786378

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATQM
Website: name=4

ID/Name id=26365

count 12

location gw

lost_avg 0.0

rtt_avg 936.93

timestamp 05 15:10:00

website
Page 1 of 2 agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATQM

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA 2011-04https://appengine.google.com/datastore/explorer?submitted=1&app_id=networkpulse&kind=Report&query=SELECT+*+FROM+Location&namespace=
Location: id=42102

Website: name=4

id=26366

11

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

0.0

1017.41109091

2011-0405 15:10:00 2011-0405 15:15:00 2011-0405 15:20:00 2011-0405 16:30:00

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATEM
Website: name=1

id=26374

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

16.6666666667

1037.709

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATEM
Website: name=1

id=26382

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

0.0

1436.77966667

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATUM
Website: name=5

id=26388

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

0.0

948.9746

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATYM
Website: name=6

id=26390

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw
Location: id=42102

Fig. 8.

The screenshot of the Snapshot

0.0 929.977

0.0

752.8685

2011-0405 table. 18:00:00 2011-0405 14:05:00

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATQM
Website: name=4

Website: name=3 For each website, the average of RTT and PLR are computed every ve minutes. The average agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA 2011-04is computed over all reports submitted from the same location and is stored in the ScreenShot agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATQM id=27336 10 gw 0.0 1185.6978 05 Website: name=4 Location: id=42102 14:10:00 table. Therefore, a website might have a set of average statistics each of which corresponds to a agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA 2011-04agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATEM specic location. stores the3983.527 average measurement results for Website id=27348 4 gw For example, the rst row 0.0 05 Website: name=1 Location: id=42102 14:30:00 #4 at the location with ID 42102 at time 15 : 10 : 00 on April 5, 2011. By doing so, when the agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA 2011-04agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATMM user requests for the global measurement results for a website, we just need to search the most https://appengine.google.com/datastore/explorer?app_id=networkpulse&namespace=&kind=Snapshot&limit=20&offset=0&query=SELECT%20*%20FROM%20Snapshot&viewby=kind Page 1 of 2 recent 12 Snapshots for this website in the Snapshot table and calculate the average. Location: id=42102

id=27331

agxuZXR3b3JrcHVsc2VyEAsSCExvY2F0aW9uGPbIA gw

agxuZXR3b3JrcHVsc2VyDgsSB1dlYnNpdGUiATMM

IV. L ESSONS L EARNED Spiral model is crucial for the success of a project. It advocates stepping progressively, instead of making a giant leap. It turns out that our plan is too ambitious at the very beginning. We have designed our own protocol that can measure the RTT, PLR and packet reordering rate at one probe. However, soon we realized that modifying low-level network protocol on iPhone is quite challenging, and is ofcially discouraged by Apple. We changed our protocol and built it based on CF N etwork , an ofcial library encapsulating the low-level operations. We started from the basic HTTP communications and added new measurement features based on previous achievements. Though the current implementation is not as powerful as the original design, it is doable and has been successfully delivered. Teamwork is also an important thing we have learned during the cooperation. We thought we have done well in allocating tasks and deciding responsibilities. The communication between group members is smooth and in time, especially when facing technical problems. Should we have a chance to revisit everything, we would 1) try to step progressively, and 2) keep on working smoothly between each other. V. C ONTRIBUTIONS OF G ROUP M EMBERS The spirals of our project and contributions of each group member is summarized in Table I.
TABLE I P ROJECT SPIRALS AND GROUP MEMBERS CONTRIBUTIONS . Project Spirals Project Proposal Project Plan Spiral 1: devices being able to measure RTTs by sending legitimate HTTP requests Spiral 2: building up servers on the Google App Engine; servers being able to process dummy RTTs to get the average value Spiral 3.1: devices being able to send the summarized RTTs to servers and retrieve the processed RTT from servers Spiral 3.2: devices being able to measure PLRs by sending ping packets Spiral 4.1: servers being able to process PLRs to get the average value Spiral 4.2: building up a plain but user-friendly interface Project Report Accomplished By Yuan Wei Wei Yuan Yuan Wei Wei Yuan Wei and Yuan

VI. F UTURE W ORK Packet reordering rate is currently unsupported in our implementation. The challenge resides in the fact that low-level network programming are ofcially discouraged by Apple. Figuring out a new implementation based on provided network library is the rst thing to do in the next step. To attract users to participate the measurement, the application has to present the statistics in a fancy way, which is implemented by our partner team. We plan to combine two teams work into a complete project. Finally, we plan to release the application and use it to probing the Internet. By analyzing the collected data from different places over the world, we can get a more in-depth understanding of the global network environment.