#13629: tcp: slow start & congestion avoidance @ rfc 5681 : updated rules for
congestion window
--------------------------------------+-----------------------------------
Reporter: a-star | Owner: axeld
Type: task | Status: new
Priority: normal | Milestone: Unscheduled
Component: Network & Internet/TCP | Version: R1/Development
Resolution: | Keywords: tcp, gsoc, slow start
Blocked By: | Blocking:
Has a Patch: 1 | Platform: All
--------------------------------------+-----------------------------------
Comment (by a-star):
UINT32_MAX shouldn't be a problem since the congestion window variable,
fCongestionWindow, is also uint32.
Till the first ACK after connection establishment is received,
fSendMaxSegments will limit the number of packets sent according to the
"MUST NOT be more than X" rule specified above. After that, on receipt of
every ACK that changes the congestion window, fSendMaxSegments counter is
restarted with UINT32_MAX.
Now let's consider the worst case scenario: the user continuously sends
packet of 1 byte in length and the other end doesn't send back
acknowledgment for a long time. Each of these packets will decrement the
value of fSendMaxSegments by 1.
[Note: Packets of zero length, like pure ACK or packets exchanged during
handshake do not decrement the value of fSendMaxSegments.]
Now for fSendMaxSegments to reduce to 0, the minimum number of such
packets required will be UINT32_MAX. The total amount of data sent will
then be UINT32_MAX * 1 byte = UINT32_MAX bytes. This value is also the
maximum size of the congestion window. Therefore if indeed this much data
is sent, the congestion window will itself withhold any more data from
being sent. So we have no problem with fSendMaxSegments getting reduced to
zero.
--
Ticket URL: <https://dev.haiku-os.org/ticket/13629#comment:5>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
