To your point about hurdles, thankfully I think the Noise blueprint will be a piece of cake - no knobs, nothing to change, it will just work for everyone.
For the TCP_FASTOPEN blueprint I think there’s three separate phases. The first phase is internal testing on test networks. We’re in the middle of that but it’s going really well.
The second phase is external testing on the real network. During this phase we’d want to engage with as many SNOs as are interested, and yeah, having the data visible in Grafana is probably acceptable, for motivated SNOs to be able to test and see how often and how well it works. We would not expect that it is widely available on the network though. We’d probably avoid enabling TCP_FASTOPEN on real client software during this phase so that SNOs could enable TCP_FASTOPEN support for testing without fear of missing out on real traffic.
What we learn from that second phase is probably what would dictate what we need to do for the third phase, which is how do we make it as easy as possible for SNOs to enable it in cases when it makes sense, and not in cases where it doesn’t make sense. I agree that reducing hurdles here is the top priority.
I guess my point is it might be useful to separate the tasks we need to be able to start trying this out on the real network from tasks that we need to be able to achieve wide adoption.
It’s definitely worth pointing out that this project has some important differences from the QUIC effort:
- The QUIC protocol has no fallback support - either the node accepts the UDP packets and responds, or it doesn’t. Both the client and node need to support QUIC, in addition to all of the middleware boxes along the way. To deal with this, QUIC-supporting clients still dial TCP in parallel for every connection, wasting resources, so that there’s a fallback connection to use if QUIC times out or fails.
- TCP_FASTOPEN is useful in that there is no new port configuration, no new firewall management, and gracefully falls back if either endpoint is missing support for TCP_FASTOPEN. If either the client or the node indicate no support for TCP_FASTOPEN, that’s okay, and things will still work even if the other peer tries for TCP_FASTOPEN. Both have to opt in, but neither need to. The only similarity here is the middlebox support needs to exist, and we don’t really know the prevalence in our network of broken middlebox support.
I think we need to get to phase two to even understand that last issue.