Md at debian.org

tales of a debian maintainer

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:

Ovviamente 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:

Real out of band connectivity with network namespaces

This post explains how to configure on a Linux server a second and totally independent network interface with its own connectivity. It can be useful to access the server when the regular connectivity is broken.

This can happen thanks to network namespaces, a virtualization feature available in recent kernels.

We need to create a simple script to be run at boot time which will create and configure the namespace. First, move in the new namespace the network interface which will be dedicated to it:

ip netns add oob
ip link set eth2 netns oob

And then configure it as usual with iproute, by executing it in the new namespace with ip netns exec:

ip netns exec oob ip link set lo up
ip netns exec oob ip link set eth2 up
ip netns exec oob ip addr add 192.168.1.2/24 dev eth2
ip netns exec oob ip route add default via 192.168.1.1

The interface must be configured manually because ifupdown does not support namespaces yet, and it would use the same /run/network/ifstate file which tracks the interfaces of the main namespace (this is also a good argument in favour of something persistent like Network Manager...).

Now we can start any daemon in the namespace, just make sure that they will not interfere with the on-disk state of other instances:

ip netns exec oob /usr/sbin/sshd -o PidFile=/run/sshd-oob.pid

Netfilter is virtualized as well, so we can load a firewall configuration which will be applied only to the new namespace:

ip netns exec oob iptables-restore < /etc/network/firewall-oob-v4

As documented in ip-netns(8), iproute netns add will also create a mount namespace and bind mount in it the files in /etc/netns/$NAMESPACE/: this is very useful since some details of the configuration, like the name server IP, will be different in the new namespace:

mkdir -p /etc/netns/oob/
echo 'nameserver 8.8.8.8' > /etc/netns/oob/resolv.conf

If we connect to the second SSH daemon, it will create a shell in the second namespace. To enter the main one, i.e. the one used by PID 1, we can use a simple script like:

#!/bin/sh -e
exec nsenter --net --mount --target 1 "$@"

To reach the out of band namespace from the main one we can use instead:

#!/bin/sh -e
exec nsenter --net --mount --target $(cat /var/run/sshd-oob.pid) "$@"

Scripts like these can also be used in fun ssh configurations like:

Host 10.2.1.*
 ProxyCommand ssh -q -a -x -N -T server-oob.example.net 'nsenter-main nc %h %p'

Level 3 su peering e monopoli dell'accesso

Perché è una cosa se lo scrivo io sul mio blog, ma un'altra se lo scrive sul blog aziendale di Level 3 il loro general counsel.

Ci si potrebbe soffermare sul fatto che questa posizione arriva da qualcuno che non è esattamente estraneo a dispute di peering finite male per gli utenti, ma ritengo comunque molto positivo che sia una voce così autorevole a dire pubblicamente quello che sappiamo tutti da anni.

Merita la lettura anche questo commento su Gigaom che sottolinea come il problema, per quanto critico, non riguardi strettamente la net neutrality.

D'altra parte, ho seri dubbi che la soluzione migliore sia regolamentare il peering piuttosto che imporre vera concorrenza nel mercato dell'accesso a Internet.

Automatically unlocking xscreensaver in some locations

When I am at home I do not want to be bothered by the screensaver locking my laptop. To solve this, I use a custom PAM configuration which checks if I am authenticated to the local access point.

Add this to the top of /etc/pam.d/xscreensaver:

auth sufficient pam_exec.so quiet /usr/local/sbin/pam_auth_xscreensaver

And then use a script like this one to decide when you want the display to be automatically unlocked:

#!/bin/sh -e

# return the ESSID of this interface
current_essid() {
  /sbin/iwconfig $1 | sed -nre '/ESSID/s/.*ESSID:"([^"]+)".*/\1/p'
}

# automatically unlock only for these users
case "$PAM_USER" in
  "")   echo "This program must be run by pam_auth.so!"
        exit 1
        ;;
  md)   ;;

  *)    exit 1
        ;;
esac

CURRENT_ESSID=$(current_essid wlan0)

# automatically unlock when connected to these networks
case "$CURRENT_ESSID" in
  MYOWNESSID) exit 0 ;;
esac

exit 6

Come negli anni '90...

Chi usa Internet da un po' si ricorderà di come, fino alla seconda metà degli anni '90, accadeva di frequente che per raggiungere dall'Italia un'altra rete italiana si passasse per gli Stati Uniti, attraversando due volte l'Atlantico. Questo accadeva perché non esistevano o non erano usati da tutti i punti di interscambio neutrali.

