idnits 2.17.1 draft-boucadair-pcp-bittorrent-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 835 has weird spacing: '...itation occur...' == Line 849 has weird spacing: '...itation occur...' -- The document date (May 4, 2012) is 4368 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-24 == Outdated reference: A later version (-10) exists of draft-ietf-pcp-upnp-igd-interworking-01 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-06 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP WG M. Boucadair, Ed. 3 Internet-Draft France Telecom 4 Intended status: Informational T. Zheng 5 Expires: November 5, 2012 P. NG Tung 6 X. Deng 7 J. Queiroz 8 Orange Labs 9 May 4, 2012 11 Behavior of BitTorrent service in PCP-enabled networks with Address 12 Sharing 13 draft-boucadair-pcp-bittorrent-00.txt 15 Abstract 17 This document describes the behavior of BitTorrent service in the 18 context of PCP-enabled address sharing functions. It provides an 19 overview of the used testbed and main results of the tests that have 20 been conducted in order to assess the limitations of an architecture 21 based on shared IP addresses. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 5, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. BitTorent Overview . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. BitTorrent at a Glance . . . . . . . . . . . . . . . . . . 3 60 2.2. Software Configuration . . . . . . . . . . . . . . . . . . 4 61 2.2.1. BitTorrent Client . . . . . . . . . . . . . . . . . . 4 62 2.2.2. BitTorrent Server . . . . . . . . . . . . . . . . . . 4 63 2.2.3. BitTorrent Tracker . . . . . . . . . . . . . . . . . . 4 64 3. Testbed Overview . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Testbed Description . . . . . . . . . . . . . . . . . . . 4 66 3.2. Files . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Methodology . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Description of Tests . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Connection to Overlay Test Group . . . . . . . . . . . . . 6 70 4.2. Upload Test Group . . . . . . . . . . . . . . . . . . . . 7 71 4.3. Mutual Download Test Group . . . . . . . . . . . . . . . . 7 72 4.4. Simultaneous Download Test Group . . . . . . . . . . . . . 8 73 5. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.1. Allow Same IP Address & PCP Disabled . . . . . . . . . . . 11 75 5.2. Forbid Same IP Address & PCP Disabled . . . . . . . . . . 13 76 5.3. Allow Same IP Address & PCP Enabled . . . . . . . . . . . 15 77 5.4. Forbid Same IP Address & PCP Enabled . . . . . . . . . . 17 78 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 Recently, several proposals have been disseminated within IETF to 89 allow for IPv4 service continuity. These solutions share the same IP 90 address among several subscribers (e.g., CGN (Carrier Grade NAT) 91 [I-D.ietf-behave-lsn-requirements] or A+P [RFC6346]) 93 Several issues are encountered in address sharing context as 94 elaborated in [RFC6269]. 96 This memo focuses on BitTorrent as an example of application which 97 applies a restriction based on IP address. This memo describes a 98 testing campaign that has been carried out to assess the impact of IP 99 shared address on BitTorrent. 101 A particular focus has been put on the impact of activating port 102 forwarding (using PCP [I-D.ietf-pcp-base]) on the download speed. 104 2. BitTorent Overview 106 2.1. BitTorrent at a Glance 108 BitTorrent is a distributed file sharing infrastructure. It is based 109 on P2P (Peer to Peer) techniques for exchanging files between 110 connected users. Three parties are involved in a BitTorrent 111 architecture as detailed hereafter: 113 1. The Server: The server into which, has been uploaded the torrent 114 file. 116 2. The Tracker: Maintains a list of clients which have the file or 117 some portions of that file. 119 3. The Client: Entities which are downloading and/or uploading 120 portions of the file. Two categories of clients may be 121 distinguished: 123 A. Leechers: Clients which are currently downloading the file 124 but do not yet detain all the portions of the file. As for 125 the portions already obtained, the leechers upload them 126 towards requesting clients; 128 B. Seeders: Clients which detain all the portions of the file 129 and are uploading them to other requesting clients. 131 A torrent file is a file which includes the meta-data information of 132 the file to be shared: the file name, its length, a hash and the URL 133 of the tracker. In order to download a given file, a BitTorrent 134 client needs to obtain the corresponding torrent file. Afterwards, 135 it connects to the tracker to retrieve a list of leechers and 136 seeders. Then, the client connects to those machines and downloads 137 the available portions of the requested file. It uploads also the 138 portions already obtained towards requesting clients. 140 2.2. Software Configuration 142 This section provides an overview of installed tools. 144 2.2.1. BitTorrent Client 146 Various BitTorrent clients are available for public use. The 147 following one has been installed for the purposes of our testing 148 activities: 150 URL: www.bittorrent.com 152 2.2.2. BitTorrent Server 154 The BitTorrent server that has been used is the following: 156 URL: www.torrentbox.com 158 2.2.3. BitTorrent Tracker 160 The BitTorrent tracker that has been used is the following: 162 URL: tracker.torrentbox.com:2710/announce 164 3. Testbed Overview 166 3.1. Testbed Description 168 The testbed used to conduct the testing activities is illustrated in 169 the figure below: 171 o The CGN DS-Lite which is responsible to share the same IP address 172 among several subscribers. The CGN embeds a PCP Server. 174 o CPE-1 and CPE-2 are two CPEs sharing the same IP address (by the 175 CGN). Each CPE embeds a IGD/PCP IWF 176 [I-D.ietf-pcp-upnp-igd-interworking]. 178 o T1 (respectively T2) is a machine located in the LAN behind CPE-1 179 (respectively CPE-2). No NAT is enabled in CPE-1 and CPE-2. 181 o RT1 and RT2 are remote machines reachable through Internet. RT1 182 and RT2 are assigned with public IP addresses. 184 +-------+ +-------+ +------------+ +----------+ 185 | | | CPE-1 | | Service | | | 186 | T1 |----|IGD/PCP|----| Provider | | | 187 | | | IWF | | Domain | | | +---------+ 188 +-------+ +-------+ | | | | | Remote | 189 | | | +----+ Terminal| 190 |+----------+| | | | (RT1) | 191 || CGN || | | +---------+ 192 ||PCP Server|| | | 193 |+----------+| | | 194 | +--+ Internet | 195 | | | | 196 | | | | 197 | | | | +---------+ 198 | | | | | Remote | 199 | | | +----+ Terminal| 200 +-------+ +-------+ | | | | | (RT2) | 201 | | | CPE-2 | | | | | +---------+ 202 | T2 |----|IGD/PCP|----| | | | 203 | | | IWF | | | | | 204 +-------+ +-------+ +------------+ +----------+ 206 Figure 1: Testbed Overview 208 3.2. Files 210 The following table lists the files available in each machine: 212 +-----------------+-------------------------------+ 213 | Machine' s name | Available files | 214 +-----------------+-------------------------------+ 215 | T1 | TestCaenF1 and TestCaenFa | 216 | T2 | TestCaenF1 and TestCaenFb | 217 | RT1 | TestCaenFRT1 and TestCaenFRTa | 218 | RT2 | TestCaenFRT1 and TestCaenFRTb | 219 +-----------------+-------------------------------+ 221 Table 1: Available files 223 3.3. Methodology 225 BitTorrent client can be configured to accept multiple connections 226 using the same IP address. A dedicated parameter can therefore be 227 positioned. This parameter is called: bt.allow_same_ip. Possible 228 values that can be taken by this parameter are: FALSE (0) or TRUE 229 (1). 231 Tests are conducted using four configurations: 233 +---------------+--------------------------+----------+ 234 | Configuration | bt.allow_same_ip | PCP | 235 +---------------+--------------------------+----------+ 236 | Section 5.1 | TRUE in all machines | Disabled | 237 | | (T1, T2, RT1, RT2) | | 238 +---------------+--------------------------+----------+ 239 | Section 5.2 | FALSE in all machines | Disabled | 240 | | (T1, T2, RT1, RT2) | | 241 +---------------+--------------------------+----------+ 242 | Section 5.3 | TRUE in all machines | Enabled | 243 | | (T1, T2, RT1, RT2) | | 244 +---------------+--------------------------+----------+ 245 | Section 5.4 | TRUE in all machines | Enabled | 246 | | (T1, T2, RT1, RT2) | | 247 +---------------+--------------------------+----------+ 249 When PCP is disabled, all port forwarding entries are flushed out. 251 4. Description of Tests 253 This section lists the tests that have been conducted. 255 4.1. Connection to Overlay Test Group 257 This table lists the test to assess the ability of distinct machines 258 having the same IP address to connect to BitTorrent overlay. 260 +--------+------------+---------------------------------------------+ 261 | Test | Test Title | Purpose & Description | 262 | Index | | | 263 +--------+------------+---------------------------------------------+ 264 | Test_1 | Connection | Check if two terminals, having the same | 265 | | to | public IP address, are able to connect to | 266 | | BitTorrent | BitTorrent overlay network. Check if | 267 | | Overlay | BitTorrent client installed on T1 and T2 | 268 | | | machines are able to use the same tracker | 269 | | | and that no problems are experienced to use | 270 | | | the same tracker by T1 and T2. | 271 +--------+------------+---------------------------------------------+ 273 Connecting to Overlay Test Group 275 4.2. Upload Test Group 277 This test group aims at checking if upload operations are not 278 impacted/restricted due to the presence of several machines with the 279 same IP address. 281 +--------+------------+---------------------------------------------+ 282 | Test | Test Title | Purpose & Description | 283 | Index | | | 284 +--------+------------+---------------------------------------------+ 285 | Test_2 | Uploading | Check if two terminals, having the same | 286 | | distinct | public IP address, are able to upload | 287 | | files | torrent files (referring to distinct files) | 288 | | using the | using the same tracker and same server. | 289 | | same | Check if torrent files may be uploaded from | 290 | | BitTorrent | T1 and T2 using the same tracker. On T1 | 291 | | tracker | (resp. T2), generate a torrent file | 292 | | and server | TestCaenFa.torrent (resp. | 293 | | | TestCaenFb.torrent) referring to the file | 294 | | | TestCaenFa (resp. TestCaenFb) and pointing | 295 | | | to the tracker TRA. From T1 (resp. T2) try | 296 | | | to put TestCaenFa.torrent (resp. | 297 | | | TestCaenFb.torrent) onto server S. Check if | 298 | | | the upload operation has succeeded | 299 +--------+------------+---------------------------------------------+ 300 | Test_3 | Uploading | Check if two terminals, having the same | 301 | | torrent | public IP address, are able to upload | 302 | | files | torrent files, which refer to the same | 303 | | referring | file, using the same tracker. On T1 (resp. | 304 | | to the | T2), generate a torrent file | 305 | | same file | TestCaenF1.torrent (resp. | 306 | | | TestCaenF1.torrent) referring to the file | 307 | | | TestCaenF1 and pointing to the tracker TRA. | 308 | | | From T1 (resp. T2) try to put | 309 | | | TestCaenF1.torrent (resp. | 310 | | | TestCaenF1.torrent) onto server S. Check if | 311 | | | the upload operation has succeeded | 312 +--------+------------+---------------------------------------------+ 314 Upload Test Group 316 4.3. Mutual Download Test Group 318 The purpose of this test group is to check if mutual downloading 319 operations can occur between machines having the same IP address. 321 +--------+-------------+--------------------------------------------+ 322 | Test | Test Title | Purpose & Description | 323 | Index | | | 324 +--------+-------------+--------------------------------------------+ 325 | Test_4 | Mutual | Check if two terminals having the same | 326 | | Downloading | public IP address can download a file from | 327 | | between | each another. Check if T1 can download | 328 | | machines | the file uploaded by T2 (ref. Test_2) and | 329 | | sharing the | vice versa. Three scenarios are to be | 330 | | same IP | tested: (1) T1 downloads TestCaenFb but T2 | 331 | | address | does not download any file from T1, (2) T2 | 332 | | | downloads TestCaenFa but T1 does not | 333 | | | download any file from T2, (3) T1 | 334 | | | downloads TestCaenFb and T2 downloads | 335 | | | TestCaenFa at the same time | 336 +--------+-------------+--------------------------------------------+ 337 | Test_5 | Mutual | Check if two terminals located behind an | 338 | | Downloading | address sharing function but assigned with | 339 | | between | distinct public IP addresses can download | 340 | | machines | a file from each another. Check if T1 can | 341 | | located | download the file uploaded by T2 (ref. | 342 | | behind an | Test_2) and vice versa. | 343 | | address | | 344 | | sharing | | 345 | | function | | 346 +--------+-------------+--------------------------------------------+ 348 Mutual Download Test Group 350 4.4. Simultaneous Download Test Group 352 This test group aims at checking if simultaneous downloading 353 operations from remote seed(s)/leecher(s) can be performed by several 354 machines sharing the same IP address. 356 +---------+--------------+------------------------------------------+ 357 | Test | Test Title | Purpose & Description | 358 | Index | | | 359 +---------+--------------+------------------------------------------+ 360 | Test_6 | Downloading | Check if two terminals, having the same | 361 | | distinct | public IP address, are able to download | 362 | | files | distinct files available on BitTorrent | 363 | | | infrastructure. Check if distinct files | 364 | | | available on BitTorrent infrastructure | 365 | | | may be downloaded by T1 and T2 | 366 | | | simultaneously | 367 +---------+--------------+------------------------------------------+ 368 | Test_7 | Downloading | Check if two terminals, having the same | 369 | | the same | public IP address, are able to download | 370 | | file located | the same file located on several | 371 | | on several | seeders. Check if a file available on | 372 | | seeders | several seeders may be downloaded from | 373 | | | T1 and T2 simultaneously. As an | 374 | | | example, check if T1 and T2 can download | 375 | | | the same file located in RT1 and RT2 | 376 | | | (referred to as TestCaenFRT1) | 377 +---------+--------------+------------------------------------------+ 378 | Test_8 | Download the | Check if two terminals having the same | 379 | | same file | public IP address are able to download, | 380 | | available on | at the same time, the same file | 381 | | a single | available on a single seed. Check if T1 | 382 | | machine | and T2 can download the same file | 383 | | | uploaded by RT1 (referred to as | 384 | | | TestCaenFRTa) concurrently. In case the | 385 | | | test fails, one of the two host is | 386 | | | called the "waiting client" | 387 +---------+--------------+------------------------------------------+ 388 +---------+--------------+------------------------------------------+ 389 | Test_9 | Simultaneous | Check if it is not precluded that a | 390 | | downloading | different file can be downloaded by the | 391 | | from the | waiting client from the same seeder. In | 392 | | same seeder | case Test_7 fails, check that it is not | 393 | | | precluded that a different file can be | 394 | | | downloaded by the waiting client (T1 or | 395 | | | T2) from the same seeder (RT1) at the | 396 | | | same time the other terminal | 397 | | | (respectively T2 or T1) is downloading | 398 | | | TestCaenFRTa. Execute Test_7 in | 399 | | | launching on T1 the downloading of | 400 | | | TestCaenFRT1 and just few seconds | 401 | | | afterwards in launching on T2 the | 402 | | | downloading of TestCaenFRT1 and | 403 | | | TestCaenFRTa. Check that while T1 is | 404 | | | downloading TestCaenFRT1 that does not | 405 | | | preclude T2 to concurrently download | 406 | | | TestCaenFRTa. | 407 +---------+--------------+------------------------------------------+ 408 | Test_10 | Downloading | Check if the two terminals having the | 409 | | distinct | same public IP address are able to | 410 | | files from | download at the same time two distinct | 411 | | the same | files from the same seeder. Check if T1 | 412 | | seeder | (respectively T2) can download files | 413 | | | uploaded by RT1 (referred to as | 414 | | | TestCaenRF1 and TestCaenFRTa) | 415 | | | concurrently. Particularly, check if T1 | 416 | | | can download TestCaenFRT1 and T2 can | 417 | | | download TestCaenFRTa simultaneously | 418 +---------+--------------+------------------------------------------+ 419 | Test_11 | Download the | Check if the same file can be downloaded | 420 | | same file | by a given machine from seeders having | 421 | | located on | the same IP address. In RT1, launch the | 422 | | machines | downloading of TestCaenF1. Check that | 423 | | having the | RT1 is downloading portions of | 424 | | same IP | TestCaenF1 at the same time from T1 and | 425 | | address | T2 | 426 +---------+--------------+------------------------------------------+ 427 | Test_12 | Automatic | Check if the terminal which was waiting | 428 | | query to | can finally download the file once the | 429 | | download the | other terminal has finished. In case | 430 | | same file | Test_7 fails, check that the terminal | 431 | | available on | which was waiting can finally download | 432 | | a single | the file once the other terminal has | 433 | | machine | finished | 434 +---------+--------------+------------------------------------------+ 435 +---------+--------------+------------------------------------------+ 436 | Test_13 | Download | Check if distinct files can be | 437 | | distinct | downloaded by the same machine from | 438 | | files from | seeders having the same IP address. | 439 | | two machines | Check if RT1 can download simultaneously | 440 | | having the | TestCaenFa (from T1) and TestCaenFb | 441 | | same IP | (from T2) | 442 | | address | | 443 +---------+--------------+------------------------------------------+ 445 Simultaneous Download Test Group 447 5. Results 449 The following tables summarize the results of the tests listed in 450 Section 4 as performed using the testbed described in Section 3. 451 Four configurations have been tested as documented in Section 3.3. 453 5.1. Allow Same IP Address & PCP Disabled 455 The following table summarizes the results of the tests when 456 "bt.allow_same_ip == TRUE" in all involved BitTorrent clients and PCP 457 is disabled. 459 +---------+-------------------------------------------+-------------+ 460 | Index | Results | Downloading | 461 | | | Speed | 462 +---------+-------------------------------------------+-------------+ 463 | Test_1 | No problems have been experienced | | 464 +---------+-------------------------------------------+-------------+ 465 | Test_2 | Both T1 and T2 are able to upload | | 466 | | distinct torrent files using the same | | 467 | | tracker and the same server. | | 468 +---------+-------------------------------------------+-------------+ 469 | Test_3 | Only one machine can upload a torrent | | 470 | | file referring to the same file. The | | 471 | | server ensures that only one single | | 472 | | torrent file corresponding to the same | | 473 | | file is listed in its base. | | 474 +---------+-------------------------------------------+-------------+ 475 +---------+-------------------------------------------+-------------+ 476 | Test_4 | Three scenarios have been tested: (1) T1 | | 477 | | downloads TestCaenFb but T2 does not | | 478 | | download any file from T1 (2) T2 | | 479 | | downloads TestCaenFa but T1 does not | | 480 | | download any file from T2 (3) T1 | | 481 | | downloads TestCaenFb and T2 downloads | | 482 | | TestCaenFa in the same time. For all | | 483 | | these scenarios, mutual downloading | | 484 | | between T1 and T2 is not observed. | | 485 +---------+-------------------------------------------+-------------+ 486 | Test_5 | No mutual downloading between T1 and T2 | | 487 | | was observed. | | 488 +---------+-------------------------------------------+-------------+ 489 | Test_6 | Both T1 and T2 are able to download | T1: | 490 | | distinct files from the BitTorrent | 50-110KBps; | 491 | | infrastructure. | T2: | 492 | | | 60-80KBps | 493 +---------+-------------------------------------------+-------------+ 494 | Test_7 | Both T1 and T2 are able to download the | T1 and T2: | 495 | | same file located in several seeders. | 50-70KBps | 496 | | Mutual downloading between T1 and T2 is | | 497 | | not observed. | | 498 +---------+-------------------------------------------+-------------+ 499 | Test_8 | Both T1 and T2 are able to download | T1: | 500 | | TestCaenFRTa from RT1 simultaneously. | 50-70KBps; | 501 | | Mutual downloading between T1 and T2 is | T2: | 502 | | not observed. | 40-80KBps | 503 +---------+-------------------------------------------+-------------+ 504 | Test_9 | Not applicable | | 505 +---------+-------------------------------------------+-------------+ 506 | Test_10 | No problem has been encountered. | T1: | 507 | | Distinct files located in RT1 have been | 30-90KBps; | 508 | | successfully downloaded by T1 | T2: | 509 | | (respectively T2). | 50-80KBps | 510 +---------+-------------------------------------------+-------------+ 511 | Test_11 | No problem has been encountered. RT1 is | RT1: | 512 | | able to download TestCaenF1 from T1 and | 60-100KBps | 513 | | T2 simultaneously. | | 514 +---------+-------------------------------------------+-------------+ 515 | Test_12 | Not applicable | | 516 +---------+-------------------------------------------+-------------+ 517 | Test_13 | No problem has been encountered. RT1 has | RT1: | 518 | | succeeded to download simultaneously | 30-50KBps | 519 | | TestCaenFa (from T1) and TestCaenFb (from | from T1 and | 520 | | T2). | 30-40KBps | 521 | | | from T2 | 522 +---------+-------------------------------------------+-------------+ 523 Table 2: Allow Same IP & PCP Disabled 525 5.2. Forbid Same IP Address & PCP Disabled 527 The following table summarizes the results of the tests when 528 "bt.allow_same_ip == FALSE" in all involved BitTorrent clients and 529 PCP is disabled. 531 +---------+-----------------------------------------+---------------+ 532 | Index | Results | Downloading | 533 | | | Speed | 534 +---------+-----------------------------------------+---------------+ 535 | Test_1 | No problems have been experienced | | 536 +---------+-----------------------------------------+---------------+ 537 | Test_2 | Both T1 and T2 are able to upload | | 538 | | distinct torrent files using the same | | 539 | | tracker and the same server. | | 540 +---------+-----------------------------------------+---------------+ 541 | Test_3 | Only one machine can upload a torrent | | 542 | | file referring to the same file. The | | 543 | | server ensures that only one single | | 544 | | torrent file corresponding to the same | | 545 | | file is listed in its base. | | 546 +---------+-----------------------------------------+---------------+ 547 | Test_4 | Three scenarios have been tested: (1) | | 548 | | T1 downloads TestCaenFb but T2 does not | | 549 | | download any file from T1 (2) T2 | | 550 | | downloads TestCaenFa but T1 does not | | 551 | | download any file from T2 (3) T1 | | 552 | | downloads TestCaenFb and T2 downloads | | 553 | | TestCaenFa in the same time. For all | | 554 | | these scenarios, mutual downloading | | 555 | | between T1 and T2 is not observed. | | 556 +---------+-----------------------------------------+---------------+ 557 | Test_5 | No mutual downloading between T1 and T2 | | 558 | | was observed. | | 559 +---------+-----------------------------------------+---------------+ 560 | Test_6 | Both T1 and T2 are able to download | T1: | 561 | | distinct files from the BitTorrent | 50-110KBps | 562 | | infrastructure. | T2: 60-80KBps | 563 +---------+-----------------------------------------+---------------+ 564 +---------+-----------------------------------------+---------------+ 565 | Test_7 | Both T1 and T2 are able to download the | T1 | 566 | | same file located in several seeders. | :100-120KBps, | 567 | | But for each file it is sending (here | After T1 | 568 | | TestCaenFRT1) RT1 can allow no more | finished, T2 | 569 | | than one unique connection to the same | started | 570 | | address IP. This is the same behavior | 100-120KBps | 571 | | for RT2. Mutual downloading between T1 | | 572 | | and T2 is not observed. | | 573 +---------+-----------------------------------------+---------------+ 574 | Test_8 | Both T1 and T2 are able to download the | T1: | 575 | | file but only one single connection is | 70-100KBps | 576 | | accepted by RT1 at the same time. This | | 577 | | is because for each file it is sending | | 578 | | (here TestCaenFRTa) RT1 can allow no | | 579 | | more than one unique connection to the | | 580 | | same address IP. The result is that, | | 581 | | once T1 (or T2) has begun to download | | 582 | | TestCaenFRTa, the other terminal (T2 or | | 583 | | respectively T1) cannot get any portion | | 584 | | of TestCaenFRTa directly from RT1 till | | 585 | | the other (T1 or respectively T2) has | | 586 | | completed the downloading of | | 587 | | TestCaenFRTa. Mutual downloading | | 588 | | between T1 and T2 is not observed. | | 589 +---------+-----------------------------------------+---------------+ 590 | Test_9 | The test has succeeded. While T1 has | T1: 50-70KBps | 591 | | been downloading TestCaenFRT1 from RT1, | T2: 40-50KBps | 592 | | T2 could download TestCaenFRTa from RT1 | | 593 | | and in addition it can get portions of | | 594 | | TestCaenFRTa already downloaded by T1. | | 595 +---------+-----------------------------------------+---------------+ 596 | Test_10 | No problem has been encountered. | T1: 50-70KBps | 597 | | Distinct files located in RT1 have been | T2: 40-60KBps | 598 | | successfully downloaded by T1 | | 599 | | (respectively T2). | | 600 +---------+-----------------------------------------+---------------+ 601 | Test_11 | Both T1 and T2 are able to upload the | RT1: | 602 | | file, but only one connection is | 20-40KBps | 603 | | accepted by RT1 at the same time. The | from T1 | 604 | | test failed because, once RT1 has begun | | 605 | | to download portions of TestCaenF1 from | | 606 | | T1 (respectively T2) it cannot accept | | 607 | | additional connection with T2 for the | | 608 | | same file. | | 609 +---------+-----------------------------------------+---------------+ 610 +---------+-----------------------------------------+---------------+ 611 | Test_12 | The test succeeded. Once T1 has | T2: | 612 | | completed its downloading from RT1, T2 | 80-100KBps | 613 | | has been able automatically to connect | | 614 | | to RT1 for receiving the same file. | | 615 +---------+-----------------------------------------+---------------+ 616 | Test_13 | No problem has been encountered. RT1 | RT1: | 617 | | has succeeded to download | 30-50KBps | 618 | | simultaneously TestCaenFa (from T1) and | from T1 and | 619 | | TestCaenFb (from T2). | 30-50KBps | 620 | | | from T2 | 621 +---------+-----------------------------------------+---------------+ 623 Table 3: Forbid Same IP & PCP Disabled 625 5.3. Allow Same IP Address & PCP Enabled 627 The following table summarizes the results of the tests when 628 "bt.allow_same_ip == TRUE" in all involved BitTorrent clients and PCP 629 is enabled. 631 +---------+---------------------------------------+-----------------+ 632 | Index | Results | Downloading | 633 | | | Speed | 634 +---------+---------------------------------------+-----------------+ 635 | Test_1 | No problems have been experienced | | 636 +---------+---------------------------------------+-----------------+ 637 | Test_2 | Both T1 and T2 are able to upload | | 638 | | distinct torrent files using the same | | 639 | | tracker and the same server. | | 640 +---------+---------------------------------------+-----------------+ 641 | Test_3 | Only one machine can upload a torrent | | 642 | | file referring to the same file. The | | 643 | | server ensures that only one single | | 644 | | torrent file corresponding to the | | 645 | | same file is listed in its base | | 646 +---------+---------------------------------------+-----------------+ 647 | Test_4 | Three scenarios have been tested: (1) | (1)T1: | 648 | | T1 downloads TestCaenFb but T2 does | 1.4-1.5MBps | 649 | | not download any file from T1 (2) T2 | (2)T2: | 650 | | downloads TestCaenFa but T1 does not | 1.4-1.5MBps | 651 | | download any file from T2 (3) T1 | (3)T1 and T2: | 652 | | downloads TestCaenFb and T2 downloads | 600-800KBps | 653 | | TestCaenFa in the same time. For all | | 654 | | these scenarios, no problems have | | 655 | | been encountered. The downloading | | 656 | | operations have succeeded. | | 657 +---------+---------------------------------------+-----------------+ 658 +---------+---------------------------------------+-----------------+ 659 | Test_5 | The mutual downloading operations | T1/T2: | 660 | | have succeeded | 1.4-1.5MBps | 661 +---------+---------------------------------------+-----------------+ 662 | Test_6 | Both T1 and T2 are able to download | T1: 100-110KBps | 663 | | distinct files from the BitTorrent | T2: 60-80KBps | 664 | | infrastructure. | | 665 +---------+---------------------------------------+-----------------+ 666 | Test_7 | Both T1 and T2 are able to download | T1 and T2: | 667 | | the same file located in several | normal speed is | 668 | | seeders. Mutual downloading by T1 of | 90-140KBps (the | 669 | | portions of TestCaenFRT1 already | highest is | 670 | | downloaded by T2 (and vice versa) has | 800KBps), | 671 | | been observed. | between T1 and | 672 | | | T2, the normal | 673 | | | speed is | 674 | | | 50-70KBps (the | 675 | | | highest is | 676 | | | 700KBps) | 677 +---------+---------------------------------------+-----------------+ 678 | Test_8 | Both T1 and T2 are able to download | T1 and T2: | 679 | | TestCaenFRTa from RT1 simultaneously. | normal speed is | 680 | | Mutual downloading by T1 of portions | 80-110KBps(the | 681 | | of TestCaenFRTa already downloaded by | highest is | 682 | | T2 (and vice versa) has been | 700KBps), | 683 | | observed. | between T1 and | 684 | | | T2, the normal | 685 | | | speed is | 686 | | | 40-50KBps (the | 687 | | | highest is | 688 | | | 600KBps) | 689 +---------+---------------------------------------+-----------------+ 690 | Test_9 | Not applicable | | 691 +---------+---------------------------------------+-----------------+ 692 | Test_10 | No problem has been encountered. | T1: 50-70KBps | 693 | | Distinct files located in RT1 have | T2: 40-70KBps | 694 | | been successfully downloaded by T1 | | 695 | | (respectively T2). | | 696 +---------+---------------------------------------+-----------------+ 697 | Test_11 | No problem has been encountered. RT1 | RT1: 60-80KBps | 698 | | is able to download TestCaenF1 from | | 699 | | T1 and T2 simultaneously. | | 700 +---------+---------------------------------------+-----------------+ 701 | Test_12 | Not applicable | | 702 +---------+---------------------------------------+-----------------+ 703 +---------+---------------------------------------+-----------------+ 704 | Test_13 | No problem has been encountered. RT1 | RT1: 30-50KBps | 705 | | has succeeded to download | from T1 and | 706 | | simultaneously TestCaenFa (from T1) | 30-40KBps from | 707 | | and TestCaenFb (from T2). | T2 | 708 +---------+---------------------------------------+-----------------+ 710 Table 4: Allow Same IP & PCP Enabled 712 5.4. Forbid Same IP Address & PCP Enabled 714 The following table summarizes the results of the tests when 715 "bt.allow_same_ip == FALSE" in all involved BitTorrent clients and 716 PCP is enabled. 718 +---------+------------------------------------------+--------------+ 719 | Index | Results | Downloading | 720 | | | Speed | 721 +---------+------------------------------------------+--------------+ 722 | Test_1 | No problems have been experienced | | 723 +---------+------------------------------------------+--------------+ 724 | Test_2 | Both T1 and T2 are able to upload | | 725 | | distinct torrent files using the same | | 726 | | tracker and the same server. | | 727 +---------+------------------------------------------+--------------+ 728 | Test_3 | Only one machine can upload a torrent | | 729 | | file referring to the same file. The | | 730 | | server ensures that only one single | | 731 | | torrent file corresponding to the same | | 732 | | file is listed in its base. | | 733 +---------+------------------------------------------+--------------+ 734 | Test_4 | Three scenarios have been tested: (1) T1 | (1)T1: | 735 | | downloads TestCaenFb but T2 does not | 1.4-1.5MBps | 736 | | download any file from T1 (2) T2 | (2)T2: | 737 | | downloads TestCaenFa but T1 does not | 1.4-1.5MBps | 738 | | download any file from T2 (3) T1 | | 739 | | downloads TestCaenFb and T2 downloads | | 740 | | TestCaenFa in the same time. For (1) | | 741 | | and (2), after several tries, | | 742 | | downloading operations have succeeded to | | 743 | | be observed. But for (3), mutual | | 744 | | downloading between T1 and T2 is not | | 745 | | observed. | | 746 +---------+------------------------------------------+--------------+ 747 | Test_5 | The mutual downloading operations have | T1/T2: | 748 | | succeeded. | 1.4-1.5MBps | 749 +---------+------------------------------------------+--------------+ 750 +---------+------------------------------------------+--------------+ 751 | Test_6 | Both T1 and T2 are able to download | T1: | 752 | | distinct files from the BitTorrent | 100-110KBps | 753 | | infrastructure. | T2: | 754 | | | 60-70KBps | 755 +---------+------------------------------------------+--------------+ 756 | Test_7 | Both T1 and T2 are able to download the | T1 | 757 | | same file located in several seeders. | :100-120KBps | 758 | | But for each file it is sending (here | After T1 | 759 | | TestCaenFRT1) RT1 can allow no more than | finished, T2 | 760 | | one unique connection to the same | started | 761 | | address IP. This is the same behavior | 100-120KBps | 762 | | for RT2. Mutual downloading between T1 | | 763 | | and T2 is not observed. | | 764 +---------+------------------------------------------+--------------+ 765 | Test_8 | Both T1 and T2 are able to download the | T1: | 766 | | file but only one single connection is | 60-90KBps | 767 | | accepted by RT1 at the same time. This | | 768 | | is because for each file it is sending | | 769 | | (here TestCaenFRTa) RT1 can allow no | | 770 | | more than one unique connection to the | | 771 | | same address IP. The result is that, | | 772 | | once T1 (or T2) has begun to download | | 773 | | TestCaenFRTa, the other terminal (T2 or | | 774 | | respectively T1) cannot get any portion | | 775 | | of TestCaenFRTa directly from RT1 till | | 776 | | the other (T1 or respectively T2) has | | 777 | | completed the downloading of | | 778 | | TestCaenFRTa. Mutual downloading | | 779 | | between T1 and T2 is not observed. | | 780 +---------+------------------------------------------+--------------+ 781 | Test_9 | The test has succeeded. While T1 has | T1: | 782 | | been downloading TestCaenFRT1 from RT1, | 50-70KBps | 783 | | T2 could download TestCaenFRTa from RT1 | T2: 40-50KBp | 784 | | and in addition it can get portions of | | 785 | | TestCaenFRTa already downloaded by T1. | | 786 +---------+------------------------------------------+--------------+ 787 | Test_10 | No problem has been encountered. | T1: | 788 | | Distinct files located in RT1 have been | 50-70KBps | 789 | | successfully downloaded by T1 | T2: | 790 | | (respectively T2). | 30-50KBps | 791 +---------+------------------------------------------+--------------+ 792 +---------+------------------------------------------+--------------+ 793 | Test_11 | Both T1 and T2 are able to upload the | RT1: | 794 | | file, but only one connection is | 20-40KBps | 795 | | accepted by RT1 at the same time. The | from T1 | 796 | | test failed because, once RT1 has begun | | 797 | | to download portions of TestCaenF1 from | | 798 | | T1 (respectively T2) it cannot accept | | 799 | | additional connection with T2 for the | | 800 | | same file. | | 801 +---------+------------------------------------------+--------------+ 802 | Test_12 | The test succeeded. Once T1 has | T2: | 803 | | completed its downloading from RT1, T2 | 80-100KBps | 804 | | has been able automatically to connect | | 805 | | to RT1 for receiving the same file. | | 806 +---------+------------------------------------------+--------------+ 807 | Test_13 | No problem has been encountered. RT1 | RT1: | 808 | | has succeeded to download simultaneously | 30-40KBps | 809 | | TestCaenFa (from T1) and TestCaenFb | from T1 and | 810 | | (from T2). | 40-50KBps | 811 | | | from T2 | 812 +---------+------------------------------------------+--------------+ 814 Table 5: Forbid Same IP & PCP Enabled 816 6. Conclusions 818 This document describes the main behavior of BitTorrent in an IP 819 shared address environment. The impact of activating port forwarding 820 (here PCP is used) has been also assessed. 822 Mutual file sharing between hosts sharing the same IP address has 823 been checked. Machines having the same IP address can share files 824 with no alteration compared to current IP architectures only if port 825 forwarding (PCP in our case) is enabled. 827 Mutual file sharing between hosts behind an IP address sharing 828 function has been also checked. Machines having distinct IP 829 addresses but located behind an address sharing function can share 830 files with no alteration compared to current IP architectures only if 831 port forwarding (PCP in our case) is enabled. 833 Even if PCP is enabled, two limitations were experienced: 835 The first limitation occurs when two clients sharing the same IP 836 address want to simultaneously retrieve the SAME file located in a 837 SINGLE remote peer. This limitation is due to the default 838 BitTorrent configuration on the remote peer which does not permit 839 sending the same file to multiple ports of the same IP address. 840 This limitation is mitigated by the fact that clients sharing the 841 same IP address can exchange portions with each other, provided 842 the clients can find each other through a common tracker, DHT, or 843 Peer Exchange. Even if they can not, we observed that the remote 844 peer would begin serving portions of the file automatically as 845 soon as the other client (sharing the same IP address) finished 846 downloading. This limitation is eliminated if the remote peer is 847 configured with bt.allow_same_ip == TRUE. 849 The second limitation occurs when a client tries to download a file 850 located on several seeders, when those seeders share the same IP 851 address. This is because the clients are enforcing 852 bt.allow_same_ip parameter to FALSE. The client will only be able 853 to connect to one seeder, among those having the same IP address, 854 to download the file (note that the client can retrieve the file 855 from other seeders having distinct IP addresses). This limitation 856 is eliminated if the local client is configured with 857 bt.allow_same_ip == TRUE, which is somewhat likely as those 858 clients will directly experience better throughput by changing 859 their own configuration. 861 7. IANA Considerations 863 This document raises no IANA considerations. 865 8. Security Considerations 867 This memo does not introduce any security issue. 869 9. References 871 9.1. Normative References 873 [I-D.ietf-pcp-base] 874 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 875 Selkirk, "Port Control Protocol (PCP)", 876 draft-ietf-pcp-base-24 (work in progress), March 2012. 878 [I-D.ietf-pcp-upnp-igd-interworking] 879 Boucadair, M., Dupont, F., Penno, R., and D. Wing, 880 "Universal Plug and Play (UPnP) Internet Gateway Device 881 (IGD)-Port Control Protocol (PCP) Interworking Function", 882 draft-ietf-pcp-upnp-igd-interworking-01 (work in 883 progress), March 2012. 885 9.2. Informative References 887 [I-D.ietf-behave-lsn-requirements] 888 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 889 and H. Ashida, "Common requirements for Carrier Grade NATs 890 (CGNs)", draft-ietf-behave-lsn-requirements-06 (work in 891 progress), May 2012. 893 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 894 Roberts, "Issues with IP Address Sharing", RFC 6269, 895 June 2011. 897 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 898 IPv4 Address Shortage", RFC 6346, August 2011. 900 Authors' Addresses 902 Mohamed Boucadair (editor) 903 France Telecom 904 Rennes 35000 905 France 907 Email: mohamed.boucadair@orange.com 909 Tao Zheng 910 Orange Labs 911 Beijing 912 China 914 Email: tao.zheng@orange.com 916 NG Tung 917 Orange Labs 918 Issy Les Moulineaux 919 France 921 Email: paul.ngtung@orange.com 922 Xiaohing Deng 923 Orange Labs 924 Beijing 925 China 927 Email: xiaohong.deng@orange.com 929 Jaqueline Queiroz 930 Orange Labs 931 Issy Les Moulineaux 932 France 934 Email: jaqueline.queiroz@orange.com