Qos met voldoende bandbreedte

[Rotty]

Ik zit met een vraagje waar ik veel verschillende meningen over lees. Mijn vraag is is qos voor bv voip nodig ook als je gegarandeerd voldoende bandbreedte hebt en je interfaces nooit congestion ervaren?

Er zijn meningen dat ivm latency en jitter het toch goed is om qos in te richten voor dit soort verkeer. Wat ik weet van qos en de verschillende queuing methoden (custom, wfq, priority queue, llq enz) is dat het allemaal software queus zijn waar verkeer naar toe gestuurd wordt op basis van je marking en waarna jet dan in de gewenste volgorde in je hardware queue komt. en dat dit pas in werking treed als je hardware queues volzitten. Hardware queues werken altijd op bais van fifo. Dus vraag ik me af als de hardware queues nooit vol raken (voldoende bandreedte) en de queueings methoden worden niet actief wat is dan het punt van qos en heeft dit dan wel zin als er gegarandeerd voldoede bandbreedte is..??

[Kabouterplop01]

Als je genoeg bandbreedte hebt dan heeft het geen nut om QoS aan te zetten.
De delay/jitter blijft hetzelfde.

Overigens moet je als je QoS implementeert, door het hele netwerk QoS hebben.

[ Voor 26% gewijzigd door Kabouterplop01 op 05-12-2012 19:28 ]

[Gomez12]

Het hangt een beetje af van je specifieke qos keuze (en wat je provider ondersteunt)

Maar in principe is qos altijd te prefereren of je moet simpelweg niet de hardware hebben om de bandbreedte vol te trekken.

Voldoende bandbreedte is een ruim begrip als je hardware meer kan trekken als je bandbreedte is. Elk programma pakt namelijk zoveel ruimte als mogelijk. Dat kan bij bijv 10 grote bestandsoverdrachten over je netwerk dan toch wel weer hikjes in je voip gaan opleveren.
Of dingen als torrent etc die je aantal connecties door het dak heen gooien (zonder bandbreedte) kunnen ook voor congestions zorgen (alhoewel dit dus over het algemeen afhangt van de qos keuze)

In principe zorgt een goede qos implementatie simpelweg voor 100% zekerheid tegenover dat het zo af en toe in incidentele gevallen niet 100% gaat. Maar dan moet idd wel het hele netwerk (dus ook je provider) qos hebben.

Heel simpel praktijkvoorbeeldje wat ik wel eens ben tegengekomen : Geen qos en netwerk draaide perfect, tot er op een gegeven moment een nieuw bedrijf overgenomen werd en er opeens 100 pc's geimaged moesten worden, toen kreeg je spontaan storingen. Zo af en toe bij een patch-dag als de WOS opengegooid werd en er grote updates overal heen gingen dan werd het telefoonverkeer minder etc. etc.
Qua normaal gebruik was er meer dan voldoende bandbreedte, maar bij incidenten merkte de klant het zo af en toe toch wel.
Daar had dat bedrijf nog wel even wat uitzoekwerk in zitten om te vinden waarom "soms" het telefoonverkeer slechter werd.

Het is gewoon net die zekerheid vs incidenten

[Rotty]

Dank voor de replies..

Dat het beter is dat is volstrekt duidelijk het ging mij meer even om het principe mbt qos en de misvatting dat het altijd noodzakelijk is...

[Gomez12]

In principe vind ik het ook altijd noodzakelijk, een gigabit netwerk kan nog steeds volgetrokken worden waardoor je voip eronder gaat lijden als je maar genoeg verkeer over je netwerk gooit van voldoende clients.

10 clients en 1 fileserver zullen niet snel een probleem krijgen, maar 50 grafici / video bewerkers die over het netwerk heen werken kunnen wellicht wel zo af en toe storingen opleveren.

[pablo_p]

Ik maak onderdeel uit van een project waarin we het netwerk in twee data centers vervangen door een nieuwe architectuur. We hebben ervoor gekozen om binnen het DC geen QoS in te richten, alleen op de koppeling tussen de data centers.

