WO2011006531A1 - Method of monitoring a bittorrent network and measuring download speeds - Google Patents

Method of monitoring a bittorrent network and measuring download speeds Download PDF

Info

Publication number
WO2011006531A1
WO2011006531A1 PCT/EP2009/058970 EP2009058970W WO2011006531A1 WO 2011006531 A1 WO2011006531 A1 WO 2011006531A1 EP 2009058970 W EP2009058970 W EP 2009058970W WO 2011006531 A1 WO2011006531 A1 WO 2011006531A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
bitfield
messages
bittorrent
monitoring
Prior art date
Application number
PCT/EP2009/058970
Other languages
French (fr)
Inventor
Georgios Siganos
Pablo Rodriguez Rodriguez
Original Assignee
Telefonica, S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica, S.A. filed Critical Telefonica, S.A.
Priority to BR112012000875A priority Critical patent/BR112012000875A2/en
Priority to EP09780552A priority patent/EP2454851A1/en
Priority to MX2012000647A priority patent/MX2012000647A/en
Priority to US13/383,989 priority patent/US20120209911A1/en
Priority to PCT/EP2009/058970 priority patent/WO2011006531A1/en
Priority to ARP100102527A priority patent/AR077471A1/en
Priority to UY0001032788A priority patent/UY32788A/en
Publication of WO2011006531A1 publication Critical patent/WO2011006531A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Definitions

  • the present invention relates to peer to peer networks, in particular to a method of monitoring a bittorrent protocol and measure the download speeds of clients in such a network.
  • the Bittorrent protocol is a p2p protocol designed for bulk data transfers. Bittorrent has three main ingredients: a) a metadata file called a torrent that contains essential information on how to connect to the network or swarm, b) a central server called tracker that coordinates the clients or peers, c) the notion of breaking the file or files into pieces that can be downloaded and uploaded in parallel.
  • the torrent file contains the id or "infohash" of the torrent, the address of the tracker and information like the size of the file, the number of pieces that the file is broken into, the piece size and other related information.
  • the client then contacts the tracker for other peers to connect to, and tries to open connections to these clients. After connecting successfully, it will send the bitfield, an array of 0 and 1 that describes the pieces it has(0 means it does not have the piece, while 1 means it has it), and a string that describes what its capabilities are.
  • the clients can support Peer Exchange messages (PEX), which can be used to learn about other peers.
  • PEX Peer Exchange messages
  • a problem still to be solved in this technical field is how to monitor a Bittorrent network and measure the download speeds of Bittorrent clients without deploying Deep Packet Inspection (DPI) equipment within the network of an Internet Service Provider (ISP).
  • DPI systems are expensive to acquire and deploy, and can only capture the behavior of part of the network. Additionally, installing such devices requires the consent and cooperation of the ISPs.
  • the system needs to have the following requirements: a) be as light-weight as possible, b) be capable of monitoring hundreds of thousands or millions of clients within a small time window, c) not be too intrusive for the clients and inflict the minimum possible overhead to them, and d) be fault-tolerant.
  • the estimate of the speed is given by the number of new pieces that the client downloaded between the two observations, multiplied by the piece size and divided by the time between the two observations.
  • Figure 1 shows the high level interactions of the Torrent Process at a particular period of the year.
  • Figure 2 shows the interactions between the client used by the invention and a Bittorrent client (Peer Process).
  • Figure 3 is a graphical representation of the number of Bittorrent clients that can be analyzed with the present invention on an hour basis.
  • Figure 4 is a representation of the measured performance of British Telecom during a 2 months period. DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION
  • the invention provides a client that participates in bittorrent swarms and connects to other clients to measure how fast they download a torrent. As an input it gets a list of torrents to process and a timeframe to process them. At any given time, it analyzes in parallel a number of torrents.
  • the client consists of a number of processes, which perform specific tasks.
  • the Rate Controller process has the role of controlling the number of active torrents by constantly monitoring the CPU load and Memory usage of the local machine.
  • the Manager process is the first process we start when we start analyzing a new torrent. It is responsible of starting all the necessary processes and passes to them the necessary references for message passing.
  • the Manager process starts the Tracker process and the Torrent process.
  • the Tracker process is responsible for the communication with the tracker.
  • the Torrent process keeps a list of the discovered peers and their status, i.e. if we are trying to connect, if we have finished analyzing them etc. For every new peer that we discover, the Torrent process starts a new process, Peer process that will be responsible for the communication with the peer.
  • the Peer process has two goals. The main one is to get an estimate of the speed of the peer, if it is still downloading the file. The second goal is to get the PEX.
  • the Torrent process every one-minute checks the current status of the peers. In order to release resources like memory, we have put a cut off point. After we analyze 98% or more of the peers, we stop measuring the torrent and release the resources. The motivation behind this is that especially for very large torrents there is a constant flow of new peers that will not allow us to release resources needed to check other torrents.
  • the estimate of the speed is given by the number of new pieces it downloaded between the two observations, multiplied by the piece size and divided by the time between the two observations. Details:
  • Incoming connections are not allowed in the present invention.
  • the main reason is to decrease the necessary state required. Otherwise, the overhead to support the incoming connections compared to the benefit would be too high.
  • the system can be used to access performance differences between ISPs and understand the different policies that they utilize.
  • client of the invention we can understand and discover the fastest ISPs around the world without the need to install specialized DPI techniques and equipments and without getting the consent of the ISPs. Finally, it is easy to understand the throttling periods where ISPs don't want bittorrent users to exchange traffic.
  • the term "comprises” and its derivations should not be understood in an excluding sense, that is, these terms should not be interpreted as excluding the possibility that what is described and defined may include further elements, steps, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

