From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 092EA21F0BA for ; Sun, 10 May 2015 09:48:43 -0700 (PDT) Received: from hms-beagle-5.home.lan ([217.247.216.138]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MAy40-1YzEAl174O-009wFM; Sun, 10 May 2015 18:48:15 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 10 May 2015 18:48:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <152DD781-725D-4DD7-AB94-C7412D92F82C@gmx.de> References: To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:fU8camZutYcggk11htiADo1b4cMErFNlVJd18GAMkcBNm1UQFYK uiWhSNPzLID9Op8cpQG1lvKgiRgKEMn42FJZsble60+8YlyH7v7h+oFvTNRCZAyUmzWYQ1Y C08qCSy5llLREO6/E2oHqcAJNAXyWcQ8fI63yAkFbsCgM0ZnHdLItqJDuXTl6gP3nEtAVxD fwRAEp60gL1YcbggoCNEQ== X-UI-Out-Filterresults: notjunk:1; Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Control theory and congestion control X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 16:49:20 -0000 Hi Jonathan, interesting post, lots of points to think about ;) On May 9, 2015, at 21:02 , Jonathan Morton = wrote: > > The "right" amount of buffering is *1* packet, all the time (the = goal is nearly 0 latency with 100% utilization). We are quite far from = achieving that on anything... >=20 > And control theory shows, I think, that we never will unless the = mechanisms available to us for signalling congestion improve. ECN is = good, but it's not sufficient to achieve that ultimate goal. I'll try to = explain why. I wonder, given the potentially hostile state of the internet, = can we realistically expect more than what we have right now? >=20 > Aside from computer networking, I also dabble in computer simulated = trains. Some of my bigger projects involve detailed simulations of what = goes on inside them, especially the older ones which are relatively = simple. These were built at a time when the idea of putting anything as = delicate as a transistor inside what was effectively a megawatt-class = power station was unthinkable, so the control gear tended to be = electromechanical or even electropneumatic. The control laws therefore = tended to be the simplest ones they could get away with. >=20 > The bulk of the generated power went into the main traction circuit, = where a dedicated main generator is connected rather directly to the = traction motors through a small amount of switchgear (mainly to reverse = the fields on the motors at either end off the line). Control of the = megawatts of power surging through this circuit was effected by varying = the excitation of the main generator. Excitation is in turn provided by = shunting the auxiliary voltage through an automatic rheostat known as = the Load Regulator before it reaches the field winding of the generator. = Without field current, the generator produces no power. >=20 > The load regulator is what I want to focus on here. Its job was to = adjust the output of the generator to match the power - more precisely = the torque - that the engine was capable of producing (or, in English = Electric locos at least, the torque set by the driver's controls, which = wasn't always the maximum). The load regulator had a little electric = motor to move it up and down. A good proxy for engine torque was = available in the form of the fuel rack position; the torque output of a = diesel engine is closely related to the amount of fuel injected per = cycle. The fuel rack, of course, was controlled by the governor which = was set to maintain a particular engine speed; a straightforward PI = control problem solved by a reasonably simple mechanical device. >=20 > So it looks like a simple control problem; if the torque is too low, = increase the excitation, and vice versa. >=20 > Congestion control looks like a simple problem too. If there is no = congestion, increase the amount of data in flight; if there is, reduce = it. We even have Explicit Congestion Notification now to tell us that = crucial data point, but we could always infer it from dropped packets = before. I think we critically depend on being able to interpret lost = packets as well, as a) not all network nodes use ECN signaling, and b) = even those that do can go into =93drop-everything=94 mode if overloaded. >=20 > So what does the load regulator's control system look like? It has as = many as five states: fast down, slow down, hold, slow up, fast up. It = turns out that trains really like changes in tractive effort to be slow = and smooth, and as infrequent as possible. So while a very simple "bang = bang" control scheme would be possible, it would inevitably oscillate = around the set point instead of settling on it. Introducing a central = hold state allows it to settle when cruising at constant speed, and the = two slow states allow the sort of fine adjustments needed as a train = gradually accelerates or slows, putting the generator only slightly out = of balance with the engine. The fast states remain to allow for quick = response to large changes - the driver moves the throttle, or the motors = abruptly reconfigure for a different speed range (the electrical = equivalent of changing gear). I think I see where you are going with this ;). Question: how = would a 5 state system look at an intermediate network router? I have = two [points I do not see clear at all. 1) Competiton with simple greedy = non-ECN flows, if these push the router into the dropping regime how = will well behaved ECN flows be able to compete? And how can the = intermediate router control/check that a flow truly is well-behaved, = especially with all the allergies against keeping per-flow state that = router=92s seem to have? >=20 > On the Internet, we're firmly stuck with bang-bang control. As big an = improvement as ECN is, it still provides only one bit of information to = the sender: whether or not there was congestion reported during the last = RTT. Thus we can only use the "slow up" and "fast down" states of our = virtual load regulator (except for slow start, which ironically uses the = "fast up" state), and we are doomed to oscillate around the ideal = congestion window, never actually settling on it. Is the steady state, potentially outside of the home, link truly = likely enough that an non-oscillating congestion controller will = effectively work better? In other words would the intermediate node ever = signal hold sufficiently often that implementing this stage seems = reasonable? >=20 > Bufferbloat is fundamentally about having insufficient information at = the endpoints about conditions in the network. We've done a lot to = improve that, by moving from zero information to one bit per RTT. But to = achieve that holy grail, we need more information still. True, but how stable is a network path actually over seconds = time frames? >=20 > Specifically, we need to know when we're at the correct BDP, not just = when it's too high. And it'd be nice if we also knew if we were close to = it. But there is currently no way to provide that information from the = network to the endpoints. Could an intermediate router actually figure out what signal to = send all flows realistically? Best Regards Sebastian >=20 > - Jonathan Morton > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake