El circuit estava bé i la videotrucada va caure igual

La sucursal va trucar a les onze i quaranta: la videotrucada amb el client s'havia tallat tres vegades aquell matí. Vas obrir incidència. Dos dies després te la van tancar amb la frase de sempre, que el circuit ha romàs dins dels paràmetres contractats. I tens al davant la gràfica del teu SD-WAN, amb tres pics de pèrdua clavats en aquella franja. Ningú no està mentint. El teu operador i tu esteu mesurant coses diferents, i les diferències estan escrites a les normes que hi ha sota el teu contracte.

Entre quins dos punts

Les mètriques de rendiment d'una xarxa IP no són propietats de «la xarxa»: estan definides entre dos punts de mesura. El retard d'un sol sentit (RFC 7679) i la pèrdua d'un sol sentit (RFC 7680) es defineixen d'un origen a un destí concrets. Canvia els dos punts i canvia el número, sense que ningú hagi falsejat res. Al pla Ethernet passa el mateix amb Y.1731: l'operador envia trames de mesura entre dos MEP que ell configura —DMM per al retard, LMM o SLM per a la pèrdua— i el resultat descriu el tram entre aquelles dues boques.

Els punts de l'operador són les vores de la seva xarxa: normalment el seu equip d'accés i la interfície de lliurament a la teva seu. El que queda fora d'aquell parell —la teva LAN, el teu tallafocs, el trànsit a internet més enllà del lliurament, el SaaS de l'altre extrem— no és al número i mai no va pretendre ser-hi. El teu SD-WAN mesura una altra cosa, igual de legítima: el túnel complet, de l'equip de la seu al node de sortida, incloent-hi trams que l'operador no et va vendre i no pot garantir.

Durant quant de temps

La recomanació ITU-T Y.1541 és la que fixa objectius de qualitat per a serveis sobre IP. La seva classe 0, l'exigent, la que correspon a veu i vídeo en temps real, demana un retard mitjà (IPTD) per sota de 100 ms, una variació de retard (IPDV) per sota de 50 ms i una taxa de pèrdua (IPLR) per sota d'1·10⁻³, és a dir un 0,1%. Suggereix un interval d'avaluació d'un minut, exigeix que l'interval quedi registrat al costat del valor observat i hi afegeix una frase que val la pena llegir a poc a poc: qualsevol minut observat hauria de complir aquells objectius. Qualsevol. No la mitjana dels del mes.

L'IPDV, a més, està definit com la cota superior del quantil 1−10⁻³ de l'IPTD menys l'IPTD mínim. Traduït: un paquet de cada mil pot sortir-se'n i l'objectiu es continua complint, per definició. És la manera correcta de descriure estadísticament una xarxa, i tot i així n'hi ha prou perquè un tècnic miri un informe conforme mentre tu senties la trucada tallar-se.

Ara mira el teu contracte. En tots els d'accés que ens han passat per revisar, el que es compromet és un percentatge de disponibilitat mensual. La classe mesurada per minut es queda fora. Són dos productes diferents i el segon és molt més barat de complir, perquè una mitjana d'un mes absorbeix episodis que un minut no absorbeix. El compte cap en una taula. Un mes de trenta dies té 2.592.000 segons:

Mira la fila del 99,9%, que és la més habitual en els contractes d'accés per a empresa. Un tall de vint segons consumeix el 0,00077% del mes. Dins d'aquell 99,9% hi caben 129 d'aquells talls: més de quatre al dia, tots els dies del mes. Si cauen en horari d'oficina i damunt de les trucades, la sucursal ha tingut un mes infernal, l'informe mensual surt en verd i les dues coses són veritat alhora. El percentatge està mesurant una altra cosa.

A això s'hi solen afegir dos filtres més, i això ho diem com a lectura dels contractes que ens passen, no com a estadística del sector: una durada mínima per sota de la qual un esdeveniment no compta, i un rellotge que arrenca quan tu obres el tiquet i no quan comença el problema. Ves al teu contracte i busca aquelles dues clàusules. Hi són gairebé sempre, i entre totes dues es mengen la majoria dels episodis que de debò molesten la gent.

En quina cua viatja la sonda

Per mesurar de manera contínua, molts operadors fan servir TWAMP, el protocol de mesura activa de dos sentits descrit al RFC 5357. A TWAMP una sessió de prova porta un DSCP, i el RFC fa servir un MUST: el reflector ha d'emprar aquell mateix DSCP als paquets que retorna. La mesura és, per disseny, per classe de trànsit. I això està bé, perquè és exactament el que cal per verificar una classe de servei contractada.

