Prestazioni della rete: explicit congestion notification
Quando gli apparati di rete chiedono aiuto.
Sentiamo spesso parlare di congestione della rete, forse un pò meno spesso di quali sono i meccanismi che cercano di gestirla.
Il meccanismo principale per gestire la congestione (fa un pò impressione a dirlo) è il packet drop. Sì, gli apparati in difficoltà buttano pacchetti in maniera pseudo casuale per guadagnare tempo (e banda), confidando nel fatto che i protocolli gestiscano i packet loss.
Questo cosa comporta negli applicativi che subiscono il packet loss?
Ci sono due effetti collaterali che vanno ad incidere nella performance di trasmissione:
- il protocollo/l’applicativo devono accorgersi di aver perso un pacchetto, perchè questo accada deve passare un certo tempo (RTO retransmission time out).
Nei sistemi operativi windows l’RTO all’inizio della connessione è impostato a 3 secondi. - nel protocollo tcp, quando avviene una ritrasmissione, il rate di trasmissione viene dimezzato, e viene reincrementato a piccoli passi (slow-start) nel prosieguo della trasmissione.
Quindi un packet loss può comportare delle situazioni di stallo anche di alcuni secondi nella trasmissione per esempio di una piccola pagina web e questo ha un effetto negativo sull’esperienza dell’utente finale.
Esiste un meccanismo per gestire la congestione senza impattare drasticamente il throughput di trasmissione?
Nel 2001 EMC e TeraOptics hanno proposto l’ Explicit Congestion Notification (ECN RFC 3168) un meccanismo per cui gli apparati di rete che si accorgono di essere in una situazione che può portare alla congestione, segnalano questo stato a chi sta per ricevere i pacchetti da loro inoltrati.
In pratica chiede aiuto alzando una bandierina (flag) con su scritto <<dite a chi spedisce i pacchetti di mandarli un po più piano, grazie>>. Se il protocollo tcp riceve questi pacchetti con la richiesta d’aiuto, segnala a chi trasmette di ridurre il rate di invio.
Se tutto va bene il rate delle trasmissioni si abbassa e l’apparato di rete esce dalla stato critico: senza crolli del throughput e senza attese di RTO.
Dico se tutto va bene perchè si possono presentare 2 situazioni in cui il meccanismo non funziona:
- il sistema operativo del client o del server o degli apparati di rete non supportano ECN
- lungo la strada i pacchetti con le richieste di aiuto o quelli che chiedono a chi invia di ridurre il rate, potrebbo essere droppati da altri apparati
La Real User Experience è in grado di individuare i pacchetti contenenti il flag ECN. È sufficiente che i soli apparati di rete abbiano attivo ECN configurando i meccanismi di queuing come RED,WRED,GRED,ALTO a seconda del vendor.
L’informazione dell’avvenuto stato di congestione di un apparato di rete ci aiuta a localizzare più velocemente la causa del problema di performance.
Come si vede nell’esempio abbiamo delle request tra due IP nella rete locale che ‘subiscono’ dei drop (vedi ritrasmissioni) di pacchetti verosimilmente causati da un apparato di rete il quale ha notificato il suo stato di congestione (vedi campo Congestion). Non conosciamo l’identità dell’apparato in questione, ma ci è sufficiente seguire la rotta percorsa dai pacchetti e verificare le statistiche degli apparati che si incontrano.
Tramite l’integrazione con NeDi siamo in grado di capire quali sono gli switch/router connessi al client o server per analizzare ulteriormente i dispositivi di rete:
CONSIGLIO: Vi starete chiedendo qual è il numero di congestioni di riferimento da cui bisogna iniziare a porre particolare attenzione. Una congestione infatti non richiede necessariamente un intervento. Personalmente mi sento di consigliarvi di osservare lo sviluppo delle congestioni. Se diventano più frequenti, dovrete analizzare la situazione per capirne la causa attraverso il packet-route. In questo modo saprete identificare anticipatamente possibili colli di bottiglia ancora prima che possano avere un impatto sulle prestazioni delle applicazioni recepite dagli utenti finali.
Perchè il meccanismo di recovery dallo stato di congestione (riduzione del rate di trasmissione) funzioni, è necessario che anche i client ed i server abbiano attivo ECN.
Aggiunta
I sistemi operativi recenti supportano tutti ECN, in alcuni il meccanismo è disabilitato di default:
Microsoft Windows
da Windows Server 2012 è abilitato di default. Nelle versioni precedenti e nelle versioni non server è disabilitato di default.
può essere abilitato con : netsh interface tcp set global ecncapability=enabled
Linux
dal kernel 2.4.20 supporta ECN in queste modalità, configurandolo tramite l’interfaccia sysctl impostando i parametri /proc/sys/net/ipv4/tcp_ecn :
0 – disable ECN and neither initiate nor accept it
1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts
2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections
Mac OS X
dalla versione 10.5 supporta ECN ma disabilitato di default. Si abilita settando le variabili sysctl net.inet.tcp.ecn_negotiate_in
dalla 10.11 è abilitata di default
iOS
dalla versione 9 ECN è abilitato di default
Luca Di Stefano
Author
