From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.merlins.org (magic.merlins.org [209.81.13.136]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id DE04621F11D; Mon, 26 Nov 2012 11:23:20 -0800 (PST) Received: from merlin by mail1.merlins.org with local (Exim 4.77 #2) id 1Td4Gz-0002uO-SR; Mon, 26 Nov 2012 11:23:17 -0800 Date: Mon, 26 Nov 2012 11:23:17 -0800 From: Marc MERLIN To: Michael Richardson Message-ID: <20121126192317.GE4860@merlins.org> References: <20121125232034.GF24680@merlins.org> <31933.1353939756@obiwan.sandelman.ca> <1353942251.571510886@apps.rackspace.com> <13866.1353944313@obiwan.sandelman.ca> <1353947863.437620265@apps.rackspace.com> <9615.1353953507@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9615.1353953507@obiwan.sandelman.ca> X-Sysadmin: BOFH X-URL: http://marc.merlins.org/ X-Operating-System: Proudly running Linux 3.1.5-core2-volpreempt-noide-hm64-20111218/Debian squeeze/sid X-Mailer: Some Outlooks can't quote properly without this header User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: marc@merlins.org Cc: cerowrt-users@lists.bufferbloat.net, dpreed@reed.com, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-users] [Cerowrt-devel] QOS settings vs speedboost and random bandwidth X-BeenThere: cerowrt-users@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Support for user problems regarding cerowrt List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 19:23:21 -0000 On Mon, Nov 26, 2012 at 01:11:47PM -0500, Michael Richardson wrote: > dpreed> I'd be happy to think about defining the pieces, but I > dpreed> really don't have time to code it, given all the other stuff > dpreed> I've done. I wonder if by putting it in these modules, one > dpreed> can use existing kernel APIs. > > How precise timing do you think we need? > > As I understand what you are saying, by periodically sending a few ICMP > messages (does it help if they are back to back?) and looking when they > are returned, one can calculate the uplink bandwidth? By the way, that was kind of what I had in mind. Capping bandwidth on the router works great for DSL where line bandwidth is known, but can't really be done right on a cable modem with effectively variable bandwidth. I kind of envisionned something where I'd enter the min and max bandwidth expected, and just like an analog modem, the router would try higher speeds first, look at how the latency is doing (vs line noise for a modem) and if it's too high, tone it down. Then, just like a modem, it could have some algorithm to try ramping back up from time to time and see what happens (I see this over periods of minutes, or even hours, not seconds). It wouldn't adapt super quickly, but at the same time it would also do better than me changing the numbers in the web interface every so often :) "How the latency is doing" could indeed be done by sending a traceroute like packet (TCP or UDP, whatever works) and an ICMP packet to the next hop up that will reply. All 3 could be done maybe once a minute? Now I'm not too sure how well that would work for seeing congestion on uplink vs downlink, but if we know the data that is being shoved in each direction and it's clearly asymetrical, it ought to be able to make a reasonable guess that's correct most of the time, no? Note, I'm not a TCP/IP congestion expert, sorry if what I just wrote isn't possible for some reason that isn't obvious to me :) Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/