From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 46A3B21F411 for ; Sun, 10 May 2015 11:32:56 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so80920635lbb.3 for ; Sun, 10 May 2015 11:32:49 -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=ckW5AoLoe5X/SdKP3WDOXh8lVA20RyCRHDnfl14oguE=; b=zrYpsDjx6PjvnniiNvNOgSzeMpkdS6uvNASb3r22a/6xRibJrPK6SQssh0buQspvB9 ycEbeg0EEIzNQM3kx3E697cGJjzWINcWnxSYdCMyHAoP1LmNBSWo57qY13zxfKCXZQje KrhsGtsH/a6iXC3qITCps60khq129wTiYD68faNnSSd5CIBXNXVrTn27jf55kEfLWS/l 9m1OEJZ5Usbq1/5cx25Kq/8oqopeZ5EgIZqQDjVcKMamPau9UY3CfHNoFMKLTE1wHjzP OYbFo/Ho7Zvc/qUBFQ0TODZgPSk2B97Qzithqku1dPqrmVDagsZSQlwltqio6ln7YJIJ dEGg== X-Received: by 10.112.134.167 with SMTP id pl7mr5398632lbb.50.1431282769615; Sun, 10 May 2015 11:32:49 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-127-129.bb.dnainternet.fi. [188.67.127.129]) by mx.google.com with ESMTPSA id jp18sm2536604lab.34.2015.05.10.11.32.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 May 2015 11:32:48 -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: <152DD781-725D-4DD7-AB94-C7412D92F82C@gmx.de> Date: Sun, 10 May 2015 21:32:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1F323E22-817A-4212-A354-C6A14D2F1DBB@gmail.com> References: <152DD781-725D-4DD7-AB94-C7412D92F82C@gmx.de> To: Sebastian Moeller 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: Sun, 10 May 2015 18:33:39 -0000 > On 10 May, 2015, at 19:48, Sebastian Moeller wrote: >=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. >=20 > 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. Yes, but I consider that a degraded mode of operation. Even if it is, = for the time being, the dominant mode. > 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? Backwards compatibility for current ECN means dropping non-ECN packets = that would have been marked. That works, so we can use it as a model. Backwards compatibility for =93enhanced=94 ECN - let=92s call it ELR for = Explicit Load Regulation - would mean providing legacy ECN signals to = legacy ECN traffic. But, in the absence of flow isolation, if we only = marked packets with ECN when they fell into the =93fast down=94 category = (which corresponds to their actual behaviour), then they=92d get a clear = advantage over ELR, similar to TCP Vegas vs. Reno back in the day (and = for basically the same reason). The solution is to provide robust flow isolation, and/or to ECN-mark = packets in =93hold=94 and =93slow down=94 states as well as =93fast = down=94. This ensures that legacy ECN does not unfairly outcompete ELR, = although it might reduce ECN traffic=92s throughput. The other side of the compatibility coin is what happens when ELR = traffic hits a legacy router (whether ECN enabled or not). Such a = router should be able to recognise ELR packets as ECN and perform ECN = marking when appropriate, to be interpreted as a =93fast down=94 signal. = Or, of course, to simply drop packets if it doesn=92t even support ECN. > 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? Core routers don=92t track flow state, but they are typically = provisioned to not saturate their links in the first place. Adequate = backwards-compatibility handling will do here. Edge routers are rather more capable of keeping sufficient per-flow = state for effective flow isolation, as cake and fq_codel do. Unresponsive flows are already just as much of a problem with ECN as = they would be with ELR. Flow isolation contains the problem neatly. = Transitioning to packet drops (ignoring both ECN and ELR) under overload = conditions is also a good safety valve. > 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? It=92s a fair question, and probably requires further research to answer = reliably. However, you should also probably consider the typical nature = of the *bottleneck* link, rather than every possible Internet link. = It=92s usually the last mile. > True, but how stable is a network path actually over seconds time = frames? Stable enough for VoIP and multiplayer twitch games to work already, if = the link is idle. > Could an intermediate router actually figure out what signal to send = all flows realistically? I described a possible method of doing so, using information already = available in fq_codel and cake. Whether they would work satisfactorily = in practice is an open question. - Jonathan Morton