<font face="arial" size="3"><p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Jonathan - all of the things you say are kind of silly. An HTTP 1.1 protocol running over TCP is not compatible with this description, except in "fantasyland".</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;">I think you are obsessed with some idea of "proving me wrong". That's not productive.</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;">If you have actual data describing how HTTP 1.1 connections proceed over time that disagrees with my observation, show them. Preferably taken in the wild.</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;">I honestly can't imagine that you have actually observed any system other than the constrained single connection between a LAN and a residential ISP.</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;">TCP doesn't have a "natural sawtooth" - that is the response of TCP to a particular "queueing discipline" in a particular kind of a router - it would respond differently (and does!) if the router were to drop packets randomly on a Poisson basis, for example. No sawtooth at all.</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;">So you seem to see routers are part of TCP. That's not the way the Internet is designed.</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;"> </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;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">On Saturday, June 22, 2019 7:07pm, "Jonathan Morton" <chromatix99@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1561402248">
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">> > On 23 Jun, 2019, at 1:09 am, David P. Reed <dpreed@deepplum.com><br />> wrote:<br />> ><br />> > per-flow scheduling is appropriate on a shared link. However, the end-to-end<br />> argument would suggest that the network not try to divine which flows get<br />> preferred.<br />> > And beyond the end-to-end argument, there's a practical problem - since the<br />> ideal state of a shared link means that it ought to have no local backlog in the<br />> queue, the information needed to schedule "fairly" isn't in the queue backlog<br />> itself. If there is only one packet, what's to schedule?<br />> <br />> This is a great straw-man. Allow me to deconstruct it.<br />> <br />> The concept that DRR++ has empirically proved is that flows can be classified into<br />> two categories - sparse and saturating - very easily by the heuristic that a<br />> saturating flow's arrival rate exceeds its available delivery rate, and the<br />> opposite is true for a sparse flow.<br />> <br />> An excessive arrival rate results in a standing queue; with Reno, the excess<br />> arrival rate after capacity is reached is precisely 1 segment per RTT, very small<br />> next to modern link capacities. If there is no overall standing queue, then by<br />> definition all of the flows passing through are currently sparse. DRR++ (as<br />> implemented in fq_codel and Cake) ensures that all sparse traffic is processed<br />> with minimum delay and no AQM activity, while saturating traffic is metered out<br />> fairly and given appropriate AQM signals.<br />> <br />> > In fact, what the ideal queueing discipline would do is send signals to the<br />> endpoints that provide information as to what each flow's appropriate share is,<br />> and/or how far its current share is from what's fair.<br />> <br />> The definition of which flows are sparse and which are saturating shifts<br />> dynamically in response to endpoint behaviour.<br />> <br />> > Well, presumably the flows have definable average rates.<br />> <br />> Today's TCP traffic exhibits the classic sawtooth behaviour - which has a<br />> different shape and period with CUBIC than Reno, but is fundamentally similar. <br />> The sender probes capacity by increasing send rate until a congestion signal is<br />> fed back to it, at which point it drops back sharply. With efficient AQM action,<br />> a TCP flow will therefore spend most of its time "sparse" and using less than the<br />> available path capacity, with occasional excursions into "saturating" territory<br />> which are fairly promptly terminated by AQM signals.<br />> <br />> So TCP does *not* have a definable "average rate". It grows to fill available<br />> capacity, just like the number of cars on a motorway network.<br />> <br />> The recent work on high-fidelity ECN (including SCE) aims to eliminate the<br />> sawtooth, so that dropping out of "saturating" mode is done faster and by only a<br />> small margin, wasting less capacity and reducing peak delays - very close to ideal<br />> control as you describe. But it's still necessary to avoid giving these signals<br />> unnecessarily to "sparse" flows, which would cause them to back off and thus waste<br />> capacity, but only to "saturating" flows that have just begun to build a queue. <br />> And it's also necessary to protect these well-behaved "modern" flows from "legacy"<br />> endpoint behaviour, and vice versa. DRR++ does that very naturally.<br />> <br />> > Merely re-ordering the packets on a link is just not very effective at<br />> achieving fairness.<br />> <br />> I'm afraid this assertion is simply false. DRR++ does precisely that, and<br />> achieves near-perfect fairness.<br />> <br />> It is important however to define "flow" correctly relative to the measure of<br />> fairness you want to achieve. Traditionally the unique 5-tuple is used to define<br />> "flow", but this means applications can game the system by opening multiple flows.<br />> For an ISP a better definition might be that each subscriber's traffic is one<br />> "flow". Or there is a tweak to DRR++ which allows a two-layer fairness<br />> definition, implemented successfully in Cake.<br />> <br />> > So the end-to-end approach would suggest moving most of the scheduling back<br />> to the endpoints of each flow, with the role of the routers being to extract<br />> information about the competing flows that are congesting the network, and<br />> forwarding those signals (via drops or marking) to the endpoints. That's because,<br />> in the end-to-end argument that applies here - the router cannot do the entire<br />> function of managing congestion or priority.<br />> <br />> It must be remembered that congestion signals require one RTT to circulate from<br />> the bottleneck, via the receiver, back to the sender, and their effects to then be<br />> felt at the bottleneck. That's typically a much longer response time (say 100ms<br />> for a general Internet path) than can be achieved by packet scheduling<br />> (sub-millisecond for a 20Mbps link), and therefore effects only a looser control<br />> (by fundamental control theory). Both mechanisms are useful and complement each<br />> other.<br />> <br />> My personal interpretation of the end-to-end principle is that endpoints generally<br />> do not, cannot, and *should not* be aware of the topology of the network between<br />> them, nor of any other traffic that might be sharing that network. The network<br />> itself takes care of those details, and may send standardised control-feedback<br />> signals to the endpoints to inform them about actions they need to take. These<br />> currently take the form of ICMP error packets and the ECN field, the latter<br />> substituted by packet drops on Not-ECT flows.<br />> <br />> - Jonathan Morton</p>
</div></font>