<div dir="ltr"><div class="gmail_extra">I'll have to find some time to look at those links.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">I guess I wasn't thinking of using latency to determine the rate but only nudge the rate, but use it only to determine to back off for a bit to allow the buffer to empty, but maintain the same rate overall. So if you have a 60ms RTT but a 50ms min RTT, keep your current rate but skip one segment periodically or maybe only make it a smaller segment like 1/2 the max size, but not often enough to make a large difference. Maybe allow latency to only reduce the current target rate by no more than 5% or something.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I guess the starting pattern could be something like this</div><div class="gmail_extra">1) build up, 2x segments per ACK</div><div class="gmail_extra">2) make sure ACKd bytes increases at the same rate as bytes sent</div><div class="gmail_extra">3) once bytes ACKd stops increasing, attempt to reduce segment size or skip a packet until current RTT is near the target RTT, but no more 5%</div><div class="gmail_extra"><br></div><div class="gmail_extra">Of course this is only good for discovering the current free bandwidth. There needs to be a way to periodically probe to discover new free bandwidth. The idea was the max detected should rarely change, so don't be aggresive when probing near the max, but when below the max, attempt to find free bandwidth by adding additional segments and seeing if the ACKd byte rate increases. If it does, start growing.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't have an engineering background, just playing with thoughts.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">[Bloat] TCP congestion detection - random thoughts</div><div class="gmail_extra">> </div><div class="gmail_extra">> Alan Jenkins alan.christopher.jenkins at <a href="http://gmail.com">gmail.com</a> </div><div class="gmail_extra">> Sun Jun 21 10:05:52 PDT 2015</div><div class="gmail_extra">> Previous message: [Bloat] TCP congestion detection - random thoughts</div><div class="gmail_extra">> Next message: [Bloat] TCP congestion detection - random thoughts</div><div class="gmail_extra">> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]</div><div class="gmail_extra">> Hi Ben</div><div class="gmail_extra">> </div><div class="gmail_extra">> Some possible Sunday reading relating to these thoughts :).</div><div class="gmail_extra">> </div><div class="gmail_extra">> <a href="https://lwn.net/Articles/645115/">https://lwn.net/Articles/645115/</a> "Delay-gradient congestion control" </div><div class="gmail_extra">> [2015, Linux partial implementation]</div><div class="gmail_extra">> </div><div class="gmail_extra">> our Dave's reply to a comment:</div><div class="gmail_extra">> </div><div class="gmail_extra">> <a href="https://lwn.net/Articles/647322/">https://lwn.net/Articles/647322/</a></div><div class="gmail_extra">> </div><div class="gmail_extra">> Quote "there is a huge bias (based on the experimental evidence) that </div><div class="gmail_extra">> classic delay based tcps lost out to loss based in an undeployable fashion"</div><div class="gmail_extra">> </div><div class="gmail_extra">> - not to argue the quote either way.  But there's some implicit </div><div class="gmail_extra">> references there that are relevant.  Primarily a well-documented result </div><div class="gmail_extra">> on TCP Vegas.  AIUI Vegas uses increased delay as well as loss/marks as </div><div class="gmail_extra">> a congestion signal.  As a result, it gets a lower share of the </div><div class="gmail_extra">> bottleneck bandwidth when competing with other TCPs. Secondly uTP has a </div><div class="gmail_extra">> latency (increase) target (of 100ms :p), _deliberately_ to de-prioritize </div><div class="gmail_extra">> itself.  (This is called LEDBAT and has also been implemented as a TCP).</div><div class="gmail_extra">> </div><div class="gmail_extra">> Alan</div><div class="gmail_extra">> </div><div class="gmail_extra">> </div><div class="gmail_extra">> On 21/06/15 17:19, Benjamin Cronce wrote:</div><div class="gmail_extra">> > Just a random Sunday morning thought that has probably already been </div><div class="gmail_extra">> > thought of before, but I currently can't think of hearing it before.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > My understanding of most TCP congestion control algorithms is they </div><div class="gmail_extra">> > primarily watch for drops, but drops are indicated by the receiving </div><div class="gmail_extra">> > party via ACKs. The issue with this is TCP keeps pushing more data </div><div class="gmail_extra">> > into the window until a drop is signaled, even if the rate received is </div><div class="gmail_extra">> > not increased. What if the sending TCP also monitors rate received and </div><div class="gmail_extra">> > backs off cramming more segments into a window if the received rate </div><div class="gmail_extra">> > does not increase.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > Two things to measure this. RTT which is part of TCP statistics </div><div class="gmail_extra">> > already and the rate at which bytes are ACKed. If you double the </div><div class="gmail_extra">> > number of segments being sent, but in a time frame relative to the </div><div class="gmail_extra">> > RTT, you do not see a meaningful increase in the rate at which bytes </div><div class="gmail_extra">> > are being ACKed, may want to back off.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > It just seems to me that if you have a 50ms RTT and 10 seconds of </div><div class="gmail_extra">> > bufferbloat, TCP is cramming data down the path with no care in the </div><div class="gmail_extra">> > world about how quickly data is actually getting ACKed, it's just </div><div class="gmail_extra">> > waiting for the first segment to get dropped, which would never happen </div><div class="gmail_extra">> > in an infinitely buffered network.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > TCP should be able to keep state that tracks the minimum RTT and </div><div class="gmail_extra">> > maximum ACK rate. Between these two, it should not be able to go over </div><div class="gmail_extra">> > the max path rate except when attempting to probe for a new max or </div><div class="gmail_extra">> > min. Min RTT is probably a good target because path latency should be </div><div class="gmail_extra">> > relatively static, however path free-bandwidth is not static. The </div><div class="gmail_extra">> > desirable number of segments in flight would need to change but would </div><div class="gmail_extra">> > be bounded by the max.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > Of course naggle type algorithms can mess with this because when ACKs </div><div class="gmail_extra">> > occur is no longer based entirely when a segment is received, but also </div><div class="gmail_extra">> > by some other additional amount of time. If you assume that naggle </div><div class="gmail_extra">> > will coalesce N segments into a single ACK, then you need to add to </div><div class="gmail_extra">> > the RTT, the amount of time at the current PPS, how long until you </div><div class="gmail_extra">> > expect another ACK assuming N number of segments will be coalesced. </div><div class="gmail_extra">> > This would be even important for low latency low bandwidth paths. </div><div class="gmail_extra">> > Coalesce information could be assumed, negotiated, or inferred. </div><div class="gmail_extra">> > Negotiated would be best.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > Anyway, just some random Sunday thoughts.</div><div class="gmail_extra">> </div></div></div>