Fashion Exchange Tomasino

pTCP is an end‐to‐end protocol for striped connections. It provides mechanisms to use striped connec‐ tions with aggregate bandwidth along multiple paths. 

The key obstacles to achieving the aggregate bandwidth for striped connections are the following:  

• Each of the individual paths can have vastly differing characteristics in terms of bandwidth  and delay (round‐trip time). If data‐striping is done without taking into account these differ‐ ences, the bandwidth achieved by the striped connection can be significantly lower than the  maximum possible [34]. 

• Fluctuations of individual path characteristics may occur. 

The problems that arise due to bandwidth differences can be solved by making sure that the  data‐striping ratio is the same as the ratio of the bandwidths of the different paths. Solutions to the  above mentioned problems are provided by pTCP which are explained as below: 

i) Decoupling of Functionalities: pTCP decouples functionalities associated with per‐path characteristics  from those that pertain to the aggregate connection. The component in pTCP that handles per‐path  functionalities is called TCP‐v (TCP‐virtual). TCP‐v is a modified version of TCP that deals only with virtual  packets and virtual buffers. Each micro flow of a striped connection is controlled by an independent  TCP‐v (as shown in figure 14).  

  Figure 14: pTCP for striped connections 

ii) Congestion control is handled by TCP‐v. SM is responsible for striping data across the different TCP‐ vs, it handles buffer management (including sequencing at the receiver), and consequently flow control.  iii) Delayed binding:   pTCP uses a delayed binding strategy that satisfies the requirement of striping  based on ratios of cwnd, rtt, and at the same time dynamically adapts to instantaneous fluctuations in  bandwidth and delay. 

iv) Packet re‐striping:  In steady state, pTCP will ensure that the number of outstanding packets in a mi‐ cro‐flow is proportional to the bandwidth along the corresponding path. Moreover, the delayed binding  strategy further ensures that all bound packets are already in transit in the network. However, during  congestion when packets are lost in the network, the reduction of the congestion window by a TCP‐v  can result in bound packets falling outside the congestion window. If such packets are lost during the  congestion, then they will remain un‐transmitted till the congestion window of that TCP‐v expands be‐ yond their sequence numbers. This can potentially result in an overflow of the receive buffer if the other  micro‐flows are active in the meantime, finally resulting in a connection stall. 

TCP‐virtual, responsi‐ ble for “per‐path func‐ tions” 

Striped connec‐ tion Manager 

  Figure 15: pTCP architecture 

pTCP handles the problem by unbinding packets that fall outside of the congestion window of TCP‐v  they were assigned to. Such unbinding results in making those packets available to the next TCP‐v that  can send more data (Figure 15). pTCP also uses the selective acknowledgements to further reduce pack‐ ets. 

3.6 BitTorrent Protocol [78] 

BitTorrent is a peer‐to‐peer file sharing protocol used to distribute large amounts of data. The initial dis‐ tributor of the complete file or collection acts as the first seed. Each peer who downloads the data also  uploads them to other peers. Relative to standard internet hosting, this provides a significant reduction  in the original distributor's hardware and bandwidth resource costs. It also provides redundancy against  system problems and reduces dependence on the original distributor. 

• BitTorrent client is any program that implements the BitTorrent protocol. Each client is ca‐ pable of preparing, requesting, and transmitting any type of computer file over a network,  using the protocol.  

• A peer is any computer running an instance of a client. 

Basic operation principle: To share a file or group of files, a peer first creates a small file called a "tor‐ rent" (e.g. MyFile.torrent). This file contains metadata about the files to be shared and about the  tracker, the computer that coordinates the file distribution. Peers that want to download the file must  first obtain a torrent file for it, and connect to the specified tracker, which tells them from which other  peers to download the pieces of the file. 

  Though both ultimately transfer files over a network, a BitTorrent download differs from a clas‐ sic full‐file HTTP request in several fundamental ways: 

• BitTorrent makes many small data requests over different TCP sockets, while web‐browsers  typically make a single HTTP GET request over a single TCP socket. 

• BitTorrent downloads in a random or in a "rarest‐first" approach that ensures high availabil‐ ity, while HTTP downloads in a sequential manner. 

  Taken together, these differences allow BitTorrent to achieve much lower cost to the content  provider, much higher redundancy, and much greater resistance to abuse or to "flash crowds" than a  regular HTTP server. However, this protection comes at a cost: downloads can take time to rise to full  speed because it may take time for enough peer connections to be established, and it takes time for a  node to receive sufficient data to become an effective uploader. As such, a typical BitTorrent download  will gradually rise to very high speeds, and then slowly fall back down toward the end of the download.  This contrasts with an HTTP server that, while more vulnerable to overload and abuse, rises to full speed  very quickly and maintains this speed throughout. 

  In general, BitTorrent's non‐contiguous download methods have prevented it from supporting  "progressive downloads" or "streaming playback". Various improvements are suggested for the bit‐ torrent clients for better performance (“BitCod Client”). Also, network topology improvements are also  suggested. For instance, use of a mesh instead of a tree topology is proposed to improve the perform‐ ance [76].