Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
siddiqirf wrote:
For traffic going from SiteA to siteB, does quality of service HAVE to be end to end (from siteA to siteB) to be effective?
If there is a node in between which doesnt have QOS, then does that mean that QoS will be ineffective? For example if there is a Service Provider network in between which you have no control over. How can you go around this ?
"HAVE to"? It depends.
You need to ask, are there any points from SiteA to SiteB where traffic might queue? If so, then you need to analyze whether the likely queuing will be adverse to the needs of your traffic.
Take for example a SiteA host has gig LAN copper link, then it crosses between SiteA buildings using an old 100 Mbps fiber link, it then crosses a T3 WAN link to SiteB where it crosses a 100 Mbps copper link to the SiteB host.
Going from the SiteA host to SiteB host, 1st possible point of possible congestion might be the gig link (a point of congestion often overlooked). 2nd point of possible congestion would be the transition from gig to 100 Mbps. 3rd point of possible congestion would be the transition form 100 Mbps to T3.
If traffic was just, for example, host backup, you'll likely have congestion at the three possible congestion points noted, but likely it wouldn't matter much. If traffic was mix of host backup and VoIP (e.g. softphone on host), the combination of backup traffic with VoIP traffic would likely require QoS traffic management at the three noted possible congestion points.
Note, the last transition, from T3 to 100 Mbps would not need QoS management because the T3 will never wait on the 100 Mbps. I.e., an example where you do not need end-to-end QoS.
If you examine traffic from SiteB to SiteA, you'll should see there's even one less point of possible congestion. I.e. another example of where you do not need end-to-end QoS.
If all traffic was interactive, because of the actual needs of the traffic, perhaps QoS management might only be needed at ingress to the link with the least bandwidth, the T3 in this example.
Real-world QoS situations can be, of course, be much more complex. However, end-to-end QoS doesn't always need to be implemented end-to-end. (Conversely, networks often would benefit much from some QoS.)
In answer to your 2nd question, what do you do when provide doesn't support QoS, well that too depends on the technology being used. Often the solution is shaping traffic to what we know the available bandwidth is, and then managing that bandwidth.
For instance, if you have a 100 Mbps Ethernet link to a MetroE provider, but only with 20 Mbps contracted, you shape your traffic to 20 Mbps and manage that.
Shaping generally works very well if all you paths can be treated as point-to-point. If you have a multipoint connection, as might be found with Ethernet or MPLS providers, shaping can still be used, but to guarantee performance, bandwidth is often "wasted" if the provider is unable to support the QoS techniques desired.
For example, say you have 11 sites, each with 100 Mbps but contracted to 20 Mbps. Assuming 10 sites could all send to a single site, even if we shape to the contracted 20 Mbps, we could send 200 Mbps. Obviously, 200 Mbps might congest the 100 Mbps. To avoid this, instead of just shaping all links to 20 Mbps, we need to shape all possible sends aggregate to 100 Mbps. This could be as simple as shaping all sites to 10 Mbps, or about half at 20 and other half at 5, or some other combination that doesn't exceed 100 Mbps aggregate.
However, before doing what I just described, you need to also determine how the provider enforces contracted bandwidths, i.e. in, out or both. If the receiving site's 20 Mbps was applied to inbound bandwidth, then we should now shape the other sites aggregate bandwidth not exceed it, for example all sites outbound shaped at 2 Mbps.
Again, real-world situations can be more complex, but for multipoint topologies, having the provider support QoS can allow much better utilization of the provided bandwidth, although if they don't, you can still often provide determinstic performance.
