Application Note

E6474A Drive Test Tool FTP IPv4/IPv6 Testing Explained

By: Fabien Pinardon

Introduction
A key feature of the E6474A Drive Test tool is its data test capabilities, including FTP testing of the TCP-IP layer.
This document shows some typical testing scenarios that highlight the capabilities of using the FTP IPv4/IPv6
test.
Network troubleshooting - a simple FTP transaction can help identify network failures, traffic problems and
highlight performance issues.
Network benchmarking - comparing network performance using different FTP tests running in parallel.
Network capacity evaluation - the buffer size feature combined with real-time measurements can help identify
network capacity issues or physical limits.
In this document the following aspects of FTP testing, using the E6474A solution, are outlined and explained:
Features of the FTP test
Parallel FTP
Multiple file downloads and uploads
Passive versus Active mode
IPv4 and IPv6
Buffer size
Abstract
Progress bar
The FTP IPv4/IPv6 Test is
Saving files to disc
designed to meet your Drive Test
Measurements
needs and accommodate the fast
Connection performance KPIs
evolution of wireless networks.
Running and average/final throughput
Find out how to best configure
E6474A FTP versus DOS FTP
your FTP test environment to get
Device binding
the most accurate information
IPv6 addressing format
from your data network.
Frequently Asked Questions

WEBSITE: www.jdsu.com/test

Application Note: IPv4/IPv6 Testing Explained

Features
Parallel FTP

A unique feature of the JDSU FTP test is its ability to run multiple
instances on more than one device in parallel. The FTP test has
been designed to run network benchmarking using multiple
devices each connected to a different network. To enable this
feature all the network communication and FTP protocol code
has been implemented without using any third-party or high level
APIs. Both the data and control sockets are bound to the chosen
device. This ensures all traffic goes to the targeted interface such as
modems, wireless cards and network cards.

on a random port and this time it is the server that will connect to
the client. If the client is behind a firewall, the connection request
from the server might be blocked.
If the FTP test fails to connect while in active mode then it is
recommended you try using passive mode before investigating
other possible reasons for the test failure.
Passive mode is mostly used within a LAN network because most
firewalls block incoming connections from unknown ports.

IPv4 and IPv6

The FTP test supports IPv4 and IPv6 protocols. This means you
can test IPv6 to IPv6 network and IPv4 to IPv4 network nodes by
selecting the appropriate protocol in the FTP IP Network Type
as shown below:

Multiple file download and upload

The FTP test supports multiple download and upload of files. All
files must be downloaded from, or uploaded to, the same folder
defined in the properties of the test. This differs from repeating a
single file FTP test for two reasons:
The connection to the remote FTP server is kept open
and only the data link is reopened. This has the benefit of
simulating what the real user would do when downloading
or uploading multiple files.
Different files can be chosen for the same connection.
When selecting multiple files you can also define a pause between
each file which is uploaded or downloaded.

Passive versus Active mode

The FTP test supports both passive and active modes.

An FTP client opens two sockets, one for remote communication
with the server on PORT 21 and one for data transfer. Once a
connection with the server is established the client will have the
choice between opening a data link either in passive or active
mode.
Using passive mode the client opens the data link by connecting
to the FTP server on a random port, thus allowing the client to
bypass the firewall if any is present.
In active mode the opposite occurs. The FTP client is listening

If you need to connect two IPv6 nodes over an IPv4 network,

you must select the correct Automatic Tunnelling Pseudo (ATP)
interface for each device network interface. If the network is fully
IPv6, then it is possible to select the respective network cards
instead of the ATP interface and run FTP tests in parallel. More
information on IPv6 networks is provided later in this application
note.

Application Note: IPv4/IPv6 Testing Explained

Node A

Network Type

Node B

Supported

IPv4

IPv6

Yes

IPv4

IPv4

IPv6

No

IPv4

IPv4

IPv4

Yes

IPv6

IPv6

Yes

IPv6

Automatic Tunnelling Pseudo Interface

IPv6

Use Network IPv6 Interface card

IPv6

IPv4 or IPv6

IPv4

No

buffer size = 2 x delay x bandwidth