Da qualche giorno siamo tornati indietro di 20 anni, perché parte del traffico diretto dai clienti di Cogent Communications (uno dei più grandi carrier globali) verso i clienti di Telecom Italia Sparkle è scambiato a New York invece che a Parigi o Francoforte come di consueto. (Non in Italia come sarebbe logico, perché avevamo già visto che Telecom Italia rifiuta di scambiare traffico in Italia con la maggior parte dei carrier...)

La spiegazione fornita da Cogent ai propri clienti è che questo dipende da Telecom Italia, che ha imposto che il traffico per alcune proprie reti non gli sia più inviato in Europa perché queste interconnessioni sono sature, e aggiunge:

Our peering engineers are actively working with Telecom Italia to expand capacity at Europe as quickly as possible but unfortunately Telecom Italia has not decide yet how to proceed.

La mia impressione quindi è che Telecom Italia stia di nuovo ritardando l'upgrade di alcune delle proprie interconnessioni, con l'effetto di spingere il traffico su percorsi non ottimali.

Naturalmente, adesso che questo traffico passa per gli USA sarà come di consueto intercettato ed analizzato dalla NSA...

On people totally opposed to systemd

Do you remember the very vocal people who, a decade ago, would endlessly argue that udev was broken and that they would never use it?

Percentage over time of systems on which udev is installed

Sometimes you can either embrace change or be dragged along by it. We are beyond the inflection point, and the systemd haters should choose their place.

Divertirsi con SSL

Uhm, vediamo un attimo perché ultimamente questa procedura fallisce...

Iniziando così ho appena perso quasi due ore di vita perché un certo sito usa una vecchia versione di IIS, che sospetto non sia stata toccata da molti anni. È un sito del Ministero dell'Interno, blindatissimo. Gestito da persone, forse un po' timide, che è scomodo contattare.

Questo sito semplicemente chiude la connessione (ma dopo avere ricevuto la richiesta HTTP) se il client invia una richiesta troppo lunga durante l'handshake SSL. Non mi dilungo su come sono arrivato a capirlo, perché tra ottenere un messaggio di errore (wget non si preoccupa di fornirne uno...) e capirne la ragione ci sono state decine di ricerche con Google.

E tante prove. Prima con wget. Poi con openssl s_client, che ho scoperto funzionare se provavo a connettermi da un'altra macchina. A questo punto la strada è tutta in discesa, o quasi: basta ridurre la lunghezza del handshake perché evidentemente il sistema non funziona più da quando avevo aggiornato il sistema operativo, che ora usa librerie SSL che implementano molte più feature e algoritmi. Verifico che se imposto un solo algoritmo con openssl s_client -cipher allora funziona tutto anche sul primo server.

Peccato che 6 anni fa avessi scritto questi script per usare wget, che permette pochissimo controllo su come deve usare SSL. Rileggo diverse volte il manuale, ma le opzioni che ho a disposizione non aumentano. L'unica possibilità offerta è forzare una certa versione di SSL/TLS, ma se provo qualcosa diverso da TLSv1 (che si porta dietro tutte le feature che vorrei evitare) il programma muore malamente per un errore interno di GnuTLS.

Scopro facilmente che è un bug di wget risolto tre mesi fa, ma che fare? C'è una versione corretta in Debian experimental ma non ho nessuna voglia di ricompilare il pacchetto per questo server. Faccio qualche ipotesi e alla fine decido che il problema non merita una soluzione elegante: ho preso l'eseguibile di wget da un pacchetto del vecchio sistema operativo e modificato il $PATH dello script per usare questa versione. Funziona tutto come previsto.

Mi chiedo se ci sono buoni motivi per continuare a usare wget invece di curl.

Easily installing Debian on a Cubieboard

I recently bought a Cubieboard to replace my old Sheevaplug which has finally blown a power supply capacitor (this appears to be a common defect of Sheevaplugs), so I am publishing these instructions which show how to install Debian on sunxi systems (i.e. based on the Allwinner A10 SoC or one of its newer versions) with no need for cross compilers, emulators or ugly FAT partitions.

This should work on any sunxi system as long as U-Boot is at least version 2012.10.