Binnen het Data center is er oversubscription factor 1:9 tussen de access laag en en de aggregatie/core (we hebben een collapsed core), dat is redelijk. Maar systemen worden maximaal met 20 Gbit aangesloten en de uplink vanuit de Accesslaag naar de Aggregatielaag is 2 x 40 Gbit. Een enkel systeem dat in de stress schiet (of waar iemand met iperf gaat testen), kan nooit de uplink dichttrekken. Dat is wel een belangrijke check.

Tussen de data centers ligt maar 2 x 20 Gbit (active-passive voor sommige stromen, active-active voor andere) en daar regelen we QoS in. We hebben geen VoIP, maar wel verkeer dat belangrijk is voor de stabiliteit van de data centers (netwerk state synchronisatie verkeer). Daarvoor reserveren we hard 200 Mbit (Priority queue). Voor de rest hebben we classes business (gewone applicaties en applicatie synchronisatie) en bulk (backup enzo). Business gaat voor bulk.
De oversubsciption van deze links is ook maximaal 1:1000 (extreem gerekend) en 1 systeem (20 Gbit aangesloten) kan in zijn eentje al de link dichttrekken. QoS is absoluut noodzakelijk volgens mij, maar zelfs daar is niet 100% consensus over.

Je moet goed kijken naar de oversubscription en ik denk dat je geen QoS nodig hebt als bv 2-3 systemen die maximaal verkeer generen niet de uplink kunnen dichttrekken en de gemiddelde belasting <30% is..

