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]