Newsgroup: it.fan.marco-ditri
Titolo: Quality of Service in Internet: giusta o sbagliata?

È giusto che un operatore possa decidere di fare passare sulla propria
rete certi pacchetti prima che altri, anche se arrivati prima al
router?
 
Per rispondere è indispensabile chiarire in quale punto si sceglie di
prioritizzare un certo tipo o sorgente di traffico (la differenza tra,
per esempio, "tutto il traffico video" e "i video di Netflix") rispetto
ad altri tipi. Le possibilità, non mutualmente esclusive, sono:
 
 
 *  sull'interconnessione con terzi
 *  nel proprio backbone
 *  tra il router/DSLAM e il clienteOvviamente non ha senso fare QoS in
un peering con Netflix (lo cito spesso perché è un buon esempio, ma si
può sostituire con Google, Akamai, eccetera), se non altro perché il
traffico è omogeneo (tutto video, tutto da loro) e quindi non può
essere prioritizzato rispetto ad altri tipi/sorgenti.
 
Non credo che abbia senso fare QoS sulle interconnessioni tra un grande
carrier e un operatore di accesso (per esempio, tra Level 3 e Telecom
Italia) per prioritizzare certo traffico a scapito del resto (per
esempio, la CDN di Level 3, o alcuni loro clienti): se si è tutti
d'accordo per fornire un buon servizio si dimensioneranno i circuiti in
modo che non ci sia congestione e quindi non serve QoS. Se invece una
delle parti vuole esercitare pressione sull'altra (con lo scopo di
farsi pagare l'interconnessione), in questo momento il mercato (o
meglio: la sua assenza...) prevede che possa farlo solo l'operatore di
accesso.
 
Visto che la sua strategia è fornire un cattivo servizio ai propri
clienti come incentivo all'altra parte, allora non c'è motivo di usare
tecniche di QoS per migliorarlo. E se l'altra parte accetta
l'estorsione allora si ricade nel caso precedente.
 
Qual è lo scopo di prioritizzare sul proprio backbone un certo tipo di
traffico? Se questo è progettato e dimensionato correttamente, in
condizioni normali non è necessario perché ci sarà sempre abbastanza
capacità per fare arrivare ai propri clienti tutti i bit che vogliono
inviare o ricevere. Anche sulle reti migliori a volte può capitare che
ci siano picchi anomali e imprevedibili di traffico oppure che per vari
motivi non si possa fare un upgrade nei tempi necessari, quindi può
avere senso prioritizzare certi tipi di traffico che richiedono
migliori prestazioni (es: video e voce) a scapito di altri che possono
soffrire un po' senza fastidi eccessivi (es: grossi download).
 
Questa è una politica tecnica ragionevole, che però diventa una pessima
politica commerciale se la rete è congestionata costantemente invece
che in momenti eccezionali. Non è una violazione della network
neutrality perché non privilegia una sorgente di traffico rispetto a
un'altra, ma solo un certo tipo di traffico riconosciuto sulla base del
protocollo usato.
 
Se invece accadesse proprio questo (per esempio se Apple pagasse per
avere un servizio migliore di Facebook) allora avremmo un problema
molto grave, per i motivi che sappiamo. Inoltre, in questa situazione
occorre riflettere su qual è l'impatto per il pubblico: se il backbone
comunque non fosse congestionato allora non avrebbe senso vendere un
servizio a qualità privilegiata, perché nessuno avrebbe bisogno di
comprarlo. Quindi si può violare la network neutrality solo su una rete
che in condizioni normali ha cattive prestazioni per tutto il traffico.
Non solo: si può violare la network neutrality soltanto dove non c'è un
mercato funzionante, perché altrimenti i clienti si sposterebbero sugli
operatori che forniscono un servizio migliore. Non ho mai incontrato
nessuno che voglia pagare un operatore perché gli consegni solo una
parte del suo traffico e butti via quello che decide essere di troppo.
 
Il pezzetto di rete tra DSLAM e cliente è diverso da tutti gli altri
perché è il cliente stesso a controllare il traffico che ci passa. Per
questo motivo non sarebbe molto utile per l'operatore violare lì la
network neutrality privilegiando il traffico di certe sorgenti, perché
comunque il cliente può fare in modo che non ci sia congestione
regolandosi nell'uso del servizio.
 
Fare QoS sull'ultimo miglio sulla base del protocollo invece può essere
un ottimo servizio fornito al cliente, perché gli permette di usare la
propria connettività in modo più libero senza rischiare per esempio che
un grosso download causi problemi a una partita a WoW.
 
Per saperne di più si può leggere i precedenti articoli sul mio blog
oppure iniziare da questi:
 
 
 * Why YouTube buffers: The secret deals that make - and break - online
video[0]
 * Peering e depeering: le interconnessioni tra le reti italiane[1]
[0]
http://arstechnica.com/information-technology/2013/07/why-youtube-buffers-the-secret-deals-that-make-and-break-online-video/
 
[1] 
http://www.linux.it/~md/text/peering-fdtict.pdf
 
 
Permalink: 
http://blog.bofh.it/id_447
 

 router?
 
Si.
 
 


Ma anche no.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left


Oltre a motivi "etici", che condivido, ne hai altri?

 Oltre a motivi "etici", che condivido, ne hai altri?
 
Se non vi sono motivi squisitamente tecnici per cui, per garantire
prestazioni eque a tutti, sia necessario applicare QoS, ogni intervento
non necessario sui pacchetti in transito è eticamente e tecnicamente
un'idiozia; e questo di per sé è il motivo principale ed inequivocabile.
 
Per il resto se ancora ancora si può tollerare che il CLIENTE che paga
di più un certo servizio possa avere un trattamento privilegiato
rispetto a chi paga di meno (e quindi venga applicata una QoS che dia
priorità al suo traffico), non è in alcun modo tollerabile né
giustificabile che tali regole siano applicate non in funzione del
cliente ma in funzione del fornitore di contenuti.
