Windows 2008 receive window Autotuning

Una cosa che non tutti sanno è che una delle grandi differenze tra Windows 2003 e Windows 2008 è la porzione di codice riguardante la gestione della suite di protocolli TCP/IP, che è stato in gran parte riscritto.

Tra le varie feature implementate abbiamo:

• Architettura IP duale IPv4/IPv6
• Supporto per il modello strong host (già discusso in questo articolo)
• Nuovi meccanismi per gestire e meglio supportare le tecniche di Offload (discusse in questo post)
• Receive window Autotuning

Vale la pena approfondire in questo post il concetto di Autotuning.

Autotuning è un meccanismo grazie al quale un server Windows 2008 (o un client Vista / 7) può migliorare le proprie performance a livello TCP, modificando dinamicamente i parametri della connessione in base ai dati di trasmissione che in tempo reale vengono misurati. L’algoritmo determinerà quindi la dimensione ottimale della finestra TCP (receive Window) in ogni istante basandosi sul BDP (prodotto banda-ritardo) e sulla frequenza con cui l’applicazione sovrastante riesce a gestire I dati. In questo modo, qualora ci fossero momenti in cui la nostra rete soffra di piccole o grandi congestioni, Autotuning riuscirà ad accorgersene molto velocemente e provvederà a dimensionare meglio la quantità di traffico trasmesso per evitare di saturare la banda troppo in fretta e dover ricominciare a trasmettere con bassissimo rate (meccanismo di TCP slow start).

Potete sbizzarrirvi a misurare le performances di una macchina con Autotuning attivato e disattivato. Io l’ho fatto, per passione e professione, e ne ho ottenuto il risultato che vedete in figura (test effettuato trasferendo un grosso file via SMB, dalla stesso client allo stesso server, con Autotuning in nero e con finestra fissa in rosso)

Come ci insegna la matematica che abbiamo studiato a scuola tanti anni fa, la differenza di performance può essere apprezzata calcolando e paragonando l’area che si trova tra l’asse orizzontale delle ascisse e le due curve. Si vede in modo molto chiaro che Autotuning cerca di “spingere” sempre al massimo, per poi adagiarsi al valore fisso quando non è possibile avere performance migliori. Il test è stato effettuato in un reale ambiente di produzione, senza particolari problemi di congestioni.

Va però detto che Autotuning, pur dandoci degli ottimi risultati, non può fare miracoli. Un tipico scenario in cui l’algoritmo non può fare la differenza rispetto alla finestra fissa, è il caso di un trasferimento di molti files piccoli di dimensioni. Data la natura di questo tipo di connessione, la finestra non potrà mai crescere con costanza perchè sarà sempre limitata dalla necessità di ricominciare (TCP slow start) con il trasferimento del file successivo. Di conseguenza, non sono apprezzabili differenze di rilievo. In figura, un altro esempio (in blu, trasferimento di 100 files da 1 Mb, in giallo trasferimento di 200 files da 30Kb). I tempi sono sostanzialmente gli stessi, con e senza Autotuning.

Inoltre, è importante sottolineare che Autotuning fa uso dell’opzione TCP scaling factor.

Scenario FIXED SIZE (scaling factor disabilitato)

Durante una connessione TCP senza scaling factor, il ricevente comunica al mittente un valore fisso di finestra. Così, se la finestra vale 50’000 byte, il mittente è autorizzato al massimo ad inviare 50’000 byte finchè il ricevente non ha comunicato di avere correttamente i dati, e solo a quel punto si potrà proseguire. Il limite di questo modello è che si possono al massimo avere finestre di 65’535 bytes.

Scenario SCALING FACTOR

Per superare i limiti della fixed window size, nelle opzioni del TCP è stato introdotto lo Scaling Factor. Tale opzione non è altro che un campo aggiuntivo, che deve essere moltiplicato per il valore della finestra. Così, un ricevente che comunica finestra=10’000 e scaling factor=3 in realtà sta dicendo che può ricevere 10’000 * (2^3) = 80’000 bytes. Questo permette al mittente una teorica possibilità di aumentare la velocità di invio dati e di conseguenza le performance. È importante sottolineare che tutti gli apparati di rete devono poter supportare lo Scaling Factor per permetterne il corretto funzionamento (non solo i due estremi della connessione TCP). Più specificamente, l’hardware di rete deve essere compliant con l’RFC 1323 (TCP Extensions for High Performance) uno standard introdotto nel 1992.

Qualora si dovesse incorrere in problemi relativi all’incompatibilità dei devices di rete con lo Scaling Factor, un possibile workaround potrà essere disabiliare l’Autotuning (perdendone però tutti gli altri benefici). Non è possibile disabilitare l’uso dello scaling factor senza disabilitare Autotuning in toto.

Per disabilitare Autotuning, il comando è

netsh interface tcp set global autotuning=disabled

Per riabilitarlo, invece il comando è:

netsh interface tcp set global autotuning=normal

Per verificare se attualmente è abilitato oppure no:

netsh interface tcp show global

Nell’esempio in figura, Autotuning è abilitato:

è importante evidenziare la presenza di un problema noto su Autotuning in Windows 7 e 2008R2 risolto da questa hotfix che andrebbe quindi installata con alta priorità su ognuna delle nostre macchine.

Infine, concluderei con un “classico” errore che fanno in molti.

È importante notare che la chiave TCPWindowSize non è più utilizzata da 2008 in poi. Averla nel registry non ha nessun effetto. Molti clienti invece, nella convinzione che lo stack sia uguale a quello di Windows 2003, continuano ad utilizzare questo setting per tentare di settare una misura fissa di finestra TCP. Questo non è più possibile.

Di seguito vi linko I documenti ufficiali che elencano la lista di chiavi di registro relative al TCP/IP presenti in Windows 2003 oppure in Windows 2008

http://technet.microsoft.com/en-us/library/cc758746(WS.10).aspx

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9152

http://technet.microsoft.com/en-us/library/ff633467(WS.10).aspx

Ciao a tutti e alla prossima!

Stefano Gagliardi
Support Engineer
Microsoft Enterprise Platform Support