<font face="arial" size="3"><p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">So, go for it, then. I wish you well.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">On Monday, June 24, 2019 4:14pm, "Jonathan Morton" <chromatix99@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1561496638">
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">> > On 24 Jun, 2019, at 10:50 pm, David P. Reed <dpreed@deepplum.com><br />> wrote:<br />> ><br />> > My overall point here is that you seem to live in a world of academic-like<br />> purity - all TCP connections are essentially huge file transfers, where there are<br />> no delays on production or consumption of packets at the endpoint, there is no<br />> multiplexing or scheduling of processes in the endpoint operating systems, etc.<br />> <br />> On the contrary, I've found that per-flow queuing algorithms like DRR++ cope<br />> naturally and very nicely with all sorts of deviations from the ideal, including<br />> for example the wild variations in goodput and RTT associated with wifi links.<br />> <br />> These are exactly the kinds of complication that I imagine - and not merely in the<br />> abstract but through observation - that a pure end-to-end approach would have<br />> great difficulty in accommodating elegantly.<br />> <br />> - Jonathan Morton<br />> <br />> </p>
</div></font>