idnits 2.17.00 (12 Aug 2021) /tmp/idnits45396/draft-boucadair-behave-bittorrent-address-sharing-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 145 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2011) is 4064 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2026' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 675, but no explicit reference was found in the text == Outdated reference: draft-ietf-behave-lsn-requirements has been published as RFC 6888 == Outdated reference: draft-ietf-intarea-shared-addressing-issues has been published as RFC 6269 == Outdated reference: draft-ymbk-aplusp has been published as RFC 6346 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft J-L. Grimault 4 Intended status: Informational P. Levis 5 Expires: September 30, 2011 A. Villefranque 6 France Telecom 7 March 29, 2011 9 Behavior of BitTorrent service in an IP Shared Address Environment 10 draft-boucadair-behave-bittorrent-address-sharing-00.txt 12 Abstract 14 This document describes the behavior of BitTorrent service in the 15 context of IP shared addresses. It provides an overview of the used 16 testbed and main results of the tests that have been conducted in 17 order to assess the limitations of an architecture based on shared IP 18 addresses. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 30, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. BitTorent Overview . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. BitTorrent at a Glance . . . . . . . . . . . . . . . . . . 3 58 2.2. Software Configuration . . . . . . . . . . . . . . . . . . 4 59 2.2.1. BitTorrent Client . . . . . . . . . . . . . . . . . . 4 60 2.2.2. BitTorrent Server . . . . . . . . . . . . . . . . . . 4 61 2.2.3. BitTorrent Tracker . . . . . . . . . . . . . . . . . . 4 63 3. Testbed Overview . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Testbed Description . . . . . . . . . . . . . . . . . . . 4 65 3.2. Files . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Description of Tests . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Connection to Overlay Test Group . . . . . . . . . . . . . 5 69 4.2. Upload Test Group . . . . . . . . . . . . . . . . . . . . 6 70 4.3. Mutual Download Test Group . . . . . . . . . . . . . . . . 7 71 4.4. Simultaneous Download Test Group . . . . . . . . . . . . . 7 73 5. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.1. First Configuration: Multiple Connections with the 75 same IP address are enabled . . . . . . . . . . . . . . . 10 76 5.2. Second Configuration: Multiple Connections with the 77 same IP address are disabled . . . . . . . . . . . . . . . 12 79 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 Recently, several proposals have been disseminated within IETF to 96 allow for IPv4 service continuity. These solutions share the same IP 97 address among several subscribers (e.g., CGN (Carrier Grade NAT) 98 [I-D.ietf-behave-lsn-requirements] or A+P [I-D.ymbk-aplusp]) 100 Several issues are encountered in address sharing context as 101 elaborated in [I-D.ietf-intarea-shared-addressing-issues]. 103 This memo focuses on BitTorrent as an example of application which 104 applies a restriction based on IP address. This memo describes a 105 testing campaign that has been carried out to assess the impact of IP 106 shared address on BitTorrent. 108 2. BitTorent Overview 110 2.1. BitTorrent at a Glance 112 BitTorrent is a distributed file sharing infrastructure. It is based 113 on P2P (Peer to Peer) techniques for exchanging files between 114 connected users. Three parties are involved in a BitTorrent 115 architecture as detailed hereafter: 117 1. The Server: The server into which, has been uploaded the torrent 118 file. 120 2. The Tracker: Maintains a list of clients which have the file or 121 some portions of that file. 123 3. The Client: Entities which are downloading and/or uploading 124 portions of the file. Two categories of clients may be 125 distinguished: 127 A. Leechers: Clients which are currently downloading the file 128 but do not yet detain all the portions of the file. As for 129 the portions already obtained, the leechers upload them 130 towards requesting clients; 132 B. Seeders: Clients which detain all the portions of the file 133 and are uploading them to other requesting clients. 135 A torrent file is a file which includes the meta-data information of 136 the file to be shared: the file name, its length, a hash and the URL 137 of the tracker. In order to download a given file, a BitTorrent 138 client needs to obtain the corresponding torrent file. Afterwards, 139 it connects to the tracker to retrieve a list of leechers and 140 seeders. Then, the client connects to those machines and downloads 141 the available portions of the requested file. It uploads also the 142 portions already obtained towards requesting clients. 144 2.2. Software Configuration 146 This section provides an overview of installed tools. 148 2.2.1. BitTorrent Client 150 Various BitTorrent clients are available for public use. The 151 following one has been installed for the purposes of our testing 152 activities: 154 URL: www.bittorrent.com 156 The installed version is 6.1. 158 2.2.2. BitTorrent Server 160 The BitTorrent server that has been used is the following: 162 URL: www.metro-torrent.com 164 2.2.3. BitTorrent Tracker 166 The BitTorrent tracker that has been used is the following: 168 URL: www.metro-torrent.com/announce.php 170 3. Testbed Overview 172 3.1. Testbed Description 174 The testbed used to conduct the testing activities, described in 175 Section 5, is the same as the one described in Section 4 of 176 [I-D.boucadair-port-range]. 178 o The PRR (Port Range Router) is responsible to implement a port- 179 driven routing so as to be able to route incoming traffic to the 180 appropriate machine among those having the same IP address. 182 o CPE-1 and CPE-2 are two CPEs to which the same IP address is 183 assigned. In order to discriminate these CPEs, distinct Port 184 Masks are assigned to each of these CPE. 186 o T1 (respectively T2) is a machine located in the LAN behind CPE-1 187 (respectively CPE-2). 189 o RT1 and RT2 are remote machines reachable through Internet. 191 +-------+ +-----+ +-----------+ +----------+ 192 | | | | | Service | | | 193 | T1 |----|CPE-1|-------| Provider | | | 194 | | | | | Domain | | | +---------+ 195 +-------+ +-----+ | | | | | Remote | 196 193.51.145.206 | | | +----+ Terminal| 197 | +-----+ | | | | (RT1) | 198 +-------+ +-----+ | | PRR | +--+ Internet | +---------+ 199 | | | | | +-----+ | | | 193.51.145.205 200 | T2 |----|CPE-2|-------| | | | 201 | | | | | | | | 202 +-------+ +-----+ | | | | +---------+ 203 193.51.145.206 | | | | | Remote | 204 | | | +----+ Terminal| 205 | | | | | (RT2) | 206 | | | | +---------+ 207 | | | | 193.51.145.208 208 +-----------+ +----------+ 210 3.2. Files 212 The following table lists the files available in each machine: 214 +-----------------+-------------------------------+ 215 | Machine' s name | Available files | 216 +-----------------+-------------------------------+ 217 | T1 | TestCaenF1 and TestCaenFa | 218 | T2 | TestCaenF1 and TestCaenFb | 219 | RT1 | TestCaenFRT1 and TestCaenFRTa | 220 | RT2 | TestCaenFRT1 and TestCaenFRTb | 221 +-----------------+-------------------------------+ 223 Available files 225 4. Description of Tests 227 This section lists the tests that have been conducted. 229 4.1. Connection to Overlay Test Group 231 This table lists the test to assess the ability of distinct machines 232 having the same IP address to connect to BitTorrent overlay. 234 +--------+------------+------------------+---------------------------+ 235 | Test | Test Title | Purpose | Description | 236 | Index | | | | 237 +--------+------------+------------------+---------------------------+ 238 | Test_1 | Connection | Check if two | Check if BitTorrent | 239 | | to | terminals, | client installed on T1 | 240 | | BitTorrent | having the same | and T2 machines are able | 241 | | Overlay | public IP | to use the same tracker | 242 | | | address, are | and that no problems are | 243 | | | able to connect | experienced to use the | 244 | | | to BitTorrent | same tracker by T1 and | 245 | | | overlay network | T2. | 246 +--------+------------+------------------+---------------------------+ 248 Connecting to Overlay Test Group 250 4.2. Upload Test Group 252 This test group aims at checking if upload operations are not 253 impacted/restricted due to the presence of several machines with the 254 same IP address. 256 +--------+------------+---------------+--------------------------------+ 257 | Test | Test Title | Purpose | Description | 258 | Index | | | | 259 +--------+------------+---------------+--------------------------------+ 260 | Test_2 | Uploading | Check if two | Check if torrent files may be | 261 | | distinct | terminals, | uploaded from T1 and T2 using | 262 | | files | having the | the same tracker. On T1 | 263 | | using the | same public | (resp. T2), generate a torrent | 264 | | same | IP address, | file TestCaenFa.torrent (resp. | 265 | | BitTorrent | are able to | TestCaenFb.torrent) referring | 266 | | tracker | upload | to the file TestCaenFa (resp. | 267 | | and server | torrent files | TestCaenFb) and pointing to | 268 | | | (referring to | the tracker TRA. From T1 | 269 | | | distinct | (resp. T2) try to put | 270 | | | files) using | TestCaenFa.torrent (resp. | 271 | | | the same | TestCaenFb.torrent) onto | 272 | | | tracker and | server S. Check if the upload | 273 | | | same server | operation has succeeded | 274 | Test_3 | Uploading | Check if two | On T1 (resp. T2), generate a | 275 | | torrent | terminals, | torrent file | 276 | | files | having the | TestCaenF1.torrent (resp. | 277 | | referring | same public | TestCaenF1.torrent) referring | 278 | | to the | IP address, | to the file TestCaenF1 and | 279 | | same file | are able to | pointing to the tracker TRA. | 280 | | | upload | From T1 (resp. T2) try to put | 281 | | | torrent | TestCaenF1.torrent (resp. | 282 | | | files, which | TestCaenF1.torrent) onto | 283 | | | refer to the | server S. Check if the upload | 284 | | | same file, | operation has succeeded | 285 | | | using the | | 286 | | | same tracker | | 287 +--------+------------+---------------+--------------------------------+ 289 Upload Test Group 291 4.3. Mutual Download Test Group 293 The purpose of this test group is to check if mutual downloading 294 operations can occur between machines having the same IP address. 296 +--------+-------------+-----------+--------------------------------+ 297 | Test | Test Title | Purpose | Description | 298 | Index | | | | 299 +--------+-------------+-----------+--------------------------------+ 300 | Test_4 | Mutual | Check if | Check if T1 can download the | 301 | | Downloading | two | file uploaded by T2 (ref. | 302 | | between | terminals | Test_2) and vice versa. Three | 303 | | machines | having | scenarios are to be tested: | 304 | | sharing the | the same | (1) T1 downloads TestCaenFb | 305 | | same IP | public IP | but T2 does not download any | 306 | | address | address | file from T1, (2) T2 downloads | 307 | | | can | TestCaenFa but T1 does not | 308 | | | download | download any file from T2, (3) | 309 | | | a file | T1 downloads TestCaenFb and T2 | 310 | | | from each | downloads TestCaenFa at the | 311 | | | another | same time | 312 +--------+-------------+-----------+--------------------------------+ 314 Mutual Download Test Group 316 4.4. Simultaneous Download Test Group 318 This test group aims at checking if simultaneous downloading 319 operations from remote seed(s)/leecher(s) can be performed by several 320 machines sharing the same IP address. 322 +---------+--------------+----------------+-------------------------+ 323 | Test | Test Title | Purpose | Description | 324 | Index | | | | 325 +---------+--------------+----------------+-------------------------+ 326 | Test_5 | Downloading | Check if two | Check if distinct files | 327 | | distinct | terminals, | available on BitTorrent | 328 | | files | having the | infrastructure may be | 329 | | | same public IP | downloaded by T1 and T2 | 330 | | | address, are | simultaneously | 331 | | | able to | | 332 | | | download | | 333 | | | distinct files | | 334 | | | available on | | 335 | | | BitTorrent | | 336 | | | infrastructure | | 337 | Test_6 | Downloading | Check if two | Check if a file | 338 | | the same | terminals, | available on several | 339 | | file located | having the | seeders may be | 340 | | on several | same public IP | downloaded from T1 and | 341 | | seeders | address, are | T2 simultaneously. As | 342 | | | able to | an example, check if T1 | 343 | | | download the | and T2 can download the | 344 | | | same file | same file located in | 345 | | | located on | RT1 and RT2 (referred | 346 | | | several | to as TestCaenFRT1) | 347 | | | seeders | | 348 | Test_7 | Download the | Check if two | Check if T1 and T2 can | 349 | | same file | terminals | download the same file | 350 | | available on | having the | uploaded by RT1 | 351 | | a single | same public IP | (referred to as | 352 | | machine | address are | TestCaenFRTa) | 353 | | | able to | concurrently. In case | 354 | | | download, at | the test fails, one of | 355 | | | the same time, | the two host is called | 356 | | | the same file | the "waiting client" | 357 | | | available on a | | 358 | | | single seed | | 359 | Test_8 | Simultaneous | Check if it is | In case Test_7 fails, | 360 | | downloading | not precluded | check that it is not | 361 | | from the | that a | precluded that a | 362 | | same seeder | different file | different file can be | 363 | | | can be | downloaded by the | 364 | | | downloaded by | waiting client (T1 or | 365 | | | the waiting | T2) from the same | 366 | | | client from | seeder (RT1) at the | 367 | | | the same | same time the other | 368 | | | seeder | terminal (respectively | 369 | | | | T2 or T1) is | 370 | | | | downloading | 371 | | | | TestCaenFRTa. Execute | 372 | | | | Test_7 in launching on | 373 | | | | T1 the downloading of | 374 | | | | TestCaenFRT1 and just | 375 | | | | few seconds afterwards | 376 | | | | in launching on T2 the | 377 | | | | downloading of | 378 | | | | TestCaenFRT1 and | 379 | | | | TestCaenFRTa. Check | 380 | | | | that while T1 is | 381 | | | | downloading | 382 | | | | TestCaenFRT1 that does | 383 | | | | not preclude T2 to | 384 | | | | concurrently download | 385 | | | | TestCaenFRTa. | 386 | Test_9 | Downloading | Check if the | Check if T1 | 387 | | distinct | two terminals | (respectively T2) can | 388 | | files from | having the | download files uploaded | 389 | | the same | same public IP | by RT1 (referred to as | 390 | | seeder | address are | TestCaenRF1 and | 391 | | | able to | TestCaenFRTa) | 392 | | | download at | concurrently. | 393 | | | the same time | Particularly, check if | 394 | | | two distinct | T1 can download | 395 | | | files from the | TestCaenFRT1 and T2 can | 396 | | | same seeder | download TestCaenFRTa | 397 | | | | simultaneously | 398 | Test_10 | Download the | Check if the | in RT1, launch the | 399 | | same file | same file can | downloading of | 400 | | located on | be downloaded | TestCaenF1. Check that | 401 | | machines | by a given | RT1 is downloading | 402 | | having the | machine from | portions of TestCaenF1 | 403 | | same IP | seeders having | at the same time from | 404 | | address | the same IP | T1 and T2 | 405 | | | address | | 406 | Test_11 | Automatic | Check if the | In case Test_7 fails, | 407 | | query to | terminal which | check that the terminal | 408 | | download the | was waiting | which was waiting can | 409 | | same file | can finally | finally download the | 410 | | available on | download the | file once the other | 411 | | a single | file once the | terminal has finished | 412 | | machine | other terminal | | 413 | | | has finished | | 414 | Test_12 | Download | Check if | Check if RT1 can | 415 | | distinct | distinct files | download simultaneously | 416 | | files from | can be | TestCaenFa (from T1) | 417 | | two machines | downloaded by | and TestCaenFb (from | 418 | | having the | the same | T2) | 419 | | same IP | machine from | | 420 | | address | seeders having | | 421 | | | the same IP | | 422 | | | address | | 423 +---------+--------------+----------------+-------------------------+ 425 Simultaneous Download Test Group 427 5. Results 429 BitTorrent client can be configured to accept multiple connections 430 using the same IP address. A dedicated parameter can therefore be 431 positioned. This parameter is called: bt.allow_same_ip. Possible 432 values that can be taken by this parameter are: FALSE (0) or TRUE 433 (1). 435 For the testing activities, two configurations have been tested: 437 1. First Configuration: bt.allow_same_ip == TRUE 439 2. Second Configuration: bt.allow_same_ip == FALSE 441 The following sub-sections describe the obtained results for each 442 configuration. 444 5.1. First Configuration: Multiple Connections with the same IP address 445 are enabled 447 The following table summarizes the results of the aforementioned 448 tests as performed using the testbed described in Section 4. Note 449 that bt.allow_same_ip is positioned to TRUE. 451 +------------+--------------------------------------+---------------+ 452 | Test | Results | Comments | 453 | Identifier | | | 454 +------------+--------------------------------------+---------------+ 455 | Test_1 | No problems have been experienced | None | 456 | Test_2 | Both T1 and T2 are able to upload | None | 457 | | distinct torrent files using the | | 458 | | same tracker and the same server | | 459 | Test_3 | Only one machine can upload a | The server | 460 | | torrent file referring to the same | ensures that | 461 | | file | only one | 462 | | | single | 463 | | | torrent file | 464 | | | corresponding | 465 | | | to the same | 466 | | | file is | 467 | | | listed in its | 468 | | | base | 469 | Test_4 | Three scenarios have been tested: | None | 470 | | (1) T1 downloads TestCaenFb but T2 | | 471 | | does not download any file from T1 | | 472 | | (2) T2 downloads TestCaenFa but T1 | | 473 | | does not download any file from T2 | | 474 | | (3) T1 downloads TestCaenFb and T2 | | 475 | | downloads TestCaenFa in the same | | 476 | | time. For all these scenarios, no | | 477 | | problems have been encountered. The | | 478 | | downloading operations have | | 479 | | succeeded | | 480 | Test_5 | Both T1 and T2 are able to download | None | 481 | | distinct files from the BitTorrent | | 482 | | infrastructure | | 483 | Test_6 | Both T1 and T2 are able to download | None | 484 | | the same file located in several | | 485 | | seeders. No particular problem has | | 486 | | been encountered | | 487 | Test_7 | No problem has been encountered. | None | 488 | | Both T1 and T2 are able to download | | 489 | | TestCaenFRTa from RT1 | | 490 | | simultaneously. Note that at the | | 491 | | same time, mutual downloading by T1 | | 492 | | of portions of TestCaenFRTa already | | 493 | | downloaded by T2 (and vice versa) | | 494 | | have been noticed | | 495 | Test_8 | Not applicable | None | 496 | Test_9 | No problem has been encountered. | None | 497 | | Distinct files located in RT1 have | | 498 | | been successfully downloaded by T1 | | 499 | | (respectively T2) | | 500 | Test_10 | No problem has been encountered | None | 501 | Test_11 | Not applicable | Not | 502 | | | applicable | 503 | Test_12 | No problem has been encountered. | None | 504 | | RT1 has succeeded to download | | 505 | | simultaneously TestCaenFa (from T1) | | 506 | | and TestCaenFb (from T2) | | 507 +------------+--------------------------------------+---------------+ 509 First Configuration Obtained Results 511 5.2. Second Configuration: Multiple Connections with the same IP 512 address are disabled 514 The following table summarizes the results of the aforementioned 515 tests as performed using the testbed described in Section 4. Note 516 that bt.allow_same_ip is positioned to FALSE. 518 +------------+-----------------------+-----------------------------------+ 519 | Test | Results | Comments | 520 | Identifier | | | 521 +------------+-----------------------+-----------------------------------+ 522 | Test_1 | No problems have been | None | 523 | | experienced | | 524 | Test_2 | Both T1 and T2 are | None | 525 | | able to upload | | 526 | | distinct torrent | | 527 | | files using the same | | 528 | | tracker and the same | | 529 | | server | | 530 | Test_3 | Only one machine can | The server ensures that only one | 531 | | upload a torrent file | single torrent file corresponding | 532 | | referring to the same | to the same file is listed in its | 533 | | file | base | 534 | Test_4 | Three scenarios have | None | 535 | | been tested: (1) T1 | | 536 | | downloads TestCaenFb | | 537 | | but T2 does not | | 538 | | download any file | | 539 | | from T1 (2) T2 | | 540 | | downloads TestCaenFa | | 541 | | but T1 does not | | 542 | | download any file | | 543 | | from T2 (3) T1 | | 544 | | downloads TestCaenFb | | 545 | | and T2 downloads | | 546 | | TestCaenFa in the | | 547 | | same time. For all | | 548 | | these scenarios, no | | 549 | | problems have been | | 550 | | encountered. The | | 551 | | downloading | | 552 | | operations have | | 553 | | succeeded | | 554 | Test_5 | Both T1 and T2 are | None | 555 | | able to download | | 556 | | distinct files from | | 557 | | the BitTorrent | | 558 | | infrastructure | | 559 | Test_6 | Both T1 and T2 are | When TestCaenFRT1 is used as | 560 | | able to download the | example. T1 and T2 are able to | 561 | | same file located in | download the same file. But for | 562 | | several seeders. No | each file it is sending (here | 563 | | particular problem | TestCaenFRT1) RT1 can allow no | 564 | | has been encountered | more than one unique connection | 565 | | | to the same address IP. This is | 566 | | | the same behavior for RT2. T1 | 567 | | | and T2 exchanges the portions of | 568 | | | the files they stored | 569 | Test_7 | Both T1 and T2 are | This is because for each file it | 570 | | able to download the | is sending (here TestCaenFRTa) | 571 | | file but only one | RT1 can allow no more than one | 572 | | single connection is | unique connection to the same | 573 | | accepted by RT1 at | address IP. The result is that, | 574 | | the same time | once T1 (or T2) has begun to | 575 | | | download TestCaenFRTa, the other | 576 | | | terminal (T2 or respectively T1) | 577 | | | cannot get any portion of | 578 | | | TestCaenFRTa directly from RT1 | 579 | | | till the other (T1 or | 580 | | | respectively T2) has completed | 581 | | | the downloading of TestCaenFRTa. | 582 | | | However, that does not preclude | 583 | | | the waiting terminal (T2 or T1) | 584 | | | to download from the other | 585 | | | terminal (T1 or T2) portions of | 586 | | | TestCaenFRTa already downloaded | 587 | | | from RT1 | 588 | Test_8 | The test 8 has | While T1 has been downloading | 589 | | succeeded | TestCaenFRT1 from RT1, T2 could | 590 | | | download TestCaenFRTa from RT1 | 591 | | | and in addition it can get | 592 | | | portions of TestCaenFRTa already | 593 | | | downloaded by T1 | 594 | Test_9 | No problem have been | None | 595 | | experienced | | 596 | Test_10 | Both T1 and T2 are | The test failed because, once RT1 | 597 | | able to upload the | has begun to download portions of | 598 | | file, but only one | TestCaenF1 from T1 (respectively | 599 | | connection is | T2) it cannot accept additional | 600 | | accepted by RT1 at | connection with T2 for the same | 601 | | the same time | file | 602 | Test_11 | The test succeeded | Once T1 has completed its | 603 | | | downloading from RT1, T2 has been | 604 | | | able automatically to connect to | 605 | | | RT1 for receiving the portions of | 606 | | | TestCaenFRTa it has not already | 607 | | | got from T2 | 608 | Test_12 | No problem has been | None | 609 | | encountered. RT1 has | | 610 | | succeeded to download | | 611 | | simultaneously | | 612 | | TestCaenFa (from T1) | | 613 | | and TestCaenFb (from | | 614 | | T2) | | 615 +------------+-----------------------+-----------------------------------+ 616 Results: Multiple connections desiabled 618 6. Conclusions 620 This memo describes the main behavior of BitTorrent service in an IP 621 shared address environment. Particularly, the tests have been 622 carried out on a testbed implementing [I-D.boucadair-port-range] 623 solution. The results are, however, valid for all IP shared address 624 based solutions. 626 Two limitations were experienced. The first limitation occurs when 627 two clients sharing the same IP address want to simultaneously 628 retrieve the SAME file located in a SINGLE remote peer. This 629 limitation is due to the default BitTorrent configuration on the 630 remote peer which does not permit sending the same file to multiple 631 ports of the same IP address. This limitation is mitigated by the 632 fact that clients sharing the same IP address can exchange portions 633 with each other, provided the clients can find each other through a 634 common tracker, DHT, or Peer Exchange. Even if they can not, we 635 observed that the remote peer would begin serving portions of the 636 file automatically as soon as the other client (sharing the same IP 637 address) finished downloading. This limitation is eliminated if the 638 remote peer is configured with bt.allow_same_ip == TRUE. 640 The second limitation occurs when a client tries to download a file 641 located on several seeders, when those seeders share the same IP 642 address. This is because the clients are enforcing bt.allow_same_ip 643 parameter to FALSE. The client will only be able to connect to one 644 seeder, among those having the same IP address, to download the file 645 (note that the client can retrieve the file from other seeders having 646 distinct IP addresses). This limitation is eliminated if the local 647 client is configured with bt.allow_same_ip == TRUE, which is somewhat 648 likely as those clients will directly experience better throughput by 649 changing their own configuration. 651 Mutual file sharing between hosts having the same IP address has been 652 checked. Indeed, machines having the same IP address can share files 653 with no alteration compared to current IP architectures. 655 7. IANA Considerations 657 This document raises no IANA considerations. 659 8. Security Considerations 661 This memo does not introduce any security issue. 663 9. Acknowledgements 665 The authors would like to thank Dan WING for suggesting the writing 666 of this memo and for the review of the text. 668 10. References 670 10.1. Normative References 672 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 673 3", BCP 9, RFC 2026, October 1996. 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, March 1997. 678 10.2. Informative References 680 [I-D.boucadair-port-range] 681 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 682 "IPv4 Connectivity Access in the Context of IPv4 Address 683 Exhaustion: Port Range based IP Architecture", 684 draft-boucadair-port-range-02 (work in progress), 685 July 2009. 687 [I-D.ietf-behave-lsn-requirements] 688 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 689 and H. Ashida, "Common requirements for IP address sharing 690 schemes", draft-ietf-behave-lsn-requirements-01 (work in 691 progress), March 2011. 693 [I-D.ietf-intarea-shared-addressing-issues] 694 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 695 Roberts, "Issues with IP Address Sharing", 696 draft-ietf-intarea-shared-addressing-issues-05 (work in 697 progress), March 2011. 699 [I-D.ymbk-aplusp] 700 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 701 draft-ymbk-aplusp-09 (work in progress), February 2011. 703 Authors' Addresses 705 Mohamed Boucadair (editor) 706 France Telecom 707 Rennes 35000 708 France 710 Email: mohamed.boucadair@orange-ftgroup.com 712 Jean-Luc Grimault 713 France Telecom 715 Email: jeanluc.grimault@orange-ftgroup.com 717 Pierre Levis 718 France Telecom 720 Email: pierre.levis@orange-ftgroup.com 722 Alain Villefranque 723 France Telecom 725 Email: alain.villefranque@orange-ftgroup.com