protocollo TCP versioni e implementazioni

Transcript

1 protocollo TCP versioni e implementazioni

2 implementazioni TCP implementations use Slow Start in as many as three different ways: (1) to start a new connection (2) to restart transmission after a long idle period (3) to restart transmission after a retransmit timeout 2

3 implementazioni (2) If one segment is dropped from the initial window, there are three different ways for TCP to recover: 1. Slow-starting from a window of one segment, as is done after a retransmit timeout, or after Fast Retransmit 2. Fast Recovery as is done after three duplicate ACKs 3. Fast Recovery with SACK,, for TCP where both the sender and the receiver support the SACK option 3

4 In generale 4

5 Evolution of TCP 5

6 Post

7 politiche di trasmissione 7

8 politiche di trasmissione cosa trasmettere Sliding Window ACK SACK quando farlo timeout (RTO) DupACK (#3) come farlo TCP-zero: No SS (Slow Start) OldTahoe: SS + CA (CongestionAvoidance) Tahoe: SS + CA + FR (Fast Retransmit) Reno: SS + CA + FR + FRec (Fast Recovery) Vegas: SS + CA + FRec + New FR NewReno: SS + CA + FR + FRec (calcolo RTO più accurato) 8

9 versioni TCP Meccanismi OldTahoe Tahoe Reno SACK NewReno (1988) (1988) (1990) (1996) (1996) Stima varianza RTT X X X X X Exp. backoff X X X X X Alg. Karn X X X X X Slow start X X X X X Dynamic window control Fast retransmit X X X X X X X X X+ Fast recovery X X X+ Selective ACK X X? 9

10 BSD pre-4.3 : nessun meccanismo di controllo della congestione. Trasmette tanti pacchetti quanti necessari a riempire la finestra di ricezione. Stima del valore di RTT primitiva e controllo di flusso tipo GoBack-N BSD 4.3 Tahoe : calcolo di RTO con algoritmo di Jacobson e introduzione delle tecniche di controllo della congestione BSD 4.3 Reno : Introduzione di Fast Recovery BSD 4.4 : Multicasting e introduzione delle Long Fat Pipes. TCP Vegas : Nuovi meccanismi di stima per RTT e gestione delle finestre di spedizione. TCP Boston : TCP ottimizzato per reti ATM. 10

11 BSD 4.3 Tahoe realizzata da Jacobson (1988) meccanismi previsti: Slow start Congestion avoidance Fast Retransmit Variazioni all algoritmo di stima RTT Exponential Backoff per la trasmissione Algoritmo di Karn 11

12 TCP Versions: Tahoe set window to 1, and do slow start! Sequence No X X X Time 12

13 performance di Tahoe Tahoe TCP è sensibile alla perdita di pacchetti Window Size is set to minimum value after packet loss. Every packet loss is assumed to be serious congestion. La perdita dell'1% dei pacchetti causa una diminuzione del 50-75% del throughput 13

14 performance Tahoe 14

15 BSD 4.3 Reno modifiche alla versione Tahoe di TCP, introdotte da Van Jacobson nel 1990 presenta Fast Recovery Timeout -> congestione rilevante cwnd al minimo. Slowstart 3 DupACK -> congestione non grave almeno tre pacchetti sono arrivati dopo quello perso cwnd dimezzata. Congestion avoidance 15

16 BSD 4.3 Reno altre meccanismi SLIP header compression SLIP header compression, ottimizzazione della dimensione dello header del pacchetto per comunicazioni che non sfruttano le capacità del link (per esempio Telnet) su collegamenti punto-punto TCP header prediction Seq ricevuto successivo all'ultimo: elaborazione veloce Altrimenti: normale: ricostruzione dell'ordine Path MTU discovery 16

17 TCP Versions: Reno Recover 1 packet loss ok, but multiple loss => timeout X Sequence No X X Now what? - timeout Time 17

18 performance Reno window SS CA time SS: Slow Start CA: Congestion Avoidance fast retransmission/fast recovery 18

19 Problemi di Reno non riesce a recuperare una situazione di congestione in cui più pacchetti di una stessa finestra di trasmissione sono stati persi. In questo caso è costretto a ripartire con Slow Start dopo lo scadere del timeout. SACK può risolvere il problema, ma deve essere implementato da mittente e destinatario 19

20 TCP Vegas nuova soluzione (1994) per TCP, non inclusa nelle varie versioni di BSD sviluppato presso il Science Departement of Arizona University da Brakmo e Peterson con il supporto di National Science Foundation e ARPA. evoluzione della versione Reno. Le modifiche riguardano solo il lato mittente, portando un incremento delle prestazioni pari al 40-70% (senza sottrarre banda alle altre connessioni presenti) Idea chiave: sfruttare l'rtt per prevenire le congestioni. (Perché?) 20

21 TCP Vegas cerca di prevenire la congestione, adattando la portata dei dati in rete, in base alle variazioni della stima del valore di RTT Un aumento dell'rtt indica un 'allungamento' delle code dei router Slow start interrotta basandosi su RTT Tentativo di utilizzare almeno una posizione nelle code (ma non più di tre) durante congestion avoidance 21

22 TCP Vegas 22

23 BSD 4.4. NewReno TCP Reno, presenta alcune lacune nella gestione di alcuni casi di congestione. (perdite multiple) nuova versione di TCP (NewReno) sviluppata dalla Berkeley University nel si introduce lo stato 'fase di recupero' ( (Fast Retransmission Phase) ) nel quale vengono spediti i pacchetti mancanti. in questa fase, non vengono spediti nuovi dati fino a quando tutti i pacchetti rimasti da confermare al momento della congestione, non siano stati ricevuti correttamente dal destinatario. Gli ACK ricevuti in tale fase, verranno considerati in maniera leggermente diversa dal normale. Infatti, il numero di sequenza presente nell ACK può solo confermare dei pacchetti ritrasmessi nella fase di recupero e non quelli trasmessi prima della congestione. Questo tipo di gestione degli ACK va sotto il nome di partial ACK. Se ci si trova di fronte alla perdita di più pacchetti in una finestra di spedizione, si possono prendere in considerazione le opzioni SACK [ [RFC2582]. 23

24 NewReno Recover multiple losses in successive RTTs using notion of partial ack. No timeout. X Sequence No X X Now what? partial ack recovery Time 24

25 SACK X Sequence No X X Now what? send retransmissions as soon as detected Time 25

26 TCP e gestione delle code (queue) Eliminazione della coda (tail drop) Se la coda del router è piena vengono i datagrammi vengono scartati Rischio di 'sincronizzazione globale' (slow-start per tutte le connessioni) Scarto casuale anticipato (RED: random early drop) Se la coda è piena il datagramma viene sempre scartato Se la coda è quasi piena,, il datagramma viene scartato con probabilità legata allo spazio disponibile in coda Utilizzo della media pesata dello spazio disponibile per ignorare picchi istantanei 26

27 Varianti di RED Stochastic Fair Blue Simile a RED ma autoconfigurante (probabilità modificata ogni volta che la coda è vuota o piena) Weighted RED Probabilità diverse secondo Type of Service Adaptive / Active RED (ARED) La lunghezza media della coda viene utilizzata per decidere la rapidità di adattamento alle variazioni (parametri media pesata) 27

28 Source Quench In caso di congestione il router invia un messaggio "ICMP Source Quench" al mittente. Il mittente riduce (al minimo) la finestra Contro: Pro: In caso di congestione aumenta il traffico Individuazione delle congestioni rapida 28

29 Explicit Congestion Notification (ECN) In caso di congestione il router imposta gli "ECN bit" nell'ip header. Il ricevente imposta "ECN echo" Il mittente, dopo la ricezione di ECN echo, imposta la finestra al minimo 29

30 Explicit Congestion Notification (ECN) Contro ECN è più lento di Source Quench. Pros. Può prevenire la perdita di pacchetti Non aumenta il traffico 30

31 Problemi di TCP in reti a banda larga Dimensioni delle code dei router Possono causare perdite di pacchetti Dimensioni dei buffer di spedizione e ricezione I dati da spediti devono essere conservati fino ad ACK Wireless: TCP potrebbe confondere la perdita di pacchetti dovuta a problemi radio con problemi di congestione Diminuzione non necessaria della velocità di trasmissione Difficoltà a ripristinare la velocità ottimale 31

32 FAST (FAST AQM Scalable TCP) TCP Congestion Avoidance per Long fat network (alto valore bandwidth*delay) Modifiche sender side Usa RTT in modo simile a Vegas Obiettivo: Mantenere costante il numero di 'flying bits' Problemi: Coesistenza con versioni di TCP 'loss based': viene prevenuta al congestione a vantaggio di chi non la previene 32

33 H TCP Loss-based, additive increase, mult decrease Il rate di incremento addittivo aumenta al passare del tempo dal precedente loss Unfair... 33

34 TCP Illinois 34

35 Scalable TCP 35

36 Westwood (+) Variante di NewReno, modifiche solo al mittente Pensato per Cammini con alti valori banda*latenza (large pipes) Potenziali perdite di dati (leaky pipes) Carico variabile (dynamic pipes) Agile probing (modifica di slow start) Eligible Rate basata su rate di ricezione ACK Utilizzata nel calcolo di ssthresh e cwin Persistent Non Congestion Detection (PNCD) 'Accellera' in caso di mancata congestione 36

37 Westwood (+) 37

38 versioni commerciali di TCP/IP Windows Linux MacOS 38

39 Windows Network Device Interface (NDIS) : interfaccia posta tra il livello 2 e 3 del modello OSI. Transport Driver Interface Specification (TDI) : interfaccia per il livello 4 del modello OSI. utilizzo di Selective ACK [ [RFC2018]] ed estensioni di TCP per ottenere alte prestazioni [ [RFC1323]. 39

40 Windows (2) Keep-Alive Messages : vengono scambiati dei messaggi tra i due host in comunicazione per sapere se sono ancora connessi. Time-wait Delay : nella fase di chiusura della connessione, prima di terminare la comunicazione, si deve attendere un tempo pari a 2MSL. In Windows 2000, questo tempo viene fissato per default a quattro minuti Calcolo dimensione di Receiver Window e Scaling Window meccanismi che permettono la spedizione di dati in reti molto performanti e con grandi periodi di latenza è possibile specificare un fattore di scala che può portare la dimensione massima di un pacchetto, a uno, due o più volte il limite massimo convenzionale di 64KByte. 40

41 Windows (3) Delayed ACK : per ridurre il numero di pacchetti spediti, si utilizza una tecnica che attende un certo periodo di tempo, prima di inviare gli ACK, sfruttando la possibilità di utilizzare gli ACK cumulativi. In generale, per verificare l arrivo di un nuovo pacchetto da confermare, si attendono 200ms. Selective ACK : è previsto l utilizzo della tecnica di Selective ACK. Agli header vengono aggiunti 2 byte per ospitare tale opzione. Timestamps : ad ogni pacchetto spedito, vengono allegate delle informazioni sul momento esatto di trasmissione, in modo tale da permettere una accuratezza maggiore nel calcolo del valore di RTT. Meccanismi di controllo della congestione : Slow start, Congestion Avoidance, Fast Retransmit e Fast Recovery analogamente alla versione Reno di TCP. 41

42 Macintosh In MacOS X, è stato utilizzato un sistema di comunicazione interamente basato sul NetBSD 4.4 versione NewReno, con funzionalità per Long Fat Pipes (analogo a Window Scaling) ) e nuove metodologie di calcolo del valore di RTT basate su timestamp. Vengono inoltre implementate le direttive per un protocollo TCP ad elevate performance [ [RFC1323] 42

43 UNIX gli ambienti UNIX come Linux, Solaris, e tutte le versioni commerciali, utilizzano come punto di riferimento le versioni di BSD, contenute nelle diverse distribuzioni (NetBSD, OpenBSD, FreeBSD). La differenza di implementazione fra i vari sistemi operativi è pressoché minima e, come MacOS X, tutte basate sulla versione 4.4 di BSD. 43

44 Linux sysctl -w net.ipv4.tcp_congestion_control=westwood oppure echo "westwood" > /proc/sys/net/ipv4/tcp_congestion_control Oppure (modifica permanente) In /etc/sysctl.conf net.ipv4.tcp_congestion_control=westwood 44