The invention discloses a method of monitoring a bittorrent network and measuring download speeds. The speed is calculated by connecting to a client, getting the bitfield and have messages, reconnecting after a predetermined time and getting a new bitfield and have messages. Taking the number of new pieces between both observations multiplied by the piece size and divided by the time between the two observations the download speed is obtained.

Description

METHOD OF MONITORING A BITTORRENT NETWORK AND MEASURING DOWNLOAD SPEEDS.
DESCRIPTION
FIELD OF THE INVENTION
The present invention relates to peer to peer networks, in particular to a method of monitoring a bittorrent protocol and measure the download speeds of clients in such a network.
STATE OF THE ART
The Bittorrent protocol is a p2p protocol designed for bulk data transfers. Bittorrent has three main ingredients: a) a metadata file called a torrent that contains essential information on how to connect to the network or swarm, b) a central server called tracker that coordinates the clients or peers, c) the notion of breaking the file or files into pieces that can be downloaded and uploaded in parallel.
In order to download a file, a user will need to find the torrent file. The torrent file contains the id or "infohash" of the torrent, the address of the tracker and information like the size of the file, the number of pieces that the file is broken into, the piece size and other related information. The client then contacts the tracker for other peers to connect to, and tries to open connections to these clients. After connecting successfully, it will send the bitfield, an array of 0 and 1 that describes the pieces it has(0 means it does not have the piece, while 1 means it has it), and a string that describes what its capabilities are. For example, the clients can support Peer Exchange messages (PEX), which can be used to learn about other peers. When a client downloads successfully a piece, it will notify its neighbors that it has the piece. Monitoring the Bittorrent network has been studied before, with the most relevant work to be the BitProbe measurement system. This system though is focused in measuring the characteristics of the line of an end user, for example line capacity, and also evaluating the effectiveness of the Bittorrent application.
A problem still to be solved in this technical field is how to monitor a Bittorrent network and measure the download speeds of Bittorrent clients without deploying Deep Packet Inspection (DPI) equipment within the network of an Internet Service Provider (ISP). DPI systems are expensive to acquire and deploy, and can only capture the behavior of part of the network. Additionally, installing such devices requires the consent and cooperation of the ISPs. The system needs to have the following requirements: a) be as light-weight as possible, b) be capable of monitoring hundreds of thousands or millions of clients within a small time window, c) not be too intrusive for the clients and inflict the minimum possible overhead to them, and d) be fault-tolerant.
DESCRIPTION OF THE INVENTION To estimate the download speeds of Bittorrent clients while solving the technical problems discussed above, the invention proposes a method according to claim 1. Optional and advantageous features can be found in the dependent claims. The procedure is generally as follows: 1. Connect to a client, get its bitfield and have messages.
2. If the client has finished downloading the file, which is indicated by a bitfield with only ones (1 ), after 1 minute disconnect and exit. If the client is still downloading the file, as indicated by the missing pieces (zeroes) in its bitfield, after 1 minute disconnect, sleep for 4 minutes. 3. Then reconnect and get the new bitfield and have messages.
4. The estimate of the speed is given by the number of new pieces that the client downloaded between the two observations, multiplied by the piece size and divided by the time between the two observations.
BRIEF DESCRIPTION OF THE DRAWINGS
To complete the description and in order to provide for a better understanding of the invention, a set of drawings is provided. Said drawings form an integral part of the description and illustrate a preferred embodiment of the invention, which should not be interpreted as restricting the scope of the invention, but just as an example of how the latter can be embodied. The drawings comprise the following figures:
Figure 1 shows the high level interactions of the Torrent Process at a particular period of the year.
Figure 2 shows the interactions between the client used by the invention and a Bittorrent client (Peer Process).
Figure 3 is a graphical representation of the number of Bittorrent clients that can be analyzed with the present invention on an hour basis.
Figure 4 is a representation of the measured performance of British Telecom during a 2 months period. DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION
The invention provides a client that participates in bittorrent swarms and connects to other clients to measure how fast they download a torrent. As an input it gets a list of torrents to process and a timeframe to process them. At any given time, it analyzes in parallel a number of torrents. The client consists of a number of processes, which perform specific tasks. The Rate Controller process has the role of controlling the number of active torrents by constantly monitoring the CPU load and Memory usage of the local machine. The Manager process is the first process we start when we start analyzing a new torrent. It is responsible of starting all the necessary processes and passes to them the necessary references for message passing. The Manager process starts the Tracker process and the Torrent process. The Tracker process is responsible for the communication with the tracker. It registers with the tracker for the torrent, and gets the initial set of peers. The Torrent process keeps a list of the discovered peers and their status, i.e. if we are trying to connect, if we have finished analyzing them etc. For every new peer that we discover, the Torrent process starts a new process, Peer process that will be responsible for the communication with the peer. The Peer process has two goals. The main one is to get an estimate of the speed of the peer, if it is still downloading the file. The second goal is to get the PEX. The Torrent process, every one-minute checks the current status of the peers. In order to release resources like memory, we have put a cut off point. After we analyze 98% or more of the peers, we stop measuring the torrent and release the resources. The motivation behind this is that especially for very large torrents there is a constant flow of new peers that will not allow us to release resources needed to check other torrents.
Measuring the Download speed:
To get an estimate of the download speed, the following high-level procedure is used:
1. Connect to a client get its bitfield and have messages.
2. If the client has finished downloading the file, after 1 minute disconnect and exit. The reason we exit is that a client that has finished downloading the file can not provide a download speed estimate. 3. If the client is still downloading the file, after 1 minute disconnect, sleep for 4 minutes.
4. Then reconnect and get the new bitfield and have messages.
Disconnect and exit.
The estimate of the speed is given by the number of new pieces it downloaded between the two observations, multiplied by the piece size and divided by the time between the two observations. Details:
In order to receive successfully Peer Exchange Messages, we stay connected the first time for 1 minute. This interval is the typical interval used. Once per minute, a bittorrent client that supports PEX, will send to all its peers either the list of its neighbors or a list of new and removed clients.
Waiting for 1 minute guarantees that we will receive this data.
In case we cannot connect to a client, we have the following policy. If we could get no response, sleep for 10 seconds between failures and try at most 5 times. If we can open successfully a socket, but we cannot send successfully our bitfield, sleep for 10 seconds and re-try at most 2 times. Note, that to measure the speed of a bittorrent client we have to connect two times. This is not always feasible. To decrease the load to the tracker, and to speed up the measurement, our main source of peers is PEX. In the typical case, that the torrent is not private, we query the tracker twice. If the torrent is private, which means that the creator of the torrent has explicitly forbidden the use of gossiping mechanisms like PEX and DHT, we have to depend on the tracker to learn the peers, since the peers we connect to will not send us any PEX. In that case, we use the scrape query of a tracker to learn the number of peers that participate and decide how many queries we need.
Incoming connections are not allowed in the present invention. The main reason is to decrease the necessary state required. Otherwise, the overhead to support the incoming connections compared to the benefit would be too high.
Problems to avoid, lazy bitfield effect:
Extra care is taken when analyzing the bitfield. A lot of clients implement a feature called lazy bitfield, where a client does not send the actual bitfield but removes from the bitfield a number of pieces, and then subsequently notifies the client that it has these pieces by using have messages. Thus, the have messages are required to eliminate this lazy bitfield problem.
This is done to avoid being detected as a bittorrent client which has finished downloading and being throttled by ISPs. To be sure that we collect all these have messages we stay connected for 10 seconds the 2nd time. We follow a very simple rule on the have messages. If the client supports the lazy bitfield feature, any have messages that it receives within 3 seconds are considered to be associated with this feature.
The system can be used to access performance differences between ISPs and understand the different policies that they utilize. Using the client of the invention we can understand and discover the fastest ISPs around the world without the need to install specialized DPI techniques and equipments and without getting the consent of the ISPs. Finally, it is easy to understand the throttling periods where ISPs don't want bittorrent users to exchange traffic. In this text, the term "comprises" and its derivations (such as "comprising", etc.) should not be understood in an excluding sense, that is, these terms should not be interpreted as excluding the possibility that what is described and defined may include further elements, steps, etc.
On the other hand, the invention is obviously not limited to the specific embodiment(s) described herein, but also encompasses any variations that may be considered by any person skilled in the art (for example, as regards the choice of materials, dimensions, components, configuration, etc.), within the general scope of the invention as defined in the claims.

