Internet DRAFT - draft-boucadair-pcp-bittorrent

draft-boucadair-pcp-bittorrent






PCP WG                                                 M. Boucadair, Ed.
Internet-Draft                                            France Telecom
Intended status: Informational                                  T. Zheng
Expires: November 5, 2012                                     P. NG Tung
                                                                 X. Deng
                                                              J. Queiroz
                                                             Orange Labs
                                                             May 4, 2012


  Behavior of BitTorrent service in PCP-enabled networks with Address
                                Sharing
                 draft-boucadair-pcp-bittorrent-00.txt

Abstract

   This document describes the behavior of BitTorrent service in the
   context of PCP-enabled address sharing functions.  It provides an
   overview of the used testbed and main results of the tests that have
   been conducted in order to assess the limitations of an architecture
   based on shared IP addresses.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 5, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Boucadair, et al.       Expires November 5, 2012                [Page 1]

Internet-Draft              BitTorrent & PCP                    May 2012


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  BitTorent Overview . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  BitTorrent at a Glance . . . . . . . . . . . . . . . . . .  3
     2.2.  Software Configuration . . . . . . . . . . . . . . . . . .  4
       2.2.1.  BitTorrent Client  . . . . . . . . . . . . . . . . . .  4
       2.2.2.  BitTorrent Server  . . . . . . . . . . . . . . . . . .  4
       2.2.3.  BitTorrent Tracker . . . . . . . . . . . . . . . . . .  4
   3.  Testbed Overview . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Testbed Description  . . . . . . . . . . . . . . . . . . .  4
     3.2.  Files  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Methodology  . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Description of Tests . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Connection to Overlay Test Group . . . . . . . . . . . . .  6
     4.2.  Upload Test Group  . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Mutual Download Test Group . . . . . . . . . . . . . . . .  7
     4.4.  Simultaneous Download Test Group . . . . . . . . . . . . .  8
   5.  Results  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Allow Same IP Address & PCP Disabled . . . . . . . . . . . 11
     5.2.  Forbid Same IP Address & PCP Disabled  . . . . . . . . . . 13
     5.3.  Allow Same IP Address & PCP Enabled  . . . . . . . . . . . 15
     5.4.  Forbid Same IP  Address & PCP Enabled  . . . . . . . . . . 17
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 19
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21














Boucadair, et al.       Expires November 5, 2012                [Page 2]

Internet-Draft              BitTorrent & PCP                    May 2012


1.  Introduction

   Recently, several proposals have been disseminated within IETF to
   allow for IPv4 service continuity.  These solutions share the same IP
   address among several subscribers (e.g., CGN (Carrier Grade NAT)
   [I-D.ietf-behave-lsn-requirements] or A+P [RFC6346])

   Several issues are encountered in address sharing context as
   elaborated in [RFC6269].

   This memo focuses on BitTorrent as an example of application which
   applies a restriction based on IP address.  This memo describes a
   testing campaign that has been carried out to assess the impact of IP
   shared address on BitTorrent.

   A particular focus has been put on the impact of activating port
   forwarding (using PCP [I-D.ietf-pcp-base]) on the download speed.


2.  BitTorent Overview

2.1.  BitTorrent at a Glance

   BitTorrent is a distributed file sharing infrastructure.  It is based
   on P2P (Peer to Peer) techniques for exchanging files between
   connected users.  Three parties are involved in a BitTorrent
   architecture as detailed hereafter:

   1.  The Server: The server into which, has been uploaded the torrent
       file.

   2.  The Tracker: Maintains a list of clients which have the file or
       some portions of that file.

   3.  The Client: Entities which are downloading and/or uploading
       portions of the file.  Two categories of clients may be
       distinguished:

       A.  Leechers: Clients which are currently downloading the file
           but do not yet detain all the portions of the file.  As for
           the portions already obtained, the leechers upload them
           towards requesting clients;

       B.  Seeders: Clients which detain all the portions of the file
           and are uploading them to other requesting clients.

   A torrent file is a file which includes the meta-data information of
   the file to be shared: the file name, its length, a hash and the URL



Boucadair, et al.       Expires November 5, 2012                [Page 3]

Internet-Draft              BitTorrent & PCP                    May 2012


   of the tracker.  In order to download a given file, a BitTorrent
   client needs to obtain the corresponding torrent file.  Afterwards,
   it connects to the tracker to retrieve a list of leechers and
   seeders.  Then, the client connects to those machines and downloads
   the available portions of the requested file.  It uploads also the
   portions already obtained towards requesting clients.

2.2.  Software Configuration

   This section provides an overview of installed tools.

2.2.1.  BitTorrent Client

   Various BitTorrent clients are available for public use.  The
   following one has been installed for the purposes of our testing
   activities:

      URL: www.bittorrent.com

2.2.2.  BitTorrent Server

   The BitTorrent server that has been used is the following:

      URL: www.torrentbox.com

2.2.3.  BitTorrent Tracker

   The BitTorrent tracker that has been used is the following:

      URL: tracker.torrentbox.com:2710/announce


3.  Testbed Overview

3.1.  Testbed Description

   The testbed used to conduct the testing activities is illustrated in
   the figure below:

   o  The CGN DS-Lite which is responsible to share the same IP address
      among several subscribers.  The CGN embeds a PCP Server.

   o  CPE-1 and CPE-2 are two CPEs sharing the same IP address (by the
      CGN).  Each CPE embeds a IGD/PCP IWF
      [I-D.ietf-pcp-upnp-igd-interworking].

   o  T1 (respectively T2) is a machine located in the LAN behind CPE-1
      (respectively CPE-2).  No NAT is enabled in CPE-1 and CPE-2.



