From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lpp01m010-f43.google.com (mail-lpp01m010-f43.google.com [209.85.215.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 8DFF3201296; Wed, 7 Dec 2011 03:53:25 -0800 (PST) Received: by lagw12 with SMTP id w12so140549lag.16 for ; Wed, 07 Dec 2011 03:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:mime-version; bh=Jni1ivBCdKvLJSoUZkweGqbVPUFbWXgsDbEzG6sQM7E=; b=PVxzgTDOsr4LZvorguytZbzP98xzZmniImGi/TLmaKq/DiRahjiM/SxbDTnjL8oQVl 0luhdDmqCg6z+otqfq6YmtScMhNd/Xnwo9GtuBzMvWRoJFwSO6Wx3SPm3XeHO36NaKSc /s3rtpMmsvJpTNl6Lg7MmFd+ZUuip2pvtVJsU= Received: by 10.152.135.225 with SMTP id pv1mr11497675lab.19.1323258803041; Wed, 07 Dec 2011 03:53:23 -0800 (PST) Received: from [10.150.51.213] (gw0.net.jmsp.net. [212.23.165.14]) by mx.google.com with ESMTPS id op2sm1392637lab.6.2011.12.07.03.53.20 (version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 03:53:21 -0800 (PST) Message-ID: <1323258799.2312.18.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> From: Eric Dumazet To: Hagen Paul Pfeifer Date: Wed, 07 Dec 2011 12:53:19 +0100 In-Reply-To: <9dfc3c5eb811f2774b378fce0158b3e7@localhost> References: <1323082774.2670.40.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <9dfc3c5eb811f2774b378fce0158b3e7@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.1- Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Cc: bloat-devel , netdev@vger.kernel.org, linux-wireless , bloat 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 11:53:26 -0000 Le mercredi 07 décembre 2011 à 11:15 +0100, Hagen Paul Pfeifer a écrit : > 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? > RED is the module to bring EWMA stuff, it seems natural to start with it. Please note that choke has a RED module too. Then later, we can add time limit stuff to other Qdisc if needed, its a plug anyway. But is there any meaning to compute a global EWMA after SFB/SFQ packet classification ? > 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? > Note that head drop is a consequence of time limit idea on top of FIFO, since only at dequeue time, we compute the delta between current time and enqueue time, and we drop/mark the (head) packet if time exceeds our current limit. In general, being able to drop/mark firsts packets in queue instead of last ones can let TCP sender be notified of congestion much earlier than a tail drop. (We gain the time to transmit whole packets in queue before receiver can report in its ACK the congestion back to sender)