5 ms·

why?

Avamander 6y ago
For multiple reasons. QUIC or HTTP/3 is going to be the next web standard widely deployed. Getting mandatory encrypted UDP traffic that looks like web is a big benefit. TFO recommendation primarily because torrenting is big, the feature is not super well-known, it would be a chance to increase its adoption, need for its support and that would benefit the web in general.
- the8472 6y ago
  Bittorrent wouldn't benefit much from TFO because that would require a cookie from a previous connection to that remote client, which is unlikely to happen among random peers. Plus connection setup is not really a limiting factor for current use-cases. Some low-latency applications of bittorrent might benefit, but that requires specialized clients tuned for low latency throughout the stack, a single change won't do it. QUIC's encryption could be beneficial, but bittorrent-over-TLS would work equally well (not standardized, but libtorrent supports it). QUIC's stream multiplexing would not be all that useful either since bittorrent's maximum message size already is fairly small so clients can already interleave and prioritize control messages as needed. Bittorrent clients usually don't run on roaming (mobile) devices due to bandwidth limits, so QUIC's path migration probably doesn't provide much of a benefit either. Being UDP-based might make NAT-traversal a bit easier, but so does µTP. If you want QUIC's congestion controller benefits then you can also get that with TCP if you're on linux. Set BBR as congestion controller and set the TCP_NOTSENT_LOWAT socket option and bittorrent should work well over long fat pipes (i.e. international peers). I'm not saying QUIC is terrible, but it's mostly designed to improve web traffic. Bulk transfers à la bittorrent benefit only marginally if you have a modern TCP stack and use it properly.
  - Avamander 6y ago
    > which is unlikely to happen among random peers. Yes, it'd be a minor suggestion at best. The biggest benefit would be to the internet as whole, motivating middle box makers into not breaking it and so on. The low-latency idea seems interesting, I suspect WebTorrent people would appreciate it. But live streams over P2P sound too fancy for now. > but bittorrent-over-TLS would work equally well (not standardized, but libtorrent supports it). Which is where the suggestion to use QUIC would have the biggest effect and getting the swarms more encrypted. > Bulk transfers à la bittorrent benefit only marginally if you have a modern TCP stack and use it properly. Unfortunately very little software actually goes into the effort at figuring each such detail out and the end result, defaults are often rather poor. I guess this more of a questions of "what are the defaults" not "what's possible."

why?

For multiple reasons. QUIC or HTTP/3 is going to be the next web standard widely deployed. Getting mandatory encrypted UDP traffic that looks like web is a big benefit. TFO recommendation primarily because torrenting is big, the feature is not super well-known, it would be a chance to increase its adoption, need for its support and that would benefit the web in general.

the8472 6y ago
Bittorrent wouldn't benefit much from TFO because that would require a cookie from a previous connection to that remote client, which is unlikely to happen among random peers. Plus connection setup is not really a limiting factor for current use-cases. Some low-latency applications of bittorrent might benefit, but that requires specialized clients tuned for low latency throughout the stack, a single change won't do it. QUIC's encryption could be beneficial, but bittorrent-over-TLS would work equally well (not standardized, but libtorrent supports it). QUIC's stream multiplexing would not be all that useful either since bittorrent's maximum message size already is fairly small so clients can already interleave and prioritize control messages as needed. Bittorrent clients usually don't run on roaming (mobile) devices due to bandwidth limits, so QUIC's path migration probably doesn't provide much of a benefit either. Being UDP-based might make NAT-traversal a bit easier, but so does µTP. If you want QUIC's congestion controller benefits then you can also get that with TCP if you're on linux. Set BBR as congestion controller and set the TCP_NOTSENT_LOWAT socket option and bittorrent should work well over long fat pipes (i.e. international peers). I'm not saying QUIC is terrible, but it's mostly designed to improve web traffic. Bulk transfers à la bittorrent benefit only marginally if you have a modern TCP stack and use it properly.
- Avamander 6y ago
  > which is unlikely to happen among random peers. Yes, it'd be a minor suggestion at best. The biggest benefit would be to the internet as whole, motivating middle box makers into not breaking it and so on. The low-latency idea seems interesting, I suspect WebTorrent people would appreciate it. But live streams over P2P sound too fancy for now. > but bittorrent-over-TLS would work equally well (not standardized, but libtorrent supports it). Which is where the suggestion to use QUIC would have the biggest effect and getting the swarms more encrypted. > Bulk transfers à la bittorrent benefit only marginally if you have a modern TCP stack and use it properly. Unfortunately very little software actually goes into the effort at figuring each such detail out and the end result, defaults are often rather poor. I guess this more of a questions of "what are the defaults" not "what's possible."