Boucadair, et al.       Expires November 5, 2012                [Page 4]

Internet-Draft              BitTorrent & PCP                    May 2012


   o  RT1 and RT2 are remote machines reachable through Internet.  RT1
      and RT2 are assigned with public IP addresses.

   +-------+    +-------+    +------------+  +----------+
   |       |    | CPE-1 |    | Service    |  |          |
   |   T1  |----|IGD/PCP|----| Provider   |  |          |
   |       |    |  IWF  |    | Domain     |  |          |    +---------+
   +-------+    +-------+    |            |  |          |    | Remote  |
                             |            |  |          +----+ Terminal|
                             |+----------+|  |          |    |  (RT1)  |
                             ||   CGN    ||  |          |    +---------+
                             ||PCP Server||  |          |
                             |+----------+|  |          |
                             |            +--+ Internet |
                             |            |  |          |
                             |            |  |          |
                             |            |  |          |    +---------+
                             |            |  |          |    | Remote  |
                             |            |  |          +----+ Terminal|
   +-------+    +-------+    |            |  |          |    |  (RT2)  |
   |       |    | CPE-2 |    |            |  |          |    +---------+
   |   T2  |----|IGD/PCP|----|            |  |          |
   |       |    |  IWF  |    |            |  |          |
   +-------+    +-------+    +------------+  +----------+

                        Figure 1: Testbed Overview

3.2.  Files

   The following table lists the files available in each machine:

            +-----------------+-------------------------------+
            | Machine' s name | Available files               |
            +-----------------+-------------------------------+
            | T1              | TestCaenF1 and TestCaenFa     |
            | T2              | TestCaenF1 and TestCaenFb     |
            | RT1             | TestCaenFRT1 and TestCaenFRTa |
            | RT2             | TestCaenFRT1 and TestCaenFRTb |
            +-----------------+-------------------------------+

                         Table 1: Available files

3.3.  Methodology

   BitTorrent client can be configured to accept multiple connections
   using the same IP address.  A dedicated parameter can therefore be
   positioned.  This parameter is called: bt.allow_same_ip.  Possible
   values that can be taken by this parameter are: FALSE (0) or TRUE



Boucadair, et al.       Expires November 5, 2012                [Page 5]

Internet-Draft              BitTorrent & PCP                    May 2012


   (1).

   Tests are conducted using four configurations:

            +---------------+--------------------------+----------+
            | Configuration |     bt.allow_same_ip     |    PCP   |
            +---------------+--------------------------+----------+
            |   Section 5.1 |   TRUE in all machines   | Disabled |
            |               |    (T1, T2, RT1, RT2)    |          |
            +---------------+--------------------------+----------+
            |   Section 5.2 |   FALSE in all machines  | Disabled |
            |               |    (T1, T2, RT1, RT2)    |          |
            +---------------+--------------------------+----------+
            |   Section 5.3 |   TRUE in all machines   |  Enabled |
            |               |    (T1, T2, RT1, RT2)    |          |
            +---------------+--------------------------+----------+
            |   Section 5.4 |   TRUE in all machines   |  Enabled |
            |               |    (T1, T2, RT1, RT2)    |          |
            +---------------+--------------------------+----------+

   When PCP is disabled, all port forwarding entries are flushed out.


4.  Description of Tests

   This section lists the tests that have been conducted.

4.1.  Connection to Overlay Test Group

   This table lists the test to assess the ability of distinct machines
   having the same IP address to connect to BitTorrent overlay.

   +--------+------------+---------------------------------------------+
   | Test   | Test Title | Purpose & Description                       |
   | Index  |            |                                             |
   +--------+------------+---------------------------------------------+
   | Test_1 | Connection | Check if two terminals, having the same     |
   |        | to         | public IP address, are able to connect to   |
   |        | BitTorrent | BitTorrent overlay network.  Check if       |
   |        | Overlay    | BitTorrent client installed on T1 and T2    |
   |        |            | machines are able to use the same tracker   |
   |        |            | and that no problems are experienced to use |
   |        |            | the same tracker by T1 and T2.              |
   +--------+------------+---------------------------------------------+

                     Connecting to Overlay Test Group





Boucadair, et al.       Expires November 5, 2012                [Page 6]

Internet-Draft              BitTorrent & PCP                    May 2012