El problema comença quan la classe de la sonda i la classe del teu trànsit no coincideixen. Al lliurament, el remarcatge de DSCP és rutina: el que va sortir del teu equip marcat com a EF pot entrar a la xarxa de l'operador com a millor esforç si el mapatge no es va acordar per escrit. La sonda informa aleshores, amb tota la veritat del món, d'una cua buida, mentre el teu vídeo espera en una altra que és plena. Ningú no ha fet trampa; s'està llegint una mesura d'una classe com si fos una afirmació sobre tot el que passa pel cable.

Queda el mostreig. Una sonda activa no mira de manera contínua: envia ràfegues de paquets amb una cadència que es configura, i entre ràfega i ràfega no està mirant res. La nostra pròpia instal·lació de SmokePing, per posar el número que sí que podem posar, va per defecte a vint pings cada cinc minuts. Amb aquella cadència, una cua que s'omple durant vuit-cents mil·lisegons pot no coincidir amb cap mostra. No han enganyat ningú: no hi havia ningú mirant en aquell instant. Abans de citar una sonda en una reclamació, esbrina cada quant mesura.

La prova d'alta certifica el dia de l'alta

Quan es va donar d'alta el circuit et van enviar un PDF amb gràfiques i un segell de «conforme». El més probable és que fos una prova Y.1564, la metodologia d'activació de serveis Ethernet de l'ITU-T. Són dues fases. La primera verifica la configuració pujant el trànsit per esglaons al 25, 50, 75 i 100% del cabal compromès, després al cabal en excés i després per sobre, per comprovar que el limitador es comporta com diu el contracte. La segona manté el 100% del cabal compromès i mesura pèrdua, retard, variació i disponibilitat. Els tres períodes que la norma obliga a suportar són quinze minuts, dues hores i vint-i-quatre hores: quinze minuts per a un servei metropolità sobre xarxa que ja porta trànsit, dues hores per a llarga distància d'un sol operador, vint-i-quatre per a un servei internacional que creua diverses xarxes.

És una bona prova i fa exactament el que promet: certificar el servei en el moment de l'activació. Però fixa't en l'escala. El cas més comú, el metropolità, es certifica amb quinze minuts de trànsit, i aquell circuit el tindràs posat cinc anys. El PDF diu la veritat sobre aquell quart d'hora. No diu res del dimarts passat a les onze i quaranta, i mai no va pretendre dir-ho. Treure'l en una reclamació —en qualsevol de les dues direccions, perquè també el traiem nosaltres quan ens convé— és demanar a un document una cosa que no conté.

El teu SD-WAN tampoc no té la veritat sencera

Aquesta part l'escrivim sent nosaltres els que muntem SD-WAN, i l'escrivim igual. Un argument que només se sosté quan el defensa qui ven la caixa val poc. La telemetria del teu orquestrador també és una sonda, amb la seva cadència, la seva mida de paquet i la seva classe, i té tres biaixos propis que convé conèixer abans de portar-la a una reunió.

• Mesura el camí sencer, no el circuit. Inclou l'encapsulació del túnel i un tram intermedi d'internet que ningú no et va vendre amb compromís. Que aquell camí estigui malament no implica que l'accés estigui malament, i si ho presentes com si ho impliqués, l'operador té raó en tornar-t'ho.
• En actuar, modifica el que estava mesurant. Així que l'equip desvia el trànsit del camí que anava malament, aquell camí deixa de portar càrrega i deixa de semblar dolent. La gràfica de després demostra que el desviament va funcionar, no que el circuit s'hagi curat. Són dues conclusions diferents i és molt fàcil cobrar la segona sense haver-la guanyat.
• La prova caduca abans que la reclamació. Comprova quant de temps guarda el teu orquestrador la sèrie a resolució de segons abans de compactar-la en mitjanes. Si la teva finestra de reclamació és de trenta dies i el detall mor als set, la teva prova es va evaporar abans que la discussió. No t'ho avisarà ningú: és a la configuració de retenció i cal anar a mirar-la.

Res d'això no treu valor a una SD-WAN ben posada; diu per a què serveix i per a què no. Ja vam escriure al juliol quan compensa i quan sobra, i allò continua vigent: resol un problema concret i sense aquell problema és una capa més per mantenir. El que afegim avui és que la seva telemetria, que és una de les seves millors raons de compra, necessita context per convertir-se en prova.

Set línies d'annex abans de signar

Set frases per escriure a l'annex tècnic del contracte, o per preguntar per correu abans de signar guardant-se la resposta. Cadascuna tanca una de les ambigüitats de dalt. Si el comercial no pot contestar sis de les set, ja saps alguna cosa útil.

