[Bloat] TCP congestion detection - random thoughts

[Benjamin Cronce]

Just a random Sunday morning thought that has probably already been thought
of before, but I currently can't think of hearing it before.

My understanding of most TCP congestion control algorithms is they
primarily watch for drops, but drops are indicated by the receiving party
via ACKs. The issue with this is TCP keeps pushing more data into the
window until a drop is signaled, even if the rate received is not
increased. What if the sending TCP also monitors rate received and backs
off cramming more segments into a window if the received rate does not
increase.

Two things to measure this. RTT which is part of TCP statistics already and
the rate at which bytes are ACKed. If you double the number of segments
being sent, but in a time frame relative to the RTT, you do not see a
meaningful increase in the rate at which bytes are being ACKed, may want to
back off.

It just seems to me that if you have a 50ms RTT and 10 seconds of
bufferbloat, TCP is cramming data down the path with no care in the world
about how quickly data is actually getting ACKed, it's just waiting for the
first segment to get dropped, which would never happen in an infinitely
buffered network.

TCP should be able to keep state that tracks the minimum RTT and maximum
ACK rate. Between these two, it should not be able to go over the max path
rate except when attempting to probe for a new max or min. Min RTT is
probably a good target because path latency should be relatively static,
however path free-bandwidth is not static. The desirable number of segments
in flight would need to change but would be bounded by the max.

Of course naggle type algorithms can mess with this because when ACKs occur
is no longer based entirely when a segment is received, but also by some
other additional amount of time. If you assume that naggle will coalesce N
segments into a single ACK, then you need to add to the RTT, the amount of
time at the current PPS, how long until you expect another ACK assuming N
number of segments will be coalesced. This would be even important for low
latency low bandwidth paths. Coalesce information could be assumed,
negotiated, or inferred. Negotiated would be best.

Anyway, just some random Sunday thoughts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150621/dad62f1f/attachment-0002.html>