Is the SEND_BUFFER_SIZE and RX_STREAM_DATA_WINDOW small?

[mxinden]

Neqo currently sets a maximum stream send and receive window of 1 MiB:

neqo/neqo-transport/src/recv_stream.rs

Line 33 in c004359

const RX_STREAM_DATA_WINDOW: u64 = 0x10_0000; // 1MiB

neqo/neqo-transport/src/send_stream.rs

Line 36 in c004359

pub const SEND_BUFFER_SIZE: usize = 0x10_0000; // 1 MiB

If my math is correct, on e.g. a 50ms connection, a 1MiB window does not allow for more than 160 Mbit/s per stream:

  delay_s = 0.05
  window_bits = 1 * 1024 * 1024 * 8
  bandwidth_bits_s = window_bits / delay_s
  bandwidth_mbits_s = bandwidth_bits_s / 1024 / 1024 # 160.0

Intuitively 160 Mbit/s on a 50ms connection seems small.

Am I missing something? Is this relevant? Are applications expected to leverage multiple streams to exhaust the bandwidth of a connection?

what do other projects use

• Chromium:
  • https://github.com/chromium/chromium/blob/904ed34564cd5482d88cfc96abf7187a1455fa16/net/quic/quic_context.cc#L20-L22
• Google Quiche:
  • https://github.com/google/quiche/blob/792c6e7d8658d7b7b27f780efec71c67930b4c9f/quiche/quic/core/quic_constants.h#L82-L86
• quic-go:
  • https://github.com/quic-go/quic-go/blob/b096e94092e97b998e396c5c67735b97e403edd3/interface.go#L291-L294

related

• Previous increase from 64KiB to 1MiB Large transport bufs #806

[larseggert]

We should do auto tuning.

[mxinden]

Closing here in favor of #733.