Commit ddb302d
committed
tcp: avoid stall with larger MSS
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 2*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.
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).
This might need rethinking if we support segmentation offload because we might
see even bigger segments.
Signed-off-by: David Scott <[email protected]>1 parent efbebdf commit ddb302d
1 file changed
+6
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
20 | 20 | | |
21 | 21 | | |
22 | 22 | | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
23 | 26 | | |
24 | 27 | | |
25 | 28 | | |
| |||
360 | 363 | | |
361 | 364 | | |
362 | 365 | | |
363 | | - | |
364 | | - | |
| 366 | + | |
| 367 | + | |
| 368 | + | |
365 | 369 | | |
366 | 370 | | |
367 | 371 | | |
| |||
0 commit comments