The first step is to erase the beginning of SD card to remove anything in the unpartitioned space which may confuse U-Boot, partition and format it as desired. The first partition must begin at 1MB (1024*1024/512=2048 sectors) because the leading unpartitioned space is used by the boot loaders.

dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=1
parted /dev/mmcblk0

  mklabel msdos
  mkpart primary ext4 2048s 15G
  unit s
  print
  mkpart primary linux-swap ... -1

mkfs.ext4 -L root /dev/mmcblk0p1
mkswap --label swap /dev/mmcblk0p2

Download the boot loaders and an initial kernel and install them:

tar xf cubieboard_hwpack.tar.xz
dd if=bootloader/sunxi-spl.bin of=/dev/mmcblk0 bs=1024 seek=8
dd if=bootloader/u-boot.bin of=/dev/mmcblk0 bs=1024 seek=32

mount /dev/mmcblk0p1 /mnt
mkdir /mnt/boot/

cp kernel/script.bin kernel/uImage /mnt/boot/

script.bin is Allwinner's proprietary equivalent of the device tree: it will be needed until sunxi support will be fully merged in mainline kernels.

U-Boot needs to be configured to load the kernel from the ext4 file system (join the lines at \\, this is not a supported syntax!):

cat << END > /mnt/boot/uEnv.txt
# kernel=uImage
root=/dev/mmcblk0p1 rootwait
boot_mmc=ext4load mmc 0:1 0x43000000 boot/script.bin && ext4load mmc 0:1 0x48000000 boot/${kernel} \\
  && watchdog 0 && bootm 0x48000000
END

Now the system is bootable: add your own root file system or build one with debootstrap. My old Sheevaplug tutorial shows how to do this without a working ARM system or emulator (beware: the other parts are quite obsolete and should not be trusted blindly).

If you have an old armel install around it will work as well, and you can easily cross-grade it to armhf as long as it is up to date to at least wheezy (the newer, the better).

You can also just use busybox for a quick test:

mkdir /mnt/bin/
dpkg-deb -x .../busybox-static_1.21.0-1_armhf.deb .
cp bin/busybox /mnt/bin/
ln -s busybox /mnt/bin/sh

After booting the busybox root file system you can run busybox --install /bin/ to install links for all the supported commands.

Until Debian kernels will support sunxi (do not hold your breath: there are still many parts which are not yet in mainline) I recommend to install one of Roman's kernels:

dpkg -i linux-image-3.4.67-r0-s-rm2+_3.4.67-r0-s-rm2+-10.00.Custom_armhf.deb
mkimage -A arm -O linux -T kernel -C none -a 40008000 -e 40008000 \
  -n uImage -d /boot/vmlinuz-3.4.67-r0-s-rm2+ /boot/uImage-3.4.67-r0-s-rm2+

It is not needed with these kernels for most setups, but an initramfs can be created with:

update-initramfs -c -k 3.4.67-r0-s-rm2+
mkimage -A arm -T ramdisk -C none -n uInitrd \
  -d /boot/initrd.img-3.4.67-r0-s-rm2+ /boot/uInitrd-3.4.67-r0-s-rm2+

/boot/uEnv.txt will have to be updated to load the initramfs.

Since the Cubieboard lacks a factory-burned MAC address you should either configure one in script.bin or (much easier) add it to /etc/network/interfaces:

iface eth0 inet dhcp
        hwaddress ether xx:xx:xx:xx:xx:xx

To learn more about the Allwinner SoCs boot process you can consult 1 and 2.

Prima legge del web hosting

Congettura:

Un servizio che promette risorse illimitate, eccetto quelle il cui costo marginale non giustifica conteggiarne l'uso, non può avere contemporaneamente buona qualità e basso costo.

Telecom Italia spinge all'estero il traffico italiano

Continuando la propria strategia di minimizzazione, dopo avere suggerito che gli ISP italiani starebbero polemizzando per risparmiare poche migliaia di Euro all'anno, Telecom Italia sostiene che il depeering attuato questa estate riguarderebbe solo qualche piccolo operatore.

Questo non è strettamente non vero, perché nella pratica già da molto tempo impedisce o scoraggia le interconnessioni in Italia con i grandi carrier globali.

Il risultato della disconnessione unilaterale da parte di Telecom Italia di un grande numero di ISP e hoster italiani è che quando i suoi clienti accedono ai propri siti o leggono l'email presso questi fornitori, il traffico spesso passa per Francoforte o Parigi. Secondo una stima veloce questo riguarda oltre un quarto dei domini .it.

