Markado de la VPN-pordo ne prioritatigas voĉajn alvokojn

Marki la UDP-porton de la VPN kiel altan prioritaton estas la plej ofta voĉa QoS-ŝanĝo, kaj ĝi ne apartigas alvokon de la dosiera transdono, kiu kunhavas tiun tunelon. Ambaŭ fluoj eliras tra la sama ĉifrita ingo. La marko diras al la sekva salto, ke ĉio same gravas, kio samas al diri al ĝi nenion. Kion protektas alvokon estas fidinda klasifiko antaŭ ĉifrado plus atendovico, kiun vi efektive regas.

La tunelo kaŝas la fluon, kiun vi volis klasifiki

Ĉifrado anstataŭigas la internajn kapliniojn per unu ekstera kaplinio por tunelo. Post tio, voĉo kaj sekurkopia trafiko prezentas la saman fonton, celon kaj transportan pordon, do klasifikilo bazita sur la tunela pordo ne povas distingi ilin. Kion ajn vi antaŭenigas, vi antaŭenigas ĝin amase.

DSCP-valoro agordita de la origina aplikaĵo postvivas nur se io kopias ĝin eksteren. OpenVPN 2.6 havas passtos, dokumentitan kun IPv4-gamoj; IPsec aplikas sian propran kopiadan aŭ mapadan politikon ĉe la tunela limo. Sen tiu paŝo la ekstera pako estas markita per ajna defaŭlto, kiun la tunela interfaco uzas, kaj la atendovico malsupre neniam ekscias, ke alvoko estas interne.

Kopiitaj markoj meritas la saman suspekton kiel ajna klient-provizita valoro. Labortablo povas postuli rapidigitan plusendadon por sekurkopia tasko, do akcepto kaj remarkado ĉe la fida limo apartenas al la dezajno antaŭ ol oni kredu la markon.

Prioritato gravas nur tie, kie formiĝas la atendovico

Satigita suprena ligo estas tio, kio transformas bonan kodekon en robotan voĉon, kaj la atendovico, kiu pleniĝas, kutime estas en la alira aparato aŭ en la bufro de la provizanto. Formi la eliran vojon al la uzebla indico, minus tunela kaj liga superkosto, tenas tiun atendovicon sur aparataro, kiun vi administras, anstataŭ en la bufro de iu alia.

Justa atendo kaj aktiva atendovica administrado helpas eĉ sen voĉa klaso, ĉar ili malhelpas unu amasan fluon plenigi la bufron. CAKE en Linux kunigas formadon, justecon laŭ fluo kaj laŭvolajn Diffserv-klasojn en unu qdisc, kaj la deplojita ret-administranto devus posedi tiun agordon anstataŭ dua konkurenca atendovica agordo. Sen formado, klaso, kiu superas amasan trafikon, ankoraŭ atendas malantaŭ bufro, kiu jam estas plena.

Traktado de envenanta trafiko ne estas senutila, sed ĝi agas post kiam la pako trapasis la ricevan ligon. Ĝi povas influi respondecan sendanton kaj ne povas redoni prokraston jam elspezitan supren, do ĝi estas mildigo, ne garantio.

Kio postvivas en la publika interreto

La Diffserv-arkitekturo priskribas traktadon ene de administraj domajnoj, tial provizanto povas ignori aŭ reverki markon ĉe limo. La kontraŭa aserto, ke ĉiu reto ĉiam forigas ĝin, estas same senbaza. La honesta demando estas, kion ĉi tiu konkreta vojo kontrakte kaj police devas fari. Testu tion per markita sondilo anstataŭ ripeti regulon, kiun vi legis ie.

Demandu, kion la provizanto faras kun la klaso, poste mezuru ĝin. Marko konservita sed ne planita estas ornamo; vojo, kiu planas sen vidi la markon, estas alia problemo, kaj la du bezonas malsamajn riparojn.

Mezurplano, kiu izolas la etapon

Faru unu ordinaran alvokon kun kontrolita konkurenca alŝuto, poste ripetu ĝin sur drata ligo. Rigardu, kion la alvoko perdis, kion registris la klasaj nombriloj kaj kiom proksime la interfaco funkcias al sia reala limo anstataŭ al la anoncita rapido de la plano.

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

Se la nombrilo de la voĉa klaso restas nulo, klasifiko aŭ markokopiado estas rompita kaj neniu kvanto de prioritato helpos. Se la klasa nombrilo moviĝas loke dum prokrasto daŭre grimpas, la botelo estas preter via enirejo. Neniun el la du rezultoj riparas plialtigo de la prioritata valoro.