VPN-portin merkitseminen ei priorisoi puheluita

VPN:n UDP-portin merkitseminen korkeaksi prioriteetiksi on yleisin puheen QoS-muutos, eikä se erota puhelua samaa tunnelia jakavasta tiedostonsiirrosta. Molemmat virrat lähtevät samasta salatusta soketista. Merkintä kertoo seuraavalle hypylle, että kaikki on yhtä tärkeää, mikä on sama kuin ei kertoisi mitään. Puhelua suojaa luotettava luokittelu ennen salausta sekä jono, jota todella hallitset.

Tunneli piilottaa virran, jonka halusit luokitella

Salaus korvaa sisäiset otsikot yhdellä ulkoisella otsikolla tunnelia kohden. Sen jälkeen puheella ja varmuuskopioliikenteellä on sama lähde, kohde ja kuljetusportti, joten tunneliporttiin perustuva luokittelija ei pysty erottamaan niitä. Mitä ikinä nostat, nostat sen kokonaisuutena.

Lähdesovelluksen asettama DSCP-arvo säilyy vain, jos jokin kopioi sen ulospäin. OpenVPN 2.6:ssa on passtos, joka on dokumentoitu IPv4-laajuudella; IPsec soveltaa omaa kopiointi- tai kuvauskäytäntöään tunnelin rajalla. Ilman tätä vaihetta ulompi paketti merkitään millä tahansa oletusarvolla, jota tunnelin rajapinta käyttää, eikä alempana oleva jono saa koskaan tietää, että sisällä on puhelu.

Kopioidut merkinnät ansaitsevat saman epäluulon kuin mikä tahansa asiakkaan antama arvo. Työasema voi vaatia nopeutettua edelleenlähetystä varmuuskopiointityölle, joten hyväksynnän ja uudelleenmerkinnän on oltava suunnittelussa luottamusrajalla ennen kuin merkintään uskotaan.

Prioriteetti merkitsee vain siellä, missä jono muodostuu

Kyllästynyt ylälinkki muuttaa hyvän koodekin robottimaiseksi ääneksi, ja täyttyvä jono on yleensä liityntälaitteessa tai palveluntarjoajan puskurissa. Lähtevän polun muotoilu käytettävään nopeuteen, miinus tunnelin ja linkin ylikuorma, pitää jonon laitteistolla, jota hallinnoit, eikä jonkun toisen puskurissa.

Reilu jonotus ja aktiivinen jononhallinta auttavat myös ilman puheluokkaa, koska ne estävät yhden massavirran puskurin täyttymisen. CAKE Linuxissa kokoaa muotoilun, virtauskohtaisen reiluuden ja valinnaiset Diffserv-luokat yhteen qdisc-kohteeseen, ja käyttöön otetun verkkohallinnan pitäisi omistaa tämä kokoonpano eikä toista kilpailevaa jonoasetusta. Ilman muotoilua massaliikennettä edeltävä luokka odottaa silti jo täynnä olevan puskurin takana.

Saapuvan liikenteen käsittely ei ole hyödytöntä, mutta se vaikuttaa vasta, kun paketti on ylittänyt vastaanottavan linkin. Se voi vaikuttaa reagoivaan lähettäjään eikä voi palauttaa ylävirrassa jo kulunutta viivettä, joten se on lievennys, ei tae.

Mikä säilyy julkisessa internetissä

Diffserv-arkkitehtuuri kuvaa kohtelua hallinnollisten alueiden sisällä, minkä vuoksi palveluntarjoaja voi jättää merkinnän huomiotta tai kirjoittaa sen uudelleen rajalla. Vastakkainen väite, että jokainen verkko aina poistaa sen, on yhtä perusteeton. Rehellinen kysymys on, mihin tämä nimenomainen polku on sopimuksella velvoitettu ja miten sitä valvotaan. Testaa se merkityllä koetinsignaalilla sen sijaan, että toistaisit jostain lukemaasi sääntöä.

Kysy, mitä palveluntarjoaja tekee luokalle, ja mittaa se sitten. Merkintä, joka säilyy mutta jota ei ajasteta, on koristetta; polku, joka ajastaa näkemättä merkintää, on toinen ongelma, ja molemmat tarvitsevat erilaiset korjaukset.

Mittaussuunnitelma, joka eristää vaiheen

Soita yksi tavallinen puhelu hallitulla kilpailevalla latauksella ja toista se sitten kaapeloidulla linkillä. Katso, mitä puhelu menetti, mitä luokkalaskurit kirjasivat ja kuinka lähellä rajapinta käy todellista rajaansa eikä suunnitelman mainosnopeutta.

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

Jos puheluokan laskuri pysyy nollassa, luokittelu tai merkinnän kopiointi on rikki eikä mikään määrä prioriteettia auta. Jos luokkalaskuri liikkuu paikallisesti viiveen yhä noustessa, pullonkaula on yhdyskäytäväsi ulkopuolella. Kumpaakaan tulosta ei korjata nostamalla prioriteettiarvoa.