Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Michael Richardson <mcr@sandelman.ca>
Cc: Richard Brown <richard.e.brown@dartware.com>,
	"cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Bufferbloat at upcoming LUG talk
Date: Mon, 26 Nov 2012 15:00:45 +0100	[thread overview]
Message-ID: <CAA93jw6P-LVda40ODMZ6uospgENSpjpNw--U2tBLdFaedcRfog@mail.gmail.com> (raw)
In-Reply-To: <10146.1353932800@obiwan.sandelman.ca>

On Mon, Nov 26, 2012 at 1:26 PM, Michael Richardson <mcr@sandelman.ca> wrote:
>
>>>>>> "Richard" == Richard Brown <richard.e.brown@dartware.com> writes:
>     Richard> - I can see how the CeroWrt de-bloating algorithms help
>     Richard> protect against bad latency when I'm *uploading* big
>     Richard> files. I'm not sure whether using CeroWrt with its
>     Richard> CoDel/FQ/SFQ/etc. helps when I'm downloading big files,
>     Richard> though. What can I say about this?
>
> If the link from the broadband to the laptop is wireless, than it's
> quite possible that the wireless link experiences bufferbloat.
> This would be true:
>      - if the laptop is far from the base station the rate could be
>        lower than the broadband download link. (Especially now that
>        cable offers 50Mb/s downlinks...)
>      - if the wireless is bridged to wired, and there are many windows
>        boxes, broadcasting a lot, then the wireless link may be
>        otherwise saturated

One point of the rrul tests are that netserver runs out of xinetd on
the router itself,
so it's possible to test wifi performance in the presence of multiple workloads.

 However, the overhead of running netserver on such a small box is too
extreme, presently. I hope to produce a simpler test that can, indeed,
work right on cerowrt, so you can easily diagnose the inside path on
your network.

You can certainly install netperf 2.6 or later on a heftier box,
locally on your network, and test wifi and wired that way.

>
> bad uplink latency will affect TCP ACKs, and can totally ruin your
> interactive ssh day too.

s/can/does

> But, in general, either the ISP has to debloat too, or it has to rate
> limit to below the actual bandwidth.

Rate limiting below the ISP's provided downlink-to-you bandwidth does
work, but tends to chop off 10-15% of what the ISP claims they are
providing.

>     Richard> - I believe the default DNS server in Sugarland is dnsmasq,
>     Richard> not bind. Is DNSSEC enabled by default? Also: there's a
>     Richard> report (Bug #411) that says that DNS is leaking internal
>     Richard> names to the outside world. What's the best advice for
>     Richard> closing this? ("list notinterface 'ge00'" is one
>     Richard> recommendation…)
>
> (In general, leaking names is really not that much of a worry...)

Names, no. Amplification attacks are a serious problem with DNS.

The internet is rife with worms and daemons that are leveraging open
dns servers to amplification attacks. In a few short weeks that macej
had left the port open,

http://www.bufferbloat.net/issues/411

"Having DNS open for a while made some evil forces notice it and use my IP
for DNS amplification attacks. I secured dnsmasq not to listen on ge00, but
I'm still getting over 300 UDP packets/s!"

I really hate having contributed to this problem with sugarland.
Nobody wants an extra 300 packets/s hitting their home network for any
reason. Please close this immediately upon installing sugarland.

I've tried very hard to respond to CVEs over the course of this
project (bind alone, had 5), but I'm away from the lab, in the middle
of a trip, in between a major upgrade of functionality to cerowrt and
trying to get funding to re-invigorate this project.

I haven't had much time to hack. None to test.

I would to get to where we had infrastructure to easily create, test,
and push out security related fixes.

>
>     Richard> My plan is to give a little of the science behind
>     Richard> bufferbloat mitigation and also put in a plug for
>     Richard> CeroWrt. Any topics I haven't already mentioned that I
>     Richard> should? Thanks!
>
> Use the fountain images that Van Jacobson used at IETF84.

In my own preso at the lincs, I used my coffee cup...

There is an interesting preso that shemminger is using that uses soda
bottles to do something similar to both concepts. Jamming holes into
it randomly to simulate red....

I may adopt this - however in explaining fq_codel, I think I need to
add multiple cups, and an eye-dropper for the ant packets.
>
> --
> ]       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.
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

  reply	other threads:[~2012-11-26 14:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.4092.1353748990.1742.cerowrt-devel@lists.bufferbloat.net>
2012-11-26  1:11 ` Richard Brown
2012-11-26 11:49   ` Dave Taht
2012-11-26 15:37     ` Jim Gettys
2012-11-26 12:26   ` Michael Richardson
2012-11-26 14:00     ` Dave Taht [this message]
2012-11-26 15:28       ` Michael Richardson
     [not found] ` <A2E41EFF-2507-457D-9086-06E718192D22@intermapper.com>
2012-12-09 16:56   ` [Cerowrt-devel] Bufferbloat at LUG talk - Meeting Report Richard Brown
2012-12-09 17:32     ` Maciej Soltysiak
2012-12-10  0:16       ` Richard Brown

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=CAA93jw6P-LVda40ODMZ6uospgENSpjpNw--U2tBLdFaedcRfog@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=mcr@sandelman.ca \
    --cc=richard.e.brown@dartware.com \
    /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