On Saturday 01 November 2008 15:35:08 Dennis M S wrote: > Currently focus is on the campus LAN..
How have you deployed your campus LAN? Is it a Layer 2 Ethernet switched or Layer 3 IP routed network? Whichever type you have would help you decide how best to use your equipment resources effectively, with regard to QoS. > as proof of > concept(actually my faculty vlan's~6,deployment will be > in the public vlan...the intranet ip video is an add on > feature not a priority as for now)...when people do have > a reasonably pleasant time using the set up..this will > encourage wide spread usage. The thing to remember is that QoS generally takes effect during times of congestion. When output interfaces are not congested, do not experience sudden spikes or do not surprisingly run out of packet/frame buffers, QoS features are typically not in effect (although they are monitoring the state of the interface). This does not mean you don't need QoS. You still do need QoS, even on a 10Gbps network, because the sudden spike that exhausts all buffers can cause your sensitive voice/video traffic to have a potentially high drop probability. I'm not sure what vendor equipment you have in your network, but whatever the case, if you have the budget, perform QoS features in hardware (queues). But if not, and your traffic levels are not that high, doing this in software (queues) is fine as well, as long as you watch that CPU bar. Your QoS strategy should be based on DSCP (Differentiated Services Code Point) - DSCP defines a PHB (per-hop behaviour) where each router/switch in the node provides the QoS services configured for a packet/frame when it first entered the network, up to the point when it egresses it: http://en.wikipedia.org/wiki/Differentiated_services Voice should be treated as low latency (EF or Expedited Forwarding as defined in DSCP). If your equipment supports low latency queues, you should place your voice traffic in there. These types of queues are serviced first before any other types of queues on the interface. This means that it's generally recommended not to assign more than 33% of the interface bandwidth to the low latency queue, otherwise you risk starving other queues and/or traffic flows. Interactive/real-time video (along with audio) should also be assigned to a low latency queue, e.g., a live video teleconference. However, video-on-demand (which as you say would be a requirement), does not have to enjoy the services of a low latency queue. You can provide assurances that traffic will be delivered as long it remains in-profile, i.e., it does not exceed CIR (or PIR, if configured). DSCP calls this AF or Assured Forwarding. Since VoD isn't real-time, users can always go back to it in case the network is facing congestion. So you don't need to give it the same treatment as real-time video. > The P.A(public address) system is already in > place..recording lecture's shouldnt be an issue...,the > bare bones functionality is to have people call the voip > server from their gsm mobile's and listen to stuff e.g > announcements,recorded lectures..etc,and ensure calls out > to gsm from the voip setup . This should be fairly straight forward then. Since each user is coming in via GSM, you just need to make sure your VoIP server can keep up with the load associated with transcoding - since GSM wouldn't be IP. If, however, you are trying to provide the stream over IP, then the QoS considerations I mention above would come into play. Cheers, Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ LUG mailing list [email protected] http://kym.net/mailman/listinfo/lug %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The List's Host is not responsible for them in any way. ---------------------------------------