[ Voor 2% gewijzigd door pablo_p op 08-12-2012 00:15 . Reden: Typo's ]

[Rotty]

pablo_p schreef op zaterdag 08 december 2012 @ 00:13:
Ik maak onderdeel uit van een project waarin we het netwerk in twee data centers vervangen door een nieuwe architectuur. We hebben ervoor gekozen om binnen het DC geen QoS in te richten, alleen op de koppeling tussen de data centers.

Je moet goed kijken naar de oversubscription en ik denk dat je geen QoS nodig hebt als bv 2-3 systemen die maximaal verkeer generen niet de uplink kunnen dichttrekken en de gemiddelde belasting <30% is..

Dat klinkt als een mooi project!! Maar idd goed om zo naar je suscription te kijken en qos daar toe te passen waar er noodzaak is.

[Verwijderd]

QOS is zeker niet altijd nodig, als je genoeg bandbreedte hebt dan is dit pure onzin. QOS mechanisme gaat ook pas werken bij een lijnbelasting van 70%, packets worden altijd wel geclassificeerd, maar het echte mechanisme hoeft nog niet aan de bak.

Tevens pas je QOS over het algemeent alleen op congestiepunten toe en hoef je het helemaal niet end2end toe te passen, tuurlijk is dit het beste, maar ook complex en zeer duur! Ik kan je zo een aantal (internationale) providers geven die in hun backbone geen qos toepassen.

[ Voor 99% gewijzigd door Verwijderd op 09-12-2012 06:22 ]

[ijdod]

Het probleem met QoS is dat het erg nuttig in je netwerk kan zijn, maar dat met name op OSI laag 8 en hoger voor veel problemen zorgt. Men ziet het als een panacea voor allerhande problemen...

Je moet je erg goed in de gaten houden wat het exact doet (en dat kan per device verschillen. Sommige hardware heeft meerdere queues, sommige niet. Anderen hebben shared buffers, enzovoorts, en wat er precies gebeurt als het ingrijpt.

Mijn ervaring is dat het goed werkt voor korte bursts in verkeer, maar niet geweldig voor langduringe (over)belasting, tenzij je een hele botte best effort groep hebt die zwaar gedropt mag worden, en die daar ook tegen kan qua applicatie(!). Backup software vindt het vaak niet echt leuk... en de retransmits verhelpen de congestie bepaald niet.

Als je echt serieus aan traffic management moet doen, kan je beter kijken naar Packeteers of vergelijkbaar.

[Vicarious]

ijdod schreef op donderdag 20 december 2012 @ 15:24:
OSI laag 8 en hoger voor veel problemen zorgt.

Die bestaat niet. Ik zie eigenlijk geen reden om het NIET te doen. Het geeft sowieso geen reductie in performance als je het goed inricht en als je lijn niet wordt dichtgetrokken wordt het mechanisme niet eens gebruikt en heb je er dus ook geen 'last' van. De spaarzame momenten dat een lijn wel wordt dichtgetrokken kan het nuttig zijn.

Tegenwoordig zijn er steeds meer verkeerstypen die QoS toch eigenlijk wel 'nodig' hebben. Bijna elk bedrijf draait VoIP of gaat dat binnenkort doen, en videoconferencing wordt ook steeds populairder. Bovendien hebben subvestigingen vaak kleine WAN verbindingen waarover QoS ook zeer nuttig kan zijn, en als je het daar toepast moet je het eigenlijk in je hele netwerk doorvoeren om het ECHT goed te laten werken.

[FatalError]

Vicarious schreef op vrijdag 28 december 2012 @ 00:45:
[...]

Die bestaat niet.

Ik moest wel gniffelen om de grap

Ik zie eigenlijk geen reden om het NIET te doen. Het geeft sowieso geen reductie in performance als je het goed inricht en als je lijn niet wordt dichtgetrokken wordt het mechanisme niet eens gebruikt en heb je er dus ook geen 'last' van. De spaarzame momenten dat een lijn wel wordt dichtgetrokken kan het nuttig zijn.

In routers welke QoS in software implementeren is het toch wel een behoorlijk zware service. Je kan een hoop routers helemaal over de zeik krijgen met wat QoS werk.

[Vicarious]

FatalError schreef op vrijdag 28 december 2012 @ 09:47:
[...]


Ik moest wel gniffelen om de grap


[...]


In routers welke QoS in software implementeren is het toch wel een behoorlijk zware service. Je kan een hoop routers helemaal over de zeik krijgen met wat QoS werk.

Met "wat QoS-werk" niet lijkt me, anders kunnen ze die functie er beter uit laten. Ik heb het in ieder geval nog niet meegemaakt. En als een router continue high CPU usage heeft puur door het QoS mechanisme moet er toch eens gedacht worden aan een lijn- of routerupgrade want dan is er blijkbaar structureel bandbreedte tekort. Let wel: het QoS mechanisme gebruikt maar weinig CPU zolang de bandbreedte niet volgedrukt wordt, want dan hoeft er niets te gebeuren.

[MrFX]

Rotty schreef op woensdag 05 december 2012 @ 14:09:
Ik zit met een vraagje waar ik veel verschillende meningen over lees. Mijn vraag is is qos voor bv voip nodig ook als je gegarandeerd voldoende bandbreedte hebt en je interfaces nooit congestion ervaren?

Er zijn meningen dat ivm latency en jitter het toch goed is om qos in te richten voor dit soort verkeer. Wat ik weet van qos en de verschillende queuing methoden (custom, wfq, priority queue, llq enz) is dat het allemaal software queus zijn waar verkeer naar toe gestuurd wordt op basis van je marking en waarna jet dan in de gewenste volgorde in je hardware queue komt. en dat dit pas in werking treed als je hardware queues volzitten. Hardware queues werken altijd op bais van fifo. Dus vraag ik me af als de hardware queues nooit vol raken (voldoende bandreedte) en de queueings methoden worden niet actief wat is dan het punt van qos en heeft dit dan wel zin als er gegarandeerd voldoede bandbreedte is..??

Voor latency is het zeer verstandig om toch QOS in te richten. Een goed voorbeeld om toch QOS te gebruiken t.b.v. het shapen van o.a. cifs verkeer. Het cifs protocol is creedy as hell en gebruikt diverse roundtrips van kleine packets. Dit resulteerd in het zo genaamde zig zag patroon qua netwerkconsumtie. Daar het verkeer te shapen is de uit eindelijke verkeersoverdracht efficienter en sneller waardoor de layer 8 knakkers minder klagen