<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Ben<br>
<br>
Some possible Sunday reading relating to these thoughts :).<br>
<br>
<a class="moz-txt-link-freetext" href="https://lwn.net/Articles/645115/">https://lwn.net/Articles/645115/</a> "Delay-gradient congestion control"
[2015, Linux partial implementation]<br>
<br>
our Dave's reply to a comment:<br>
<br>
<a class="moz-txt-link-freetext" href="https://lwn.net/Articles/647322/">https://lwn.net/Articles/647322/</a><br>
<br>
Quote "there is a huge bias (based on the experimental evidence)
that classic delay based tcps lost out to loss based in an
undeployable fashion"<br>
<br>
- not to argue the quote either way. But there's some implicit
references there that are relevant. Primarily a well-documented
result on TCP Vegas. AIUI Vegas uses increased delay as well as
loss/marks as a congestion signal. As a result, it gets a lower
share of the bottleneck bandwidth when competing with other TCPs.
Secondly uTP has a latency (increase) target (of 100ms :p),
_deliberately_ to de-prioritize itself. (This is called LEDBAT and
has also been implemented as a TCP).<br>
<br>
Alan<br>
<br>
<br>
<div class="moz-cite-prefix">On 21/06/15 17:19, Benjamin Cronce
wrote:<br>
</div>
<blockquote
cite="mid:CAJ_ENFHOO28_SxQXhvAc6W=WHhA6Lp4Gec5C1u0zGkWLH-LitQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Just a random Sunday morning thought that has probably
already been thought of before, but I currently can't think of
hearing it before.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Anyway, just some random Sunday thoughts.</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bloat mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/bloat">https://lists.bufferbloat.net/listinfo/bloat</a>
</pre>
</blockquote>
<br>
</body>
</html>