Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Using HTB as an ISP "provisioning engine"
Date: Thu, 19 Dec 2002 21:10:29 +0000	[thread overview]
Message-ID: <marc-lartc-104033233406529@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104033114505084@msgid-missing>

On Thursday 19 December 2002 21:51, Brian Capouch wrote:
> I am new to shaping but not to routing; forgive me if this request is
> inappropriate for this list.
>
> I am a very small ISP and would like to use HTB to enforce contractual
> bandwidth limits on my customers.  I am trying to think through one
> aspect of this that is vexing me.  I'm sure it's no great secret that
> many ISPs oversell their bandwidth, and in our case we have a
> combination of accounts that total approximately 2.2Mbs on our feed,
> which is 1.2Mbs. (Concentrating right now on our download stream)
>
> How could something like this be accomodated?  The documentation says
> that the total bandwidth allocations of a set of subclasses should total
> that assigned to the class.
>
> But my understanding is that if I bump up the bandwidth on the primary
> class to a value greater than my actual bandwidth, then I'm going to be
> filling up queues at the upstream ISP and negatively affecting my
> performance.
>
> I'm sure there is something I'm missing, but I've discussed this with a
> couple of fellow network engineers and neither was able to posit how
> such thing might work, although they both said they were sure that it is
> a common scenario.
You can create a root class with rate = ceil = 1.2 Mbps.  Create a class for 
each customer with ceil = selled bandwidth and the sum of the rates=1.2Mbps.

Example :
You selled 1.1 Mbps to customer1 and 0.37 (=2.2Mbps/6) to 3 other customers.  
So you have a total bandwidth of 2.2Mbps.  But you have only 1.2 Mbps 
available.
class rate = ceil = 1.2 Mbps
  class1 rate = 0.6, ceil = 1.1Mbps
  class2 rate = 0.2, ceil = 0.37Mbps
  class3 rate = 0.2, ceil = 0.37Mbps
  class4 rate = 0.2, ceil = 0.37Mbps

The bandwidth you selled to the customers is the ceil.  They never can use 
more then the ceil.  If one customer is using no bandwidth, the remaining 
bandwidth is given to the other customers.
If all customers are using all bandwidth, each customer is "punished" in the 
same way.

You can also give the customers a possibility to use as much bandwidth as 
available.  To do so, give each class ceil = 1.2Mbps, but that bandwidth is 
not guaranteed.  In this case, the rate is the minimum bandwidth they can 
get.  So for a SLA, you can say to the customer : "You have a minimum 
bandwidth of 0.6Mbps and a maximum bandwidth of 1.2Mbps."

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  reply	other threads:[~2002-12-19 21:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-19 20:51 [LARTC] Using HTB as an ISP "provisioning engine" Brian Capouch
2002-12-19 21:10 ` Stef Coene [this message]
2002-12-20  5:24 ` S Mohan
2002-12-20 11:07 ` Daniel Egger
2002-12-23 16:30 ` raptor
2002-12-23 16:53 ` Stef Coene

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

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

  git send-email \
    --in-reply-to=marc-lartc-104033233406529@msgid-missing \
    --to=stef.coene@docum.org \
    --cc=lartc@vger.kernel.org \
    /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