[clug] Feedback...

[Martin Schwenke]

>>>>> "Angus" == Angus Gratton <indogus at gmail.com> writes:

    Angus> I did a blog post last week comparing some of the costs of
    Angus> mobile data plan excess usage in Australia (for example
    Angus> Virgin Mobile, $15 for a 1Gb plan incurs $2097 for the
    Angus> second gigabyte.)

    Angus> http://projectgus.com/2010/01/in-australia-a-3g-mobile-data-plan-can-cost-you-thousands/

Nicely explained so a wide audience can understand it!

Now combine this with the following story and prepare to be horrified,
because you don't actually need anything like a DoS attack.  You just
need a software installation system that doesn't like to fail...  ;-)

Back in December I upgraded my laptop to Ubuntu 9.10 (Karmic Koala)
without major problems so, a few days later, I decided it was time to
upgrade my desktop machine.  The order of upgrades might seem weird
but I'm the only user of my laptop whereas the desktop is also used by
my wife and some things need to actually work.  Anyway, that's not so
relevant.  The most relevant thing is that I run approx (a package
cache) on a little server here and most of the packages were already
in approx's cache, so the upgrade was going to be fast and painless.

Some time later I noticed that the upgrade was stuck downloading a
package.  The upgrade might have failed here and caused me to restart
- can't remember.  Anyway, I logged into my little server and noticed
lots of approx processes.  I checked the relevant cache directory and
noticed *lots* (10s) of copies of the package being downloaded.  After
much fiddling, killing, reconfiguring of approx and restarting of the
upgrade I finally managed to complete the upgrade.

So, what happened?

Approx has a setting called max_wait.  If approx has a request for a
file already underway and it receives another request for that file
then max_wait is how long approx will wait before it tries to retrieve
another copy of the file.  The default value for max wait is 10.
That's 10 *seconds*.

This should be OK in many circumstances.  However, it looks like the
Ubuntu upgrader likes to please the user so it doesn't like to fail.
So, if a file is taking too long, it likes to try again.  I haven't
looked into the details of the timeout...  but it seems to try again a
lot... 

The package that was being downloaded was supertuxkart-data.  It is
100MB.  At 8Mb/s (my maximum download rate - I'm not actually on 3G
wireless broadband ;-) that will take 100 seconds.  Superficially,
that looks like I might get 10 concurrent retries in that time.
However, each one uses bandwidth and the number of concurrent
downloads continued to increase well after my link was saturated.

The result?  3.2GB of downloads for the day.  I'm guessing that 3GB of
that would be supertuxkart-data.  At $2K per GB, that could suddenly
become a $6K package!

Now, of course, 3G wireless broadband is a lot slower than that, so
the amount of data downloaded would be less...  but I'm sure the
combination of the Ubuntu upgrader and approx could saturate a 3G
wireless broadband link for enough time to make it very expensive...

peace & happiness,
martin