[LARTC] HFSC Advanced Limiting

* [LARTC] HFSC Advanced Limiting
@ 2005-10-13 14:41 Eliot, Wireless and Server Administrator,  Great Lakes Internet
  2005-10-13 19:45 ` Jason Boxman
                   ` (11 more replies)
  0 siblings, 12 replies; 13+ messages in thread
From: Eliot, Wireless and Server Administrator,  Great Lakes Internet @ 2005-10-13 14:41 UTC (permalink / raw)
  To: lartc

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

--===============1335067882==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5D004.2CC3F3F6"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 3336 bytes --]

I am investigating changing our broadband bandwidth control scripts over to HFSC. What I would like to accomplish is this:

{ * DOWNLOAD *
  I need a download class for each user (we'll call it Class 1) that offers a minimum of lets say 384Kbps and a maximum of 1.5Mbps.

  The rates between 384Kbps and 1.5Mbps should be shared among all users. 

  Each user should always be able to get at least 384Kbps.

  Inside this main class for each user, there will be different categories of traffic (VoIP, P2P, General).

  The VoIP subclass (Class 11) should offer a real-time bandwidth of 64Kbps minimum with a maximum of 128Kbps, sharing anything over 80Kbps with other services.

  The VoIP subclass should also be able to dequeue the packets within a 30ms timeframe, but more importantly, it should not vary the time in which it dequeues the packets by more than 2-3ms between each packet. 

  The P2P subclass (Class 12) should offer a mimimum of 0Kbps and a maximum of 384Kbps, sharing all of its allotted bandwidth with anything that needs it.

  The General subclass (Class 13) should offer a minimum of 320Kbps and a maximum of 1.5Mbps sharing anything over 320Kbps. 
}

{ * UPLOAD *
  I also need an upload class for each user (we'll call it Class 2) that offers a minimum of lets say 256Kbps and a maximum of 768Kbps.

  The rates between 256Kbps and 768Kbps will be shared among all users.

  Each user should always be able to upload at a speed of at least 256Kbps.

  Ther should also be VoIP, P2P, and General subclasses on upload.

  VoIP (Class 21) should be exactly the same as in the download class.

  P2P (Class 22) should go from 0-256Kbps sharing all allotted bandwidth with anything that needs it.

  The General subclass (Class 23) should offer a minimum of 192Kbps upload with a max of 768Kbps, sharing anything over 192Kbps.
}

My biggest confusion is on how to get the rates to say something like:

If the VoIP upload subclass needs the bandwidth, it gets it, but otherwise the 64Kbps from the VoIP class is allotted to the General upload subclass giving it 256Kbps for upload and the General upload subclass does not need to share that 256Kbps with anything else except the VoIP subclass, but if it goes over the 256Kbps, it shares that extra bandwidth with other people. 

Are all of these criteria possible to meet with HFSC? If not, which ones need to be adjusted and why? What would you recommend in place of them?

What is the maximum number you can use on class IDs? 

How many customers should one router be able to handle with this kind of QoS policy? 

With a P3 800MHz proccessor in a router, will I be able to implement this complex of a QoS policy and still have it handle 4,000 customers? 

What about 10,000?

Is there any way to do triple numbering for class IDs (i.e. 1:1:2 instead of 1:12)? 

Also, if you do not know for certain any of the answers to these questions, please do not make conjecture. Only answer with facts.
Thank you in advance for any responses to this.

Eliot Gable
Certified Wireless Network Administrator
Cisco Certified Network Associate
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and Systems Administrator
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
810-679-3395

[-- Attachment #3: Type: text/html, Size: 4035 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread