[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-boucadair-behave-bittorrent-address-sharing

Network Working Group                                  M. Boucadair, Ed.
Internet-Draft                                             J-L. Grimault
Intended status: Informational                                  P. Levis
Expires: July 16, 2009                                   A. Villefranque
                                                          France Telecom
                                                        January 12, 2009


  Behaviour of BitTorrent service in an IP Shared Address Environment
           draft-boucadair-behave-bittorrent-portrange-02.txt

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 16, 2009.

Copyright Notice

   Copyright (c) 2009 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
   carefully, as they describe your rights and restrictions with respect
   to this document.






Boucadair, et al.         Expires July 16, 2009                 [Page 1]

Internet-Draft            Port Range BitTorrent             January 2009


Abstract

   This memo describes the behaviour of BitTorrent service in the
   context of IP shared addresses.  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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  BitTorent Overview . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  BitTorrent at a Glance . . . . . . . . . . . . . . . . . .  4
     2.2.  Software Configuration . . . . . . . . . . . . . . . . . .  5
       2.2.1.  BitTorrent Client  . . . . . . . . . . . . . . . . . .  5
       2.2.2.  BitTorrent Server  . . . . . . . . . . . . . . . . . .  5
       2.2.3.  BitTorrent Tracker . . . . . . . . . . . . . . . . . .  6

   3.  Testbed Overview . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Testbed Description  . . . . . . . . . . . . . . . . . . .  6
     3.2.  Files  . . . . . . . . . . . . . . . . . . . . . . . . . .  7

   4.  Description of Tests . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Connection to Overlay Test Group . . . . . . . . . . . . .  7
     4.2.  Upload Test Group  . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Mutual Download Test Group . . . . . . . . . . . . . . . .  8
     4.4.  Simultaneous Download Test Group . . . . . . . . . . . . .  9

   5.  Results  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  First Configuration: Multiple Connections with the
           same IP address are enabled  . . . . . . . . . . . . . . . 12
     5.2.  Second Configuration: Multiple Connections with the
           same IP address are disabled . . . . . . . . . . . . . . . 14

   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 17

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18




Boucadair, et al.         Expires July 16, 2009                 [Page 2]

Internet-Draft            Port Range BitTorrent             January 2009


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19


















































Boucadair, et al.         Expires July 16, 2009                 [Page 3]

Internet-Draft            Port Range BitTorrent             January 2009


1.  Introduction

   Recently, several proposals have been disseminated within IETF to
   contribute to solve the IP exhaustion problem.  These solutions may
   be grouped into two categories:

      (1) Solutions which propose the introduction of a second level of
      NAT (Network Address Translator), denoted also as Carrier Grade
      NAT (CG-NAT).  This node is located in the Service Provider
      domain.  Private addresses are assigned to end-user CPEs, which
      still perform their own NAT.  The CG-NAT is responsible for
      translating IP packets issued with private addresses to ones with
      publicly routable IPv4 addresses (especially when exiting the
      domain of the Service Provider).
      [ID.durand-softwire-dual-stack-lite] is a variant of these
      solutions where there is only one NAT hosted in the Service
      Provider's network.

      (2) Solutions which avoid the introduction of a NAT in the Service
      Provider's network.  Examples of these solutions are
      [ID.ymbk-aplusp], [ID.boucadair-port-range], [ID.despres-sam] and
      [ID.bajko-v6ops-port-restricted-ipaddr-assign].  These solutions
      allocate the same IP public address to several customers at the
      same time.  They also allocate a restricted port range to each
      customer so that two customers with the same IP address have two
      different port ranges that do not overlap.

   Both the above listed categories are based on sharing an IP address
   between several machines.  In this context, the delivery of some
   services may be impacted, especially those enforcing a restriction
   based on the source IP address.

   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.

   Testing activities are conducted using a testbed which is configured
   according to the solution described in [ID.boucadair-port-range].


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



Boucadair, et al.         Expires July 16, 2009                 [Page 4]

Internet-Draft            Port Range BitTorrent             January 2009


   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
   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

   The installed version is 6.1.

2.2.2.  BitTorrent Server

   The BitTorrent server that has been used is the following:

   URL: www.metro-torrent.com



Boucadair, et al.         Expires July 16, 2009                 [Page 5]

Internet-Draft            Port Range BitTorrent             January 2009


2.2.3.  BitTorrent Tracker

   The BitTorrent tracker that has been used is the following:

   URL: www.metro-torrent.com/announce.php


3.  Testbed Overview

3.1.  Testbed Description

   The testbed used to conduct the testing activities, described in
   Section 5, is the same as the one described in Section 4 of
   [ID.boucadair-port-range].

   o  The PRR (Port Range Router) is responsible to implement a port-
      driven routing so as to be able to route incoming traffic to the
      appropriate machine among those having the same IP address.

   o  CPE-1 and CPE-2 are two CPEs to which the same IP address is
      assigned.  In order to discriminate these CPEs, distinct Port
      Masks [ID.boucadair-dhc-port-range] are assigned to each of these
      CPE.

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

   o  RT1 and RT2 are remote machines reachable through Internet.

   +-------+    +-----+       +-----------+  +----------+
   |       |    |     |       | Service   |  |          |
   |   T1  |----|CPE-1|-------| Provider  |  |          |
   |       |    |     |       | Domain    |  |          |    +---------+
   +-------+    +-----+       |           |  |          |    | Remote  |
            193.51.145.206    |           |  |          +----+ Terminal|
                              |  +-----+  |  |          |    |  (RT1)  |
   +-------+    +-----+       |  | PRR |  +--+ Internet |    +---------+
   |       |    |     |       |  +-----+  |  |          |    193.51.145.205
   |   T2  |----|CPE-2|-------|           |  |          |
   |       |    |     |       |           |  |          |
   +-------+    +-----+       |           |  |          |    +---------+
               193.51.145.206 |           |  |          |    | Remote  |
                              |           |  |          +----+ Terminal|
                              |           |  |          |    |  (RT2)  |
                              |           |  |          |    +---------+
                              |           |  |          |    193.51.145.208
                              +-----------+  +----------+




Boucadair, et al.         Expires July 16, 2009                 [Page 6]

Internet-Draft            Port Range BitTorrent             January 2009


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 |
            +-----------------+-------------------------------+

                              Available files


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     | Check if BitTorrent       |
   |        | to         | terminals,       | client installed on T1    |
   |        | BitTorrent | having the same  | and T2 machines are able  |
   |        | Overlay    | public IP        | to use the same tracker   |
   |        |            | address, are     | and that no problems are  |
   |        |            | able to connect  | experienced to use the    |
   |        |            | to BitTorrent    | same tracker by T1 and    |
   |        |            | overlay network  | T2.                       |
   +--------+------------+------------------+---------------------------+

                     Connecting to Overlay Test Group

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.





Boucadair, et al.         Expires July 16, 2009                 [Page 7]

Internet-Draft            Port Range BitTorrent             January 2009


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

                             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 July 16, 2009                 [Page 8]

Internet-Draft            Port Range BitTorrent             January 2009


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

                        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.

   +---------+--------------+----------------+-------------------------+
   | Test    | Test Title   | Purpose        | Description             |
   | Index   |              |                |                         |
   +---------+--------------+----------------+-------------------------+
   | Test_5  | Downloading  | Check if two   | Check if distinct files |
   |         | distinct     | terminals,     | available on BitTorrent |
   |         | files        | having the     | infrastructure may be   |
   |         |              | same public IP | downloaded by T1 and T2 |
   |         |              | address, are   | simultaneously          |
   |         |              | able to        |                         |
   |         |              | download       |                         |
   |         |              | distinct files |                         |
   |         |              | available on   |                         |
   |         |              | BitTorrent     |                         |
   |         |              | infrastructure |                         |










Boucadair, et al.         Expires July 16, 2009                 [Page 9]

Internet-Draft            Port Range BitTorrent             January 2009


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





























Boucadair, et al.         Expires July 16, 2009                [Page 10]

Internet-Draft            Port Range BitTorrent             January 2009


   | Test_8  | Simultaneous | Check if it is | In case Test_7 fails,   |
   |         | downloading  | not precluded  | check that it is not    |
   |         | from the     | that a         | precluded that a        |
   |         | same seeder  | different file | different file can be   |
   |         |              | can be         | downloaded by the       |
   |         |              | downloaded by  | waiting client (T1 or   |
   |         |              | the waiting    | T2) from the same       |
   |         |              | client from    | seeder (RT1) at the     |
   |         |              | the same       | same time the other     |
   |         |              | seeder         | 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_9  | Downloading  | Check if the   | Check if T1             |
   |         | distinct     | two terminals  | (respectively T2) can   |
   |         | files from   | having the     | download files uploaded |
   |         | the same     | same public IP | by RT1 (referred to as  |
   |         | seeder       | address are    | TestCaenRF1 and         |
   |         |              | able to        | TestCaenFRTa)           |
   |         |              | download at    | concurrently.           |
   |         |              | the same time  | Particularly, check if  |
   |         |              | two distinct   | T1 can download         |
   |         |              | files from the | TestCaenFRT1 and T2 can |
   |         |              | same seeder    | download TestCaenFRTa   |
   |         |              |                | simultaneously          |
   | Test_10 | Download the | Check if the   | in RT1, launch the      |
   |         | same file    | same file can  | downloading of          |
   |         | located on   | be downloaded  | TestCaenF1.  Check that |
   |         | machines     | by a given     | RT1 is downloading      |
   |         | having the   | machine from   | portions of TestCaenF1  |
   |         | same IP      | seeders having | at the same time from   |
   |         | address      | the same IP    | T1 and T2               |
   |         |              | address        |                         |




Boucadair, et al.         Expires July 16, 2009                [Page 11]

Internet-Draft            Port Range BitTorrent             January 2009


   | Test_11 | Automatic    | Check if the   | In case Test_7 fails,   |
   |         | query to     | terminal which | check that the terminal |
   |         | download the | was waiting    | which was waiting can   |
   |         | same file    | can finally    | finally download the    |
   |         | available on | download the   | file once the other     |
   |         | a single     | file once the  | terminal has finished   |
   |         | machine      | other terminal |                         |
   |         |              | has finished   |                         |
   | Test_12 | Download     | Check if       | Check if RT1 can        |
   |         | distinct     | distinct files | download simultaneously |
   |         | files from   | can be         | TestCaenFa (from T1)    |
   |         | two machines | downloaded by  | and TestCaenFb (from    |
   |         | having the   | the same       | T2)                     |
   |         | same IP      | machine from   |                         |
   |         | address      | seeders having |                         |
   |         |              | the same IP    |                         |
   |         |              | address        |                         |
   +---------+--------------+----------------+-------------------------+

                     Simultaneous Download Test Group


5.  Results

   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
   (1).

   For the testing activities, two configurations have been tested:

   1.  First Configuration: bt.allow_same_ip == TRUE

   2.  Second Configuration: bt.allow_same_ip == FALSE

   The following sub-sections describe the obtained results for each
   configuration.

5.1.  First Configuration: Multiple Connections with the same IP address
      are enabled

   The following table summarises the results of the aforementioned
   tests as performed using the testbed described in Section 4.  Note
   that bt.allow_same_ip is positioned to TRUE.






Boucadair, et al.         Expires July 16, 2009                [Page 12]

Internet-Draft            Port Range BitTorrent             January 2009


   +------------+--------------------------------------+---------------+
   | Test       | Results                              | Comments      |
   | Identifier |                                      |               |
   +------------+--------------------------------------+---------------+
   | Test_1     | No problems have been experienced    | None          |
   | Test_2     | Both T1 and T2 are able to upload    | None          |
   |            | distinct torrent files using the     |               |
   |            | same tracker and the same server     |               |
   | Test_3     | Only one machine can upload a        | The server    |
   |            | torrent file referring to the same   | ensures that  |
   |            | file                                 | only one      |
   |            |                                      | single        |
   |            |                                      | torrent file  |
   |            |                                      | corresponding |
   |            |                                      | to the same   |
   |            |                                      | file is       |
   |            |                                      | listed in its |
   |            |                                      | base          |
   | Test_4     | Three scenarios have been tested:    | None          |
   |            | (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, no   |               |
   |            | problems have been encountered.  The |               |
   |            | downloading operations have          |               |
   |            | succeeded                            |               |
   | Test_5     | Both T1 and T2 are able to download  | None          |
   |            | distinct files from the BitTorrent   |               |
   |            | infrastructure                       |               |
   | Test_6     | Both T1 and T2 are able to download  | None          |
   |            | the same file located in several     |               |
   |            | seeders.  No particular problem has  |               |
   |            | been encountered                     |               |
   | Test_7     | No problem has been encountered.     | None          |
   |            | Both T1 and T2 are able to download  |               |
   |            | TestCaenFRTa from RT1                |               |
   |            | simultaneously.  Note that at the    |               |
   |            | same time, mutual downloading by T1  |               |
   |            | of portions of TestCaenFRTa already  |               |
   |            | downloaded by T2 (and vice versa)    |               |
   |            | have been noticed                    |               |
   | Test_8     | Not applicable                       | None          |






Boucadair, et al.         Expires July 16, 2009                [Page 13]

Internet-Draft            Port Range BitTorrent             January 2009


   | Test_9     | No problem has been encountered.     | None          |
   |            | Distinct files located in RT1 have   |               |
   |            | been successfully downloaded by T1   |               |
   |            | (respectively T2)                    |               |
   | Test_10    | No problem has been encountered      | None          |
   | Test_11    | Not applicable                       | Not           |
   |            |                                      | applicable    |
   | Test_12    | No problem has been encountered.     | None          |
   |            | RT1 has succeeded to download        |               |
   |            | simultaneously TestCaenFa (from T1)  |               |
   |            | and TestCaenFb (from T2)             |               |
   +------------+--------------------------------------+---------------+

                   First Configuration Obtained Results

5.2.  Second Configuration: Multiple Connections with the same IP
      address are disabled

   The following table summarises the results of the aforementioned
   tests as performed using the testbed described in Section 4.  Note
   that bt.allow_same_ip is positioned to FALSE.

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













Boucadair, et al.         Expires July 16, 2009                [Page 14]

Internet-Draft            Port Range BitTorrent             January 2009


   | Test_4     | Three scenarios have  | None                              |
   |            | 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, no   |                                   |
   |            | problems have been    |                                   |
   |            | encountered.  The     |                                   |
   |            | downloading           |                                   |
   |            | operations have       |                                   |
   |            | succeeded             |                                   |
   | Test_5     | Both T1 and T2 are    | None                              |
   |            | able to download      |                                   |
   |            | distinct files from   |                                   |
   |            | the BitTorrent        |                                   |
   |            | infrastructure        |                                   |
   | Test_6     | Both T1 and T2 are    | When TestCaenFRT1 is used as      |
   |            | able to download the  | example.  T1 and T2 are able to   |
   |            | same file located in  | download the same file.  But for  |
   |            | several seeders.  No  | each file it is sending (here     |
   |            | particular problem    | TestCaenFRT1) RT1 can allow no    |
   |            | has been encountered  | more than one unique connection   |
   |            |                       | to the same address IP.  This is  |
   |            |                       | the same behaviour for RT2.  T1   |
   |            |                       | and T2 exchanges the portions of  |
   |            |                       | the files they stored             |
















Boucadair, et al.         Expires July 16, 2009                [Page 15]

Internet-Draft            Port Range BitTorrent             January 2009


   | Test_7     | Both T1 and T2 are    | This is because for each file it  |
   |            | able to download the  | is sending (here TestCaenFRTa)    |
   |            | file but only one     | RT1 can allow no more than one    |
   |            | single connection is  | unique connection to the same     |
   |            | accepted by RT1 at    | address IP.  The result is that,  |
   |            | the same time         | 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.  |
   |            |                       | However, that does not preclude   |
   |            |                       | the waiting terminal (T2 or T1)   |
   |            |                       | to download from the other        |
   |            |                       | terminal (T1 or T2) portions of   |
   |            |                       | TestCaenFRTa already downloaded   |
   |            |                       | from RT1                          |
   | Test_8     | The test 8 has        | While T1 has been downloading     |
   |            | succeeded             | TestCaenFRT1 from RT1, T2 could   |
   |            |                       | download TestCaenFRTa from RT1    |
   |            |                       | and in addition it can get        |
   |            |                       | portions of TestCaenFRTa already  |
   |            |                       | downloaded by T1                  |
   | Test_9     | No problem have been  | None                              |
   |            | experienced           |                                   |
   | Test_10    | Both T1 and T2 are    | The test failed because, once RT1 |
   |            | able to upload the    | has begun to download portions of |
   |            | file, but only one    | TestCaenF1 from T1 (respectively  |
   |            | connection is         | T2) it cannot accept additional   |
   |            | accepted by RT1 at    | connection with T2 for the same   |
   |            | the same time         | file                              |
   | Test_11    | The test succeeded    | Once T1 has completed its         |
   |            |                       | downloading from RT1, T2 has been |
   |            |                       | able automatically to connect to  |
   |            |                       | RT1 for receiving the portions of |
   |            |                       | TestCaenFRTa it has not already   |
   |            |                       | got from T2                       |
   | Test_12    | No problem has been   | None                              |
   |            | encountered.  RT1 has |                                   |
   |            | succeeded to download |                                   |
   |            | simultaneously        |                                   |
   |            | TestCaenFa (from T1)  |                                   |
   |            | and TestCaenFb (from  |                                   |
   |            | T2)                   |                                   |
   +------------+-----------------------+-----------------------------------+




Boucadair, et al.         Expires July 16, 2009                [Page 16]

Internet-Draft            Port Range BitTorrent             January 2009


                  Results: Multiple connections desiabled


6.  Conclusions

   This memo describes the main behaviour of BitTorrent service in an IP
   shared address environment.  Particularly, the tests have been
   carried out on a testbed implementing [ID.boucadair-port-range]
   solution.  The results are, however, valid for all IP shared address
   based solutions.

   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 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.

   Mutual file sharing between hosts having the same IP address has been
   checked.  Indeed, machines having the same IP address can share files
   with no alteration compared to current IP architectures.


7.  IANA Considerations

   This document raises no IANA considerations.







Boucadair, et al.         Expires July 16, 2009                [Page 17]

Internet-Draft            Port Range BitTorrent             January 2009


8.  Security Considerations

   This memo does not introduce any security issue.


9.  Acknowledgements

   The authors would like to thank Dan WING for suggesting the writing
   of this memo and for the review of the text.


10.  References

10.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [ID.bajko-v6ops-port-restricted-ipaddr-assign]
              Bajko, G. and T. Savolainen, "Port Restricted IP Address
              Assignment", Internet Draft, draft-bajko-v6ops-port-
              restricted-ipaddr-assign-02.txt (work in progress),
              November 2008.

   [ID.boucadair-dhc-port-range]
              Boucadair, M., Grimault, J-L., Levis, P., and A.
              Villefranque, "DHCP Options for Conveying Port Mask and
              Port Range Router IP Address", Internet
              Draft, draft-boucadair-dhc-port-range-01.txt (work in
              progress), October 2008.

   [ID.boucadair-port-range]
              Boucadair, M., Grimault, J-L., Levis, P., and A.
              Villefranque, "Provider-Provisioned CPE: IPv4 Connectivity
              Access in the context of IPv4 address exhaustion",
              Internet Draft, draft-boucadair-port-range-00.txt (work in
              progress), October 2008.

   [ID.despres-sam]
              Despres, R., "Stateless Address Mappings (SAMs) IPv6 &
              extended IPv4 via local routing domains - possibly
              multihomed", Internet Draft, draft-despres-sam-01.txt
              (work in progress), November 2008.



Boucadair, et al.         Expires July 16, 2009                [Page 18]

Internet-Draft            Port Range BitTorrent             January 2009


   [ID.durand-softwire-dual-stack-lite]
              Durand , A., Droms, R., Haberman, B., and J. Woodyatt,
              "Dual-stack lite broadband deployments post IPv4
              exhaustion", Internet
              Draft, draft-durand-softwire-dual-stack-lite-01.txt (work
              in progress), November 2008.

   [ID.ymbk-aplusp]
              Maennel , O., Bush, R., Cittadini, L., and S. Bellovin ,
              "The A+P Approach to the Broadband Provider IPv4 Address
              Shortage", Internet Draft, draft-ymbk-aplusp-01.txt (work
              in progress), November 2008.


Authors' Addresses

   Mohamed Boucadair (editor)
   France Telecom
   42 rue des Coutures
   BP 6243
   Caen Cedex 4  14066
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Jean-Luc Grimault
   France Telecom

   Email: jeanluc.grimault@orange-ftgroup.com


   Pierre Levis
   France Telecom

   Email: pierre.levis@orange-ftgroup.com


   Alain Villefranque
   France Telecom

   Email: alain.villefranque@orange-ftgroup.com









Boucadair, et al.         Expires July 16, 2009                [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/