This didn't seem to post earlier.... I try not to use the following on my networks, but have also never had it fail to deliver service when there was no other choice.
The common streaming of windows media and real have such large client side buffers that you'll find you can seemingly overload the link without having any user observable qualitative difference. Some factors which contribute even more to the success of overloading are the bit rate varies as the encoders don't always output the maximum data rate. The fact that most streams on the public internet are short lived, the standard buffers can cover the end of the stream the user is still viewing leaving capacity for other streams to go through their peak startup period. The traditional stat muxing factors come into play where depending upon the application there is some downcycle in streaming usage in the workflow. You only need a 2.5:1 to get "300"kbps streams through uncongested. Lastly I think you are approaching the wrong problem. Non streaming uses for the same 2Mbps link will be the big enemy of predictably good streaming performance. Your application may even be one of those by downloading other supporting data... Now to more directly approach the problem space you posed: -There is xauth in pixOS and I believe IOS NAT -Couple that with a creative authentication server, or script to control it.... -The above should get you the max number of sessions through. -Can't recall the reflexive access lists with CAR ball of wax off the top of my head. But there is some per-session rate limiting in cisco. There are various rate limiting equipment out there. Riverstone has good affordable routers for this, Netscreen claims to do it(haven't used them yet), and Packeteer also does this type of thing. There is more but I believe them to be the notables. There are proxy and/or cache products which would address the max number of sessions issue and maybe address the usage pattern you have. Not that I'd recommend this, but if your application and rest of the network path can adequately support forcing the streams over a tcp session you'll probably find it much easier to deal with the rate limiting. But really try to handle it without forcing tcp as any backoffs will hurt the qualitative performance if there are other signficant numbers of tcps over any congested link. Basically that should read that in my experience tcp will backoff quicker than a given streaming protocol and that definately FASTER than common streams. Good Luck, Darrell (always looking for contract work) Newcomb [EMAIL PROTECTED] Gaz wrote: > > Hi all, > > I'm after some ideas if you'd be so kind :-) > > A 2Mb link being used mainly for streaming media has about 15 > potential > users. The task is to limit the number of users at any one time > to four, so > they have half a Mb each (ish). > > My initial idea, which I must admit, I dont think is such a > good one is to > set up a NAT pool of four addresses, and drag the translation > timeout down > to about a minute (yet to be tested), so that the first four > users to pass > traffic will be translated and allowed through, but after that, > they'll have > to wait. > > I'm off to look at something like TACACS to see if I can > control network > authorization by number of users (shot in the dark). > > No equipment in place yet, so we have a clean drawing board. > > Anybody have any neat ideas please!!!!!! > > > Thanks, > > Gaz > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=33311&t=33306 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