Since twice the delay is the same as the round-trip time, you can
use the RTT: This value can be found using the PING command.
buffer size = RTT x bandwidth
This diagram shows that increasing the buffer size will increase
fragmentation at the TCP-IP layer, which results in more packets
being sent and acknowledged.
E6474A FTP Client

TCP-IP Stack

Socket
TCP Buffer

File to be transferred
data

send

Block 1

Buffer size

Block 2

FTP uses Transmission Control Protocol (TCP) which is the most

common network protocol used on the Internet. Understanding
how TCP operates can help you understand how to set the buffer
size.
When GPRS networks were first established the FTP test had a
default socket buffer size of 4 KBytes which reflected the relatively
low data rates of the early GPRS networks. This size is too small for
faster networks such as HSPA or WiMAX.
The table below shows the recommended buffer size for FTP
PUT, depending on the type of network used:
Network Type

Recommended Buffer Size

GPRS

4 KBytes

UMTS & CDMA

64 KBytes

Server

Packet 2

send
ack
send
ack

Packet N

send
ack

Packet 1

fragmentation

The diagram below shows the different supported combinations

of IP interface:

ACK

The TCP buffer size can be set in the FTP test properties.

HSPA & WiMAX (Fast Data) 64 to 512 KBytes

TCP overview
TCP uses a congestion window to decide how many
packets to send to the server at one time before looking for an
acknowledgement. The bigger the congestion window, the higher
the throughput. The congestion window is directly related to the
buffer size.
To get the maximum throughput you need to have the optimal
TCP socket buffer size. If the buffer size is too small the TCP
congestion window will also be too small and will not let enough
packets through so the sender will be throttled.
If the buffer size is too large the sender client can overrun the
server with data. This will cause dropped packets and the TCP
congestion window to close.
TCP buffer size
It is commonly agreed that the best buffer size is usually double
the value for the packet delay multiplied by the bandwidth of the
network:

The default FTP buffer size is 64 KBytes. It is also the default buffer
size of most FTP clients.
As explained previously the buffer size will affect the performance
of TCP. For instance, in case of FTP upload, a buffer too large will
increase network congestion and the throughput will drop. On the
other hand a buffer size too small will have the opposite effect and
the throughput will be consistent but low.
The following figure shows a FTP upload running throughput
line chart. The square shape shows periods of no activity due
to the socket being nonresponsive for too long. This is usually

Application Note: IPv4/IPv6 Testing Explained

an indication that the buffer is too large and that the network is
overloaded:

Similarly if the test fails at the stage User authentication (value =

7), then check you have the right username and password entered
in the properties for the test.

Upload Throughput

Buffer size too large

Time

Ultimately the buffer size should be set appropriately for network

conditions to optimize throughput and minimize packet
fragmentation and network congestion.

Progress bar

The JDSU FTP test has the ability to monitor the file transfer
progress using the FTP Test Completed data item from the FTP
Results frame. By selecting this data item and adding it to a Grid
View and then configuring the properties of that data items to
display the range of expected values you can generate a progress
bar for the FTP test. Here are the values for this data item reported
during an FTP transaction.
0 = FTP connecting to server
5 = FTP connected
7 = User authenticated
10 = Data connection established
10 to 100 = File transfer progress
If there is a test failure, this data item can help to troubleshoot the
test by showing where to start looking for a problem.
For example if the test fails at the stage FTP connecting to server
(value = 0), check that you have the right server name and IP
address.

Saving files to disc

When performing an FTP download you can save files to disc by

specifying an output folder. Each test iteration will automatically
generate a sub-folder named as follows:
[output folder]\[test label]_[device name]_
[date and time]
For example: MyFiles\MyFTPTest_
datadevice_25_8_2008_16_23_2_478
When more than one FTP test is running in parallel ensure that
each test has an unique test name. This prevents the same output
folder being used by different tests.
The downloaded file is saved inside the above sub-folder with an
automatically generated name with the following format:
[iteration number]_[file position in file
list]_[source file name].[source file name
extension]

Application Note: IPv4/IPv6 Testing Explained

For example: 1_4_My10MEGFile.txt

Average throughput - The average or cumulative throughput is

defined as:
Tp (Kilobits/sec) = Size of transfer (Kilobits) / Time for transfer
(seconds)
Running throughput - The running throughput calculates the
amount of data transferred in a one second period. It shows how
much new data has been sent or received for each second elapsed.