Le implicazioni di privacy e sicurezza nazionale non possono essere trascurate: se i clienti di Telecom Italia per leggere la propria posta devono transitare dall'estero diventa molto più facile per un Paese straniero intercettare il loro traffico. Considerazioni di questo genere sono già state fatte dai politici di diversi paesi, compreso il nostro...

Telecom Italia Sparkle, il carrier internazionale di Telecom Italia, da un paio di anni è ritenuto essere un Tier 1. Questo in pratica significa che non compra connettività da nessuno per raggiungere terzi e può raggiungere chiunque solo grazie ai propri peering con gli altri Tier 1. (Questa mia presentazione spiega concetti come peering e transito).

Esaminiamo brevemente i suoi peering italiani, tutti a Milano. I risultati di questa piccola analisi sono riproducibili da chiunque osservando traceroute e rotte BGP, quindi sono oggettivi e difficilmente contestabili.

GTT (ex Inteliquent, ex Tinet, ex Tiscali International, ex Nacamar: una storia di acquisizioni complicata...) ha una interconnessione, ma è satura e per non avere cattive prestazioni parte del traffico viene comunque scambiato a Parigi e Francoforte. Ha dichiarato pubblicamente che Telecom Italia rifiuta da oltre un anno di fare l'upgrade necessario a Milano: pare che in tutto il resto del mondo si possano fare, ma in Italia proprio no.

NTT Communications, arrivata da poco in Italia, ha imposto qualche mese fa di attivare una interconnessione grazie alla sua posizione di forza che le deriva dal essere stata in passato uno dei transit provider di Telecom Italia. Si è immediatamente saturata e da diverse settimane dicono ai clienti che stanno lavorando a un upgrade, ma ancora non è stato fatto e nel frattempo non è utilizzabile.

Tata Communications faceva peering al MIX, ma non ne trovo più traccia.

Anche Global Crossing faceva peering al MIX, e anche questo è sparito. I miei commerciali, interrogati a riguardo più volte, si sono chiusi nel silenzio.

Mi dicono che Level3 abbia una interconnessione, ma sia mantenuta così piccola da essere inutilizzabile: di sicuro nessuno ha mai visto passarci del traffico.

Cable & Wireless Worldwide (che nel 2012 è stata acquisita da Vodafone, ma è ancora una rete indipendente) e Sprint hanno una interconnessione, ma comunque da molti anni non sono più fornitori di transito rilevanti nel mercato italiano.

Deutsche Telekom ha una interconnessione, ma non è mai stata rilevante nel mercato italiano.

Come è evidente, da questa lista mancano del tutto altri grandi carrier, alcuni anche più importanti della stessa Telecom Italia. A titolo di esempio cito solo Cogent.

La nuova politica di peering italiana di Telecom Italia non è mai stata resa nota con precisione, ma mi risulta che gli unici soggetti con cui fa settlement free peering nazionalmente siano Wind, Fastweb, BT-I.Net e GARR (la rete delle università e della ricerca). Alcuni sono grandi reti di accesso, mentre altri non sono certamente "operatori di telecomunicazioni suoi pari" e suggeriscono che il criterio usato sia piuttosto elastico.

Quello che si vede in pratica è che Telecom Italia, in Italia, ha attivamente adottato una politica che la porta a non avere interconnessioni ben funzionanti con nessun grande carrier internazionale da cui si possa comprare connettività. Questa politica riguarda esclusivamente il mercato nazionale, perché se non facesse peering con gli altri Tier 1 nemmeno all'estero non potrebbe rimanere nel club...

Naturalmente il peering è una relazione bilaterale e partecipare non è obbligatorio, però è giusto discutere delle ripercussioni tecniche e politiche delle decisioni prese da Telecom Italia, l'operatore dominante nel mercato della connettività.

Gli articoli precedenti:

(Errata corrige: Vodafone era stata erroneamente elencata tra gli operatori interconnessi a Telecom Italia, ma anche i loro clienti sono raggiunti dall'estero tramite carrier terzi.)

(Aggiornamento: a febbraio 2014 non risulta più una interconnessione con il Vaticano.)

About

Sono l'Italia che non vuole bene.

S M T W T F S
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

See also:

My blogroll:


W3C HTML 4.01
W3C CSS 2.0     

Powered by Bryar.pm.