When send window is not big enough for the required TCP segment to send, we may split the segment so it will fir into the window. Before this change - We didn't split the segment in the case we have unacked segments. The motivation was that we anticiapte to get ACK on the inflight segments, which will trigger the next send operation.
This flow count on RTT for receiving ACKs, which may be delayed depending on the remote side. When RTT is long - we would block sending although TCP send window allows it.
The change is to split TCP segments although we have unacked data, in case the send window is big enough (mss).
Change type
What kind of change does this PR introduce?
[x] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Tests
[ ] Other
Check list
[ ] Code follows the style de facto guidelines of this project
[ ] Comments have been inserted in hard to understand places
When send window is not big enough for the required TCP segment to send, we may split the segment so it will fir into the window. Before this change - We didn't split the segment in the case we have unacked segments. The motivation was that we anticiapte to get ACK on the inflight segments, which will trigger the next send operation. This flow count on RTT for receiving ACKs, which may be delayed depending on the remote side. When RTT is long - we would block sending although TCP send window allows it.
The change is to split TCP segments although we have unacked data, in case the send window is big enough (mss).
Change type
What kind of change does this PR introduce?
Check list