From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eric.dumazet@gmail.com>
Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(Client CN "smtp.gmail.com",
	Issuer "Google Internet Authority" (verified OK))
	by huchra.bufferbloat.net (Postfix) with ESMTPS id DA99F201AEE
	for <codel@lists.bufferbloat.net>; Thu, 28 Jun 2012 11:12:37 -0700 (PDT)
Received: by eeke50 with SMTP id e50so1601502eek.16
	for <codel@lists.bufferbloat.net>; Thu, 28 Jun 2012 11:12:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=AhLmA04CMXl/W8ljl5xjFYqoqrAxewJ5hBjXom6k9C8=;
	b=lU8mJ3GE1ZYY2kDvL2gfXtBRm6bTySW1R66k31F6fcbLgKxlbNrDsvSmba+4QSFehS
	wG4138hrgx9q6UbqT3qqsx1oNQEb3/XK7QW6sdap33Xxn0BGF4z/cCZAFIy8xnq75ef3
	efWm/xCgPuTOoFjYc4ofNsRNIhHnxPJMIWpSX+uH/4yrbNSp/hHJQMHuCRSJBjOuQ/pr
	PyNvEYmJO+QUeXRKXubvaJ93QPuP62IFmV+HTSJ0tW3fhXVsYBL+sLsaMjKwm26O3ySZ
	L8V8Yof1JWBJp1ZifVXy/rhzjkv2Yo6MbjLYr+8U+9W6dZ82CBzxqOTarvyroI0+xXvP
	eWnw==
Received: by 10.14.95.6 with SMTP id o6mr664065eef.144.1340907155925;
	Thu, 28 Jun 2012 11:12:35 -0700 (PDT)
Received: from [172.28.89.75] ([74.125.122.49])
	by mx.google.com with ESMTPS id y54sm93449eef.10.2012.06.28.11.12.33
	(version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 11:12:34 -0700 (PDT)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
In-Reply-To: <CAA93jw7agn2J6Hd7x22KWhENY5jqVjnk6uRr=3LJ5Anw7EgacQ@mail.gmail.com>
References: <1340903237.13187.151.camel@edumazet-glaptop>
	<CAA93jw7agn2J6Hd7x22KWhENY5jqVjnk6uRr=3LJ5Anw7EgacQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 28 Jun 2012 20:12:31 +0200
Message-ID: <1340907151.13187.169.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Cc: Nandita Dukkipati <nanditad@google.com>, netdev <netdev@vger.kernel.org>,
	codel@lists.bufferbloat.net, Yuchung Cheng <ycheng@google.com>,
	Neal Cardwell <ncardwell@google.com>, David Miller <davem@davemloft.net>,
	Matt Mathis <mattmathis@google.com>
Subject: Re: [Codel] [PATCH net-next] fq_codel: report congestion
 notification at enqueue time
X-BeenThere: codel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: CoDel AQM discussions <codel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/codel>
List-Post: <mailto:codel@lists.bufferbloat.net>
List-Help: <mailto:codel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2012 18:12:38 -0000

On Thu, 2012-06-28 at 10:51 -0700, Dave Taht wrote:

> clever idea. A problem is there are other forms of network traffic on
> a link, and this is punishing a single tcp
> stream that may not be the source of the problem in the first place,
> and basically putting it into double jeopardy.
> 

Why ? In fact this patch helps the tcp session being signaled (as it
will be anyway) at enqueue time, instead of having to react to packet
losses indications given (after RTT) by receiver.

Avoiding losses help receiver to consume data without having to buffer
it into Out Of Order queue.

So its not jeopardy, but early congestion notification without RTT
delay.

NET_XMIT_CN is a soft signal, far more disruptive than a DROP.

> I am curious as to how often an enqueue is actually dropping in the
> codel/fq_codel case, the hope was that there would be plenty of
> headroom under far more circumstances on this qdisc.
> 

"tc -s qdisc show dev eth0" can show you all the counts.

We never drop a packet at enqueue time, unless you hit the emergency
limit (10240 packets for fq_codel). When you reach this limit, you are
under trouble.