4.2.  Upload Test Group

   This test group aims at checking if upload operations are not
   impacted/restricted due to the presence of several machines with the
   same IP address.

   +--------+------------+---------------------------------------------+
   | Test   | Test Title | Purpose & Description                       |
   | Index  |            |                                             |
   +--------+------------+---------------------------------------------+
   | Test_2 | Uploading  | Check if two terminals, having the same     |
   |        | distinct   | public IP address, are able to upload       |
   |        | files      | torrent files (referring to distinct files) |
   |        | using the  | using the same tracker and same server.     |
   |        | same       | Check if torrent files may be uploaded from |
   |        | BitTorrent | T1 and T2 using the same tracker.  On T1    |
   |        | tracker    | (resp. T2), generate a torrent file         |
   |        | and server | TestCaenFa.torrent (resp.                   |
   |        |            | TestCaenFb.torrent) referring to the file   |
   |        |            | TestCaenFa (resp. TestCaenFb) and pointing  |
   |        |            | to the tracker TRA.  From T1 (resp. T2) try |
   |        |            | to put TestCaenFa.torrent (resp.            |
   |        |            | TestCaenFb.torrent) onto server S. Check if |
   |        |            | the upload operation has succeeded          |
   +--------+------------+---------------------------------------------+
   | Test_3 | Uploading  | Check if two terminals, having the same     |
   |        | torrent    | public IP address, are able to upload       |
   |        | files      | torrent files, which refer to the same      |
   |        | referring  | file, using the same tracker.  On T1 (resp. |
   |        | to the     | T2), generate a torrent file                |
   |        | same file  | TestCaenF1.torrent (resp.                   |
   |        |            | TestCaenF1.torrent) referring to the file   |
   |        |            | TestCaenF1 and pointing to the tracker TRA. |
   |        |            | From T1 (resp. T2) try to put               |
   |        |            | TestCaenF1.torrent (resp.                   |
   |        |            | TestCaenF1.torrent) onto server S. Check if |
   |        |            | the upload operation has succeeded          |
   +--------+------------+---------------------------------------------+

                             Upload Test Group

4.3.  Mutual Download Test Group

   The purpose of this test group is to check if mutual downloading
   operations can occur between machines having the same IP address.






Boucadair, et al.       Expires November 5, 2012                [Page 7]

Internet-Draft              BitTorrent & PCP                    May 2012


   +--------+-------------+--------------------------------------------+
   | Test   | Test Title  | Purpose & Description                      |
   | Index  |             |                                            |
   +--------+-------------+--------------------------------------------+
   | Test_4 | Mutual      | Check if two terminals having the same     |
   |        | Downloading | public IP address can download a file from |
   |        | between     | each another.  Check if T1 can download    |
   |        | machines    | the file uploaded by T2 (ref.  Test_2) and |
   |        | sharing the | vice versa.  Three scenarios are to be     |
   |        | same IP     | tested: (1) T1 downloads TestCaenFb but T2 |
   |        | address     | does not download any file from T1, (2) T2 |
   |        |             | downloads TestCaenFa but T1 does not       |
   |        |             | download any file from T2, (3) T1          |
   |        |             | downloads TestCaenFb and T2 downloads      |
   |        |             | TestCaenFa at the same time                |
   +--------+-------------+--------------------------------------------+
   | Test_5 | Mutual      | Check if two terminals located behind an   |
   |        | Downloading | address sharing function but assigned with |
   |        | between     | distinct public IP addresses can download  |
   |        | machines    | a file from each another.  Check if T1 can |
   |        | located     | download the file uploaded by T2 (ref.     |
   |        | behind an   | Test_2) and vice versa.                    |
   |        | address     |                                            |
   |        | sharing     |                                            |
   |        | function    |                                            |
   +--------+-------------+--------------------------------------------+

                        Mutual Download Test Group

4.4.  Simultaneous Download Test Group

   This test group aims at checking if simultaneous downloading
   operations from remote seed(s)/leecher(s) can be performed by several
   machines sharing the same IP address.

















Boucadair, et al.       Expires November 5, 2012                [Page 8]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+--------------+------------------------------------------+
   | Test    | Test Title   | Purpose & Description                    |
   | Index   |              |                                          |
   +---------+--------------+------------------------------------------+
   | Test_6  | Downloading  | Check if two terminals, having the same  |
   |         | distinct     | public IP address, are able to download  |
   |         | files        | distinct files available on BitTorrent   |
   |         |              | infrastructure.  Check if distinct files |
   |         |              | available on BitTorrent infrastructure   |
   |         |              | may be downloaded by T1 and T2           |
   |         |              | simultaneously                           |
   +---------+--------------+------------------------------------------+
   | Test_7  | Downloading  | Check if two terminals, having the same  |
   |         | the same     | public IP address, are able to download  |
   |         | file located | the same file located on several         |
   |         | on several   | seeders.  Check if a file available on   |
   |         | seeders      | several seeders may be downloaded from   |
   |         |              | T1 and T2 simultaneously.  As an         |
   |         |              | example, check if T1 and T2 can download |
   |         |              | the same file located in RT1 and RT2     |
   |         |              | (referred to as TestCaenFRT1)            |
   +---------+--------------+------------------------------------------+
   | Test_8  | Download the | Check if two terminals having the same   |
   |         | same file    | public IP address are able to download,  |
   |         | available on | at the same time, the same file          |
   |         | a single     | available on a single seed.  Check if T1 |
   |         | machine      | and T2 can download the same file        |
   |         |              | uploaded by RT1 (referred to as          |
   |         |              | TestCaenFRTa) concurrently.  In case the |
   |         |              | test fails, one of the two host is       |
   |         |              | called the "waiting client"              |
   +---------+--------------+------------------------------------------+



















