LinuxSA Mailing list archives

  From: Alan Kennington <akenning@topology.org>
  To  : LinuxSA <linuxsa@linuxsa.org.au>
  Date: Mon, 11 Jun 2001 17:42:57 +0930

Re: [OT] Telstra ADSL 'Unlimited' Introduces Download Limit

On Mon, Jun 11, 2001 at 04:56:03PM +0930, Dan Shearer wrote:
> On Mon, 11 Jun 2001, Simon Hackett wrote:
> 
> > At 2:09 PM +0930 11/6/01, Alan Kennington wrote:
> > 
> > >But they have to do a bit of forward thinking first!!
> > >
> > 
> > Including how to get their customers to understand what (to them) may 
> > seem to be a very complicated approach to what their 'limit' is. 
> > Again, I'm saying -to them- - not to me or to you - because they're 
> > the ones that'll be racing off to the TIO to hit up on what might 
> > seem difficult for them to understand.
> 
> Both you and Alan have some background in this area, but I have none. I
> simply can't assess what would be better.
> 
> But if you offered a service where:
> 
>    a) I could choose to have a conventional charging scheme, or
> 
>    b) I could choose Alan's leaky bucket, with loads of parameters tunable
>       by me, but
> 
>    c) Amid all the complication there was a guarantee that I cannot
>       tune my plan to be worse than XYZ, where XYZ is some basic 
>       conventional charging scheme, but
> 
>    d) With the exception of (c) above the ISP could specify that the
>       charging was never any worse for them than some set of parameters

Dan,

I am always so perplexed when people use the word "complicated"
to describe any service level spec or pricing spec that is more
complicated than a single multiplication and addition.

Even more astounding to me is when I get this kind of reaction
from people who have an in-depth familiarity with very complex
algorithms themselves. But anything that requires more than 4 operations
on a calculator for their Internet service/charging spec is just
too "complex".

The service/charging scheme I was suggesting was arithmetically
identical to the monthly carry-over concept, except that I was
proposing a daily carry-over. That's all that "token buckets" are.
They just keep track of your carry-over. And they require only a
couple of comparisons and 1 multiplication and 1 addition.

I'm mystified that this is "complex" to people who have written
big heaps of software.

How many lines of code have you written in the last 3 years?
How does that compare to the 8 lines of my algorithm?
And how many lines of other people's uncommented code
have you read?

As you can imagine, after 12 years of research into bandwidth
management and charging mechanisms, the kinds of things that I think
are optimal _are_ complex. They include TB (token bucket) arrays,
TB trees, TB array-trees, sustained bit-rate profiles (max bit-rate
as a continuous function of time-scale), probabilistic sustained bit-rate
profiles (total traffic distribution as a function of time-scale),
trees of PBRSs, and more complex things than that.
I don't invent these concepts for intellectual exercise. They just
come naturally out of the nature of networks and facts of economics.

These are the kinds of things which I envisage for the future,
but what hope is there when even a simple token bucket (i.e. carry-over
algorithm) is considered too complex?

I don't expect my sophisticated algorithms to be expected by
the hoi polloi, although I expect them to be implemented in
real systems. But I would expect a carry-over algorithm to
be understood, and also my 3-level average bit-rate SLA that
I mentioned in a previous e-mail.
http://www.topology.org/comms/statshaper.html

Operating systems penalise processes which use a lot of CPU time by
reducing their priority (which in Unix means that the priority
number increases, of course). No one has thought to use this mechanism
in the Internet, even though vast numbers of access network operators
have studied this in their comp sci courses.

Access networks currently have the scheduling sophistication of
a 1950s mainframe. That's why there's such widespread dissatisfaction.
My guess is that Australian ISPs are waiting for US ISPs to show the way
forward, and then they'll adopt the innovations from there.

> Then I could tune the account to suit my particular pattens of use without
> fearing that I might inadvertently sent myself broke.

This is what I've been saying for well over a year now to various
ISPs. But ISPs think that if their customers use too much bandwidth,
so much the better. However, what if one of your subscribers
accidentally runs up a debt in a month which would bankrupt them?
Do you wind up their business? Do you forgive them, and pay the
upstream costs on their behalf?
Surely it is not profitable to send your subscribers broke.

Someone offered me a 2 Mbit/sec link at 36 cents/MByte or something
over a year ago. I calculated that that was $7200/day, and thought
about what that meant if someone pinged me continuously over a long weekend.
I came to the conclusion that risking bankruptcy every time I went
on holiday was not my cup of tea.

Clearly, a per-MByte country like Australia needs "budget shapers" to
be installed by [forward-thinking] ISPs for all broadband customers.

Ironically, this is really trivial to do with the linux "tc" software
and iptables etc. etc.

So here we have an idea of great value, which costs next to nothing,
and no one uses it.
I guess no one wants to be the first into the pool on a cold day.

> This would be one way of acknowledging that not only do customers like me
> have no idea how to parameterise what they are looking for but ISPs seem
> to be equally uncertain about what they are doing.

Dan, you could write the software and offer it to ISPs to do exactly what
you want to be done with controlling/bounding your traffic.
You could even get e-mail alerts to be generated when your budget
is being stressed.
This could be done as an open source project here in Adelaide
as a gift to the Internet.

Cheers,
Alan Kennington.

--------------------------------------------------------------------
    name: Dr. Alan Kennington
  e-mail: akenning@topology.org
 website: http://www.topology.org/
    city: Adelaide, South Australia
  coords: 34.88051 S, 138.59334 E
timezone: UTC+0930 http://www.topology.org/timezone.html
 pgp-key: http://www.topology.org/key_ak2.asc

-- 
LinuxSA WWW: http://www.linuxsa.org.au/  IRC: #linuxsa on irc.linux.org.au
To unsubscribe from the LinuxSA list:
  mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject