From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from grace.univie.ac.at (grace.univie.ac.at [IPv6:2001:62a:4:25::25:115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7DD1D208AD4 for ; Mon, 12 Nov 2012 00:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=univie.ac.at; s=rev2; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=PAWg3zLzVbwjbVmcaki4IJQrFFQDrAuFO9pkiWLxAvU=; b=FIYAvi0KJxG+bsm9F5/AOXHt+ckVyZD+c84NZ3+tS8+twjKJ6nDnZ2zMBTO9++FsthacS7Vlf6/vIJ6sZ99r1nF1itI/YXKcB6LtiypRGcMzy5BKTf0RhQqX+kae9J/8yvdaGguIwOu2eDyfWFCmowgeGYQ/Nqo3yNRPiKiMtWM=; Received: from jarvis.univie.ac.at ([131.130.3.112] helo=jarvis.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.80) (envelope-from ) id 1TXozI-0007JW-Fa; Mon, 12 Nov 2012 09:03:20 +0100 Received: from rhea.cs.univie.ac.at ([131.130.116.135] helo=rhea.cs.univie.ac.at) by jarvis.univie.ac.at with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TXozI-0007aR-Cp; Mon, 12 Nov 2012 09:03:20 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Albert Rafetseder In-Reply-To: <1210270249.AA18154@ivan.Harhan.ORG> Date: Mon, 12 Nov 2012 09:03:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49104739-8041-4BB9-84E8-A5A5398FC716@univie.ac.at> References: <1210270249.AA18154@ivan.Harhan.ORG> To: bloat X-Mailer: Apple Mail (2.1085) X-Univie-Virus-Scan: scanned by ClamAV on jarvis.univie.ac.at Subject: Re: [Bloat] Designer of a new HW gadget wishes to avoid bufferbloat 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: Mon, 12 Nov 2012 08:03:26 -0000 > Yes, I know how ring buffers work. :-) No offense meant :-) >> The trick is now to push the read =3D >> pointer forward a bit instead of holding back the write pointer. >=20 > Can't do that: the ^r pointer will normally point at some cell in the > middle of a packet being transmitted. Jerking that pointer forward > will cause us to transmit garbage consisting of partial packets, which > is the last thing we want. As it turns out from your answer to Jonathan, we were talking about the = same (kind of) implementation, i.e. keep additional information on the = start cells of packets, advance the read pointer systematically if = needed, so as not to stop transmitting in the middle of packets, etc. To save you the additional ring buffer, the starts-of-packets = information could be stored as a length or number of cells field in = front of the stream of cells of one packet. In a 46kibibit RAM, this = will consume 3-4 cells' worth of data as overhead. > But we still have to have tail drop (or my > "modified tail drop") as the backup packet drop mechanism that > protects the integrity of the ring buffer. I guess the trick is to > design the AQM policy such that it does most of the job and the > out-of-buffer packet drop mechanism is rarely exercised. "Caudal" (near tail / tail-side) drop? I wonder if it suffices to = head-drop more than one packet's worth of cells if required to keep the = read and write pointers sufficiently far apart. With a buffer of less = than four Ethernet MTUs, what's the worst case really? I'll need to get myself an envelope to scribble on... Albert. --=20 Albert Rafetseder BSc. MSc. Member of Scientific Staff University of Vienna Faculty of Computer Science Research Group Future Communication (Endowed by A1 Telekom Austria AG) Waehringer Strasse 29/5.46, A-1090 Vienna, Austria T +43-1-42777-8620 albert.rafetseder@univie.ac.at http://www.cs.univie.ac.at/fc