Iycee Charles de Gaulle Summary CS of Alexa’s top 100 websites which

CS of Alexa’s top 100 websites which

                             CS 653                         

     Performance
Analysis of IPv4 and IPv6

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

 

                            Abhilash Muralidhara                     Raghavan Venkataraman                          

 

ABSTRACT

 

  The project aims at comparing the performance
of IPv4 and IPv6. To accomplish this, 25 RIPE Atlas nodes from random locations
are chosen. Ping measurements and traceroute commands to 25 of Alexa’s top 100
websites which support IPv6 are executed. These measurements are evaluated to determine
di?erences in the performance between IPv4 and IPv6.

 

Keywords

IPv4, IPv6, RTT, comparison,
performance,

 real world, RIPE Atlas

 

1.   INTRODUCTION

 

         The exhaustion
of IPv4 has gained significant attention since the APNIC (Asia Paci?c Network
Information Centre) announcement in February 2011 regarding the allocation of
the last two /8 address blocks from Internet Assigned Numbers Authority. The
Internet Protocol version 6 (IPv6) with an extended address space is proposed
to meet the addressing shortage experienced in IPv4. The new version is an
improvement over the previous version, while keeping many of the
characteristics of the earlier protocol. IPv6 is designed to have many
additional features such as optional IP headers, class and flow labels, large
datagrams and fragmentation-less data transfer. Thus, the aim is to replace the
older version of the IPv4 protocol, to meet the increasing demand for IP
addresses and to use the new features offered by the new version. However, due
to the vast success and wide spread use of the World Wide Web, the monetary
cost and time involved, the transition to IPv6 is occurring gradually as
opposed to a sudden conversion. The two protocol stacks are expected to coexist
for an extended period and to be supported by almost every host. Over the past
few years, there has been a global scale deployment of IPv6 in many countries.
This support for both the protocols means a host can be reached by both the
stacks, IPv4 and IPv6. Both protocols may or may not follow the same network
path based on the underlying network infrastructure. Even though IPv6 nodes
have increased in recent years, there has not been a corresponding increase in
applications using or switching to the IPv6 protocol. With relatively light
traffic load on IPv6 and abundant IPv6 backbone bandwidth, there is a high
probability of greater IPv6 Bandwidth availability than IPv4. Additionally,
there are still large IPv6-over-IPv4 tunnels widely in use where native IPv6
connectivity is not available. IPv6 events have been organized since then to
further promote the usage of IPv6. It was suggested during the early scientific
research that IPv6 may have a higher Round-Trip-Time between two nodes as well
as higher packet-loss while in transit, whereas recent research advocate that
the performance is similar to IPv4 performance.                                                                                            

 

The paper makes use of
RIPE Atlas platform. RIPE Atlas has a network of probes with internet
connectivity and reachability which provides a understanding of the internet in
real time. There are thousands of active probes available at different
geographical location which can be used to perform different measurements such
as ping, Traceroutes.  It collects data
from this probe and provides visualization based on the results. The probes can
be hosted not only in data centers, but also in the homes of the volunteers. The
GPS coordinates of the node are submitted by every Atlas Probe owner to RIPE by
accurately selecting his/her node position on a digital map. The accuracy of
these locations is therefore likely to be precise because owners will enter
their building address instead of using a geolocation database to get the GPS
coordinates.

 

2. BACKGROUND AND
RELATED WORK

 

  2.1 Performance

  

  
       We define a network’s performance depending on its
carrying potential, the end-to-end delay, bandwidth as well as its jitter. The
software’s overall performance is affected by all these parameters. Bandwidth
and end-to-end delay influence a large-scale transfer of data while a video or
voice stream with crude encoding would be less perceptive to end-to-end delay
than jitter.

         Considering a scenario of two sessions between
the same hosts, with the identical end-to-end protocol as well as employment of
the exact application at each end, then execution of the transaction at the
same time by changing only the underlying protocol would cause the differences
in their performance by what extent?

         There
exist two critical facets of performance that could potentially differ between the
protocols as well as the endpoint nodes that would impact the result. The
dependability of the protocol under varied circumstances is the first facet
while the path variation caused due to the change in the protocol is the second
facet.

 

         2.2
Related Work

 

Hop count and End
to End delay: IPv6 versus IPv4 (2005)

 

This study used an earlier
version of RIPE Atlas called as the Test Traffic Measurement (TTM) service.
Endpoints as well as measurement nodes were contained within the TTM. In about
one-third of the test cases, IPv6 RTT was significantly higher than that for
IPv4. They inferred that the difference in the IPv6 packet delays was
attributed to the lower IPv6 infrastructure in place as well as badly
configured IPv6 tunnels.

 

Evaluating IPv6 on a
large-scale

 Network (2006)

 