Boucadair, et al.       Expires November 5, 2012                [Page 9]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+--------------+------------------------------------------+
   | Test_9  | Simultaneous | Check if it is not precluded that a      |
   |         | downloading  | different file can be downloaded by the  |
   |         | from the     | waiting client from the same seeder.  In |
   |         | same seeder  | case Test_7 fails, check that it is not  |
   |         |              | precluded that a different file can be   |
   |         |              | downloaded by the waiting client (T1 or  |
   |         |              | T2) from the same seeder (RT1) at the    |
   |         |              | same time the other terminal             |
   |         |              | (respectively T2 or T1) is downloading   |
   |         |              | TestCaenFRTa.  Execute Test_7 in         |
   |         |              | launching on T1 the downloading of       |
   |         |              | TestCaenFRT1 and just few seconds        |
   |         |              | afterwards in launching on T2 the        |
   |         |              | downloading of TestCaenFRT1 and          |
   |         |              | TestCaenFRTa.  Check that while T1 is    |
   |         |              | downloading TestCaenFRT1 that does not   |
   |         |              | preclude T2 to concurrently download     |
   |         |              | TestCaenFRTa.                            |
   +---------+--------------+------------------------------------------+
   | Test_10 | Downloading  | Check if the two terminals having the    |
   |         | distinct     | same public IP address are able to       |
   |         | files from   | download at the same time two distinct   |
   |         | the same     | files from the same seeder.  Check if T1 |
   |         | seeder       | (respectively T2) can download files     |
   |         |              | uploaded by RT1 (referred to as          |
   |         |              | TestCaenRF1 and TestCaenFRTa)            |
   |         |              | concurrently.  Particularly, check if T1 |
   |         |              | can download TestCaenFRT1 and T2 can     |
   |         |              | download TestCaenFRTa simultaneously     |
   +---------+--------------+------------------------------------------+
   | Test_11 | Download the | Check if the same file can be downloaded |
   |         | same file    | by a given machine from seeders having   |
   |         | located on   | the same IP address.  In RT1, launch the |
   |         | machines     | downloading of TestCaenF1.  Check that   |
   |         | having the   | RT1 is downloading portions of           |
   |         | same IP      | TestCaenF1 at the same time from T1 and  |
   |         | address      | T2                                       |
   +---------+--------------+------------------------------------------+
   | Test_12 | Automatic    | Check if the terminal which was waiting  |
   |         | query to     | can finally download the file once the   |
   |         | download the | other terminal has finished.  In case    |
   |         | same file    | Test_7 fails, check that the terminal    |
   |         | available on | which was waiting can finally download   |
   |         | a single     | the file once the other terminal has     |
   |         | machine      | finished                                 |
   +---------+--------------+------------------------------------------+




Boucadair, et al.       Expires November 5, 2012               [Page 10]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+--------------+------------------------------------------+
   | Test_13 | Download     | Check if distinct files can be           |
   |         | distinct     | downloaded by the same machine from      |
   |         | files from   | seeders having the same IP address.      |
   |         | two machines | Check if RT1 can download simultaneously |
   |         | having the   | TestCaenFa (from T1) and TestCaenFb      |
   |         | same IP      | (from T2)                                |
   |         | address      |                                          |
   +---------+--------------+------------------------------------------+

                     Simultaneous Download Test Group


5.  Results

   The following tables summarize the results of the tests listed in
   Section 4 as performed using the testbed described in Section 3.
   Four configurations have been tested as documented in Section 3.3.

5.1.  Allow Same IP Address & PCP Disabled

   The following table summarizes the results of the tests when
   "bt.allow_same_ip == TRUE" in all involved BitTorrent clients and PCP
   is disabled.

   +---------+-------------------------------------------+-------------+
   | Index   | Results                                   | Downloading |
   |         |                                           | Speed       |
   +---------+-------------------------------------------+-------------+
   | Test_1  | No problems have been experienced         |             |
   +---------+-------------------------------------------+-------------+
   | Test_2  | Both T1 and T2 are able to upload         |             |
   |         | distinct torrent files using the same     |             |
   |         | tracker and the same server.              |             |
   +---------+-------------------------------------------+-------------+
   | Test_3  | Only one machine can upload a torrent     |             |
   |         | file referring to the same file.  The     |             |
   |         | server ensures that only one single       |             |
   |         | torrent file corresponding to the same    |             |
   |         | file is listed in its base.               |             |
   +---------+-------------------------------------------+-------------+










Boucadair, et al.       Expires November 5, 2012               [Page 11]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+-------------------------------------------+-------------+
   | Test_4  | Three scenarios have been tested: (1) T1  |             |
   |         | downloads TestCaenFb but T2 does not      |             |
   |         | download any file from T1 (2) T2          |             |
   |         | downloads TestCaenFa but T1 does not      |             |
   |         | download any file from T2 (3) T1          |             |
   |         | downloads TestCaenFb and T2 downloads     |             |
   |         | TestCaenFa in the same time.  For all     |             |
   |         | these scenarios, mutual downloading       |             |
   |         | between T1 and T2 is not observed.        |             |
   +---------+-------------------------------------------+-------------+
   | Test_5  | No mutual downloading between T1 and T2   |             |
   |         | was observed.                             |             |
   +---------+-------------------------------------------+-------------+
   | Test_6  | Both T1 and T2 are able to download       | T1:         |
   |         | distinct files from the BitTorrent        | 50-110KBps; |
   |         | infrastructure.                           | T2:         |
   |         |                                           | 60-80KBps   |
   +---------+-------------------------------------------+-------------+
   | Test_7  | Both T1 and T2 are able to download the   | T1 and T2:  |
   |         | same file located in several seeders.     | 50-70KBps   |
   |         | Mutual downloading between T1 and T2 is   |             |
   |         | not observed.                             |             |
   +---------+-------------------------------------------+-------------+
   | Test_8  | Both T1 and T2 are able to download       | T1:         |
   |         | TestCaenFRTa from RT1 simultaneously.     | 50-70KBps;  |
   |         | Mutual downloading between T1 and T2 is   | T2:         |
   |         | not observed.                             | 40-80KBps   |
   +---------+-------------------------------------------+-------------+
   | Test_9  | Not applicable                            |             |
   +---------+-------------------------------------------+-------------+
   | Test_10 | No problem has been encountered.          | T1:         |
   |         | Distinct files located in RT1 have been   | 30-90KBps;  |
   |         | successfully downloaded by T1             | T2:         |
   |         | (respectively T2).                        | 50-80KBps   |
   +---------+-------------------------------------------+-------------+
   | Test_11 | No problem has been encountered.  RT1 is  | RT1:        |
   |         | able to download TestCaenF1 from T1 and   | 60-100KBps  |
   |         | T2 simultaneously.                        |             |
   +---------+-------------------------------------------+-------------+
   | Test_12 | Not applicable                            |             |
   +---------+-------------------------------------------+-------------+
   | Test_13 | No problem has been encountered.  RT1 has | RT1:        |
   |         | succeeded to download simultaneously      | 30-50KBps   |
   |         | TestCaenFa (from T1) and TestCaenFb (from | from T1 and |
   |         | T2).                                      | 30-40KBps   |
   |         |                                           | from T2     |
   +---------+-------------------------------------------+-------------+



