On Wednesday 24 July 2002 13:29, you wrote:
> Pardon me if I'm wrong, but should'nt QOS management should be allocated
> with edge devices, packets shifter and dynamic caches/proxies not by end
> station operating systems....
But then the applications have to talk to those devices :(
Can you imagine how stuck we'd get with all these 'Windows Direct X.Net ready
devices' which are protected by DCMA?
> anyone out there played with linux qos/bandwidth controls... has anyone
> got real rsvp running (YUM!) ? I alway seem to remember the linux
> networking faq, having most sections on qos missing. dunno about the
> software.
>
> here's the fact's...100/mb switch connection are cheap.
> Server power is cheap.
> Server networks card's are cheap
>
> gigabit ether net works are comming online for normal people
> WAN backbone links are so sloooooooooooooow and EXPENSIVE
> WAN Equipment is expensive
> ATM SUCKS! (no it really really does)
>
> Clients are more reliable when the complexity is low.
> so, who can guess where qos should fit into a real network? ;-).
>
> Client applications should be able to request qos from
> end network infrastructure devices. bu I don't think server software
> should get involved too, too too too complex.... ah well. More
> features..that's ms way.
>
> and when I say real network, I mean real world network. qos on paper =
> easy , qos on existing networks is hard!
>
> server/client side packet schedules rareley works well, because of
> layer 2 qos gurantee's, getting all those layers from 2-7 to aggree,
> it's hard one, ah well...cisco will save us won't they? Only if their
> running microsoft active directory...
>
> I see dark days ahead..
The fundamental argument is, whether it's cheaper to do 'accounting' and
'have service gurantees', or simply provide massive over supply of bandwidth.
Now locally as you say, the balance is way in favour of low utilisation, and
having simplicity!
On the longhaul, again due to number of links needing to support bandwidth
guarantees, is it really every going to be practical?
Isn't broadband putting everyone in direction of bandwidth 'over' supply, and
then your 'realtime streaming' applications share a small part of a very
large pot, rather than lots of small bandwidth slices in 'dedicated' virtual
circuits.
Having seen how flaky long haul Internet is, and how much ISP's can do to
screw things up, when it gets to BGP routing etc. I have to be rather
cynical about the practicality of bandwidth reservation. And if it's only
practical in LANs or MANs where you have control then as you pointed out,
economics is in favour of lots of neat hardware and large bandwidth links.
Rob
--------------------------------------------------------------------
http://www.lug.org.uk http://www.linuxportal.co.uk
http://www.linuxjob.co.uk http://www.linuxshop.co.uk
--------------------------------------------------------------------
This archive was generated by hypermail 2.1.3 : Wed 31 Jul 2002 - 16:35:59 BST