TCP Windows Scale problem

Om TCP/IP slår hål på en buffer genom att skicka fler paket än vad den buffrande enhet klarar av att hantera uppstår ibland stora svårigheter i kommunikationen. Samma sak kan lätt ske om överföringen hanteras av en 'hård' shaping någonstans på vägen mellan avsändare och mottagare. Det kan gå så långt att TCP sessionen stannar helt och kopplar ner. Sessionen startar bra, allt flyter på för att sen gå långsammare och långsammare tills den stannar helt. Tillåter/använder server/klienten dessutom TCP option 3 för att utöka fönsterstorleken (Window scale) utöver de normala max 64KByte, kan problemet bli än värre. Det här har jag sett mellan en Mac OS X 10.5 och en Windows 2008 server som skapade ett TCP fönster på 512KByte. Så länge kommunikationen med stora block sker över LAN är det normalt inga problem, däremot om det finns långsamma WAN-länkar med enklare typer av moden (= liten buffer) eller icke buffrande shaping (= t.ex. Cisco CAR) kan problemet uppstå. Det som händer är att TCP's fönsterstorlek ökar allt eftersom överföringen kommer igång. Förr eller senare är den så stor att någon buffer/shaping kastar en stor mängd paket i slutet av fönstret. Det här förutsätter att avsändaren sitter på en snabb LAN access som tillåter all trafik i fönstret att skickas under en mycket kort tid. Den här pulsen av ett stort antal paket är betydligt större än vad en mellanliggande enhet orkar ta emot (= bufferproblem) eller vill ta emot (= 'hård' shaping). I båda fallen kastas alla paket i slutet av 'pulsen'. TCP kommer att sända om paketen som slängdes när den upptäcker att paketen inte nått fram. Om den här omsändningen är så stor att även den 'pulsen' kommer att tappa ett större antal paket i slutet av pulsen, börjar sessionen närma sig ett farligt läge. Beroende på konfiguration i avsändaren kommer normalt 3-5 omsändningsförsök ske. Om även sista 'omsändningspulsen' tappar några paket, kommer avsändaren att lägga ner försöken att skicka om paketen. Avsändaren tycker helt enkelt inte det är värt att försöka hur länge som helst. Om TCP option för Window scale används så att ett datablock kan bli större än standard 64KByte, ökar möjligheten att 'pulsen' blir så stor så att mellanliggande buffrar/shaping aldrig kommer att hinna släppa igenom allt paket innan avsändaren tröttnar. Det lustiga är att option 3, windows scale, togs fram för att öka kapaciteten mellan två maskiner, inte förvärra situationen. Men tanken med windows scale var för att kunna utnyttja höghastighetslänkar, t.ex. lokala 1Gbit Ethernet. Att funktionen kan ha en klar negativ effekt på samma kommunikation över långsamma länkar, kanske inte är lika känt. Tittar man på TCP-flödet med en nätverksanalysator och filtrerar fram omsända kontra icke omsända paket kommer sessione starta med ett antal icke omsända paket, därefter blir det i princip bara omsändingar som syns. Dessutom kan man se att det blir tomrum mellan omsändningsförsöken. Dessa tomrum kan bli längre och längre tills dess att sessionen kopplas ner (FIN). Dessutom kan jag tänka mig att problemet faktiskt är värst där trafiken på något sätt stryps ner till en mycket låg hastighet jämfört med den fysiska länken. T.ex. om en operatör drar fram en 1Gbit fiber som kunden sedan köper 4/8Mbit access ur. Om operatören har en stor 'burst' konfigurerad och en 'hård' shaping (CAR), är det här problemet inte alls orimligt. Lösningen är 1) att låta avsändaren inte tillåta window scale, vilket ger sämre överföringskapacitet på t.ex. 1GBit LAN eller 2) se till så att långsamma länkar har bra bufferkapacitet och användar buffrande shaping. Alternativ 1 är egentligen bara aktuellt om alternativ 2 inte går att genomföra. En riktig fusklösning som kan hjälpa i viss utsträckning är att sänka avsändarens LAN anslutning till lägre hastighet. Det är enkelt, men absolut inte optimalt i många lägen. Men jag har gärna långsam och fungerande överföring är snabb överföring som stannar halvägs :-) Vänligen - Per Håkansson, CCIE 2446 SpeedApp AB