Boucadair, et al.       Expires November 5, 2012               [Page 12]

Internet-Draft              BitTorrent & PCP                    May 2012


                   Table 2: Allow Same IP & PCP Disabled

5.2.  Forbid Same IP Address & PCP Disabled

   The following table summarizes the results of the tests when
   "bt.allow_same_ip == FALSE" in all involved BitTorrent clients and
   PCP is disabled.

   +---------+-----------------------------------------+---------------+
   | Index   | Results                                 | Downloading   |
   |         |                                         | Speed         |
   +---------+-----------------------------------------+---------------+
   | Test_1  | No problems have been experienced       |               |
   +---------+-----------------------------------------+---------------+
   | Test_2  | Both T1 and T2 are able to upload       |               |
   |         | distinct torrent files using the same   |               |
   |         | tracker and the same server.            |               |
   +---------+-----------------------------------------+---------------+
   | Test_3  | Only one machine can upload a torrent   |               |
   |         | file referring to the same file.  The   |               |
   |         | server ensures that only one single     |               |
   |         | torrent file corresponding to the same  |               |
   |         | file is listed in its base.             |               |
   +---------+-----------------------------------------+---------------+
   | Test_4  | Three scenarios have been tested: (1)   |               |
   |         | T1 downloads TestCaenFb but T2 does not |               |
   |         | download any file from T1 (2) T2        |               |
   |         | downloads TestCaenFa but T1 does not    |               |
   |         | download any file from T2 (3) T1        |               |
   |         | downloads TestCaenFb and T2 downloads   |               |
   |         | TestCaenFa in the same time.  For all   |               |
   |         | these scenarios, mutual downloading     |               |
   |         | between T1 and T2 is not observed.      |               |
   +---------+-----------------------------------------+---------------+
   | Test_5  | No mutual downloading between T1 and T2 |               |
   |         | was observed.                           |               |
   +---------+-----------------------------------------+---------------+
   | Test_6  | Both T1 and T2 are able to download     | T1:           |
   |         | distinct files from the BitTorrent      | 50-110KBps    |
   |         | infrastructure.                         | T2: 60-80KBps |
   +---------+-----------------------------------------+---------------+










Boucadair, et al.       Expires November 5, 2012               [Page 13]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+-----------------------------------------+---------------+
   | Test_7  | Both T1 and T2 are able to download the | T1            |
   |         | same file located in several seeders.   | :100-120KBps, |
   |         | But for each file it is sending (here   | After T1      |
   |         | TestCaenFRT1) RT1 can allow no more     | finished, T2  |
   |         | than one unique connection to the same  | started       |
   |         | address IP.  This is the same behavior  | 100-120KBps   |
   |         | for RT2.  Mutual downloading between T1 |               |
   |         | and T2 is not observed.                 |               |
   +---------+-----------------------------------------+---------------+
   | Test_8  | Both T1 and T2 are able to download the | T1:           |
   |         | file but only one single connection is  | 70-100KBps    |
   |         | accepted by RT1 at the same time.  This |               |
   |         | is because for each file it is sending  |               |
   |         | (here TestCaenFRTa) RT1 can allow no    |               |
   |         | more than one unique connection to the  |               |
   |         | same address IP.  The result is that,   |               |
   |         | once T1 (or T2) has begun to download   |               |
   |         | TestCaenFRTa, the other terminal (T2 or |               |
   |         | respectively T1) cannot get any portion |               |
   |         | of TestCaenFRTa directly from RT1 till  |               |
   |         | the other (T1 or respectively T2) has   |               |
   |         | completed the downloading of            |               |
   |         | TestCaenFRTa.  Mutual downloading       |               |
   |         | between T1 and T2 is not observed.      |               |
   +---------+-----------------------------------------+---------------+
   | Test_9  | The test has succeeded.  While T1 has   | T1: 50-70KBps |
   |         | been downloading TestCaenFRT1 from RT1, | T2: 40-50KBps |
   |         | T2 could download TestCaenFRTa from RT1 |               |
   |         | and in addition it can get portions of  |               |
   |         | TestCaenFRTa already downloaded by T1.  |               |
   +---------+-----------------------------------------+---------------+
   | Test_10 | No problem has been encountered.        | T1: 50-70KBps |
   |         | Distinct files located in RT1 have been | T2: 40-60KBps |
   |         | successfully downloaded by T1           |               |
   |         | (respectively T2).                      |               |
   +---------+-----------------------------------------+---------------+
   | Test_11 | Both T1 and T2 are able to upload the   | RT1:          |
   |         | file, but only one connection is        | 20-40KBps     |
   |         | accepted by RT1 at the same time.  The  | from T1       |
   |         | test failed because, once RT1 has begun |               |
   |         | to download portions of TestCaenF1 from |               |
   |         | T1 (respectively T2) it cannot accept   |               |
   |         | additional connection with T2 for the   |               |
   |         | same file.                              |               |
   +---------+-----------------------------------------+---------------+





