Performance Analysis on TCP Communication … · ow control and congestion control mechanisms....

平成２4年度修士論文

Performance Analysis on TCP Communication Behaviors of

Tablet Terminals

大学院情報システム学研究科

情報ネットワークシステム学専攻

学籍番号：1052029

氏名：王瑋凱

主任指導教員：加藤聰彦教授

指導教員：笠井裕之准教授

指導教員：大坐畠智准教授

提出年月日：平成２4 年７月２0 日

修士論文の和文要旨

研究科・専攻大学院情報システム学研究科ネットワークシステム専攻博士前期課程

氏名王瑋凱学籍番号 1052029

論文題目 Performance Analysis on TCP Communication Behaviors of

Tablet Terminals

要旨

TCPは、伝送制御プロトコルといわれ、インターネット通信の中核プロトコルである。

TCPは、あるコンピュータから別のコンピュータに信頼できるデータ転送を行うため

に、誤り検出、フロー制御、輻輳制御など機能を用いる。HTTP、電子メール、FTP な

どの主要なインターネットのアプリケーションは TCPを利用している。近年の携帯情

報端末の高機能化および普及に伴い、今後のモバイル通信のトラヒックの多くは、こ

れらの端末の TCP通信が占めるようになると予想される。TCPはもともと有線ネット

ワークのために提案していたプロトコルである、無線ネットワーク環境で、特に電力

と計算力より小さい携帯端末でどんな性能あるか、しらべとしたい。そこで、このよ

うな端末の TCPトラヒックのふるまいを、実際のトラヒックをモニタリングすること

により調査した。

本研究は、iPad、iPad2など携帯情報端末を対象として、その TCPの機能や性能など

に関して、実際に疑似ネットワーク上で、伝送遅延や伝送誤りを発生させ、そのトラ

ヒックをモニタリングし、パケット単位で TCP通信の振る舞いを解析した。その結果、

携帯情報端末の TCP処理では、重度の伝送誤りが発生した場合、正規の TCPの手順に

はみられないような、誤った動作を示すことが明らかとなった。具体的には、パケッ

トの再送に遅延が発生したり、新たなパケットの送信が間歇的となったりして、TCP

の性能が低下することが明らかとなった。このような問題点は、Macintoshの PCに

おいて、iPadのエミュレータを動作させた実験でも、さらに Macintosh自身を対象

とした実験でも、発見された。このため、本研究では、iPad、iPad2およびその関連

製品の TCP通信には何らかの問題点が存在すると結論付けている。

Performance Analysis on TCP

Communication Behaviors of Tablet

Terminals

by

Wang Weikai

Department of Information Network Systems

Graduate School of Information Systems

University of Electro-Communications

July 2012

[email protected]

