<font face="times new roman" size="3"><p style="margin:0;padding:0;">Michael - My kludge code predated all of the "bloat" activity (I wrote it in 2002, when I had a Linux box as my home router, and I stopped using it because as a practical matter it was easier to use off-the-shelf home routers to support my family when I travel).  It was a complete kludge using a modified kernel, etc.  Not the right way to do it, and probably impossible to understand.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">But I've thought about coding it again for cerowrt.  Where to modularly slot it in seems to be worth thinking about.  Perhaps in two key pieces: an iptables/xfilter module and a routing/traffic control module - with some direct interaction between the two using some appropriate intermodule bus/link/coordination link.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">I'd be happy to think about defining the pieces, but I really don't have time to code it, given all the other stuff I've done.  I wonder if by putting it in these modules, one can use existing kernel APIs.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Michael Richardson" <mcr@sandelman.ca><br />Sent: Monday, November 26, 2012 10:38am<br />To: dpreed@reed.com<br />Cc: cerowrt-users@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net<br />Subject: Re: [Cerowrt-devel] [Cerowrt-users] QOS settings vs speedboost and random bandwidth<br /><br /></p>
<div id="SafeStyles1353944649"><br />>>>>> "dpreed" == dpreed  <dpreed@reed.com> writes:<br /> dpreed> You can use a small fraction of the capacity of the cable<br /> dpreed> uplink path to measure its queueing delay dynamically, and<br /> dpreed> when it gets longer than latency*"expected bitrate", reduce<br /> dpreed> "expected bitrate". <br /><br /> dpreed> You want to do this *as quickly as possible*, so what you do<br /> dpreed> is insert a "link monitor" task in the driver that sends<br /> dpreed> tiny probe packets addressed to the nearest "loopback point"<br /> dpreed> you can find/create on the other side, and measure the RTT.<br /> dpreed> You can use, for example, the technique used by traceroute,<br /> dpreed> which is to set the hop count to the smallest number that<br /> dpreed> causes a return ICMP packet to be sent, and send one of<br /> dpreed> those periodically. <br /><br />As I understand it, you can do this with 802.1ag<br /> http://en.wikipedia.org/wiki/IEEE_802.1ag, <br />with the Loop-back frames as well.<br /><br />Whether or not any of this is enabled on typical broadband networks, I<br />have no idea.<br /><br /> dpreed> I used this specific technique to cause my uplink queue to<br /> dpreed> move back into my router, where I could manage it.  You can<br /> dpreed> also use it for the downlink queue measurement, but it<br /> dpreed> doesn't move the queue into the router smoothly, instead you<br /> dpreed> have to drop/ECN-mark the IP frames coming in. <br /><br /> dpreed> This can all be done between the IP layer and layer 2.<br /> dpreed> Since it exploits speedboost better, it might be worth<br /> dpreed> adding as an option to cerowrt, so you don't have to set a<br /> dpreed> speed limit explicitly when you have a single connection to<br /> dpreed> the public Internet. <br /><br />wow, this would be awesome... code??<br />-- <br />]       He who is tired of Weird Al is tired of life!           |  firewalls  [<br />]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[<br />] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[<br /> Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE><br /> then sign the petition. <br /><br /></div></font>