Boucadair, et al.       Expires November 5, 2012               [Page 14]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+-----------------------------------------+---------------+
   | Test_12 | The test succeeded.  Once T1 has        | T2:           |
   |         | completed its downloading from RT1, T2  | 80-100KBps    |
   |         | has been able automatically to connect  |               |
   |         | to RT1 for receiving the same file.     |               |
   +---------+-----------------------------------------+---------------+
   | Test_13 | No problem has been encountered.  RT1   | RT1:          |
   |         | has succeeded to download               | 30-50KBps     |
   |         | simultaneously TestCaenFa (from T1) and | from T1 and   |
   |         | TestCaenFb (from T2).                   | 30-50KBps     |
   |         |                                         | from T2       |
   +---------+-----------------------------------------+---------------+

                  Table 3: Forbid Same IP & PCP Disabled

5.3.  Allow Same IP Address & PCP Enabled

   The following table summarizes the results of the tests when
   "bt.allow_same_ip == TRUE" in all involved BitTorrent clients and PCP
   is enabled.

   +---------+---------------------------------------+-----------------+
   | Index   | Results                               | Downloading     |
   |         |                                       | Speed           |
   +---------+---------------------------------------+-----------------+
   | Test_1  | No problems have been experienced     |                 |
   +---------+---------------------------------------+-----------------+
   | Test_2  | Both T1 and T2 are able to upload     |                 |
   |         | distinct torrent files using the same |                 |
   |         | tracker and the same server.          |                 |
   +---------+---------------------------------------+-----------------+
   | Test_3  | Only one machine can upload a torrent |                 |
   |         | file referring to the same file.  The |                 |
   |         | server ensures that only one single   |                 |
   |         | torrent file corresponding to the     |                 |
   |         | same file is listed in its base       |                 |
   +---------+---------------------------------------+-----------------+
   | Test_4  | Three scenarios have been tested: (1) | (1)T1:          |
   |         | T1 downloads TestCaenFb but T2 does   | 1.4-1.5MBps     |
   |         | not download any file from T1 (2) T2  | (2)T2:          |
   |         | downloads TestCaenFa but T1 does not  | 1.4-1.5MBps     |
   |         | download any file from T2 (3) T1      | (3)T1 and T2:   |
   |         | downloads TestCaenFb and T2 downloads | 600-800KBps     |
   |         | TestCaenFa in the same time.  For all |                 |
   |         | these scenarios, no problems have     |                 |
   |         | been encountered.  The downloading    |                 |
   |         | operations have succeeded.            |                 |
   +---------+---------------------------------------+-----------------+



Boucadair, et al.       Expires November 5, 2012               [Page 15]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+---------------------------------------+-----------------+
   | Test_5  | The mutual downloading operations     | T1/T2:          |
   |         | have succeeded                        | 1.4-1.5MBps     |
   +---------+---------------------------------------+-----------------+
   | Test_6  | Both T1 and T2 are able to download   | T1: 100-110KBps |
   |         | distinct files from the BitTorrent    | T2: 60-80KBps   |
   |         | infrastructure.                       |                 |
   +---------+---------------------------------------+-----------------+
   | Test_7  | Both T1 and T2 are able to download   | T1 and T2:      |
   |         | the same file located in several      | normal speed is |
   |         | seeders.  Mutual downloading by T1 of | 90-140KBps (the |
   |         | portions of TestCaenFRT1 already      | highest is      |
   |         | downloaded by T2 (and vice versa) has | 800KBps),       |
   |         | been observed.                        | between T1 and  |
   |         |                                       | T2, the normal  |
   |         |                                       | speed is        |
   |         |                                       | 50-70KBps (the  |
   |         |                                       | highest is      |
   |         |                                       | 700KBps)        |
   +---------+---------------------------------------+-----------------+
   | Test_8  | Both T1 and T2 are able to download   | T1 and T2:      |
   |         | TestCaenFRTa from RT1 simultaneously. | normal speed is |
   |         | Mutual downloading by T1 of portions  | 80-110KBps(the  |
   |         | of TestCaenFRTa already downloaded by | highest is      |
   |         | T2 (and vice versa) has been          | 700KBps),       |
   |         | observed.                             | between T1 and  |
   |         |                                       | T2, the normal  |
   |         |                                       | speed is        |
   |         |                                       | 40-50KBps (the  |
   |         |                                       | highest is      |
   |         |                                       | 600KBps)        |
   +---------+---------------------------------------+-----------------+
   | Test_9  | Not applicable                        |                 |
   +---------+---------------------------------------+-----------------+
   | Test_10 | No problem has been encountered.      | T1: 50-70KBps   |
   |         | Distinct files located in RT1 have    | T2: 40-70KBps   |
   |         | been successfully downloaded by T1    |                 |
   |         | (respectively T2).                    |                 |
   +---------+---------------------------------------+-----------------+
   | Test_11 | No problem has been encountered.  RT1 | RT1: 60-80KBps  |
   |         | is able to download TestCaenF1 from   |                 |
   |         | T1 and T2 simultaneously.             |                 |
   +---------+---------------------------------------+-----------------+
   | Test_12 | Not applicable                        |                 |
   +---------+---------------------------------------+-----------------+






