How we built a new, fast file transfer protocol

Re:How we built a new, fast file transfer protocol by ncmncm on Sunday March 27, 2022 @07:09PM (#30825100)

Then let's not say it. Clearly you miss the point: any provisioned backbone bandwidth that does not carry a packet just goes to waste. Network backbone channels are not provisioned like your consumer-grade cable TV network endpoint hubs. Carriers pay for guaranteed capacity. When TCP fails to use bandwidth capacity, it is failing to use backbone bandwidth, not dodgy last-mile bandwidth.

Even moreso: when so configured, FASP is having exactly zero effect on the actual bit rate of the TCP connections. Another TCP connection would compete for the same packet slots, slowing them all down. The FASP traffic does not slow down any of the TCP connections, but only competes with other FASP (or similar) traffic.

[ Parent | on HN ]

Re:How we built a new, fast file transfer protocol by jandrese on Monday March 28, 2022 @10:30AM (#30830864)

Anything that causes packet loss will slow down TCP. If you are fully saturating a link you will introduce packet loss. It's just how TCP works.

[ Parent | on HN ]

Re:How we built a new, fast file transfer protocol by ncmncm on Monday March 28, 2022 @04:39PM (#30835286)

And if you are fully saturating exactly the packet slots TCP would not try to use, then you are not introducing packet loss. That is just how FASP works.

[ Parent | on HN ]

Re:How we built a new, fast file transfer protocol by hansel_der on Friday April 01, 2022 @09:05AM (#30877700)

there is just no way for end-points to know about the 'unused slots' much less use them specifically (w/o introducing packet loss or latency).

[ Parent | on HN ]