Faculty Web Site URL Here (include http://)

http://www.is.uec.ac.jp/

http://www.uec.ac.jp

Abstract

Department of Information Network Systems

Graduate School of Information Systems

University of Electro-Communications

by Wang Weikai

The Transmission Control Protocol is a core protocol in Internet data communications.

TCP provide host-to-host reliable data transmission service by using packet loss detec-

tion, flow control and congestion control mechanisms. HTTP, E-mail FTP and other

major Internet applications relies on TCP. In recent years, tablet device is getting pop-

ular as a platform for portable wireless computing and is used in various communication

scenarios, TCP data traffics from these table PC will take great share of future Internet

data communications. However, such device is newly introduced in the market and it

has limited CPU processing ability because of battery issue, it may possibly have some

differences form the common notebook computers. Because of TCP protocol works as a

basis of various communication applications on tablet device, so in this research analyse

about various types of TCP communication has been done. In these analysis, TCP

communication in various conditions is examined by introducing transmission errors.

Segment sequences in detail have been analysed. This paper shows the evaluation re-

sults and points out some issues which tablet device has in its TCP implementation.

When heavy burst errors are inserted, iOS or other OS X based terminal will transmit

data packet intermittently, this is because terminal will finish retransmitting before all

lost data segments are recovered and turn to new transmit succeeding data segments.

Same results are collected from iOS simulator terminal and OS X terminal, thus, iPad

,iPad2 and other related production have some mal-functions on TCP data communica-

tions are concluded.

Faculty Web Site URL Here (include http://)

http://www.is.uec.ac.jp/

http://www.uec.ac.jp

[email protected]

Contents

Abstract iii

List of Figures vii

1 Introduction 1

1.1 About this research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Structure of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 3

2.1 Basic mechanism of TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 3 Hand-Shake and 4 Hand-Shake . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 Receiver Window Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5 Fast Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Experimental Setup 7

3.1 Configuration of the experiment . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 The generation of burst errors . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 The capture of data traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4 Hardware specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Experiment 11

4.1 Test for iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1 Test for iOS on iPad . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1.1 Upload Test For iOS 4.2 Under No Burst Error . . . . . . 12

4.1.1.2 Test For iOS 4.2 Downloading . . . . . . . . . . . . . . . 14

4.1.1.3 Test For iOS 4.3 Under no Burst Error . . . . . . . . . . 15

4.1.1.4 Test For iOS 4.3 Under 500ms Delay . . . . . . . . . . . 17

4.1.1.5 Test For iOS 4.3 Under 50ms Burst Error . . . . . . . . . 18

4.1.2 Test for iOS on iPad2 . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.2.1 Test for iOS 4.3 under 50ms Burst Error . . . . . . . . . 25

4.1.2.2 Test for iOS 4.3 under 100ms Burst Error . . . . . . . . . 28

4.1.2.3 Test for iOS 4.3 under Background Load . . . . . . . . . 30

4.1.3 Test for iOS on XCode iOS simulator . . . . . . . . . . . . . . . . 35

4.1.4 Test for OS X on MacBook Pro . . . . . . . . . . . . . . . . . . . . 41

4.2 Test for Windows 7 Under 100ms Burst Error . . . . . . . . . . . . . . . . 45

v

5 Results and Discussion 47

6 Conclusion 49

6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2 Future plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Acknowledgements 51

vi

List of Figures

2.1 An example of slide window . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 An example of establish and close connection between sender and receiver 4

2.3 An example of Window Update Event . . . . . . . . . . . . . . . . . . . . 5

2.4 An example of Fast Retransmission with Selective Acknowledgement . . . 6

3.1 Performance Test Configuration of speed test by Internet server . . . . . . 7

3.2 Performance Test Configuration in local WiFi environment . . . . . . . . 8

3.3 Specification of experiment Machines . . . . . . . . . . . . . . . . . . . . . 9

4.1 Test configuration for iOS on iPad . . . . . . . . . . . . . . . . . . . . . . 11

4.2 TCP iOS4.2 Upload Through Internet . . . . . . . . . . . . . . . . . . . . 12

4.3 Time Line of Segment Exchange Around Time 0.5 Through 3 Seconds . . 13

4.4 Sequence number vs time in download for iOS 4.2 . . . . . . . . . . . . . 14

4.5 Time line of segment exchange around 2.5 second . . . . . . . . . . . . . . 15

4.6 Sequence number vs. time in upload for iOS4.3 . . . . . . . . . . . . . . . 16

4.7 Sequence number vs. time in download for iOS4.3 . . . . . . . . . . . . . 16

4.8 Time line of segment exchange of iOS4.3 download. . . . . . . . . . . . . . 17

4.9 Sequence number vs. time with 500 msec delay . . . . . . . . . . . . . . . 18

4.10 Time line of segment exchange of iOS4.3 under 500ms delay . . . . . . . . 19

4.11 Sequence number vs. time with 50ms burst errors . . . . . . . . . . . . . . 20

4.12 Time line of segment exchange at 2 second . . . . . . . . . . . . . . . . . . 21

4.13 Time line of segment exchange at 3 second . . . . . . . . . . . . . . . . . . 22

4.14 Time line of segment exchange around 20 to 26 seconds . . . . . . . . . . 23

4.15 Time line of segment exchange around 40 to 46 seconds . . . . . . . . . . 24

4.16 Test configuration for iOS on iPad2 . . . . . . . . . . . . . . . . . . . . . . 25

4.17 Sequence number vs. time for iPad2 with 50ms burst error . . . . . . . . 26

4.18 Time line of segment exchange between time 5.38 and 5.558 second inFigure 4.17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.19 Time line of segment exchange between time 9.94062 and 10.1043 secondin Figure 4.17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.20 Time line of segment exchange between time 22.60683 and 22.69176 sec-ond in Figure 4.17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.21 Sequence number vs. time for iPad2 with 100ms burst error . . . . . . . . 30

4.22 Time line of segment exchange between time 4.374 2and 14.8901 secondin Fig 4.21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.23 Time line of segment exchange between time 49.4307 and 51.34401 secondin Figure 4.21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

vii

4.24 Sequence number vs. time for iPad2 with background load and 50msburst error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.25 Time line of segment exchange between time 14.37094 and 26.29731 sec-ond in 4.25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.26 Test configuration for iOS simulator TCP . . . . . . . . . . . . . . . . . . 35

4.27 Sequence number vs. time for iOS simulator with 200ms burst error . . . 35

4.28 Time line of segment exchange between time 2.463478 and 12.068945 sec-ond in 4.27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.29 Time line of segment exchange between time 12.068945 and 13.381198second in 4.27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.30 Time line of segment exchange between time 107.550765 and 108.955763second in Figure 4.27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39


4.32 Test configuration for OS X TCP . . . . . . . . . . . . . . . . . . . . . . . 41

4.33 Sequence number vs. time for OSX with 200ms burst error . . . . . . . . 41

4.34 Time line of segment exchange between time 1.886613 and 4.062501 sec-ond in Figure 4.33 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43


4.36 Test configuration for Windows 7 TCP . . . . . . . . . . . . . . . . . . . . 45

4.37 Sequence number vs. time for Windows 7 PC with 100ms burst error . . . 45

4.38 Windows7 handles 100ms burst error . . . . . . . . . . . . . . . . . . . . . 46

5.1 Summary for all experiments parameters and results . . . . . . . . . . . . 48

viii

Chapter 1

Introduction

1.1 About this research

Recently, tablet devices are becoming more and more popular. People are using these

devices for many purposes including browsing, email, file sharing, gaming and streaming.

Among those devices, iPad series are attracting a lot of attentions.

However, iPad series are newly introduced to the market and they may possibly have

some differences from the common wireless terminals such as notebook computers. E-

specially, since various network applications are using TCP as their basis of the com-

munication. the throughput of TCP communication will give a large impact on their

utility value.

From this point of view, iPad is tested for the TCP behaviors in detail with its operat-

ing system, iOS 4.2 and iOS 4.3. In the tests, Wireshark[1] is used for capturing TCP

communication of iPad and analyzed the captured data in detail. iPad TCP commu-

nication in various conditions such as iPad as a data sender, as a data receiver, with

large propagation delay, and with heavy transmission errors are examined. As a result,

several problems are pointed out on iPad TCP behaviors. Especially test with heavy

transmission errors revealed some TCP mal-behaviors. When TCP segments are lost,

the iPad TCP falls into an ”intermittent” data transmission which reduces the TCP

throughput drastically[2].

Since iPad2 is introduced with a new hardware, but it is possible that there still remain

some deficiencies in its TCP behaviors. Especially, in the previous experiments[3], the

deficiencies were detected though the tests with heavy transmission errors. So, a detail

analysis of iPad2 TCP behaviors under those tests has been intensively performed. This

test also eliminated the possibility of hardware influence.

1

Since iOS is a modification of OS X with different application larger but same core of

operating system, tests over XCode iOS simulator and OS X derationing system are also

carried out, similar intermittent data transmission are also found during experiment.

This thesis presents the results of those tests, and based on the experimental results,

some possible issues had been pointed out in iPad and iPad2 TCP implementation.

These findings are useful for designing a more powerful tablet device.

1.2 Structure of this thesis

In chapter2 background theory will be introduced. In chapter3 the experiment setting

will be introduced. In chapter4 test on iPad,iPad2, iOS simulator, OS X and Windows 7

will be described. In chapter 5 there will be a discussion on test results. At last, chapter

6 is the conclusion of whole thesis.

2

Chapter 2

Background

2.1 Basic mechanism of TCP

With the development of ubiquitous network, many applications such as WWW, E-mail,

FTP, Bittorrent are based on TCP’s reliable service, therefore the Transmission Control

Protocol carries great share of Internet traffic. TCP is a protocol works on transportation

layer of ISO model, under transportation layer there is IP layer, which only provide

best-effort service for data exchange[4]. To establish reliable data exchange service, each

packet sent from sender will have to be confirmed by receiver‘s acknowledgement packet

which contains one sequence number and sometimes with selective sequence number.

Acknowledgement packet also contains receiver‘s window size, this will be used to control

slid windows size by sender. TCP standard also specified a sliding window for data flow

control[5]. Before sending data, sender assigns buffered data with sequence number,

then packet is transmitted by IP layer. After receiver confirmed these packets, sender

will transmit new packets[6].

Data stream

Slide Window

Slide WindowTransmitted data

1 2 3 4 5 6 7 8 9 . . .

1 2 3 4 5 6 7 8 9 . . . Data stream

Figure 2.1: An example of slide window.

3

2.2 3 Hand-Shake and 4 Hand-Shake

To establish a reliable TCP connection between sender and receiver, 3 Hand-Shake is

needed, that is, sender sends SYN segment requests TCP connection, client returns SYN

ACK segment confirms this request, and then server returns ACK acknowledges client

SYN ACK segment, TCP connection between server and client then is ready to data

transmission. When data transmission is finished, 4 hand-shake is needed to make sure

two host cut connection separately, first sender transmits FIN segment request to close

connection, then receiver returns ACK segment, after that receiver will transmit a FIN

segment too, after sended confirms this FIN segment with ACK segment, connection

between sender and receiver is closed. These two processes are shown in Figure 2.2

Server Client PC

SYN ACK

0.001 SYN

ACK

0.002

0.003

Data Transmission and ACKs

10.001 FIN ACK

ACK10.002

FIN ACK10.003

10.004 ACK

Figure 2.2: An example of establish and close connection between sender and receiver.

2.3 Congestion Control

Congestion control algorithm is an important part of TCP. To achieve high performance

and avoid congestion collapse, some mechanisms control the throughput of data, keeping

data communications without congestion. Sender congestion control algorithm adjust

data throughput by acknowledgments from receiver without other information. There

are 4 key algorithms in modern TCP: Slow-start, congestion avoidance, fast retransmit,

and fast recovery[7]. Sender side also has retransmission time out which is based on

the estimated round-trip time (or RTT) between sender and receiver[8]. Original TCP

4

congestion avoidance algorithm is design for wire network environment in which packet

is mainly caused by congestion, therefore, original congestion avoidance algorithm is

not applied for wireless environments, because in wireless environment packet losses are

mainly caused by noise, interfere and other random reasons. TCP Westwood is proposed

to solve congestion control problems in wireless environments, but this algorithm is not

widely applied in commercial systems.

2.4 Receiver Window Update

When receiver‘s is not able to accept more new packets, it will reduce receiver window

size advertised in ACK packet, as a responde sender will reduce the amount of packets

to send. When receiver returns ACK packet with zero window, sender will have to stop

further transmission and starts persist timer [9], when timer is time out, sender will first

send a small amount of data as a probe, and continue normal transmission if receiver

window is large enough. Figure 2.3 demonstrates receiver window update process in

detail.

Server Client PC

4.37094

4.40756

79022:80470(1448)

ACK 80470 WIN=0

4.53861 ACK 80470 WIN=62264

9.472849.47289 ACK 80471

80470 :80471(1)

9.48066 80471:81919(1448)9.48068 ACK 81919

Figure 2.3: An example of Window Update Event.

2.5 Fast Retransmission

As mentioned in last section, fast retransmission is an important mechanism to retrans-

mit lost packet. When certain packet is lost during transmission, receiver will not be

5

able to send ACK packet with that sequence number, therefore continue to send ACK

packets with prior sequence number, when sender gets 3 duplicate ACK packets, it will

start a retransmission without waiting for time out[10], this is called fast retransmission

which is shown in Figure 2.4. There is also an option called selective ACK, or SACK,

which let receiver can confirm segments after lost ones[11].

Server Client PC

1448:2896(1448) LostACK 1448

2896:4344(1448)

4344:5792(1448)

5792:6240(1448)

Fast Retransmission1448:2896(1488)

0.001 1:1448(1448)

ACK 1448(dup ACK #1)SACK 2896-4344

ACK 1448(dup ACK #2)SACK 2896-5792

ACK 1448(dup ACK #3)SACK 2896-6240

0.002

0.004

0.005

0.006

0.007

0.008

0.009

0.010

Figure 2.4: An example of Fast Retransmission with Selective Acknowledgement.

6

Chapter 3

Experimental Setup

3.1 Configuration of the experiment

At the very beginning, network speed test application is used on iPad, Figure 4.1 shows

the configuration for the perform test. There is an iPad connected to Internet speed

test server, data transmissions are captured on bridge machine with Wireshark installed.

Because this test can easily be affected by other traffics, later tests are conducted in local

WiFi environment, also more adjustable parameters such as burst error and transmission

delay are added on bridge machine.

Bridge PC

iPad Server

Internet

CaputuringCaputuring

Figure 3.1: Performance Test Configuration of speed test by Internet server.

Figure 3.2 shows the configuration for the performance test, whose operating system is

iOS 4.3. An iPad2 or a Laptop PC uses WiFi interface and accesses to an Ethernet

LAN via an access point. It communicates with a local PC connected to Ethernet

LAN through a bridge PC which has a Linux installed. The bridge PC performs the

network emulator which introduces burst error, and the packet capturing function is also

performed on it. On sever side, FTP client has been installed, which allows iPad2 or

7

Laptop PC works as a FTP server. The local PC can logon FTP server and download

file from it. Then data traffic on both server and client PC has been captured.

Experiment Configuration

Test configuration

Wireshark for capturingDummynet for bridging

FTP server

50ms or 100ms burst error for both directions

in every 5 seconds

Figure 3.2: Performance Test Configurational local WiFi environment.

In order to give some kind of stress to different kinds of TCP implementations, heavier

burst error is introduced to simulate wireless packet loss environment. During burst

error all segments are dropped for 100ms in both directions in every 5 seconds. This is

provided by DummyNet channel function[12].

During the daily use of iPad2, when more than several applications had been run, the

upload of picture to Facebook costs more time than usual, to replicate this scenario,

similar applications have been loaded and hide to the background when FTP service

starts, and the TCP data exchange has been captured for the later analysis.

The operating system on server side are iOS 4.2.1, iOS 4.3.2, Windows 7, and on client

OS is Debian5.

3.2 The generation of burst errors

To generate burst error on Debian5, DummyNet is needed. Although FreeBSD has al-

ready includes this function in core of OS, but because of hardware driver compatible

issue, debian5 is chosen. So a install process is needed, kernel of Debian5 is also recom-

piled, then DummyNet starts to work. After installation, a script is needed to generate

8

proper patten of burst error. In this script, traffic through two LAN interfaces will be

dropped for 50ms(in some experiments it is set wo 100 or 200ms)in every 5 seconds on

both up and down link.

3.3 The capture of data traffic

Data traffic is captured on two interfaces of bridge PC for each round of experiment,

later two traffic will be compared and then formed into one traffic log. The reason why

of doing so is that, with only one side of traffic will not able to find out exact lost point

of packet.

3.4 Hardware specification

In Fig 3.3 all experiment machine are list with hardware and software specifications.

Machine OS CPU Memory Main Applications Interface

Bridge Debian5 Pentinum4 3.4Ghz 1GB Dummynet

Wireshark

100M Lan X 2

WiFi AP

iPad iOS4.2,iOS4.3 Apple A4 1Ghz 256MB

FTP Sever WiFi 802.11n

iPad2 iOS4.3 Apple A5 1Ghz Duel

Core

512MB

FTP Server, 3D

Game

WiFi 802.11n

Notebook Windows 7 Pro

SP1

Centrino 2Ghz Duel

Core

1GB

FTP Server

Wireshark

WiFi

2915ABG

MacBookPro OS X 10.6.7 Intel Core i7 2.6Ghz

8GB

FTP Server

Wireshark

WiFi 802.11n

Client Debian5 Pentium4 3.4Ghz 1GB

Filezilla

Wireshark

100MB Lan

Figure 3.3: Specification of experiment Machines.

9

Chapter 4

Experiment

4.1 Test for iOS

In this section, experiments on iOS are introduced, all tests are performed on both real

hardware and code simulator. Because it is very difficult to capture packet on iPad, so

instead, packet capturing is performed on one of LAN interfaces on Bridge PC which is

on iPad side, and the result is actuate enough.

4.1.1 Test for iOS on iPad

First, experiments for iOS on iPad are introduced, upload and download tests are per-

formed through network speed test application, burst errors are introduced by dummynet

installed on bridge PC, the data segments of of test are captured in the method mention

in Chapter 3. Experiment configuration is shown in Figure4.1.

Bridge PC

iPad Server

Internet

CaputuringCaputuring

Figure 4.1: Test configuration for iOS on iPad.

11

4.1.1.1 Upload Test For iOS 4.2 Under No Burst Error

First,iOS TCP upload test is performed. Several TCP communications in which iPad

transferred data to the SpeedTest server are captured. Figure 4.2 shows an example of

captured communications. This figure is a plot of the sequence number in TCP data

segments versus the time when the segments are captured. This graph is generated by

Wireshark. The time is the elapsed time since the SYN segment is captured for the

focused TCP connection. The sequence number corresponds to the transferred bytes.

1 2 3 4 5 6 7 Second

500000

1000000

1500000

SequenceNumber

(B)

Figure 4.2: TCP iOS4.2 Upload Through Internet.

According to this figure, there are several time gaps in the communication. Those gaps

range from one second to two seconds, and the total duration of the gaps seems to be

larger than the total duration when the data segments are actually transferred.

Figure 4.3 shows the detailed time line of TCP segment exchange at the time gap between

time 0.6 second and time 2.5 second. In this figure, the number at the left side shows

the elapsed time from the SYN segment. A horizontal line with arrow indicates a data

segment and an ACK segment exchanged between iPad and the SpeedTest server. In the

case of a data segment, the figure uses a representation such as ”111862:113310(1448),”

which means that the sequence number specified in the header of this segment is 111862

12

and the number of bytes in this segment is 1448. The number 113310 is the sequence

number assigned the last byte in this segment plus 1. This number corresponds to

the sequence number in the header contained in the next data segment. For an ACK

segment, this figure shows the acknowledgment number in the style of ”ack 113310”

and the other parameters such as window size are also added when it is needed. Those

representations are commonly used[9].

iPad SpeedTest server

0.6000 111862:113310(1448)

ack 113310 win 768

1.7565sec

0.6320

ack 113310 win 53760.7109

ack 113310 win 139520.7113

ack 113310 win 296960.7115

2.4680 113310:114758(1448)

Figure 4.3: Time line of segment exchange around time 0.5 through 3 seconds.

In Figure 4.3, a data segment is transferred at time 0.6000 and it is acknowledged at time

0.6320. However, the window size in this ACK segment is 768, which is smaller than

the maximum segment size (MSS) used in this TCP connection. So iPad stops the data

sending. At time 0.7109, the SpeedTest server sends an ACK segment which extends

the window size to 5376 (this ACK is called an window update). The server also sends

window updates at time 0.7113 and 0.7115. However, iPad does not correspond to those

window updates at all and looks like keeping a blocked status. After around 1.8 seconds,

iPad restarts the data sending again. The other time gaps in this communication (around

time 3 to 4 seconds and time 5 second) shows the same behaviours.

In this test, it could be considered that the TCP module in iOS 4.2 iPad has some

deficiency in the handling of window updates and data segment sending. Data trans-

missions have been interrupted into many separated ones, this is called gap which will

be mentioned later in this thesis. Gaps degraded throughput of iPad significantly.

13

4.1.1.2 Test For iOS 4.2 Downloading

Then download test where iPad receives data from the file server is performed. Figure 4.4

shows the sequence number versus time relationship of a data download communication.

Basically, the communication is going well compared with the upload test.

0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5time(sec)

7

6

5

4

3

2

1

sequence number

(Mbytes)

Figure 4.4: Sequence number vs time in download for iOS 4.2.

However, there are two gaps at time 2.5 and time 3.3 seconds. Figure 4.5 shows the

detailed time line of segment exchanges at around 2.5 second. In this sequence, three

data segments sent by the SpeedTest server are detected at time 2.4120, 2.4121 and

2.4122. At time 2.4159, iPad sends an ACK segment which gives the acknowledgment

up to the second data segment (segment 1630781). After that, the server sends the

succeeding six data segments. iPad, then, sends an ACK segments which gives the

acknowledgment to the data segment 1632229. After that, iPad looks like entering a

blocked status and does not send any ACK segments for other data segments. After

around 0.2 seconds, the server seems to retransmit the oldest unacknowledged data

segment. This retransmission will be caused by retransmission timeout. After that,

iPad returns an ACK segments which gives the acknowledgment for all data segments.

The time gap at around 3.3 second shows the similar situation.

It is possible that the data segment 1633677 is actually lost at the wireless LAN after

it was captured at the bridge PC. However, in this case, iPad needs to send duplicated

ACK segments for the rest of data segments, because they are not retransmitted and are

14

iPad SpeedTest server

2.4120 1629333:1630781(1448)

ack 1632229

ack 1633677

1630781:1632229(1448)

1632229:1633677(1448)

1633677:1635125(1448)1635125:1636573(1448)1636573:1638021(1448)1638021:1639469(1448)1639469:1640917(1448)1640917:1642365(1448)

1633677:1635125(1448): retransmission0.2122sec

0.2154sec

ack 16423650.0830sec

2.41212.4122

2.4159

2.41642.41652.4166

2.41682.41692.4170

2.4196

2.6318

2.7148

Figure 4.5: Time line of segment exchange around 2.5 second.

acknowledged by iPad. So, it is considered that iPad does receive those data segments

from 1633677 to 16409117 but does not send any ACK segments for some period to

time.

In this test, iOS 4.2 TCP has better performance than uploading test. But at the very

beginning data transmissions are not smooth, shorter gaps also exist during downloading

data transmissions.

4.1.1.3 Test For iOS 4.3 Under no Burst Error

After tests for iOS4.2, iPad OS has been updated to iOS4.3. Performance test with no

propagation delays nor transmission errors introduced at the bridge PC is performed.

Figure 4.6 shows the sequence number versus time relationship when file data is trans-

ferred from iPad to ftp client PC (upload direction from the viewpoint of iPad). In this

test, the initial window size and MSS of the file client PC are set to 1460. The window

size increases gradually to 65535.

The communication is going well compared with the result in iOS 4.2 version iPad. In

this communication, 267 ACK segments which closes the window and the corresponding

window updates are transmitted. However, iPad restarts the data transfer in response

to window updates about in 5 mili seconds. Similar experiments have been performed

15

5 10 15 20 25 30 35 40 45 time(sec)

sequencenumber

(Mbytes)

15

10

5

Figure 4.6: Sequence number vs. time in upload for iOS4.3.

in many times, and as the result, it could be considered the problem identified for iOS

4.2 version iPad is resolved in the iOS 4.3.

Figure 4.7 shows the sequence number versus time relationship for data transfer from ftp

client PC to iPad(download direction for iPad). Similarly, the communication is going

well and the problems identified in iOS 4.2 was not found in iOS 4.3 version.

1 2 3 4 5 6 7 8 9 time(sec)

sequencenumber

(Mbytes)

8

7

6

5

4

3

2

1

Figure 4.7: Sequence number vs. time in download for iOS4.3.

16

Figure 4.8 shows the detailed time line of segment exchanges at the very beginning of

this communication. It is needed to mention that there is some amount of time delay

in iPad between receiving a data segment and sending the corresponding ACK segment.

In this figure, there is several mili seconds order delay. Throughout the communication,

the delay is around several mili seconds to tens mili seconds. This delay may cause the

performance degradation in the case of large transmission delay and small window size.

iPad ftp client PC

1817:3277(1460)

0.06387

0.06979

0.06381

0.0590

0.063840.06385

0.06386

3277:4737(1460)

6197:7657(1460)

4737:6197(1460)

ack 3277

ack 4737

7657:9117(1460)

0.06984

0.06985

9117:10577(1460)

10577:12037(1460)

ack 76570.07258

0.07264

0.07268

0.07260

0.07261

0.07262

12037:13497(1460)

14957:16417(1460)

13497:14957(1460)

ack 9117

16417:17877(1460)

4.8msec

6.0msec

8.7msec

8.8msec

Figure 4.8: Time line of segment exchange of iOS4.3 download.

In this test, it could be considered that the TCP module in iOS 4.3 iPad has over came

iOS4.2 had in normal downloading and uploading.

4.1.1.4 Test For iOS 4.3 Under 500ms Delay

Next, various propagation delays are introduced at the bridge PC. Figure 4.9 shows

the sequence number versus time relationship when 500 mili seconds round trip delay

is introduced. Specifically, 250 mili seconds delay is added in each direction. Because

under 500ms delay uploading 20 MBytes file unsuccessful, file size is changed to 2 M-

Bytes The data transfer is the upload direction and the capturing is done at the iPad

side of the bridge PC. In this communication, iPad transmits several data segments

17

contiguously and waits for their acknowledgments, and these behaviours are repeated.

Figure 11 shows the detailed time line of segment exchanges in the very beginning part

of this communication. At time 0.6120, an ACK segment is transferred to iPad with

window size 5480, which establishes this TCP connection by the three-way handshake.

iPad transmits four data segments within the advertized window. The traditional slow

start procedure is not adopted here. Then iPad waits for four ACK segments sent by ftp

client PC, and around 100 mili seconds after receiving ACKs iPad transmits eleven data

segments (though it can transmit twelve data segments according to the advertized win-

dow), and waits for eleven ACKs from ftp client PC. As a TCP procedure, it is possible

to transmit data segment when one ACK segment is received, but iPad waits for the

arrival of all ACK segments (and additional duration). These procedures are repeated

until the end of the communication. So, the results depicted in Fig. 10 (contiguous data

transfer and wait) are observed. Figure 4.10 shows time line of segment exchange for

Figure 4.9.

5 10 15 20 25 30 35 time(sec)

20

15

10

5

sequence number

(Mbytes)

2

1.5

1

0.5

Figure 4.9: Sequence number vs. time with 500 msec delay.

4.1.1.5 Test For iOS 4.3 Under 50ms Burst Error

As the last evaluation, transmission errors are introduced at the bridge PC. In order

to give some kind of stress to iPad TCP implementation, errors which are heavier than

18

iPad ftp client PC

0

1:1449(1448)

1.232021.23203

0.7275

SYN0.1062 SYN+ACK

0.6120 ack 1 win 5840

0.72830.72900.7302

1449:2897(1448)

4097:5545(1448)2897:4097(1448)

1.236001.23601

ack 1449ack 2897ack 4097

ack 5545 win 173765545:6993(1448)1.3358

1.33661.33741.3383

6993:8441(1448)

9889:11337(1448)8441:9889(1448)

11337:12785(1448)1.33911.34001.34231.3433

12785:14233(1448)

15681:17129(1448)14233:15681(1448)

17129:18577(1448)1.34411.34511.3507

1.8400

18577:20025(1448)

ack 6993

20025:21473(1448)

Followed by 10 ACKs up to 21473

Figure 4.10: Time line of segment exchange of iOS4.3 under 500ms delay.

19

normal environment are introduced. The error drops all segments for 50 mili seconds

in both directions for each 5 seconds period. Upload data transfer is evaluated.Figure

4.11 shows the sequence number versus time relationship when the above mentioned

burst errors are added. There are three ”flat” parts in which the data transfer is not

performed properly. Besides those parts, several ”inappropriate” TCP behaviours are

found.

5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80time

(sec)

20

15

10

5

sequence number(Mbytes)

Figure 4.11: Sequence number vs. time with 50ms burst errors.

The first burst errors are added around at time 2 second. Figure 4.12 shows the detailed

time line at this point.Sixteen data segments are lost around time 2 second. For the

succeeding data segments such as time 2.0001 and 2.00410, the ftp client PC replies

duplicate ACK segments with a SACK option. At time 2.0201, the fast retransmit pro-

cedure is detected. For this retransmission, a new ACK segment is replied with a SACK

option, and for this new ACK, iPad seems to retransmit the next missing data segment

(see time 2.0321 and 2.0561). The same retransmission is performed for all missing data

segments and all the data are acknowledged at time 2.2362. So far, iPad TCP seems to

work well.Next burst errors occur around time 3 second. However, iPad TCP behaves

”inappropriately” as shown in Fig 4.13. One data segment is lost before time 3.1602,

and so the ftp client PC replies duplicate ACK segments in response to succeeding data

segments. However, iPad does not retransmit the lost segment even it receives three

duplicate ACKs. Instead, it continues to sending succeeding data segments. In this

20

sequence, it is likely that iPad performs first retransmit after it receives 23 duplicate

ACKs. Similar behaviours are repeated for other burst errors.

iPad ftp client PC

1.6161

2.0201

1.9881

1.6202163625:165073(1448)

1.6203ack 165073

1.9882

2.0001

2.0002

ack 165073 (dup ACK #1)

ack 165073 (dup ACK #2) SACK 188241-189689

188241:189689(1448)

165073:166521(1448) Fast Retransmission

Followed by similar retranmsissions

162177:163625(1448)

162177:163625(1448) retransmission

2.00410188689:191137(1448)

2.00412ack 165073 (dup ACK #3)

SACK 188241-191137

2.0202ack 166521 SACK 188241-191137

2.0321166521:167969(1448) Retransmission

2.0322ack 167969 SACK 188241-191137

2.0561167969:169417(1448) Retransmission

2.0562ack 169417 SACK 188241-191137

2.2361186793:188241(1448) Retransmission

2.2362ack 191137

16 data segments are lost.

Figure 4.12: Time line of segment exchange at 2 second.

Then detailed analysis around time 20 second is shown. Figure 4.14 shows the detailed

time line. Before time 21.57238, one data segment is lost, and iPad keeps transmitting

succeeding data segments with ignoring duplicate ACKs from the ftp client PC. This

is exactly the same as Fig. 14. In this case, the ftp client PC sends 19 duplicate

21

iPad ftp client PC

3.0881

3.1602

3.1281ack 573409

3.1603

3.16411

3.16413ack 573409 (dup ACK #2)

SACK 574857-577753

576305:577753(1448)

Followed by similar tranmsissions

571961:573409(1448)

3.1642566653:579201(1448)

ack 608161

One data segment is lost.

574857:576305(1448)

ack 573409 (dup ACK #1) SACK 574857-576305

3.1643ack 573409 (dup ACK #3)

SACK 574857-579201

3.2162606713:608161(1448)

3.2163ack 573409 (dup ACK #23)

SACK 574857-608161

3.2201573409:574857(1448) Fast Retransmission

3.2202

Figure 4.13: Time line of segment exchange at 3 second.

ACKs. Then, after 0.3 seconds, iPad retransmits the lost segment. This retransmission

is considered as a timeout retransmission. After that, the first ”flat” part in Fig. 12

starts. iPad sends one data segment, receives the corresponding ACK, and, 0.4 seconds

later, sends the next one data segment. iPad repeats this behavior from time 22.34438

to time 25.2565.This is the reason for the first ”flat” part in the sequence vs. time chart.

After that, iPad starts frequent data transmissions with changing it’s MSS to 1188.

At the end of this section, behaviours of the second ”flat” part in Fig 4.11 is decribed.

Figure 4.15 shows the detailed time line in this part. Before time 42.41255, twenty-one

data segments are lost. iPad transmits a succeeding data segment and the ftp client PC

replies a duplicate ACK segment with SACK option. For this ACK segment at time

22

iPad ftp client PC

21.5084

21.57238

21.5481ack 9274441

21.57241


9272993:9274441(1448)

ack 9303401 win 23168

One data segment is lost.

9275889:9277337(1448)

ack 9274441 (dup ACK #1) SACK 9275889-9277337

21.620499301953:9303401(1448)

21.62052

21.940379274441:9275889(1448)

Retransmission

21.94041

ack 9274441 (dup ACK #19) SACK 9275889-9303401

ack 9303401 win 46336 21.9413

22.344389303401:9304849(1448)

22.34442ack 9304849

22.744399304849:9306297(1448)

22.74442ack 9306297


24.8524ack 9313537

25.25659313537:9314985(1448)

25.2566ack 9314985

26.160389314985:9316173(1188)

26.16042ack 9316173

26.172389316173:9317361(1188)

26.17241ack 9317361

26.176389317361:9318549(1188)

26.17641ack 9318549

Figure 4.14: Time line of segment exchange around 20 to 26 seconds.

23

42.41259, iPad responds in the following way.First, iPad waits for around 0.4 second-

s.Then, it retransmits the oldest lost data segment at time 42.79655. This retransmission

occurs neither for three duplicate ACK nor retransmission timeout. It is considered that

it is done in response to SACK option.The ftp client PC responds to this by sending a

new ACK segment at time 42.79663. For this ACK segment, iPad sends a succeeding

data segment. The ftp client PC responds to this with a duplicate ACK with SACK

option.

iPad ftp client PC

41.6166

42.39655

41.6561ack 15291813

42.39659

42.79663

Followed by similar transmissions

15290625:15291813(1188)

21 data segments are lost.

ack 15291813 (dup ACK #1)

42.8127

15290625:15291813(1188) retransmission

42.4125515316761:15317949(1188)

42.41259ack 15291813 (dup ACK #2) SACK 15316761-15317949

42.7965515291813:15293001(1188) retransmission

ack 15293001 SACK 15316761-1531794942.812615317949:15319137(1188)

ack 15293001 (dup ACK #1) SACK 15316761-15319137

43.2005615293001:15294189(1188) retransmission

46.4127

46.42863

46.412615302505:15303693(1188) retransmission

ack 15303693 win 26136 SACK 15316761-15319137

46.4285915328641:15329829(1188)

ack 15303693 (dup ACK #1) SACK 15316761-15329829

46.8447

46.844615303693:15304881(1188) retransmission

ack 15304881 win 26136 SACK 15316761-15329829

Followed by similar retransmissions

Figure 4.15: Time line of segment exchange around 40 to 46 seconds.

Then iPad repeats the similar behaviour. This is the reason for the second ”flat” part

in the sequence number vs. time chart. This behaviour is repeated until time 46.42863.

This is because, at this point, the advertised window range is up to 15,329,828 (acknowl-

edgment number is 15,303,693 and the window size is 26,136), and the transmitted data

segment is also 15,329,828. After that, the retransmission of lost segments and their

acknowledgment procedure are repeated as is time 46.8446 and 46.8447. This behaviour

does not include a large time gap. This is the reason for the second ”flat” part. In the

third ”flat” part, the similar behaviours as the first ”flat” part are detected.

24

4.1.2 Test for iOS on iPad2

Then, experiments for iOS on iPad2 are introduced, upload tests are performed by FTP

through local WiFi network, burst errors are introduced by dummynet on bridge PC.

Experiment configuration is shown in Figure 4.16.

Bridge PC

iPad2 CaputuringCaputuring Client PC

Figure 4.16: Test configuration for iOS on iPad2.

4.1.2.1 Test for iOS 4.3 under 50ms Burst Error

Experiment with continuous packet losses for 50ms in every 5 second is performed.

Figure 4.17 shows a plot of sequence number in TCP data segments versus the time. In

Figure 4.17, data transmission of iPad2 appears to be different than usual ones.

At the beginning, iPad2 transmits data smoothly. After time 4.8809 second, packet losses

were inserted with 21 data segments being lost. Figure 4.18 is the time line which shows

details of how iPad2 handles these lost segments. At time 4.93417 second, client PC sends

duplicate ACK segment requesting for sequence number 2626425 with SACK option

confirming segment 2656833-2658281. iPad2 then sends succeeding segment 2658281,

and client PC returns second duplicate ACK with SACK for segment 2656833-2659129.

Then iPad2 continuously sends 4 data segments at time 4.9418, 4.9436, 4.9454, and

4.9474 second, and then, at time 4.94748, client PC send 4 duplicate ACKs with SACK

option which confirms segment from 2656833 to 2665521. But, iPad2 continues ignoring

duplicate ACKs and sending succeeding data segment. Every time iPad2 sends out

one segment, client PC replies a duplicate ACK. Similar behaviors continued until 24th

duplicate ACK, at time 5.00162 second, and at this time iPad2 starts fast retransmission,

to every retransmission, and client PC sends out corresponding ACKs. At time 5.0586

client PC confirmed all retransmissions.

25

5

10

time

(sec)

10

15

20

sequence

number

(Mbytes)

10 20 30 40 50 60 70

Figure 4.17: Sequence number vs. time for iPad2 with 50ms burst error.

This is similar with the results of 20 ms burst error test. It seems that iPad2 does not

respond duplicate ACKs quickly.The second group of burst errors happened after time

9.94062 second. 20 data segments are lost in this group of errors, but iPad2 ignores

25 duplicate ACKs from client PC and then starts retransmission. Compared to the

sequence in Figure 4.18, the retransmission in Figure 4.19 has some problems. For

example, at time 10.06154 second, client PC sends out an ACK segment, but iPad2

waits for about 11ms and then sends out the succeeding data segment at time 10.07258

second. Client PC replies this segment with ACK within less than 1ms, but iPad2 waits

another 11ms again and then sends the next data segment at time 10.08401 second.

Similar behaviors continue in other retransmissions, and the waiting duration varies

from 8ms to 20ms.

Another kind of intermittent data transfer happens when burst errors are not inserted. It

is clear that in Figure 4.17 , there is a period from time 20 second to 45 second, when the

throughput is lower than average. Figure 4.20 gives a detailed time line chart. At time

22.60683 second, client PC sends segment ACK 9589909, and iPad2 sends 2 succeeding

data segments at time 22.60889 and 22.61442 second. Then, at time 22.61445 second,

client PC sends an ACK segment to iPad2, but iPad2 waits 74ms and sends out a data

segment at time 22.68881 second. Similar behaviors happened from time from 55 to 60

seconds.

The transmission last 76.144 seconds, and iPad2 had an average throughput of 2.634

26

iPad2 Client PC

4.8809 ACK 2626425

4.93414 2656833:2658281(1448)

4.93417

4.9379 2658281:2659729(1448)

4.94184.9436 2661177:2662625(1448)

4.9454 2662625:2664073(1448)4.9474 2664073:2665521(1448)

Followed by similar transmissionsACK 2626425 (dup ACK #24)

SACK 2656833-26915854.9998

5.00162Fast retransmission

2626425:2627873(1448)

ACK 2626425 (dup ACK #1)SACK 2656833-2658281

21 data segments lost

4.9407ACK 2626425 (dup ACK #2)

SACK 2656833-26597292659729:2661177(1448)

4.94748ACK 2626425 (dup ACK #3)

SACK 2656833-2661177

4.947493ACK 2626425 (dup ACK #4)

SACK 2656833-2662625

4.947499ACK 2626425 (dup ACK #5)

SACK 2656833-2664073

4.9475ACK 2626425 (dup ACK #6)

SACK 2656833-26655214.95034 26655521:2666969(1448)

4.95037ACK 2626425 (dup ACK #7)

SACK 2656833-2666969

5.00165 ACK 2627873

5.0033Retransmission

2627873:2629321(1448)5.0034 ACK 2629321



2655385:2656833(1448)5.0586 ACK 2691585

Figure 4.18: Time line of segment exchange between time 5.38 and 5.558 second inFigure 4.17.

27

iPad2 Client PC

9.9241 ACK 5133288

9.94062 5162248:5163696(1448)

9.94065

9.94231 5163696:5165144(1448)

9.95075

9.95528

10.1043

ACK 5133288 (dup ACK #1)SACK 5162248-5163696


9.94233ACK 5133288 (dup ACK #2)

SACK 5162248-51651445165144:5166592(1448)

10.06154

10.07258

10.07261

10.08401

9.95077ACK 5133288 (dup ACK #3)

SACK 5162248-51665925166592:5168040(1448)

Followed by similar transmissionsACK 5139080

Retransmission5139080:5140582(1448)

ACK 5140582Retransmission

5140582:5141796(1448)Followed by similar retransmissions

10.0907 ACK 5144872



Figure 4.19: Time line of segment exchange between time 9.94062 and 10.1043 secondin Figure 4.17.

Mbps. Due to the intermittent data transfer, the throughput degrades significantly

compared to the experiment with 10 ms burst error.

4.1.2.2 Test for iOS 4.3 under 100ms Burst Error

Figurer 4.21 is a sequence number graph. There are many flat parts in the graph. The

length of these flat parts ranges from 5 to 15 seconds. Figure 4.22 shows a detailed time

line in the first flat part. At time 4.7877 second, segment losses are detected, with 45

data segments being lost. At time 4.7878 second, client PC sends the first duplicate

ACK with acknowledgement number 2415017. At time 5.1813, about 0.4 second later,

28

iPad2 Client PC

22.60683 ACK 9589909

22.61442 9591357:9592805(1448)22.60889 9589909:9591357(1448)

22.61445 ACK 9592805

22.69173 9594523:9595701(1448)22.68881 9592805:9594523(1448)

22.69176 ACK 9595701

Figure 4.20: Time line of segment exchange between time 22.60683 and 22.69176second in Figure 4.17.

iPad2 retransmitted data segment 2415017. Client PC replies with ACK segment at

time 5.1814 second, and iPad2 transmits the succeeding data segment 2480177 at time

5.18842 second. This is done quickly. Client PC sends another duplicate ACK with

acknowledgement number 2416465 at time 5.18845 second, and then iPad2 retransmitted

this segment at time 5.6831 second. This retransmission is performed after about 0.5

second waiting. Similar behavior continued until time 14.8142 second, which is the

reason for the first flat part. Around time 9.7799 second, another 100ms burst error was

inserted. But, at this timing, iPad2 was under waiting status, and so this burst error did

not affect any more. At time 14.7799 second, the 3rd burst error was inserted and caused

1 retransmission data segment loss, as shown in the figure. iPad2 then retransmitted this

segment at time 14.8142 second. From this point, iPad2 started normal retransmission

with changing MSS to 1188, and at time 14.8900, all lost segments detected at time

5.1877 second is retransmitted.

At time 49.4307 second, iPad2 sent one data segment, and then burst error is inserted,

with 52 data segment being lost. Figure 4.23 shows a detailed time line. At time 49.83294

second, iPad2 retransmitted segment 12159521: 12160709(1188). This could be a time

out retransmission. Then client PC replied duplicate ACK with SACK option, and i-

Pad2 sent succeeding data segment 12222485: 12223673(1188). Client PC confirmed this

segment by second duplicate ACK segment with SACK option. After that, iPad2 waits

about 0.5 second then starts retransmission of data segment 12160709: 12161897(1188),

which is requested by previous two duplicate ACK segments. Client PC confirms this

segment with ACK segment. iPad2 is supposed to retransmit succeeding lost data seg-

ment at time 50.3487 second, but turned out it transmitted succeeding data segment

29

5

time

(sec)

10

15

20

sequence

number

(Mbytes)

10

50 100

Figure 4.21: Sequence number vs. time for iPad2 with 100ms burst error.

before second duplicate ACK segment. Therefore, client PC had to send another du-

plicate ACK segment request next lost segment. 0.5 second later, iPad2 retransmitted

this segment. But after client PC confirmed it, iPad2 transmitted another succeeding

data segment. Similar behaviors continued until all lost segment retransmitted. This

sequence also degrades the throughput largely.

The transmission last 144.260 seconds, and iPad2 had an average throughput of 1.409

Mbps.

4.1.2.3 Test for iOS 4.3 under Background Load

The affect of background application over iPad2 is also examined. A game program

or an image editing program is executed, and then iPad2 switched to FTP program to

perform the experiment. The background application remained on the iPad2 and used

some amount of memory during the TCP communication.

Figure 4.24 shows a plot of sequence number in TCP data segments versus the time.

In this experiment, both background load and burst packet losses for 50ms in every

5 second are set. In this figure, there are some time gaps in the increase of sequence

number. There are five time gaps happened around time 4, 14, 40, 55 and 70 second.

They are all caused by the same reason; the slow reaction to the window update ACK

after zero window ACK.

30

iPad2 Client PC

4.3742 ACK 2413569

4.7799

5.6832

5.1813

4.7878ACK 2415017 (dup ACK #1)

SACK 2478729-2480177


ACK 2417913


4.7498 2413569:2415017(1448)

ACK 241501741 data segments lost

4.7877 2478729:2480177(1448)

5.1814 ACK 2416465

5.18845ACK 2416465 (dup ACK #1)

SACK 2478729-2481625

5.18842 2480177:2481625(1448)


2416465:2417913(1448)

5.6904 2481625:2483073(1448)

14.01785ACK 2445425 (dup ACK #1)

SACK 2478729-2510585


2445425:2446613(1188)14.8143 ACK 2446613


2446613:2447801(1188)Followed by similar retransmissions


2478689:2479877(1188)14.8901 ACK 2510585

14.0178 2509137:2510585(1448)

Blank burst error9.7799

1 Retransmission segment lost14.7799


Figure 4.22: Time line of segment exchange between time 4.374 2and 14.8901 secondin Fig 4.21.

31

iPad2 Client PC

49.8403


Followed by similar communications

49.4307 12159521:12160709(1188)


12159521:12160709(1188)

49.83299ACK 12160709 (dup ACK #1)SACK 12159521-12160709

12222485:12223673(1188)

49.8404ACK 12160709 (dup ACK #2)SACK 12222485-12223673


12160709:12161897(1188)

50.3357 ACK 12161897

50.3487 12223673:1224861(1188)

50.3488ACK 12161897 (dup ACK #1)SACK 12222485-12224861


121661897:12163085(1188)50.836 ACK 12163085

50.842 12224861:12226049(1188)

50.8426ACK 12163085 (dup ACK #1)SACK 12222485-12226049


12163085:12164273(1188)51.33789 ACK 12164273

51.34401 12226049:12227237(1188)


In the gap after time 14 second, a flat part is followed by a time gap. Figure 4.25 shows

a detailed time line in this part. Around time 14.37094 second, iPad2 transmitted one

data segment to client PC. Client PC returned an ACK segment with window size set

to 0. After that, at time 14.53861 second, client PC transmitted another ACK segment

(window update), and this time, the window size is set to 62264. Normally iPad2 should

respond this ACK segment less than 30ms, but when there is heavy work load running in

the back ground, iPad2 responds very slow. The same problem was discovered in iOS4.2

iPad. At time 19.47284 second, iPad2 starts to exchange with client PC again. It first

transmitted a data segment with only one byte data. This is a window probe invoked

by the persist timer at iPad2 TCP. This action itself is correct as the TCP procedure.

The problem is that iPad2 does not recognize the window update sent by client PC

32

5

sequence

number

(Mbytes)

time

(sec)

10

15

20

20 30 10 40 50 60 70 80 90

Figure 4.24: Sequence number vs. time for iPad2 with background load and 50msburst error.

at time 14.53861 second. Of course, it is possible that the window update is lost in

the wireless LAN between the access point and iPad2 depicted in Fig. 1. However,

this situation happens only when the background application exists. Therefore, It is

considered that the heavy load condition in iPad2 affects the TCP processing on zero

window and window update.

iPad2 receives the ACK for the window probe data segment, and sends another 1448

bytes long data segment at time 19.48066 second. After time19.87629 second, a burst

error were inserted, and 16 data segments were lost. After time 19.88282 second, when

iPad2 transmitted segment 3722563:3724011, client PC returned duplicate ACK segment

3699395 with SACK option. At time 20.27804 second, iPad2 retransmitted one data

segment after segment 3699395, but after client returned ACK segment, it started to

transmit succeeding data segment before it was interrupted for duplicate ACK segment.

Because of this, client PC has to send another duplicate ACK segment, while after

retransmitted request segment iPad2 went back to normal data exchange again. This

situation is similar with the sequence in Figure 4.23, which was observed in the test with

100 ms burst error. When no background load was on iPad2, this kind of situation was

not observed in 50 ms burst error test. It could be considered that the background load

affected the TCP processing status.

33

iPad2 Client PC

14.37094

14.40756

3679122:3680570(1448)

ACK 3680570 WIN=0

14.53861 ACK 3680570 WIN=62264

19.4728419.47289 ACK 3680571

Followed by normal transmissions


3680570:3680571(1)

19.48066 3680571:3682019(1448)

19.48068 ACK 3682019

19.87626 3697947:3699395(1448)

19.87629 ACK 3699395

19.88282 3722563:3724011(1448)ACK 3699395 (dup ACK #1)

SACK 3722563-372401119.88282


20.27804

20.27807 ACK 3700843

20.28487 3724011:3725459(1448)ACK 3700843 (dup ACK #1)

SACK 3722563-372401120.28488


20.67885

20.67891 ACK 3702291

20.68524 3725459:3726097(1448)Followed by normal transmissions


25.89590

25.89592 ACK 3721115

25.90337 3744283:3745731(1448)ACK 3721115 (dup ACK #1)

SACK 3722563-374573125.90339


26.29728

26.29731 ACK 3745731

Figure 4.25: Time line of segment exchange between time 14.37094 and 26.29731second in 4.25.

34

4.1.3 Test for iOS on XCode iOS simulator

Apple company also provides developing environment called XCode, which contains

iOS simulator for developer develop and debug applications on Macintosh platform[13].

According to Apple’s developer reference, applications can be tested equally on iOS sim-

ulator as on iPad hardware. Therefore, having experiment results taken with iPad and

iPad2 on iOS, experiments on XCode looks necessary. Then upload tests are performed

by FTP through local WiFi network, 200ms burst errors are introduced by dummynet

on bridge PC. Experiment configuration is shown in Figure 4.26.

Bridge PC

CaputuringCaputuring Client PCXcode iOS simulator

Figure 4.26: Test configuration for iOS simulator TCP.

Sequence Number

(B)

5000000

10000000

15000000

10000000

100 150 Second50

150 Second

Figure 4.27: Sequence number vs. time for iOS simulator with 200ms burst error.

35

Figure 4.27 shows the sequence line of iOS running on XCode iOS simulator. There are

a lot of flat parts in this Figure, and these behaviors have similar patten found in Figure

4.11 and Figure 4.21, which is caused by intermittent data transmissions.

Figure 4.28 shows the data segment exchanges between time 2.463478 and 12.068945

second. At time 2.463478 and 2.463510 second, 2 data iOS simulator sends two data

segments, after that a 200ms burst error is inserted, 36 data segments lost, at time

3.017189 second retransmits segment 780473:781921, this is a time out retransmission

because ACK segments are also lost during burst errors were inserted, client PC sends

nonmoral ACK segment for this segment. After that, iOS simulator changed to send suc-

ceeding data segment after sequence number 829705, which should be done only after all

lost segments are retransmitted. Client PC returns duplicate ACK with sequence num-

ber 781921, this ACK segment also carries an SACK option, which confirmed simulator’s

previous data segment 829705:831153. iOS simulator responds this duplicate ACK im-

mediately at time 3.721828, data segment 781921:783369 is sent, and confirmed by client

PC with normal ACK, at this point, iOS simulator is supposed to be retransmitting rest

lost segment after segment 781921:783369, but it starts to sending succeeding segment

before burst errors were inserted, therefore client PC has to send more duplicate ACKs,

this patten continues until time 12.068945 seconds.

Figure 4.29 shows at time 12.068945 second iOS simulator sends normal data segment

848529:849977, which should be retransmission of lost segments, therefore client PC

returns duplicate ACK with SACK option 848529-849977, then iOS simulator starts

to normal retransmission at time 12.568744 second, but first retransmission gets no

respond from client, at time 13.275639 second iOS simulator retransmits again, while

this time MSS is changed to 1188 bytes. At time 13.279085 second client PC returns

ACK for segment 801933, similar retransmissions continues till all lost data segments

are recovered at time 13.381009 second with ACK segment from client PC, after that,

iOS simulator goes back to normal data transmission at time 13.381198 second. This

”Flat” part starts at time 2.463478 second and ends at time 13.381198 second, which is a

very long duration, while there are shorter flat parts, for example from time 117.938961

second to time 120.374823 second.

Figure 4.30 shows, at time 107.550765 and time 107.550796 second two data segments

are transmitted by iOS simulator, after that burst errors are inserted 52 data segments

and ACK segments lost. Then at time 107.938961 second, iOS simulator retransmits

segment 8499509:8500697 because of time out, client PC returns ACK segment. As other

flat parts, iOS simulator starts to transmit succeeding before burst errors are inserted,

client PC returns duplicate ACK segment with SACK option 8555345-8556533, then

iOS simulator retransmits data segment 8500697:8501885, and then goes back to sending

36

iOS Simulator Client PC

2.463478 826809:828857(1448)2.463510 828257:829705(1448)



780473:781921(1448)3.021077 ACK 7819213.021248 829705:831153(1448)

3.031002 ACK 781921(dup ACK #1)SACK 829705-831153


781921:783369(1448)3.740088 ACK 783369

3.740181 831153:832601(1448)

3.744544 ACK 783369(dup ACK #1)SACK 829705-832601


783369:784817(1448)4.535000 ACK 7848174.535190 832601:834049(1448)

4.547770 ACK 784817(dup ACK #1)SACK 829705-834049



succeeding data segment. Similar data exchanges continue till time 109.559724 second.

Figure 4.31 shows data segment exchanges at that time. After receiving duplicate ACK

segment 8504261, iOS simulator starts retransmitting lost data segments caused by burst

errors.

In this test, iOS simulator TCP shows similar flat behaviors,which indicate this problem

is not hardware related, because it’s host is more powerful than iPad and iPad2 platform.

During transmission MMS has been changed to 1188, but helps little on preventing flat

parts happening.

37


12.068945 848529:849977(1448)



ACK 800745(dup ACK #1)SACK 848529-849977

12.072733

12.568744


13.275639

13.279085 ACK 801933Retransmission

828069:829257(1448)13.351438


13.351481

13.355173 ACK 823317

13.367931 ACK 82450513.370835 ACK 825693

13.381009 ACK 849977

13.381198 848529:849977(1448)


38


107.550765 8552969:8554157(1188)



ACK 8500697

ACK 8501885

107.550796 8554157:8555345(1188)52 data segments lost

107.938961

107.956242

107.956423 8555345:8556533(1188)

ACK 8500697(dup ACK #1)SACK 8555345-8556533

107.963144


108.443912

108.463386

ACK 8503073

108.463478 8556533:8557721(1188)

ACK 8501885(dup ACK #1)SACK 8555345-8557721

108.508621


108.948910

108.952291

108.952473 8557721:8558909(1188)

ACK 8503073(dup ACK #1)SACK 8555345-8558909

108.955763


39




ACK 8504261(dup ACK #1)SACK 8555345-8560097

109.559724

110.153851

ACK 8505449110.224378


8505449:8506637(1188)


8506637:8507825(1188)ACK 8506637110.246099


8552969:8554157(1188)


8554157:8555345(1188)ACK 8530397110.366757

ACK 8555345110.445919


40

4.1.4 Test for OS X on MacBook Pro

In Apple‘s developer reference also mentioned[13], iOS simulator share same OS kernel

with OS X, so OS X might has similar TCP behavior as on iPad like hardware. Therefore,

experiments for OS X on MacBook are taken. Upload tests are performed by File

share utility pre-installed on OS X through local WiFi network[quote], 200ms burst

errors are introduced by dummynet on bridge PC. Experiment configuration is shown

in Figure4.32.

Bridge PC

CaputuringCaputuring Client PCOS X on

MacBook Pro

Figure 4.32: Test configuration for OS X TCP.

Sequence Number

(B)

5000000

10000000

15000000

10000000

100 150 Second50

150 Second

Figure 4.33: Sequence number vs. time for OSX with 200ms burst error.

41

Figure 4.33 shows the sequence line of OS X TCP data exchange. This patten looks like

Figure 4.11, Figure 4.21 and Figure 4.27, which proves OS X operating system also has

intermittent data transmissions issue.

In Figure 4.34, first flat part is described in details. At time 1.886613 and 1.886647

second, OS X transmits two data segments, then burst errors are inserted , 53 data

segments lost, at time 2.540605 second a time out retransmission 1136681:1138129 was

transmitted, at time 2.558016 second client pc returns ACK segment, OS X is supposed

to be transmitting other lost segments, instead, it continues to transmit succeeding data

segment before burst errors are inserted. Although client PC sends duplicate ACK with

SACK option to request other lost segments, but after one retransmission it will has to be

requested again, and for each duplicate ACK segments, OS X spends longer than 800ms

to respond. Figure 4.35 shows intermittent transmission continued till time 11.416833

second client PC sends duplicate ACK 1155505 with SACK option SACK 1198945-

1217769, after 477ms OS X retransmits requested lost data segment 1155505, but this

retransmission was time out, therefore at time 12.695357 second OS X changes MMS to

1188 bytes and retransmits segment 1155505, client PC confirmed this retransmission at

time 12.698403 second, after this ACK, OS X finally goes back to normal retransmission,

it sends data segments without long wait, at time 12.800675 second client PC confirmed

all lost data segments. Similar flat parts are everywhere during test for OS X TCP,

which indicate OS X is also has flat part issue, it will not able to handle retransmission

process in correct order, and there are waiting time longer than usual, this mal-function

degrades OS X TCP throughput a lot when it encounters burst error more than 200ms.

42

OS X Client PC

1.886613 1196049:1197497(1448)



ACK 1138129

ACK 1139577


2.540605

2.558016

2.558197 1198945:1200393(1448)

ACK 1138129(dup ACK #1)SACK 1198945-1200393

2.561577


3.246535

3.250055

ACK 1141025

3.250255 1200393:1201841(1448)

ACK 1139577(dup ACK #1)SACK 1198945-1201841

3.253527


4.051549

4.056209

4.056398 1201841:1203289(1448)

ACK 1141025(dup ACK #1)SACK 1198945-1203289

4.062501


43

OS X Client PC

11.392605

1216321:1217769(1448)


11.40361511.403798

11.893077

12.695357

12.698403

12.702251


ACK 1155505

ACK 1155505(dup ACK #1)SACK 1198945-121776911.416833



ACK 1156693

12.698539

12.698586



ACK 1157881



1198273:1199461(1188)

12.789401 ACK 1191145

12.800675 ACK 1199461


44

4.2 Test for Windows 7 Under 100ms Burst Error

In this section, similar test for Windows 7 PC is performed. For the comparison with

iPad2 TCP behaviors, experiments for Windows 7 TCP are taken. Upload tests are

performed by FTP through local WiFi network, 100ms burst errors are introduced by

dummynet on bridge PC. Experiment configuration is shown in Figure 4.36. Figure 4.37

shows that burst error has little effect on the TCP throughput of Windows 7 PC.

Bridge PC

CaputuringCaputuring Client PCWindows 7 Notebook

Figure 4.36: Test configuration for Windows 7 TCP.

5

time

(sec)

10

15

20

sequence

number

(Mbytes)

10 20 30 40 50 60

70

Figure 4.37: Sequence number vs. time for Windows 7 PC with 100ms burst error.

Figure 4.38 shows the sequence line from time 8.1185 second to 8.44782 second. At

time 8.1246 second burst error is inserted, 3 data segments and 1 ACK segment lost.

Windows 7 note PC stops transmission and waits 300ms, then starts retransmission

45

Windows 7 notebook Client PC


8.4394 ACK 3280897

1 ACK segment lost (ACK 3280897)


3275601:3277049(1448)

Notebook waited 300ms


3280897:3282345(1448)

8.4435 ACK 3282345


3282345:3283793(1448)

8.44569 ACK 3283793


3283793:3284993(1448)

8.44782 ACK 3284993

8.1229 3278249:3279697(1448)

8.1211 3276801:3278249(1448)

8.1185 3275601:3276801(1200)

Figure 4.38: Windows7 handles 100ms burst error.

procedure, at first it retransmits data segment with sequence number 3275601, which is

actually receipted by client but not acknowledged specifically since last receipted ACK

segment. So client returns ACK segment 3280897, then sever starts retransmission with

right segment. At time 8.47782 second, client acknowledged all 3 lost segments. From

this test, it is clear that when burst error happens, the less server transmits the faster

it will be recovered, proper burst error detection mancinism like Window 7 behaves is

required in wireless TCP communications, because in this environment primary packet

lost is caused by random burst error.

46

Chapter 5

Results and Discussion

From the experiment and analysis proceed so far, it is considered there following prob-

lems.

• The processing of data segment has considerable delay. For example, the sending

out of ACK segments seems to take a long processing time compared with personal

computer.

• The granularity of context switch of protocol processing is coarse. It seems that

the contiguous data transmissions or ACK receptions are handled in one context.

Unexpected protocol processing might not be able to interrupt a series of similar

or predetermined processing.

• Some protocol events cannot be handled in the correct order. For example, the

third duplicate ACK reception needs to invoke the fast retransmission even if there

are a series of sending data. However, it looks like that the duplicate ACK event

cannot take over the ongoing flow of protocol processing.

• It seems that there are still a lot of deficiencies remaining in the protocol processing.

They might be complicated problems, for example, invoked in the combination of

the protocol logic, the status of the hardware and the operating system.

• Some protocol events cannot be handled in correct order. For example, the third

duplicate ACK reception is supposed to invoke the fast retransmission even if there

are a series of sending data. However, it looks like that the duplicate ACK event

cannot take over the ongoing flow of protocol processing.

• It seems that there are still a lot of deficiencies remaining in the protocol processing.

They might be complicated problems, for example, invoked in the combination of

the protocol logic, the status of the hardware and the operation system.

47

• TCP implementation in iOS system has low endurance of long duration burst

error, for example, iOS TCP can handle 10ms and 50 ms second burst error almost

without degrade throughput, but under 100ms burst error, serious problem will

occur.

• When there is a load in iPad2, it is possible that some event such as the reception

of ACK segment is missing.

• OS X has similar problems as iOS when encounters burst error, it will not able to

handle protocol events in correct order.

Platform Operating System Test parameter Results

iPad iOS 4.2 No burst error upload Gaps

iPad iOS 4.2 Normal download Gaps

iPad iOS 4.3 No burst error download Going well

iPad iOS 4.3 500ms delay Transmission cut into pieces

iPad iOS 4.3 50ms burst error upload Intermittent transmission

iPad2 iOS 4.3 50ms burst error upload Slightly improved

iPad2 iOS 4.3 100ms burst error upload Intermittent transmission

iPad2 iOS 4.3 50ms burst error upload

with background load

Gaps Intermittent transmission

MacBook Pro iOS Simulator 200ms burst error upload Intermittent transmission

MacBook Pro OS X 10.6.7 200ms burst error upload Intermittent transmission

Notebook PC Windows 7 SP1 100ms burst error upload Influent transmission

Figure 5.1: Summary for all experiments parameters and results.

48

Chapter 6

Conclusion

6.1 Summary

In this thesis, tablet PC TCP communication behaviors have been analyzed in detail.

TCP communications of iPad on iOS4.2 and iOS4.3, and iPad2 on iOS4.3 under various

burst error durations have been monitored and examined. There seems to be some de-

ficiencies in iPad and iPad2 TCP implementation. Throughput of iOS4.2 iPad is lower

than iOS4.3 iPad, which indicates operating system updates do have significant upgrade

of performance. After test of iPad with two iOS versions, experiments on iPad2 with

iOS4.3 have been carried out to verify hardware affection on TCP behaviors, while sim-

ilar result on iPad are taken, which means hardware change doesn’t improve poor TCP

performance of iOS. As a comparison with iOS TCP, Windows 7 TCP communications

are also been tested and analyzed, according to the results, Windows 7 TCP handles

burst error very well. To eliminate possibility of hardware affection, experiments under

same environment have been carried out on XCode iOS simulator and OSX, both op-

erating systems are install on MacBook Pro laptop computer, similar intermittent TCP

behaviors are found. According to Apple’s developer reference, iOS and OSX share same

OS core, two similar experiment results do verified that OSX TCP is not able to handle

burst errors correctly. Unfortunately, because of close-source issue of iOS and OSX,

reason for those behaviors remains unknown.

6.2 Future plan

In this thesis, Macintosh TCP is tested, because Macintosh is modified from FreeBSD.

So it is possible to solve current Macintosh TCP problems and improve performance by

analysing FreeBSD’s TCP source code.

49

Also, Android based mobile devices are widely used just like iPad serials did. Perfor-

mance analyse on such devices is needed. Because Android OS is open source project,

it is easier to test and analysis source code of TCP module, experiments mentioned

in this thesis is required to be carried on Android OS based mobile devices. By now

Linux provides APIs for user switch TCP versions for particular connection according

to different network environment, to develop proper TCP version switching algorithm

become a new challenge.

There are a lot of prior researches on wireless TCP. All these researches consider termi-

nals have high processing ability, but in recent years, with the development of mobile

smart-like devices, which take great share of Internet traffics. Therefore, a low pro-

cessing ability oriented TCP is need to be proposed to improve performance on mobile

devices. To achieve that, further surveys on existed TCP congestion control algorith-

m and performance evaluation on network simulator are needed, also a wireless TCP

congestion control algorithm efficiency and fairness improvement are expected.

50

Acknowledgements

This research has been done with the help from a lot of people, I want take this chance

to express my appreciations to them.

Many thanks to my supervisor Professor KATO in Department of Information Network

Systems, Graduate School of Information Systems, University of Electro-Communications,

thank you for your supervision and advices in this research.

Also many thanks to my instructor associate Professor KASAI in Department of In-

formation Network Systems, Graduate School of Information Systems, University of

Electro-Communications, thank you for your advices.

Also many thanks to my instructor associate Professor OHZAHATA in Department of

Information Network Systems, Graduate School of Information Systems, University of

Electro-Communications, thank you for your advices and lessons.

Many thanks to Assistant Professor Celimuge in Department of Information Network

Systems, Graduate School of Information Systems, University of Electro-Communications,

your passion and patients always inspire me.

At last, many thanks to my families, who give me chance to study in UEC in Japan,

without your support I won’t achieve this.

51

Bibliography

[1] A. Orebaugh, G. Ramirez, and J. Burke. ”Wireshark & Ethereal network protocol

analyzer toolkit”. Syngress Media Inc, 2007.

[2] Weikai WANG, Celimuge WU, Satoshi OHZAHATA, Toshihiko KATO. ”Perfor-

mance analysis of iPad TCP communiations”. IEICE Technical Report, pages 85–90,

2011.

[3] Weikai WANG, Celimuge WU, Satoshi OHZAHATA, Toshihiko KATO. ”Detailed

analysis of iPad2 TCP behaviors”. IEICE Technical Report, pages 95–100, 2012.

[4] J. Postel. ”RFC791 Internet Protocol”. RFC, 1981.

[5] J. Postel. ”RFC793 Transmission Control Protocol”. RFC, 1981.

[6] A. Afanasyev, N. Tilley, P. Reiher, and L. Kleinrock. Host-to-Host Congestion

Control For Tcp. Communications Surveys & Tutorials, IEEE, 12(3):304–342, 2010.

[7] M. Allman and V. Paxson. ”RFC 5681 TCP Congestion Control”. RFC, 2011.

[8] V. Paxson and M. Allman. ”RFC 2988 Computing TCPfs retransmission timer”.

[9] W.R. Stevens. ”TCP/IP Illustrated: The Protocols”, volume 1. Addison-Wesley

Professional, 1994.

[10] W.R. Stevens. ”RFC2001 TCP slow start, congestion avoidance, fast retransmit,

and fast recovery algorithms”. RFC, 1997.

[11] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. ”RFC2018 TCP selective

acknowledgment options”. RFC, 1996.

[12] L. Rizzo. ”Dummynet: a simple approach to the evaluation of network protocols”.

ACM SIGCOMM Computer Communication Review, 27(1):31–41, 1997.

[13] Apple Inc. iOS App Programming Guide. iOS Developer Library, 2012.

Performance Analysis on TCP Communication … · ow control and congestion control mechanisms....

Documents

Transcript of Performance Analysis on TCP Communication … · ow control and congestion control mechanisms....