Boucadair, et al.       Expires November 5, 2012               [Page 16]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+---------------------------------------+-----------------+
   | Test_13 | No problem has been encountered.  RT1 | RT1: 30-50KBps  |
   |         | has succeeded to download             | from T1 and     |
   |         | simultaneously TestCaenFa (from T1)   | 30-40KBps from  |
   |         | and TestCaenFb (from T2).             | T2              |
   +---------+---------------------------------------+-----------------+

                   Table 4: Allow Same IP & PCP Enabled

5.4.  Forbid Same IP  Address & PCP Enabled

   The following table summarizes the results of the tests when
   "bt.allow_same_ip == FALSE" in all involved BitTorrent clients and
   PCP is enabled.

   +---------+------------------------------------------+--------------+
   | Index   | Results                                  | Downloading  |
   |         |                                          | Speed        |
   +---------+------------------------------------------+--------------+
   | Test_1  | No problems have been experienced        |              |
   +---------+------------------------------------------+--------------+
   | Test_2  | Both T1 and T2 are able to upload        |              |
   |         | distinct torrent files using the same    |              |
   |         | tracker and the same server.             |              |
   +---------+------------------------------------------+--------------+
   | Test_3  | Only one machine can upload a torrent    |              |
   |         | file referring to the same file.  The    |              |
   |         | server ensures that only one single      |              |
   |         | torrent file corresponding to the same   |              |
   |         | file is listed in its base.              |              |
   +---------+------------------------------------------+--------------+
   | Test_4  | Three scenarios have been tested: (1) T1 | (1)T1:       |
   |         | downloads TestCaenFb but T2 does not     | 1.4-1.5MBps  |
   |         | download any file from T1 (2) T2         | (2)T2:       |
   |         | downloads TestCaenFa but T1 does not     | 1.4-1.5MBps  |
   |         | download any file from T2 (3) T1         |              |
   |         | downloads TestCaenFb and T2 downloads    |              |
   |         | TestCaenFa in the same time.  For (1)    |              |
   |         | and (2), after several tries,            |              |
   |         | downloading operations have succeeded to |              |
   |         | be observed.  But for (3), mutual        |              |
   |         | downloading between T1 and T2 is not     |              |
   |         | observed.                                |              |
   +---------+------------------------------------------+--------------+
   | Test_5  | The mutual downloading operations have   | T1/T2:       |
   |         | succeeded.                               | 1.4-1.5MBps  |
   +---------+------------------------------------------+--------------+




Boucadair, et al.       Expires November 5, 2012               [Page 17]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+------------------------------------------+--------------+
   | Test_6  | Both T1 and T2 are able to download      | T1:          |
   |         | distinct files from the BitTorrent       | 100-110KBps  |
   |         | infrastructure.                          | T2:          |
   |         |                                          | 60-70KBps    |
   +---------+------------------------------------------+--------------+
   | Test_7  | Both T1 and T2 are able to download the  | T1           |
   |         | same file located in several seeders.    | :100-120KBps |
   |         | But for each file it is sending (here    | After T1     |
   |         | TestCaenFRT1) RT1 can allow no more than | finished, T2 |
   |         | one unique connection to the same        | started      |
   |         | address IP.  This is the same behavior   | 100-120KBps  |
   |         | for RT2.  Mutual downloading between T1  |              |
   |         | and T2 is not observed.                  |              |
   +---------+------------------------------------------+--------------+
   | Test_8  | Both T1 and T2 are able to download the  | T1:          |
   |         | file but only one single connection is   | 60-90KBps    |
   |         | accepted by RT1 at the same time.  This  |              |
   |         | is because for each file it is sending   |              |
   |         | (here TestCaenFRTa) RT1 can allow no     |              |
   |         | more than one unique connection to the   |              |
   |         | same address IP.  The result is that,    |              |
   |         | once T1 (or T2) has begun to download    |              |
   |         | TestCaenFRTa, the other terminal (T2 or  |              |
   |         | respectively T1) cannot get any portion  |              |
   |         | of TestCaenFRTa directly from RT1 till   |              |
   |         | the other (T1 or respectively T2) has    |              |
   |         | completed the downloading of             |              |
   |         | TestCaenFRTa.  Mutual downloading        |              |
   |         | between T1 and T2 is not observed.       |              |
   +---------+------------------------------------------+--------------+
   | Test_9  | The test has succeeded.  While T1 has    | T1:          |
   |         | been downloading TestCaenFRT1 from RT1,  | 50-70KBps    |
   |         | T2 could download TestCaenFRTa from RT1  | T2: 40-50KBp |
   |         | and in addition it can get portions of   |              |
   |         | TestCaenFRTa already downloaded by T1.   |              |
   +---------+------------------------------------------+--------------+
   | Test_10 | No problem has been encountered.         | T1:          |
   |         | Distinct files located in RT1 have been  | 50-70KBps    |
   |         | successfully downloaded by T1            | T2:          |
   |         | (respectively T2).                       | 30-50KBps    |
   +---------+------------------------------------------+--------------+









