From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <4bone@gndrsh.dnsmgr.net> Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DBA803CB35 for ; Wed, 15 May 2019 11:43:35 -0400 (EDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x4FFhYd0051658; Wed, 15 May 2019 08:43:34 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x4FFhXrA051657; Wed, 15 May 2019 08:43:33 -0700 (PDT) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201905151543.x4FFhXrA051657@gndrsh.dnsmgr.net> In-Reply-To: <87zhno25g0.fsf@toke.dk> To: "Toke H?iland-J?rgensen" Date: Wed, 15 May 2019 08:43:33 -0700 (PDT) CC: ecn-sane@lists.bufferbloat.net X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: Re: [Ecn-sane] Using the ECN bits as signalling for explicit congestion control X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 15:43:36 -0000 > This popped up in my Google scholar: "ABC: A Simple Explicit Congestion > Control Protocol for Wireless Networks" - https://arxiv.org/pdf/1905.03429 > > Basically, they propose an explicit congestion control mechanism that > uses signalling from the bottleneck router to slow down or speed up, and > they re-purpose ECT(0) and ECT(1) as the signalling mechanism. I do > believe the end result is rather similar to SCE, isn't it? > > The appendix contains what appears to be an extensive stability > analysis. It appears to indeed be similiar, though they solved the hard problem with: To this end, ABC routers separate ABC and non-ABC flows into two queues, and use a simple algorithm to schedule packets from these queues. ABC makes no assumptions about the conges- tion control algorithm of non-ABC flows, is robust to the presence of short or application-limited flows, and requires a small amount of state at the router. Thus they require a 2 queue AQM, something the SCE work knows is the easy way out, and are trying to solv in ways that do not require this added complexity. Also they seem to be miss named the actual bits and confused the bit names with the meaning of the 4 possible code values. The bits, per RFC are ECT(0) and ECT(1) and can be used to signal the 4 states non-ECN, ECN cable, unused, and CE (by current RFC, we intened to consume the unused as SCE) I find it interesting that the apparent publication date is ~16 days after the SCE ietf/104 presentation and some months after the SCE work had become semi public. Regards, -- Rod Grimes rgrimes@freebsd.org