From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp116.iad3a.emailsrvr.com (smtp116.iad3a.emailsrvr.com [173.203.187.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8CD7F3B2A4 for ; Mon, 25 Mar 2019 18:53:49 -0400 (EDT) Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5952225E55; Mon, 25 Mar 2019 18:53:49 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 53C0C25E61; Mon, 25 Mar 2019 18:53:49 -0400 (EDT) Received: from app23.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3B48925E55; Mon, 25 Mar 2019 18:53:49 -0400 (EDT) Received: from app23.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Mon, 25 Mar 2019 18:53:49 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app23.wa-webapps.iad3a (Postfix) with ESMTP id 27BAB60058; Mon, 25 Mar 2019 18:53:49 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 25 Mar 2019 18:53:49 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Mon, 25 Mar 2019 18:53:49 -0400 (EDT) From: "David P. Reed" To: "Mikael Abrahamsson" Cc: "Jonathan Morton" , ecn-sane@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190325185349000000_43982" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <3E9C6E74-E335-472B-8745-6020F7CDBA01@gmx.de> <907D3152-4AD5-4551-AA6A-46FF9CA567DE@gmail.com> Message-ID: <1553554429.159920096@apps.rackspace.com> X-Mailer: webmail/16.2.2-RC Subject: Re: [Ecn-sane] =?utf-8?q?robustness_against_attack=3F?= 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: Mon, 25 Mar 2019 22:53:49 -0000 ------=_20190325185349000000_43982 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThe only latency-under-load mechanism other than FQ that can work is "no= (absolute minimal) queueing". That's fine as a goal.=0A =0AUnfortunately, = I would suggest that the whole concept of ECN/SCE has to be rethought from = the ground up if the goal is "no queueing", because ECN and SCE are current= ly defined only when a queue has built up, which of course means that laten= cy has built up.=0A =0ANow, of course, throughput is completely independent= of queueing delay (except when there are a lot of erasure errors on the li= nks, in which case modest queueing can perhaps enhance aggregate throughput= ).=0A =0AWhen the whole point of things is to minimize queueing delay throu= gh whatever links turn out to be bottlenecks, by getting flows to be thrott= led by lowering cwnd or source rate or whatever, the ONLY way to do this is= to get early feedback as queueing just begins to build.=0A =0A(Of course, = I am one of those people who constantly point out that classes of service h= ave no meaning, really, unless one precisely defines the queue management i= n terms of flows, not individual packets).=0A =0AI really worry that this d= iscussion is going off the rails due to a lack of understanding of queueing= theory and control theory.=0A ------=_20190325185349000000_43982 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The only latency-under= -load mechanism other than FQ that can work is "no (absolute minimal) queue= ing". That's fine as a goal.

=0A

 

=0A

Unfortunately, I would suggest that the whole concept of ECN= /SCE has to be rethought from the ground up if the goal is "no queueing", b= ecause ECN and SCE are currently defined only when a queue has built up, wh= ich of course means that latency has built up.

=0A

&= nbsp;

=0A

Now, of course, throughput is completely i= ndependent of queueing delay (except when there are a lot of erasure errors= on the links, in which case modest queueing can perhaps enhance aggregate = throughput).

=0A

 

=0A

W= hen the whole point of things is to minimize queueing delay through whateve= r links turn out to be bottlenecks, by getting flows to be throttled by low= ering cwnd or source rate or whatever, the ONLY way to do this is to get ea= rly feedback as queueing just begins to build.

=0A

&= nbsp;

=0A

(Of course, I am one of those people who c= onstantly point out that classes of service have no meaning, really, unless= one precisely defines the queue management in terms of flows, not individu= al packets).

=0A

 

=0A

I= really worry that this discussion is going off the rails due to a lack of = understanding of queueing theory and control theory.

=0A

 

 ------=_20190325185349000000_43982--