(I'm not an expert on this so I might have misunderstood something!)

If the connection requests a large MSS > 16k, for example to exploit a large MTU, then writes block because available space is believed to be 0.

Consider UTX.available:

let available t =    let a = Int32.sub t.max_size t.bufbytes in    match a < (Int32.of_int (Window.tx_mss t.wnd)) with    | true -> 0l    | false -> a

Initially max_size = 16k (hardcoded in flow.ml) and bufbytes = 0, so a = 16k (meaning 16k space is free in the buffer).

If the free space (a) is less than an MSS, we return 0 and the connection stalls.

I think the assumption is that the UTX can buffer at least an MSS worth of data so that when the free space (a) is less than an MSS, the buffer already contains an MSS worth of data to transmit to make progress (does this make sense? Or does it only need to contain 1 byte, so it could be MSS + 1?)

Bump the user buffer size to 128k which is 2x a 64k MSS (where 64k is the max value of the 16-bit MSS option). (Does this need to be configurable somewhere? Linux hasip route add 192.168.1.0/24 dev eth0 advmss 65536 and socket options.)

My hope is that forhttps://github.com/moby/vpnkit which will use aSOCK_DGRAM interface tosend andrecv ethernet frames via Apple virtualization.framework and qemu, I'll be able to bump the ethernet MTU and TCP MSS to 64k to reduce the number of packets, since there's a syscall overhead per-packet.

I'm not completely sure this change is correct and I've not got a 64k MTU/MSS working end-to-end yet. I thought it was worth making the PR for discussion.

This might need rethinking if we support segmentation offload because we might see segments >> MTUs.

Signed-off-by: David Scottdave@recoil.org