E6474A FTP versus DOS FTP

Measurements
Time calculation

Many different times are measured during FTP transactions. Each

time is measured in milliseconds.
This diagram represents a multi-file transfer using one FTP test:
First File

DNS Resolution
DNS Time

Connect
Connect Time

Authentication Pause
Authentication Time

Response

Transfer

Response Time

GET Time

Total Time
Pause

Second File

Response

Transfer

Response Time

GET Time

Total Time

Optional pauses can be added to the FTP test after the connection
has been authenticated. For multi-file FTP tests a different pause
can be added for each subsequent file transfer.

Throughput calculation

Throughputs are calculated at the application level. Some network

monitoring tools (for example; NetPerSec) return slightly higher
throughput values. This is because they calculate throughputs
at the IP network layer, which includes the TCP header and
retransmissions.
Throughputs are measured in Kilobits/sec (Kilo = 1024).
Throughputs are calculated in real-time every second. Two types
of throughput are provided:

The DOS FTP is faster than any Windows FTP tool due to its
extra access privileges. However, the JDSU FTP can be as fast as
the DOS FTP.
The main advantages of using the JDSU FTP test over DOS FTP
are:
Produces real-time measurements and timers
Provides error reports
Supports multiple devices
The DOS FTP only provides final measurements and does
not allow device selection. The JDSU FTP test provides more
details about progress and errors. The JDSU FTP test also uses
synchronous socket mode which is also used by DOS FTP.
A benchmark test was used to compare the DOS FTP and E6474A
FTP tests. First five FTP GET tests were run for both the DOS and
E6474A FTP tests in parallel. The tests used the same device and
remote file from the same FTP server. Then five FTP PUT tests
were performed using the same conditions but this time using
source files of the same size but with different file names to prevent
file writing violations on the server.

Application Note: IPv4/IPv6 Testing Explained

The following table and charts outlines the results of the

benchmark tests.
DOS FTP

E6474A FTP

Time

Total
Throughput

Time

Total
Throughput

Get

51.94

967.76

50.189

978.06

Put

25.92

1939.04

26.40

1858.90

Get

52.00

966.64

45.95

1068.18

Put

24.64

2039.84

25.76

1905.07

Get

99.42

505.60

99.11

495.28

Put

26.39

1904.64

25.11

1954.84

Get

99.21

506.72

98.86

496.53

Put

25.45

1974.80

26.17

1875.52

Get

88.42

568.48

88.72

553.28

Put

24.75

2030.96

24.47

2006.05

2500
2000
1500
E6474A Tp Uplink

1000

DOS Tp Uplink

500
0

1200
1000
800
600
400
E6474A Tp Downlink

200
0

DOS Tp Downlink

Device binding
The JDSU FTP test supports device binding which allows
multiple FTP tests to bind to different devices and run in parallel.
Device binding is a two step process. The socket is first bound to
the assigned IP address of the device parent, with both IPv6 and
IPv4 being supported.
A second binding occurs at the routing table level. Unfortunately
in the Windows Operating System, the routing table supersedes
the socket binding. The routing table decides which device to use
for sending packets. To ensure data goes to the correct device a
route is added to the operating system routing table.
Note: Since IPv6 does not share the same routing table as IPv4 this
makes the bindings more complicated. However, E6474A FTP
deals with those complications to make sure the communication
is bound to the correct device.

IPv6 addressing format

As explained previously there are restrictions when using IPv6.
Most of the Internet is IPv4 based and to support IPv6 networks
designers have had to compromise on the network protocol
standards.
To reach an IPv6 host on a IPv4 network the Automatic
Tunnelling Pseudo-Interface (ATP) must be used. Effectively
IPv6 in Windows XP and Windows Server 2003 use the
Automatic Tunnelling Pseudo-Interface for encapsulating IPv6
packets with an IPv4 header so that they can be sent across an
IPv4 network. By default, IPv6 configures a link-local Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP) address on the
Automatic Tunnelling Pseudo-Interface. The link-local ISATAP
address has the form fe80::200:5efe:w.x.y.x or fe80::5efe:w.x.y.x,
where w.x.y.x is an IPv4 address assigned to the computer.
In the case of a multi-host machine capable of running parallel
FTP tests, it is necessary to check that each interface has a
respective ATP interface assigned. If this is not the case then
parallel testing will not be possible. Please check your network
configuration for more details.
If the network is fully IPv6 and all routers within the sub network
are IPv6 enabled then it should be possible to use the network card
interface instead of the ATP interface. This is adequate for parallel
FTP testing on different devices.
At present the E6474A application does not support IPv6 to IPv4
FTP. This requires Dual-Stack sockets which are only supported
by the Windows Vista operating system. Another alternative
would be the use of the IPv4-mapped IPv6 address format.
Any IPv4 address must be represented in the IPv4-mapped
IPv6 address format which enables an IPv6 only application to
communicate with an IPv4 node. The IPv4-mapped IPv6 address