Claims

1. A method of monitoring a bittorrent network and measuring download speeds, the method comprising the steps of:
a. connecting to a client, getting the bitfield and have messages b. reconnecting after a predetermined time and getting a new bitfield and have messages
c. calculating the speed as the result of taking the number of new pieces between both observations multiplied by the piece size and divided by the time between the two observations.
2. The method of claim 1 wherein
if the client has finished downloading the file, disconnect after 1 minute if the client is still downloading, disconnect after 1 minute, sleep for 4 minutes and proceed with b.
3. The method of any of the preceding claims wherein, if the have messages incorporate a lazy bitfield, the reconnection in step b. has a duration of 10 seconds.
4. The method claim 1 wherein, in case where a client cannot be connected, the steps a and b are separated by 10 seconds between failures, the process being repeated at most 5 times if the failure persists.
PCT/EP2009/058970 2009-07-14 2009-07-14 Method of monitoring a bittorrent network and measuring download speeds WO2011006531A1 (en)

Priority Applications (7)

Application Number Priority Date Filing Date Title
BR112012000875A BR112012000875A2 (en) 2009-07-14 2009-07-14 method of monitoring a bittorrent network and measuring download speeds
EP09780552A EP2454851A1 (en) 2009-07-14 2009-07-14 Method of monitoring a bittorrent network and measuring download speeds
MX2012000647A MX2012000647A (en) 2009-07-14 2009-07-14 Method of monitoring a bittorrent network and measuring download speeds.
US13/383,989 US20120209911A1 (en) 2009-07-14 2009-07-14 Method of monitoring a bittorrent network and measuring download speeds
PCT/EP2009/058970 WO2011006531A1 (en) 2009-07-14 2009-07-14 Method of monitoring a bittorrent network and measuring download speeds
ARP100102527A AR077471A1 (en) 2009-07-14 2010-07-13 METHOD FOR MONITORING A BITTORRENT NETWORK AND MEASURING DOWNLOAD SPEEDS
UY0001032788A UY32788A (en) 2009-07-14 2010-07-13 METHOD FOR MONITORING A BITTORRENT NETWORK AND MEASURING DOWNLOAD SPEEDS

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2009/058970 WO2011006531A1 (en) 2009-07-14 2009-07-14 Method of monitoring a bittorrent network and measuring download speeds

