As far as I understand GridFTP, it's an FTP that runs multiple (up to
100) parallel TCP streams in order to have less of a reduce-the-window
impact when one packet is lost; they want it to be able to fill a
dedicated lambda and keep it full, even when having a residual packet
loss rate.
Of course, the impact on Net congestion is exactly the same as when
reducing the downscaling factor in TCP (I think).
As an aside:
If you ran 100 parallel TCP streams, that would approximate a single
TCP that reduced it's window by 0.5% in response to a single loss, but
also increased by 100 packets per RTT in the absense of loss.
But it's more subtle than that. Suppose those 100 TCP flows have a
window of exactly 10 packets each (the total window is therefore 1000
packets). In the RTT where you take a single loss, one flow decreases
to a 5 packet window, and the other 99 flows increase to an 11 packet
window. Thus you took a loss, but the total window actually increased
from 1000 packets to 1094 packets.
To reduce the rate _at all_, you need to take 16 losses in an RTT from
different flows (84*11 + 16*5 = 988).
Also, things behave differently when some of these connections get
into retransmit timeout. In this case the 100 parallel flows might
behave much more conservatively than a single flow that increased by
100 packets/RTT in the absense of loss and decreased by 0.5% in
response to a single loss. If the 100 parallel flows have a total
window of less than 400 packets, then some of them will be in RTO
because there aren't enough packets in flight to trigger fast
retransmit.
As always, the dynamics of TCP end up being more subtle than I expect
at first glance.
Cheers,
Mark