Application Note: IPv4/IPv6 Testing Explained

format allows the IPv4 address of an IPv4 node to be represented

as an IPv6 address. The IPv4 address is encoded into the loworder 32 bits of the IPv6 address, and the high-order 96 bits hold
the fixed prefix 0:0:0:0:0:FFFF. The IPv4-mapped IPv6 address
format is specified in RFC 4291.
Here is the content of the RFC:
IPv6 Addressing Architecture
80 bits

16

0000 .......................................................... 0000 FFFF

32 bits
IPv4 address

Frequently Asked Questions

Does increasing the buffer size impact FTP
download?

Changing the buffer size for download has less impact than for
upload. Most PCs can receive and store data faster than the FTP
server can send data. Thus a small buffer size can be as effective
as a large one. However, a very large buffer size can be a waste
of memory and take up resources that can be used by other
processes running on your PC. JDSU recommends a buffer size of
2000KBytes for downloads.

Does increasing the buffer size impact FTP upload?

Yes. Large buffer size will increase the risk of network congestion.
This means that the FTP test sends more data than the network
can cope with, resulting in packets being dropped and resent. Also
the FTP server bandwidth is shared amongst multiple users and
can be limited. The server might not be able to receive as fast as the
FTP client can send. It is possible to check packets dropped and
other network information using the DOS command
netstat s1.
Additionally using a line chart and monitoring the throughput
you will see the square stepped shape line indicating periods of low
throughput as the network layer is overloaded and consequently
not updating the layer above (FTP application layer) fast enough.
If you believe your network can cope with a larger buffer sizes
but you still see throughput problems then check your network
reliability using the DOS command netstat s. Refer to the
section on Buffer size (page 3) for more information.

What is the recommended buffer size?

It depends on the network used. The E6474A application

uses a default value of 64 Kbytes. As mentioned earlier the
recommended buffer sizes change depending on the network
type being used. For example, fast 3G and 4G networks benefit
1 Netstat is a DOS command-line tool that displays network connections
(both incoming and outgoing), routing tables, and network interface
statistics.

from increasing the buffer size for FTP download to a maximum

(2000KB) for an optimum performance.

Does increasing the operating system MTU improve

the FTP upload rate?

MTU (Maximum Transmission Unit), also referred to as packet

size, is the greatest amount of data that can be transferred in one
physical frame on the network. For Ethernet the MTU is around
1500 bytes, dial-up connections often use 576 bytes. A packet
consists of header and data information, the data is also referred to
as MSS (Maximum Segment Size).
MTU = MSS + TCP/IP header
In theory increasing the MTU will increase the transfer rate
because larger packets are being sent, in reality this will work only
if the network can support large packets. Increasing the MTU will
also reduce the number of headers and routing decisions, as well
as client socket requests and device interrupts. There are some
obvious benefits in manipulating the MTU for large buffer size on
fast networks such as WiMAX but JDSU does not recommend
doing this. The E6474A FTP test does not support MTU
manipulation. Changes to the MTU can have a critical impact on
your system.

What is the best file size to use for an FTP test?

There is no correct answer to this but it makes sense to consider

the expected data transfer rates on the network when choosing
file sizes. If you are testing UMTS or HSPA technologies with very
high transfer rates, it does not (in general) make sense to choose
a 200 Kilobytes test file. By the time the transfer has started, it
is almost finished and the networking mechanics have hardly
had a chance to get going. Conversely if you are testing GPRS
with a throughput of 48 Kilobits per second you will be waiting
for a long time to complete a download of a 1 megabyte file. It is
recommended to chose a file size that best exercises your network.