This
paper focused on the study between IPv4 and IPv6 performance in terms of delay,
packet loss

 

   rate, bandwidth throughput and
Round-Trip-Time.

The measurements were
conducted between nodes connected by the gigabit Ethernet connection. The
experiment inferred that the similarity in the network performance is
attributed to similarity in the AS paths.

 

3.  METHODOLOGY

 

         The
method presented in this paper makes use of the RIPE Atlas platform. RIPE Atlas
consists of thousands of active small nodes, spread across the world, capable
of running ping and traceroute commands. The traceroute, ping, SSL/TLS, HTTP, NTP
and DNS measurements that evaluate the network performance are conducted by
volunteers hosting probes world-wide. The nodes can be hosted in data centers
as well as the homes of volunteers. This allows the user of RIPE Atlas to not
just measure data center performance, but real-world end user scenarios as
well.

         We
must apply to host a RIPE Atlas probe. The probes are plugged to an Ethernet
port on the node’s switch or router and are powered via USB. RIPE NCC
accumulates the data aggregated from the probe measurements continuously and
make them available. Probe hosts earn credits for the time their probes remain
connected, which they can use to perform their own customized measurements.

         The
measurements we perform use the same 25 randomly selected RIPE Atlas nodes to
ensure consistency among the measurements. These 25 nodes will be situated at
different locations around the world. Then run IP ping and traceroute commands
using IPv4 and IPv6 packets in a periodic fashion to Alexa’s top 100 websites.
RIPE Atlas uses a credit system to run these measurements and credits can be
earned by hosting a node. For each new measurement, we choose the destination
address that is one of Alexa’s top 100 sites and we select the protocol. The
packet size and the time interval are set to default values.

         The probe
is selected across different geographical locations manually by selecting the
probes individually. The same procedure is repeated for other RIPE Atlas nodes
and websites combinations. Also, using the traceroute we can view the route
which the IPv4 and IPv6 packets take to reach the destination. From this route
information, we can calculate the path differences between the packet routes.
From the above measurements, we shall plot graphs of throughput and latency
with respect to time using Math library for each node to the website. The graph
consists of two curves (one for IPv4 and other for IPv6). The graphs shall compare
the Average RTT performance between IPv4 packets and IPv6 packets from each
node to the destination website. Apart from the above measurements, we shall
also explore the tunneling capabilities and evaluate the performance in the
same way as mentioned above.

 

              Fig. 1   25 geographical locations

 

         Above
figure shows the 25 different geographical locations selected for creating
measurements on RIPE atlas. Each location was selected to measure traceroute
and ping to top 100 Alexa’s websites which supported both IPv4 and IPv6. The
protocol used for tracerouting is TCP while it is ICMP for ping. The Ping and
traceroute from a specific node to a website was measured at the same time to
analyze the route and RTT taken by IPv4 and IPv6 in more detail. The same
process is repeated for 25 websites which support both IPv6 and IPv4 address.
The ping measurement data consists of Maximum and Minimum RTT, Source address,
Destination address and probe ID. The traceroute measurement data consists of
Source address, Destination address, hops, timestamp, protocol and probe ID. We
download the results which is in json format. We retrieve the values of each
parameter by parsing the measurement data through our Python script. The
performance comparison is made by plotting graphs for each website with the
y-axis denoting the RTT value and the x-axis denoting all the locations for
IPv4 as well as IPv6.

 

 

4.  RESULTS AND DATA
ANALYSIS

 

 4.1 Ping and
Traceroute result to Yahoo.com

 

         

              Fig. 2 Ping to Yahoo.com

 

          

                   Fig. 3 IPv4 Traceroute

 

               

                     Fig. 4 IPv6 Traceroute

 

         From
Fig. 4, we see that the RTT of IPv4 and IPv6 in most geographical locations are
almost the same.

         Moscow and Morocco don’t have IPv6 RTT
as shown in the graph. This is due to the network being disconnected which can
be seen on the IPv6 traceroute figure where probe 241 gets disconnected at a certain point. Probe
11185 which corresponds to Leipzig, Germany have comparable RTT for both IPv4 and IPv6 as they
have the same number of hops in both cases as seen in figure 3 and 4. The Major
difference in RTT can be seen on probe 17011 which corresponds to Rohtak, India.
IPv4 RTT is 98ms whereas IPv6 RTT is 222ms. The difference in RTT is due to the
variations in the number of hops taken by them which are 17 and 26 respectively.

 

4.2 Ping and
Traceroute result to Youtube.com

 

     

          Fig. 5 Ping to Youtube.com

 

      

          Fig. 6 IPv4 Traceroute

 

           

              Fig. 7 IPv6 Traceroute

             

 
       From the above graph, we analyze that RTT of IPv4
