• In general, Throughput formula is
  

  RCV buffer size / RTT = Max TCP throughput = ? bps, (Buffer size is normally 64Kbps)

  ex) (64Kbyte x 8bit) / 0.17 = 3011764 bps = 3Mbps, (RTT=170ms)

• My understanding, that some FTP transfers are far below the allocated bandwidth of their connection. They approach full bandwidth
  on FTP transfers that are "in-country", but this degrades when they FTP from remote sites (e.g., U.S. FTP sites).

  I can't overemphasize the role of delay in the TCP windowing algorithm, which( if we assume no packet loss nor a bottleneck in Maximum Segment Size), is the most likely factor that is leading to the FTP throughput reductions.

  TCP ,without RFC1323 extensions, can set receive buffer window upto a maximum 64 Kbytes. This is adequate for most LAN implementations.
  FTP'ng from the US to Panama is a classic "Long Fat Network" (LFN) scenario, in which TCP throughput is highly affected by the long RTT's.

  e.g., Assuming a buffer of 50Kbytes, and 20 ms RTT, *Note: optimal buffer size is considered to be 2 x BDP, where BDP is the Bandwidth*Delay Product, so for a 20 ms RTT, and a 10 Mbps connection, that would be 2 x (10Mbps/8 * .020s) = 50Kbytes

  (50K x 8)/.02 = 20 Mbps

  Which is more than adequate for a 10 Mbps service, but insufficient for a 100 Mbps service.

  If you use an FTP session from Chile to Seattle(US), you will experience a RTT of at least 170 ms. In this scenario, the maximum TCP throughput would be:

  (64K x 8)/.170 = 3 Mbps.

  You can see the deficiency with the greater RTT.

Be first to comment this article

Only registered users can write comments.
Please login or register.

Powered by AkoComment Tweaked Special Edition v.1.4.3

---

Please share this article with ;