Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: dpreed@reed.com
To: "Michael Richardson" <mcr@sandelman.ca>
Cc: cerowrt-users@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] [Cerowrt-users] QOS settings vs speedboost and random bandwidth
Date: Mon, 26 Nov 2012 11:37:43 -0500 (EST)	[thread overview]
Message-ID: <1353947863.437620265@apps.rackspace.com> (raw)
In-Reply-To: <13866.1353944313@obiwan.sandelman.ca>

[-- Attachment #1: Type: text/plain, Size: 3307 bytes --]


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.
 
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.
 
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.
 
 
 
-----Original Message-----
From: "Michael Richardson" <mcr@sandelman.ca>
Sent: Monday, November 26, 2012 10:38am
To: dpreed@reed.com
Cc: cerowrt-users@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] [Cerowrt-users] QOS settings vs speedboost and random bandwidth



>>>>> "dpreed" == dpreed  <dpreed@reed.com> writes:
 dpreed> You can use a small fraction of the capacity of the cable
 dpreed> uplink path to measure its queueing delay dynamically, and
 dpreed> when it gets longer than latency*"expected bitrate", reduce
 dpreed> "expected bitrate". 

 dpreed> You want to do this *as quickly as possible*, so what you do
 dpreed> is insert a "link monitor" task in the driver that sends
 dpreed> tiny probe packets addressed to the nearest "loopback point"
 dpreed> you can find/create on the other side, and measure the RTT.
 dpreed> You can use, for example, the technique used by traceroute,
 dpreed> which is to set the hop count to the smallest number that
 dpreed> causes a return ICMP packet to be sent, and send one of
 dpreed> those periodically. 

As I understand it, you can do this with 802.1ag
 http://en.wikipedia.org/wiki/IEEE_802.1ag, 
with the Loop-back frames as well.

Whether or not any of this is enabled on typical broadband networks, I
have no idea.

 dpreed> I used this specific technique to cause my uplink queue to
 dpreed> move back into my router, where I could manage it.  You can
 dpreed> also use it for the downlink queue measurement, but it
 dpreed> doesn't move the queue into the router smoothly, instead you
 dpreed> have to drop/ECN-mark the IP frames coming in. 

 dpreed> This can all be done between the IP layer and layer 2.
 dpreed> Since it exploits speedboost better, it might be worth
 dpreed> adding as an option to cerowrt, so you don't have to set a
 dpreed> speed limit explicitly when you have a single connection to
 dpreed> the public Internet. 

wow, this would be awesome... code??
-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
 Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
 then sign the petition. 


[-- Attachment #2: Type: text/html, Size: 4051 bytes --]

  reply	other threads:[~2012-11-26 16:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20121125232034.GF24680@merlins.org>
2012-11-26  8:32 ` Dave Taht
2012-11-26 14:22   ` Michael Richardson
2012-11-26 15:04     ` dpreed
2012-11-26 15:38       ` Michael Richardson
2012-11-26 16:37         ` dpreed [this message]
2012-11-26 18:11           ` Michael Richardson
2012-11-26 19:23             ` Marc MERLIN
2012-11-26 19:58             ` dpreed
2012-11-26 21:27               ` Michael Richardson
2012-11-26 22:26                 ` dpreed
2012-11-26 15:35     ` Jim Gettys
2012-11-26 18:13       ` Michael Richardson
2012-11-26 18:28         ` Jim Gettys
2012-11-26 21:29           ` Michael Richardson
2012-11-26 15:27   ` Jim Gettys

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1353947863.437620265@apps.rackspace.com \
    --to=dpreed@reed.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=cerowrt-users@lists.bufferbloat.net \
    --cc=mcr@sandelman.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox