From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hagen@jauu.net>
Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de
	[88.198.24.89])
	by huchra.bufferbloat.net (Postfix) with ESMTP id 5F30D201296;
	Wed,  7 Dec 2011 02:15:40 -0800 (PST)
Received: by geheimer.internetendpunkt.de (Postfix, from userid 33)
	id D15D7F44130; Wed,  7 Dec 2011 11:15:38 +0100 (CET)
To: Eric Dumazet <eric.dumazet@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Date: Wed, 07 Dec 2011 11:15:38 +0100
From: Hagen Paul Pfeifer <hagen@jauu.net>
In-Reply-To: <1323082774.2670.40.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
References: <CAA93jw7kQYONQiAozatRmdRRJeK0GB9eNDWtRZ3AL+OVKn0OpA@mail.gmail.com>
	<1323082774.2670.40.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Message-ID: <9dfc3c5eb811f2774b378fce0158b3e7@localhost>
X-Sender: hagen@jauu.net
User-Agent: RoundCube Webmail/0.1-rc1
Cc: bloat-devel <bloat-devel@lists.bufferbloat.net>, netdev@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Time in Queue, bufferbloat,
	and... our accidentally  interplanetary network
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2011 10:15:40 -0000


On Mon, 05 Dec 2011 11:59:34 +0100, Eric Dumazet wrote:


> Adding a time limit is possible, all we need is a proper design and
> implementation :)
> 
> Here is my suggestion :
> 
> Design a new tfifo/tred qdisc, with following properties :
> 
> Adaptative RED, (ECN enabled + head drop), but instead of using
> bytes/packet qlen average, use time_in_queue average.

Question one: is anything wrong with sfb or choke as the basis, instead of
RED?

Question two: I submitted pfast_head_drop to drop more outdated data
instead of new data. Back in time I thought TCP _may_ experience benefits
because more up-to-date SACK data packets are saved. Are there any other
TCP advantages with head drop policy?

Hagen