From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8D2A321F34A for ; Tue, 12 May 2015 20:53:52 -0700 (PDT) Received: by layy10 with SMTP id y10so20254010lay.0 for ; Tue, 12 May 2015 20:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y95Jw89eHMIvv3RaLAU4WzfdMP8xt5kWL1CszBc1IyA=; b=IbY20KkT27lzFe8j0eVx/o3oyn9gn7Cl3VhD1no+uqzrJAD36R7JCFD9nx6F4ovMgX zrcwhcE58ZOo4YbIQ+Pn3CEilnPEdBDja69vSNtdtMq3kfc2iCeOMMl+wVhlPgidrHq6 4B6U+1LzA4yLA+tU1pBsH3jyp3jmPMcSqb+IWEhiPvl/nAxTB1gLTcpRMAkgFev0MsSP /hwpXWIyc9xW2KLCJtN2vrkVglm+zuyBzLkbNisJ7B3+5rKqTdd1mnodzyXcM7kYMI/a hVPmPl98prEgDiBAHlpAcWTpuyeejdFKKURwPkzHkExlB4aty1kfRTfRHsylxz/VdQH6 o1TA== X-Received: by 10.152.21.136 with SMTP id v8mr1844543lae.19.1431489230725; Tue, 12 May 2015 20:53:50 -0700 (PDT) Received: from bass.home.chromatix.fi (87-93-63-112.bb.dnainternet.fi. [87.93.63.112]) by mx.google.com with ESMTPSA id ac6sm4500137lbd.41.2015.05.12.20.53.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 May 2015 20:53:49 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Wed, 13 May 2015 06:53:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <54C4B6F6-B3A6-4271-88B5-566B727389FE@gmail.com> References: <152DD781-725D-4DD7-AB94-C7412D92F82C@gmx.de> <1F323E22-817A-4212-A354-C6A14D2F1DBB@gmail.com> <7E879DBB-1EFB-46FA-9230-A5AFC97B93B0@gmail.com> To: David Lang X-Mailer: Apple Mail (2.2098) 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: Wed, 13 May 2015 03:54:22 -0000 >> So what you might have is an ELR queue happily controlling the cwnd = based on the assumption that *it* is the bottleneck, which until now it = has been. But *after* that queue is another one which has just *become* = the bottleneck, and it=92s not ELR - it=92s plain ECN. The only way it = can tell the flow to slow down is by giving =93fast down=94 signals. = But that=92s okay, the endpoints will react to that just as they should = do, as long as they correctly interpret the most restrictive signal as = being the operative one. >=20 > how would the ELR queue know that things should slow down? If it isn't = the bottleneck, how does it know that there is a bottleneck and the flow = that it's seeing isn't just the application behaving normally? The ELR queue doesn=92t know anything about the other one, and doesn=92t = need to. The *new* bottleneck sends ECN signals, which override the ELR = =93hold" signals (which are sent using the same two bits in the TOS = byte). ELR endpoints react to both ECN and ELR signals. The send rate = reduces, and the ELR queue is no longer saturated, ergo no longer the = bottleneck; it then stops sending =93hold=94. So it=92s possible to have two queues which simultaneously believe they = are the bottleneck, but only as a transient condition. In fact, we = often have that today, when we insert a shaped ingress queue *after* our = last-mile link. Please read the post entitled =93Explicit Load Regulation=94, which I = wrote after spending several hours figuring out the right way to do it, = and try to keep up. >> On many links, light traffic such as e-mail will disturb the balance = too little to even notice, especially with flow isolation. >=20 > This depends on the bandwidth and the type of e-mail. It's very common = for single e-mails in an office environment to be several MB (not the = ones with big document or spreadsheet attachments, but the things like = holiday party announcements and other similar things) But you=92re not getting those continuously, are you? Or, if you are, = it=92s time to reconfigure the office=92s spam filter. So while a *big* email is coming in, the bandwidth available to other = flows might be disturbed. ELR will help to adjust to that, just like = ECN does. Then it=92ll adjust back when the disturbance has gone, and = resume the steady state. This is not rocket science. This is 1950s locomotive technology. > e-mail to a mobile device can have a rather significant impact on cell = or wifi bandwidth. Yes - at least on mobile, I=92d agree - but that=92s one case. There = are others. And even on a mobile connection, it=92s potentially useful to have a = well-defined steady state, when conditions are right for it. It=92s = harder to get to those conditions in a wireless environment, but not = impossible, especially for rate-limited subscriptions. As they say, don=92t ban steak just because a baby can=92t eat it. >> Of course, as with any speculation of this nature, simulations and = other experiments will tell a more convincing story. >=20 > I have a significant distrust of simulations at this point. Hence =93and other experiments=94. But it=92s also likely that simulations will help to understand the = emergent behaviour of something like ELR, before anyone expends too much = effort on implementation and standardisation. - Jonathan Morton