• Entre quins dos punts es mesura, anomenats amb la interfície concreta i no amb «la xarxa del client». Si el punt del teu costat és l'equip de l'operador a la teva seu, digues-ho així per escrit.
• Quin paràmetre i contra quina norma: retard, variació i pèrdua amb els valors exactes, citant Y.1541 o Y.1731 si és el que aplica. Un «qualitat garantida» sense paràmetre és decoratiu.
• L'interval d'avaluació i si la xifra és mitjana o percentil, i en el segon cas quin. La diferència entre una mitjana de cinc minuts i un percentil 95 d'un minut és la diferència entre veure l'episodi i no veure'l.
• En quina classe viatja la sonda i quin marcatge rep el teu trànsit al lliurament. Si enviaràs vídeo marcat com a EF, que estigui escrit què fa l'operador amb aquella marca a la seva frontera.
• Què compta com a esdeveniment: durada mínima, i si el rellotge arrenca en la detecció de l'operador o en l'obertura del teu tiquet. De totes les d'aquesta llista, és la línia que més vegades hem vist decidir com acaba la discussió.
• Qui aporta prova, en quin format i quant de temps la guarda cada part. Si ells conserven noranta dies i tu set, a la pràctica la prova la posa un de sol.
• Quina és la compensació i què no cobreix. En els contractes que hem revisat sempre ha estat un percentatge de la quota del mes. Està bé que existeixi i convé dir en veu alta el que ja saps: no paga la reunió perduda. Si el servei és crític, els diners es gasten millor en un segon camí que negociant la penalització.

Des dels dos costats del telèfon

Ens trobem en una posició estranya que aquí va bé: som operador amb xarxa pròpia —BGP, trànsit, peering i un looking glass públic a lg.everywan.com— i alhora portem serveis gestionats per a empreses amb circuits venuts per un altre. Hem escrit la reclamació i hem escrit la resposta. Amb el biaix per endavant: ens convé que contractis serveis gestionats, així que dona-ho per fet. El que ve funciona exactament igual si ho muntes tu.

De tot això en surten dos costums que ens han estalviat discussions. La primera: guardar la dispersió i no només la mitjana. Fem servir SmokePing precisament perquè conserva el repartiment de cada ronda de sondes, així que un episodi de vint segons deixa una marca visible que una mitjana mensual esborra sense deixar rastre; i Zabbix per als llindars i per a l'alerta que de debò desperta algú, que és un ofici a part del qual ja hem parlat. La segona: que el circuit tingui nom. Mantenim NetBox com a font de veritat amb la seva referència, la seva interfície de lliurament i el seu responsable, perquè una bona part de les reclamacions que es moren es moren al primer correu, discutint de quin circuit estem parlant.

I una tercera, menys còmoda: hi ha avaries que cap annex no arregla, perquè el que decideix el resultat és on es pot actuar. Ho vam explicar quan vam parlar de per què un blackhole local no salva el teu enllaç d'accés: si l'enllaç ja és ple quan el trànsit arriba a la teva porta, el que facis a la teva porta arriba tard. Saber de qui és cada tram serveix per a dues coses, i reclamar és la menys important; l'altra és saber a qui cal demanar-li que actuï.

El que es compra de debò

Un SLA de disponibilitat funciona com una assegurança: retorna part de la quota quan el servei falla molta estona seguida. Té valor, està bé que existeixi i no hi ha res de tèrbol. El que no fa és descriure com es comporta la teva xarxa el dimarts a les onze i quaranta, perquè per a això caldria mesurar una altra cosa, en un altre lloc i amb una altra finestra, i això és precisament el que no s'ha contractat.

Ens vam trobar el mateix mecanisme a l'agost amb una incidència de Microsoft 365: el cercador feia dies que estava trencat i, llegit contra les definicions de Downtime del mateix SLA, allò no computava com a caiguda. Allà el que manava era la definició de servei; aquí manen el punt i la finestra de mesura. El fons és el mateix: el que un contracte considera una fallada ho decideix el contracte, no l'usuari a qui se li ha tallat la trucada.

El nostre eix de sempre diu que la fallada és inevitable i l'avaria és una decisió de disseny. La discussió amb l'operador, en canvi, no és gens inevitable: és la conseqüència que ningú va escriure, abans de signar, què vol dir que això funciona. Set línies, mitja pàgina, i s'escriuen una sola vegada.

Si estàs muntant o renegociant una WAN multiseu, aquell annex val més que una comparativa de preus: és el que decideix qui té raó d'aquí a vuit mesos. És el punt per on comencem quan dissenyem una SD-WAN o quan ens fem càrrec de les xarxes i comunicacions d'una empresa, abans de tocar cap caixa. Si vols que fem un cop d'ull al teu contracte actual i et diguem quina de les set línies et falta, escriu-nos.