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 CA72821F0F2 for ; Mon, 22 Oct 2012 09:00:19 -0700 (PDT) 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=BjFpk2yTqJzadUqGIm1CbpEoU+QStD3PKGi8bigKZJA=; b=TMeqKcT4PkVUso5g/C/g/aCJubkb2rtjAYKXNtl5v6AtJTX9Nu6iXzLTxnSvF1FmmYWt47xRyt/Yop1K+DgnN6FhG6Dj9gNoyq70hmjJXpqq2uosLwOljt2YhyhQ96E/tzlynwwP9EHIpjxTwVUcnl+qqGaFViHzZfSDGlNfBJo=; Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.80) (envelope-from ) id 1TQKQI-0005Tw-5U; Mon, 22 Oct 2012 18:00:14 +0200 Received: from 046207099148.atmpu0028.highway.a1.net ([46.207.99.148] helo=[192.168.43.184]) by justin.univie.ac.at with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TQKQG-0007aZ-Ai; Mon, 22 Oct 2012 18:00:14 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Albert Rafetseder In-Reply-To: <1210140341.AA29907@ivan.Harhan.ORG> Date: Mon, 22 Oct 2012 17:58:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1210140341.AA29907@ivan.Harhan.ORG> To: bloat X-Mailer: Apple Mail (2.1085) X-Univie-Virus-Scan: scanned by ClamAV on justin.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, 22 Oct 2012 16:00:20 -0000 Hi Michael, Not that I'm an expert of any means on the topics you touch, but I'll = share my point of view on some of the questions raised. Please excuse my = aggressive shortening of your original post. > http://ifctfvax.Harhan.ORG/OpenWAN/OSDCU/ The site appears down, but from your description I think I understand = what you are building. > The SDSL->HDLC direction involves no bufferbloat issues: I can set > things up so that no received packet ever has to be dropped, and the > greatest latency that may be experienced by any packet is the HDLC > side (DSU->DTE router) transmission time of the longest packet size > allowed by the static configuration - and I can statically prove that > both conditions I've just stated will be satisfied given a rather > small buffer of only M+1 ATM cells, where M is the maximum packet size > set by the static configuration, translated into ATM cells. (For IPv4 > packets of up to 1500 octets, including the IPv4 header, using the > standard RFC 1483 encapsulation, M=3D32.) You must also rule out ATM cell loss and reordering. Otherwise, there is = too little data in your receive buffer to reassemble the transmitted = frame (temporarily with reordering, terminally with loss). This calls = for a timeout of sorts. Quoting RFC 791 "Internet Protocol": "The current recommendation for the initial timer setting is 15 = seconds." My colleague tells me his Linux boxes (3.5/x64, 2.6.32/x86) have an = ip.ipfrag_time of 30 seconds. Anyway, it's lots of cells to buffer, I = suppose. > Strictly speaking, one could set the bit rate for the router->DSU > direction of the V.35 interface so low that no matter what the router > sends, that packet stream will always fit on the SDSL side without a > packet ever having to be dropped. However, because the worst case > expansion in the HDLC->SDSL direction is so high (in one hypothetical > case I've considered, UDP packets with 5 octets of payload, such that > each IPv4 packet is 33 octets long, the RFC 1490->1483 expansion is > 2.4x *before* the cell tax!), setting the clock so slow that even a > continuous HDLC line rate stream of worst-case packets will fit is not > a serious proposition. Setting the ingress rate into your board on the HDLC side that low also = pushes the potential bloat issue into the router's transmit buffer which = might be even more difficult to control. > L is the maximum allowed HDLC->SDSL packet latency measured in ATM > cells, which directly translates into milliseconds for each given SDSL > kbps tier [...] > My proposed logic design will drop the packet if that > latency measure exceeds a set threshold, or allow it through > otherwise. My questions to the list are: >=20 > a) would it be a good packet drop policy, or not? >=20 > b) if it is a good policy, what would be a reasonable value for the > latency threshold L? (In ATM cells or in ms, I can convert :) >=20 > The only major downside I can see with the approach I've just outlined > is that it is a tail drop. I've heard it said in the bufferbloat > community that tail drop is bad and head drop is better. However, > implementing head drop or any other policy besides tail drop with the > HW logic design outlined above would be very difficult: if the buffer > is physically structured as a queue of ATM cells, rather than packets, > then deleting a packet from the middle of the queue (it does no good > to abort the transmission of a packet already started, hence head drop > effectively becomes middle drop in terms of ATM cells) becomes quite a > challenge. Canceling packets halfway through transmission makes no sense. I think = there are many good arguments for head-drop, and while I'm not a = hardware engineer, I don't see why it would be terribly difficult to = implement. Suppose you have a list of starts of packets addresses within = your cell transmit ring buffer. Drop the first list element. Head drop! = Done! Once the current packet's cells are transmitted, you jump to the = next start of packet in the list, wherever it is. As long as you ensure = that packets you receive on the HDLC side don't overwrite the cells you = are currently transmitting, you are fine. (If the buffer was really = small, this probably meant lots of head drop.) As regards values for the maximum latency L, this might be a too = restrictive way of thinking of queue lengths. Usually, you'd like to = accommodate for short bursts of packets if you are sure you can get the = packets out in reasonable time, but don't want a long "standing queue" = to develop. You might have read over at ACM Queue [1] that the CoDel = queue management algorithm starts dropping packets if the time packets = are enqueued exceeds a threshold. This doesn't mean that the queue = length has a hard upper limit, though -- it will try to keep the queue = short (as dropping packets signals "back off!" to the end hosts = communicating across the link) with some elasticity towards longer = enqueueing times. Maybe you'd like to be the pioneer acid-testing = CoDel's implementability in silicon. [1] http://queue.acm.org/detail.cfm?id=3D2209336 Does any of this make sense to you? Cheers, 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