Publications (1)

Publication Number Publication Date
WO2011006531A1 true WO2011006531A1 (en) 2011-01-20

Family

ID=41211916

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/058970 WO2011006531A1 (en) 2009-07-14 2009-07-14 Method of monitoring a bittorrent network and measuring download speeds

Country Status (7)

Country Link
US (1) US20120209911A1 (en)
EP (1) EP2454851A1 (en)
AR (1) AR077471A1 (en)
BR (1) BR112012000875A2 (en)
MX (1) MX2012000647A (en)
UY (1) UY32788A (en)
WO (1) WO2011006531A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10911337B1 (en) * 2018-10-10 2021-02-02 Benjamin Thaddeus De Kosnik Network activity monitoring service

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2013271563B2 (en) * 2012-06-07 2016-10-20 Kroll Information Assurance, Llc Bit Torrent scan with cross comparison for robust data monitoring
US10361940B2 (en) 2015-10-02 2019-07-23 Hughes Network Systems, Llc Monitoring quality of service
CN118381838A (en) * 2023-01-20 2024-07-23 达发科技(苏州)有限公司 Computer device and transmission control protocol packet processing method for computer device

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090122697A1 (en) * 2007-11-08 2009-05-14 University Of Washington Information plane for determining performance metrics of paths between arbitrary end-hosts on the internet

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020116518A1 (en) * 2001-02-01 2002-08-22 Silen Bradley A. Fast environment detection and selection of optimized media
US7509372B2 (en) * 2001-09-13 2009-03-24 International Business Machines Corporation Method and system for redirecting data requests in peer-to-peer data networks
EP1723747B1 (en) * 2004-03-10 2011-08-24 AB Seesta OY Heterogeneous network system, network node and mobile host
US7409482B2 (en) * 2004-10-26 2008-08-05 Lenovo (Singapore) Pte, Ltd. Computer and method for on-demand network access control
US20060184688A1 (en) * 2005-02-17 2006-08-17 Nec Laboratories America, Inc. System and Method for Parallel Indirect Streaming of Stored Media from Multiple Sources
US8738778B2 (en) * 2006-04-26 2014-05-27 Bittorrent, Inc. Peer-to-peer download and seed policy management
KR101409991B1 (en) * 2007-04-16 2014-06-20 삼성전자주식회사 Method and apparatus for data transfer in peer-to-peer network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090122697A1 (en) * 2007-11-08 2009-05-14 University Of Washington Information plane for determining performance metrics of paths between arbitrary end-hosts on the internet

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
TOMAS ISDAL ET AL: "Leveraging BitTorrent for End Host Measurements", PASSIVE AND ACTIVE NETWORK MEASUREMENT; [LECTURE NOTES IN COMPUTER SCIENCE;;LNCS], SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, vol. 4427, 5 April 2007 (2007-04-05), pages 32 - 41, XP019078589, ISBN: 978-3-540-71616-7 *
TOMAS ISDAL: "Using BitTorrent for Measuring End-to-End Internet Path Characteristics", MASTER OF SCIENCE THESIS, 1 January 2006 (2006-01-01), Stockholm, XP002552952, Retrieved from the Internet <URL:http://www.cs.washington.edu/homes/isdal/papers/bitprobes_masters_thesis.pdf> [retrieved on 20091028] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10911337B1 (en) * 2018-10-10 2021-02-02 Benjamin Thaddeus De Kosnik Network activity monitoring service