Boucadair, et al.       Expires November 5, 2012               [Page 18]

Internet-Draft              BitTorrent & PCP                    May 2012


   +---------+------------------------------------------+--------------+
   | Test_11 | Both T1 and T2 are able to upload the    | RT1:         |
   |         | file, but only one connection is         | 20-40KBps    |
   |         | accepted by RT1 at the same time.  The   | from T1      |
   |         | test failed because, once RT1 has begun  |              |
   |         | to download portions of TestCaenF1 from  |              |
   |         | T1 (respectively T2) it cannot accept    |              |
   |         | additional connection with T2 for the    |              |
   |         | same file.                               |              |
   +---------+------------------------------------------+--------------+
   | Test_12 | The test succeeded.  Once T1 has         | T2:          |
   |         | completed its downloading from RT1, T2   | 80-100KBps   |
   |         | has been able automatically to connect   |              |
   |         | to RT1 for receiving the same file.      |              |
   +---------+------------------------------------------+--------------+
   | Test_13 | No problem has been encountered.  RT1    | RT1:         |
   |         | has succeeded to download simultaneously | 30-40KBps    |
   |         | TestCaenFa (from T1) and TestCaenFb      | from T1 and  |
   |         | (from T2).                               | 40-50KBps    |
   |         |                                          | from T2      |
   +---------+------------------------------------------+--------------+

                   Table 5: Forbid Same IP & PCP Enabled


6.  Conclusions

   This document describes the main behavior of BitTorrent in an IP
   shared address environment.  The impact of activating port forwarding
   (here PCP is used) has been also assessed.

   Mutual file sharing between hosts sharing the same IP address has
   been checked.  Machines having the same IP address can share files
   with no alteration compared to current IP architectures only if port
   forwarding (PCP in our case) is enabled.

   Mutual file sharing between hosts behind an IP address sharing
   function has been also checked.  Machines having distinct IP
   addresses but located behind an address sharing function can share
   files with no alteration compared to current IP architectures only if
   port forwarding (PCP in our case) is enabled.

   Even if PCP is enabled, two limitations were experienced:

   The first limitation  occurs when two clients sharing the same IP
      address want to simultaneously retrieve the SAME file located in a
      SINGLE remote peer.  This limitation is due to the default
      BitTorrent configuration on the remote peer which does not permit



Boucadair, et al.       Expires November 5, 2012               [Page 19]

Internet-Draft              BitTorrent & PCP                    May 2012


      sending the same file to multiple ports of the same IP address.
      This limitation is mitigated by the fact that clients sharing the
      same IP address can exchange portions with each other, provided
      the clients can find each other through a common tracker, DHT, or
      Peer Exchange.  Even if they can not, we observed that the remote
      peer would begin serving portions of the file automatically as
      soon as the other client (sharing the same IP address) finished
      downloading.  This limitation is eliminated if the remote peer is
      configured with bt.allow_same_ip == TRUE.

   The second limitation  occurs when a client tries to download a file
      located on several seeders, when those seeders share the same IP
      address.  This is because the clients are enforcing
      bt.allow_same_ip parameter to FALSE.  The client will only be able
      to connect to one seeder, among those having the same IP address,
      to download the file (note that the client can retrieve the file
      from other seeders having distinct IP addresses).  This limitation
      is eliminated if the local client is configured with
      bt.allow_same_ip == TRUE, which is somewhat likely as those
      clients will directly experience better throughput by changing
      their own configuration.


7.  IANA Considerations

   This document raises no IANA considerations.


8.  Security Considerations

   This memo does not introduce any security issue.


9.  References

9.1.  Normative References

   [I-D.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-24 (work in progress), March 2012.

   [I-D.ietf-pcp-upnp-igd-interworking]
              Boucadair, M., Dupont, F., Penno, R., and D. Wing,
              "Universal Plug and Play (UPnP) Internet Gateway Device
              (IGD)-Port Control Protocol (PCP) Interworking Function",
              draft-ietf-pcp-upnp-igd-interworking-01 (work in
              progress), March 2012.



Boucadair, et al.       Expires November 5, 2012               [Page 20]

Internet-Draft              BitTorrent & PCP                    May 2012


9.2.  Informative References

   [I-D.ietf-behave-lsn-requirements]
              Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common requirements for Carrier Grade NATs
              (CGNs)", draft-ietf-behave-lsn-requirements-06 (work in
              progress), May 2012.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,
              June 2011.

   [RFC6346]  Bush, R., "The Address plus Port (A+P) Approach to the
              IPv4 Address Shortage", RFC 6346, August 2011.


Authors' Addresses

   Mohamed Boucadair (editor)
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com


   Tao Zheng
   Orange Labs
   Beijing
   China

   Email: tao.zheng@orange.com


   NG Tung
   Orange Labs
   Issy Les Moulineaux
   France

   Email: paul.ngtung@orange.com











Boucadair, et al.       Expires November 5, 2012               [Page 21]

Internet-Draft              BitTorrent & PCP                    May 2012


   Xiaohing Deng
   Orange Labs
   Beijing
   China

   Email: xiaohong.deng@orange.com


   Jaqueline Queiroz
   Orange Labs
   Issy Les Moulineaux
   France

   Email: jaqueline.queiroz@orange.com





































Boucadair, et al.       Expires November 5, 2012               [Page 22]