Why does IE FTP and DOS FTP work while the JDSU
FTP does not?

Internet Explorer (IE), DOS and other windows-based FTP

applications bind differently from the method used by the JDSU
FTP test.
The JDSU FTP binds to an IP address specified in the device
properties so that the IP traffic is directed to the right network
adapter (dialup or network cards). Refer to the device binding
section previously in this document.
The JDSU FTP test binds using the selected interface IP address
while the windows-based FTP tests use the default gateway which
is not always the same as the interface IP address.
The JDSU FTP test might be blocked because the network may
not allow the specified interface IP address. This will result in a

Application Note: IPv4/IPv6 Testing Explained

Winsock connection error.

Check with your network administrator to confirm if there
are any blocked IP address groups which include your selected
interface IP address.
What do these system error messages mean?

FTP error 425Cant open data connection

The data connection (for a directory listing, upload, or download)

was unable to be established. Check your FTP server settings to
make sure no ports are blocked. Also if your FTP server is behind
a firewall then check the firewall permission settings. Switching
to active mode might solve the problem assuming your client
machine is not behind a firewall as well.

solution is to ensure that the file name is different on each machine

preventing file sharing violation on the server.

FTP IPv4 Error - Net Socket Error

This IPv4 error occurs when the remote FTP server is not
responding to connection attempts. This could be due to network
congestion or the FTP server not completely disconnecting from
the previous session.

Winsock error 10053The connection to the FTP

server fails

The software caused a connection abort. This is usually caused by

a connection time-out. To quickly check that your FTP server is
running and is reachable, run a traceroute test.
The connection could have been terminated by the server. The
FTP server logs can provide some clues about the exact reason
for the failure. Check and verify that your ISP allows multiple
FTP sessions. Also, if a previous session failed for some reason
but has not been killed off by the server, then the server may force
a disconnection of subsequent sessions until the broken session
times out.
Finally, the error could be that you have a firewall configuration
problem which is causing the link to fail intermittently, in which
case try using passive mode.

FTP IPv4 Error - System Format Error

This IPv4 error occurs when the application can not parse the
reply returned from the remote FTP server. For example, the
servers reply might include additional spaces between command
codes or the FTP server welcome/warning message is too large to
fit into single a internet packet and get phrased.

FTP Error 10057Socket is not connected

A request to send or receive data was disallowed because the

socket is not connected and no address has been supplied.

FTP Error 10060Connection timed out

A connection attempt failed because the connected party did

not properly respond after a period of time, or the established
connection failed because the connected host server failed to
respond.

The connection to the FTP server was successful but

the FTP upload fails intermittently with FTP errors or
Winsock errors. What is the problem?
During drive testing it is common that the same file may be
uploaded at the same time by different users. As a result some
requests would be rejected by the server because FTP servers
only allow one upload of the same file at a time. This is similar to
shared file systems. More than one user can simultaneously read
from the same file (equivalent to FTP download) but only one
user can write to a file at a time (equivalent to FTP upload). One

References And Additional Information

RFC 2581: TCP Congestion Control
http://www.rfc-editor.org/rfc/rfc2581.txt

RFC793 - Transmission Control Protocol

http://www.faqs.org/rfcs/rfc793.html

RFC959 - File Transfer Protocol

http://www.faqs.org/rfcs/rfc959.html

Tuning TCP/IP for Performance

http://support.microsoft.com/kb/93444/en-us

MTU, what difference does it make?

http://www.speedguide.net/read_articles.php?id=111

IPv6

NORTH AMERICA

LATIN AMERICA

ASIA PACIFIC

TEL: 1 866 228 3762

FAX: +1 301 353 9216

TEL: +1 954 688 5660

FAX: +1 954 345 4668

TEL: +852 2892 0990

FAX: +852 2892 0770

http://technet.microsoft.com/en-us/network/bb530961.aspx
EMEA

TEL: +49 7121 86 2222

FAX: +49 7121 86 1222

Product specifications and descriptions in this document subject to change without notice. 2010 JDS Uniphase Corporation

30168098 501 0111

WEBSITE: www.jdsu.com/test

DTFTPTEST.AN.NSD.TM.AE

Jan 2011