Ok this is like the 8th time I've sent this, maybe I'm tripping the new spam system....but never had a problem posting before.
I try not to use the below logic 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 300kbps 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... To more directly approach the problem space you posed: -There is xauth in pixOS and I believe IOS as well -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.(read: IME(nee opinion) tcp will backoff quicker than a given streaming protocol) Good Luck, Darrell (always looking for contract work) Newcomb [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=33368&t=33306 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