Also Published As

Publication number Publication date
MX2012000647A (en) 2012-02-08
AR077471A1 (en) 2011-08-31
EP2454851A1 (en) 2012-05-23
US20120209911A1 (en) 2012-08-16
UY32788A (en) 2011-02-28
BR112012000875A2 (en) 2016-03-01

Similar Documents

Publication Publication Date Title
JP7178646B2 (en) Network security monitoring method, network security monitoring device and system
Liang et al. The FastTrack overlay: A measurement study
Spring et al. Using PlanetLab for network research: myths, realities, and best practices
EP3167572B1 (en) Relay residential gateway between a terminal device and a server
JP4393032B2 (en) Information processing system having path switching function in case of failure and information terminal thereof
WO2017218820A1 (en) Monitoring enterprise networks with endpoint agents
US20050152364A1 (en) Traffic control system of P2P network
EP2894872B1 (en) Method for scheduling tasks in a power line carrier network
US20120209911A1 (en) Method of monitoring a bittorrent network and measuring download speeds
CN109412890B (en) DDS-based joint test platform middleware node state detection method
Kryczka et al. Measuring the bittorrent ecosystem: Techniques, tips, and tricks
Price et al. Still alive: Extending keep-alive intervals in P2P overlay networks
Peterson et al. Using PlanetLab for Network Research: Myths, Realities, and Best Practices.
Sánchez et al. A measurement experimentation platform at the Internet's edge
FR2964280A1 (en) EVENT CENTRALIZATION METHOD FOR MULTI-LEVEL HIERARCHICAL INFORMATION SYSTEM
US20160294648A1 (en) Hub filtering
Lin et al. An isp-friendly file distribution protocol: analysis, design, and implementation
JP5381247B2 (en) Load distribution device, load distribution method, load distribution program, and load distribution system
US20130326010A1 (en) System and method for monitoring network connections
Hu et al. Downloading trace study for BitTorrent P2P performance measurement and analysis
JP2006311048A (en) Band control device
US20100250737A1 (en) Detecting and controlling peer-to-peer traffic
Zeilemaker et al. Large-scale message synchronization in challenged networks
Lehmann et al. Disconnecting to connect: Understanding optimistic disconnection in bittorrent
Ngiwlay et al. Bittorrent peer identification based on behaviors of a choke algorithm

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09780552

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012000110

Country of ref document: CL

Ref document number: 12004922

Country of ref document: CO

Ref document number: 000049-2012

Country of ref document: PE

Ref document number: MX/A/2012/000647

Country of ref document: MX

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112012000875

Country of ref document: BR

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2009780552

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13383989

Country of ref document: US

ENP Entry into the national phase

Ref document number: 112012000875

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20120113