and IPv6 for most of the geographical locations are comparable. This is due to
the similarity in the number of hops taken by IPv4 and IPv6. But in
geographical location like Uruguay, IPv6 RTT is more than IPv4 RTT. This can be
analyzed from traceroute where     number
of hops taken by Uruguay with IPv4 traffic is 8 and number of hops taken by
IPv6 traffic is 19. Moscow and Morocco don’t have IPv6 RTT. This is due to the
network being disconnected that can be seen on the IPv6 traceroute figure where
the probe 241 gets disconnected after routing for some distance.

         The
maximum RTT in both cases IPv4 and IPv6 can be seen for location Rohtak, India
is due to the maximum number of hops taken by IPv4 and IPv6 traffic are 12 and
18 respectively which corresponds eventually to the distance travelled by these
packets. In the traceroute graph, we notice that the destination is Google
instead of YouTube. The destination visible on traceroute graph are Google edge
cache which has a cache of YouTube requests on it and replies to the requests. Edge
nodes (Google Global Cache, or GGC) represent the tier of Google’s
infrastructure closest to our users. With our edge nodes, network operators and
internet service providers deploy Google-supplied servers inside their network.

         Static
content that is very popular with the local host’s user base, including YouTube,
is temporarily cached on edge nodes. Google’s traffic management systems direct
user requests to an edge node that will provide the best experience.

 

 

4.3 Ping and Traceroute
results to Adobe.com                           

 

            

               Fig. 8 Ping to Adobe.com

 

              

                Fig. 9
IPv4 Traceroute

 

              Fig. 10 IPv6 Traceroute

 

      
  From the above graph we can evaluate that IPv4 has
more RTT than IPv6 in most of the geographical locations. There is a comparable
RTT difference between IPv4 and IPv6. Adobe is the only website out of 25
websites where IPv4 RTT is more than IPv6 RTT. The major difference can be seen
in the location Sydney, Australia where RTT of IPv4 is 316ms with 14 hops and
RTT of IPv6 is 3ms with 5 hops. We can ensure this by looking at the path taken
by Probe ID 25208 on traceroute of both IPv4 and IPv6. This is contradictory to
other graphs and reasons for this might be NAT avoidance and sub peering
differences. There are also some locations where IPv4 and IPv6 traffic gets
disconnected such as in Morocco, Moscow and Kensington, Australia. Also, some
locations have more RTT for IPv6 than IPv4 such as in     Tel Aviv, Israel. RTT for IPv4 is 65ms with
network hops of 7 whereas for IPv6 it is 130ms with 11 network hops. This is
depicted on traceroute graph with probe ID 17856 where IPv6 has a longer
network path and more hops than IPv4 network path. Hence, it is very difficult
to decide on the best protocol to choose in these cases as there are
contradictory results.

 

        

 

 5. DISCUSSION

 

Most of the
estimations were persistent estimations, thereby making it less likely as an
arbitrary event. Conceivable reasons for the significance of varied comparison
results is due to increment in web traffic on the websites during a particular
time of the day or routing issues. Something that is more likely to happen
would be transitory routing issues. As we had discussed these in results, some of
the probes gets disconnected after routing through some ASes. This can be
acknowledged as a routing issue. Looking at the results of this paper, we can
see large differences in traceroute or path taken by the packets to reach the
destination which results in significant difference in RTT. In most cases the
RTTs were comparable. In other cases, such as Moscow and Morocco, the issue
persists with most of the websites. There are many potential causes of IPv6
connection failures. A common reason is overly restrictive filters applied on
the customer site, where incoming IPv6 packets are refused. It is also possible
that there are asymmetric routing issues that allow the client to see the
relevant experiment server, but not the reverse. Possibility of a sub peering
understanding between the providers at play exists which might be the cause of
disconnection of requests.

 

    6. CONCLUSION

 

    The main aim of
this paper was to analyze the performance of IPv4 and IPv6 for different
websites and different geographical locations. According to the results
depicted in this paper, there is no major contrast in performance of RTT between
IPv4 and IPv6. The difference arises only when the network paths taken by IPv4
and IPv6 differ as perceived in traceroutes.

 

 7. FUTURE WORK

 

  Internet is very dynamic and the routes
between the hosts is changing everyday depending on the AS paths. Many use the
shared intermediate AS path to reach the host. It all depends on the peering
involved between the enterprises and tunneling. So, it is very difficult to conclude
about the performance of IPv4 and IPv6 based on a single criterion.

  

    

  

In our paper, we
have lot of anomalies regarding the places like Moscow and Morocco which
doesn’t have IPv6 routes. The IPv6 was comparatively faster in most of the
geographical location only in host adobe.com.

We need to better
understand the inter-domain routing within an organization such ag google edge
cache which we plan to carry out in the future.