Il livello 4: TCP, UDP

Transcript

1 Il livello 4: TCP, UDP Silvano GAI Fulvio RISSO TCP-UDP - 1 Copyright: si veda nota a pag. 2

2 Nota di Copyright Questo insieme di trasparenze (detto nel seguito slides) è protetto dalle leggi sul copyright e dalle disposizioni dei trattati internazionali. Il titolo ed i copyright relativi alle slides (ivi inclusi, ma non limitatamente, ogni immagine, fotografia, animazione, video, audio, musica e testo) sono di proprietà degli autori indicati a pag. 1. Le slides possono essere riprodotte ed utilizzate liberamente dagli istituti di ricerca, scolastici ed universitari afferenti al Ministero della Pubblica Istruzione e al Ministero dell Università e Ricerca Scientifica e Tecnologica, per scopi istituzionali, non a fine di lucro. In tal caso non è richiesta alcuna autorizzazione. Ogni altra utilizzazione o riproduzione (ivi incluse, ma non limitatamente, le riproduzioni su supporti magnetici, su reti di calcolatori e stampate) in toto o in parte è vietata, se non esplicitamente autorizzata per iscritto, a priori, da parte degli autori. L informazione contenuta in queste slides è ritenuta essere accurata alla data della pubblicazione. Essa è fornita per scopi meramente didattici e non per essere utilizzata in progetti di impianti, prodotti, reti, ecc. In ogni caso essa è soggetta a cambiamenti senza preavviso. Gli autori non assumono alcuna responsabilità per il contenuto di queste slides (ivi incluse, ma non limitatamente, la correttezza, completezza, applicabilità, aggiornamento dell informazione). In ogni caso non può essere dichiarata conformità all informazione contenuta in queste slides. In ogni caso questa nota di copyright non deve mai essere rimossa e deve essere riportata anche in utilizzi parziali. TCP-UDP - 2 Copyright: si veda nota a pag. 2

3 I protocolli TCP e UDP Application Presentation Session Transport Telnet FTP SMTP SNMP TCP e UDP NFS XDR RPC Network Data Link Physical OSI Arp e Rarp ICMP IP Non Specificati Protocolli di routing Internet Protocol Suite TCP-UDP - 3 Copyright: si veda nota a pag. 2

4 TCP e UDP Due protocolli di trasporto alternativi Caratteristiche diverse: controllo di flusso end-to-end (TCP), oppure semplice protocollo di trasporto non affidabile (UDP) Realizzano funzionalità comuni a tutti gli applicativi Possono operare simultaneamente con molti applicativi diversi, tramite il concetto di porta (si veda in seguito) TCP-UDP - 4 Copyright: si veda nota a pag. 2

5 TCP-UDP: gestione degli applicativi (1) TCP e UDP gestiscono il livello di trasporto Devono realizzare un meccanismo per permettere agli applicativi di parlarsi Nel modello TCP/IP non esistono altri livelli intermedi tra transport e application Devono dare modo al sistema operativo di capire qual è l applicativo che desidera ricevere un determinato pacchetto dati Si definisce il concetto di PORTA All interno del pacchetto TCP/UDP, il campo PORT definisce quale applicativo di livello superiore dovrà ricevere il pacchetto TCP-UDP - 46 Copyright: si veda nota a pag. 2

6 TCP-UDP: gestione degli applicativi (2) Si definisce il concetto di SESSIONE All interno di un applicativo, gli identificativi di sessione definiscono qual è il thread incaricato di gestire il pacchetto in esame Sessione: IPsource, IPdest, PROTO, PORTsource, PORTdest Viene normalmente utilizzata a livello network (es. dai router per identificare un particolare livello dati); a livello TCP/UDP si preferisce parlare di connessione Connessione E identificata dai campi precedenti, escluso il PROTO Viene usata sia da TCP (es. trasferimento dati) che da UDP (es. sessione multimediale) TCP-UDP - 47 Copyright: si veda nota a pag. 2

7 Demultiplexing applicativo Thread 1 Thread 2 Connection Application 1 Application 2 Port Port TCP UDP Protocol Type IP layer TCP-UDP - 48 Copyright: si veda nota a pag. 2

8 Porte TCP e UDP Sono il mezzo con cui un programma client indirizza un programma server un ftp client per connettersi ad un ftp server indica: l indirizzo IP dell elaboratore remoto il numero della porta associata all ftp server Caratteristiche identificate da un numero naturale su 16 bit = porte privilegiate (solo UNIX) = porte utente porte statiche quelle dove un server è in ascolto porte dinamiche quelle usate per completare una richiesta di connessione e svolgere un lavoro TCP-UDP - 49 Copyright: si veda nota a pag. 2

9 Well Known Port Sono associate agli applicativi principali, ad esempio: servizio port TCP UDP daytime 13 X X ftp 21 X telnet 23 X smtp 25 X tftp 69 X gopher 70 X finger 79 X http 80 X pop 110 X nntp 119 X Nonostante le porte UDP e TCP siano indipendenti si è scelto di non avere well known port sovrapposte In questo modo è più semplice gestire servizi che possono essere chiamati sia via UDP che TCP TCP-UDP - 50 Copyright: si veda nota a pag. 2

10 Connessioni TCP/UDP identificano un canale di comunicazione con il nome di connessione Sono identificate dalla quadrupla: <IP client><ip server><port client><port Server> 32 bit 32 bit 16 bit 16 bit Questa soluzione permette A molti client diversi di accedere allo stesso servizio sullo stesso server Allo stesso client di attivare più sessioni dello stesso servizio Viola il modello a layer (informazioni di livello 4 mischiate con informazioni di livello 3) TCP-UDP - 51 Copyright: si veda nota a pag. 2

11 Connessioni multiple A IP A, Port A, IP B, Port B Server B Main Thread (Well Known Port) C IP C, Port C, IP B, Port B Server B Main Thread (Well Known Port) A IP A, Port A, IP B, Port B Fork() Service Thread (Well Known Port) TCP-UDP - 52 Copyright: si veda nota a pag. 2

12 Server Iterativi e Concorrenti Sono i modi con cui i server possono gestire le connessioni in ingresso Iterativi: esiste un solo thread server; gestisce la connessione seguente solo quando quella precedente è terminata Utilizzati spesso da servizi basati su UDP Concorrenti: esiste un main thread server, che si clona ogni volta che arriva una nuova connessione; possono essere servite più connessioni contemporaneamente Utilizzati spesso da servizi basati su TCP TCP-UDP - 53 Copyright: si veda nota a pag. 2

13 UDP: User Datagram Protocol Protocollo di trasporto di tipo non connesso Aggiunge due funzionalità a quelle di IP: multiplexing delle informazioni tra le varie applicazioni tramite il concetto di porta checksum per verificare l integrità dei dati Non prevede un controllo di flusso Non è in grado di adattarsi autonomamente a variazioni di traffico Non prevede meccanismi di ritrasmissione in caso di errori E un potenziale killer della rete Internet Error checking Controlla che il pacchetto sia integro, ma non si preoccupa di correggere in qualche modo l errore TCP-UDP - 5 Copyright: si veda nota a pag. 2

14 UDP: Formato Pacchetto UDP Source Port UDP Destination Port UDP Message Length UDP Checksum DATA Checksum e UDP Source sono opzionali: possono essere posti a 0 CRC= 0: non interessa il controllo errori sull header comunicazione monodirezionale TCP-UDP - 6 Copyright: si veda nota a pag. 2

15 UDP: applicabilità Utile quando: si opera su rete affidabile oppure quando l affidabilità non è importante l applicazione mette tutti i dati in un singolo pacchetto non è importante che tutti i pacchetti arrivino a destinazione eventuali meccanismi di ritrasmissione (se necessari) vengano gestiti direttamente dall applicazione TCP-UDP - 7 Copyright: si veda nota a pag. 2

16 UDP: applicazioni multimediali Caratteristiche delle applicazioni multimediali I dati devono arrivare più velocemente possibile (è preferibile perdere pacchetti piuttosto che questi arrivino in ritardo) l applicazione non necessita di ritrasmissione è necessaria una certa banda minima per la comunicazione RTP (Real Time Transfer Protocol) H.323: standard per videoconferenza su IP UDP non ha controllo di flusso, quindi è adatto a trasmissioni in real time TCP-UDP - 8 Copyright: si veda nota a pag. 2

17 UDP: applicazioni convenzionali Le principali applicazioni classiche che utilizzano UDP sono: NFS (Network File System) SNMP (Simple Network Management Protocol) Applicazioni Runix rwho ruptime TCP-UDP - 9 Copyright: si veda nota a pag. 2

18 TCP: Transmission Control Protocol Un protocollo di trasporto: byte-oriented connesso Utilizzato da applicativi che richiedono la trasmissione affidabile dell informazione: telnet ftp (File Transfer Protocol) smtp (Simple Mail Transfer Protocol) http (HyperText Transfer Protocol) TCP-UDP - 10 Copyright: si veda nota a pag. 2

19 TCP: funzionalità Funzionalità TCP: Supporto della connessione tramite circuiti virtuali Error Checking Controllo di flusso Multiplazione e demultiplazione Controllo di stato e di sincronizzazione TCP garantisce la consegna del pacchetto, UDP no! TCP-UDP - 11 Copyright: si veda nota a pag. 2

20 TCP: caratteristiche (1) Come UDP ha il concetto di porta La comunicazione tra due entità TCP fa uso di un circuito virtuale Al circuito virtuale è associato un protocollo di trasporto full-duplex acknowledge controllo di flusso TCP-UDP - 12 Copyright: si veda nota a pag. 2

21 TCP: caratteristiche (2) TCP richiede più banda e più CPU di UDP maggiori controlli maggiore memoria necessaria header più grosso ( spreco di banda) memoria centrale nell host (codice di gestione più grosso) Buffering (per riassemblaggio del flusso) ritrasmissione TCP segmenta e riassembla i dati secondo le sue necessità: non garantisce nessuna relazione tra il numero di read e quello di write Il TCP remoto deve fornire un acknowledge dei dati, normalmente tramite piggybacking TCP-UDP - 13 Copyright: si veda nota a pag. 2

22 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 point-to-point: one sender, one receiver reliable, in-order byte steam: no message boundaries pipelined: TCP congestion and flow control set window size full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver 3: Transport Layer 3b-1

23 TCP: Formato pacchetto Destination Port Source Port Sequence Number Acknowledgement Number HLEN Reserv. Control Window Checksum Options (if any) Urgent Pointer Padding Data TCP-UDP - 14 Copyright: si veda nota a pag. 2

24 TCP: Campi dell header (1) Source Port, Destination Port Sequence Number Indica la posizione (in byte) di quel pacchetto all interno del flusso Il valore iniziale è scelto in maniera casuale ad ogni connessione e indipendentemente da ogni macchina Acknowledge Number Campo dedicato al piggyback Indica il numero d ordine del prossimo byte che ci si aspetta di ricevere Header Lenght Lunghezza dell header in multipli di 32 bit TCP-UDP - 15 Copyright: si veda nota a pag. 2

25 TCP: Campi dell header (2) Reserved Non usato Control URG: Urgent Pointer is valid ACK: Acknowledgement field is valid PSH: This segment request a push RST: Reset the connection SYN: Synchronize sequence number FIN: Sender has reached end of its byte stream TCP-UDP - 16 Copyright: si veda nota a pag. 2

26 TCP: Campi dell header (3) Window Indica quanti byte possono ancora essere trasmessi prima di un ACK L host è in grado di ricevere quindi fino al numero di sequenza ACK + WINDOW Urgent Pointer Indica che nel pacchetto ci sono uno o più byte urgenti Lo stack TCP deve far in modo che l applicazione interessata vada in urgent mode. Solo dopo che i dati urgenti sono stati tutti consumati, l applicazione può tornare in normal mode Tipicamente associati ad eventi asincroni: interrupt, abort, TCP-UDP - 17 Copyright: si veda nota a pag. 2

27 TCP: Campi dell header (4) Options, nella forma TLV Maximum Segment Size (normalmente pari alla MTU) SACK (Selective Acnowledgements) Window Scale Option TCP-UDP - 18 Copyright: si veda nota a pag. 2

28 TCP seq. # s and ACKs Seq. # s: byte stream number of first byte in segment s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn t say, - up to implementor User types C host ACKs receipt of echoed C Host A Host B Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 simple telnet scenario host ACKs receipt of C, echoes back C time 3: Transport Layer 3b-3

29 TCP ACK generation [RFC 1122, RFC 2581] Event in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending out-of-order segment arrival higher-than-expect seq. # gap detected arrival of segment that partially or completely fills gap TCP Receiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap 3: Transport Layer 3b-6

30 TCP: retransmission scenarios Host A Host B Host A Host B Seq=92, 8 bytes data Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 ACK=100 X timeout Seq=100 timeout Seq=92 timeout loss Seq=92, 8 bytes data Seq=92, 8 bytes data ACK=120 ACK=100 time lost ACK scenario time premature timeout, cumulative ACKs 3: Transport Layer 3b-7

31 TCP: reliable data transfer event: data received from application above create, send segment simplified sender, assuming one way data transfer no flow, congestion control wait wait for event event event: timer timeout for segment with seq # y retransmit segment event: ACK received, with ACK # y ACK processing 3: Transport Layer 3b-4

32 TCP: reliable data transfer Simplified TCP sender 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compue new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */ 3: Transport Layer 3b-5

33 TCP Round Trip Time and Timeout Q: how to set TCP timeout value? longer than RTT note: RTT will vary too short: premature timeout unnecessary retransmissions too long: slow reaction to segment loss Q: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions, cumulatively ACKed segments SampleRTT will vary, want estimated RTT smoother use several recent measurements, not just current SampleRTT 3: Transport Layer 3b-9

34 TCP Round Trip Time and Timeout EstimatedRTT = (1-x)*EstimatedRTT + x*samplertt Exponential weighted moving average influence of given sample decreases exponentially fast typical value of x: 0.1 Setting the timeout RTT plus safety margin large variation in EstimatedRTT -> larger safety margin Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*abs(samplertt-estimatedrtt) 3: Transport Layer 3b-10

35 TCP Connection Management Recall: TCP sender, receiver establish connection before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow) client: connection initiator Socket clientsocket = new Socket("hostname","port number"); server: contacted by client Socket connectionsocket = welcomesocket.accept(); Three way handshake: Step 1: client end system sends TCP SYN control segment to server specifies initial seq # Step 2: server end system receives SYN, replies with SYNACK control segment ACKs received SYN allocates buffers specifies server-> receiver initial seq. # 3: Transport Layer 3b-11

36 Apertura della connessione Three way handshake Eventi Host A Network Eventi Host B Invia SYN seq=x Riceve SYN segment Invia SYN seq=y, ACK=x+1 Riceve SYN + ACK segment Invia ACK=y+1 Riceve ACK segment TCP-UDP - 19 Copyright: si veda nota a pag. 2

37 Chiusura della connessione Three way handshake modificato Eventi Host A (L utente chiude la connessione) Invia FIN seq=x Riceve ACK segment Riceve FIN + ACK segment Invia ACK=y+1 Network Eventi Host B Riceve FIN segment Invia ACK=x+1 (Notifica la chiusura all utente) (L utente chiude la connessione) Invia FIN seq=y, ACK=x+1 3-way handshake modificato: l host B può ancora voler trasmettere dei dati, anche se l host A ha chiuso la connessione; quindi la chiusura della connessione (lato host B) può avvenire in un secondo tempo Riceve ACK segment TCP-UDP - 20 Copyright: si veda nota a pag. 2

38 TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle 3: Transport Layer 3b-14

39 Gestione della connessione (1) Comprende due compiti Error control: determinare se c è stato un errore di trasmissione (ad es. se mancano alcuni dati) Flow control, che può essere suddiviso in: End-to-end flow control: meccanismo per adattare il flusso alla massima capacità disponibile sulla rete, senza penalizzare altre sorgenti (fairness) Congestion control: meccanismo per adattare il flusso nel caso in cui la capacità di trasporto della rete diminuisce TCP-UDP - 21 Copyright: si veda nota a pag. 2

40 Gestione della connessione (2) In TCP questi compiti sono svolti contemporaneamente dagli stessi meccanismi Una situazione di congestione è determinata in base a segnali impliciti provenienti dalla rete Segnale implicito: packet lost Tradeoffs Vantaggi: un solo meccanismo gestisce ambedue i task Svantaggi: in certi casi non è possibile discriminare tra una situazione di errore e una congestione TCP-UDP - 22 Copyright: si veda nota a pag. 2

41 TCP Flow Control flow control sender won t overrun receiver s buffers by transmitting too much, too fast receiver: explicitly informs sender of (dynamically changing) amount of free buffer space rcvr window size field in TCP segment recevier buffering sender: amount of transmitted, unacked data less than most recently-receiver rcvr window size 3: Transport Layer 3b-8

42 End-to-end flow control (Flow Ctrl-1) Controlla che il flusso di dati endto-end sia accettabile evita che il trasmettitore spedisca troppi dati se il ricevitore non è in grado di riceverli (ad es. un mainframe che trasmette ad un PC) controlla che i pacchetti arrivino correttamente, e nel momento in cui qualcuno si perde procede alla loro ritrasmissione E composto da due algoritmi Sliding window mechanism: è il meccanismo che gestisce il numero di pacchetti da trasmettere prima di ricevere una conferma di avvenuta ricezione controlla inoltre che i pacchetti siano arrivati e in caso non siano arrivati procede alla ritrasmissione Round Trip Estimate: è il meccanismo che controlla il round trip delay per sapere quando procedere alla ritrasmissione (su una connessione lenta questo time deve essere fissato ad un valore più alto) TCP-UDP - 23 Copyright: si veda nota a pag. 2

43 E2E FC: Sliding Window (1) Meccanismo che permette la trasmissione di N dati (N-window) prima che giunga l acknowledge del primo dato trasmesso Dati trasmessi e confermati Ampiezza della Window (10) Dati non trasmissibili (a meno che arrivi un acknowledge) Dati trasmessi e non ancora confermati Dati non ancora trasmessi (ma è possibile farlo) Sender host TCP-UDP - 24 Copyright: si veda nota a pag. 2

44 E2E FC: Sliding Window (2) In TCP la Window è variabile Deve essere stabilito un valore iniziale (che può essere diverso per Sender e Receiver); viene negoziato all apertura della connessione A connessione aperta il ricevitore comunica al trasmettitore, insieme all acknowledge, il valore della window ammessa Può ad esempio diminuirla se il buffer nel quale mette i dati TCP è pieno e la ricezione di altri segmenti provocherebbe la perdita di alcuni dati per overflow L incremento della window porta ad un incremento di prestazioni, visibile soprattutto nel caso di lunghe distanze (nel quale il round trip time è notevole) Solo con una opportuna Window è possibile giungere alla completa occupazione del canale, anche se il round trip time tra sorgente e destinazione è molto alto TCP-UDP - 25 Copyright: si veda nota a pag. 2

45 E2E FC: Sliding Window (3) In TCP la dimensione della finestra è in byte, non in segmenti Il campo window del pacchetto TCP indica quanti byte possono ancora essere trasmessi prima di un ACK L acknowledge è dato in forma cumulativa L arrivo di un ack relativo al segmento X indica implicitamente che tutti i segmenti precedenti ad X sono stati ricevuti E un vantaggio se la connessione non ha perdite di pacchetti (si diminuisce il traffico di controllo tra il receiver e il sender) Può essere uno svantaggio nel caso di perdita di pacchetti (può essere forzata la trasmissione di un segmento anche se questo era precedentemente arrivato correttamente) Evoluzione: SACK TCP-UDP - 26 Copyright: si veda nota a pag. 2

46 E2E FC: Retransmission Timer (1) E la soglia massima di tempo che deve intercorrere da quando un pacchetto è inviato dal Sender a quando questo riceve l acknowledge dal Receiver Ad ogni segmento trasmesso viene fatto partire un timer Se il timer scatta senza aver ricevuto l ACK relativamente a quel segmento scatta la procedura di ritrasmissione Non essendo obbligatorio confermare tutti i segmenti, basta che un segmento successivo sia stato a sua volta confermato TCP-UDP - 27 Copyright: si veda nota a pag. 2

47 E2E FC: Retransmission Timer (2) Il timer è autoadattante è calcolato in base alle condizioni del traffico: connessioni con basso Round Trip Delay hanno timer bassi a run-time è inoltre in grado di adattarsi ad eventuali variazioni del round trip time medio generando un aumento del timer senza causare ritrasmissioni ad ogni ack ricevuto il valore del timer viene ricalcolato per tenere conto delle variazioni di round trip time Cosa si ritrasmette? Se si ritrasmette una quantità di dati pari a tutta la Window ammessa, è possibile dare origini a congestioni Entrano in gioco i meccanismi di Congestion Control TCP-UDP - 28 Copyright: si veda nota a pag. 2

48 Principles of Congestion Control Congestion: informally: too many sources sending too much data too fast for network to handle different from flow control! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) a top-10 problem! 3: Transport Layer 3b-15

49 Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput 3: Transport Layer 3b-16

50 Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet 3: Transport Layer 3b-17

51 Causes/costs of congestion: scenario 2 always: λ = λ (goodput) in out perfect retransmission only when loss: λ > λ in out retransmission of delayed (not lost) packet makes λ larger in (than perfect case) for same λ out costs of congestion: more work (retrans) for given goodput unneeded retransmissions: link carries multiple copies of pkt 3: Transport Layer 3b-18

52 Causes/costs of congestion: scenario 3 four senders multihop paths timeout/retransmit Q: what happens as λ in and increase? λ in 3: Transport Layer 3b-19

53 Causes/costs of congestion: scenario 3 Another cost of congestion: when packet dropped, any upstream transmission capacity used for that packet was wasted! 3: Transport Layer 3b-20

54 Approaches towards congestion control Two broad approaches towards congestion control: End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at 3: Transport Layer 3b-21

55 Case study: ATM ABR congestion control ABR: available bit rate: elastic service if sender s path underloaded : sender should use available bandwidth if sender s path congested: sender throttled to minimum guaranteed rate RM (resource management) cells: sent by sender, interspersed with data cells bits in RM cell set by switches ( network-assisted ) NI bit: no increase in rate (mild congestion) CI bit: congestion indication RM cells returned to sender by receiver, with bits intact 3: Transport Layer 3b-22

56 Case study: ATM ABR congestion control two-byte ER (explicit rate) field in RM cell congested switch may lower ER value in cell sender send rate thus minimum supportable rate on path EFCI bit in data cells: set to 1 in congested switch if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell 3: Transport Layer 3b-23

57 TCP Congestion Control end-end control (no network assistance) transmission rate limited by congestion window size, Congwin, over segments: Congwin w segments, each with MSS bytes sent in one RTT: throughput = w * MSS RTT Bytes/sec 3: Transport Layer 3b-24

58 TCP congestion control: probing for usable bandwidth: ideally: transmit as fast as possible (Congwin as large as possible) without loss increase Congwin until loss (congestion) loss: decrease Congwin, then begin probing (increasing) again two phases slow start congestion avoidance important variables: Congwin threshold: defines threshold between two slow start phase, congestion control phase 3: Transport Layer 3b-25

59 Congestion Control (Flow Ctrl-2) La congestione è rilevata nel momento in cui un retransmission timer va in timeout Le prime versioni di TCP quando andavano in timeout ritrasmettevano l intera window (4.2BSD) Questo poteva causare gravi congestioni della rete (congestion collapse): Nell ottobre 1986 Arpanet fu bloccata da una congestione (da 32 kbs a 40 bps) Meccanismi (4.3 BSD Tahoe) Additive Increase - Multiplicative Decrease (AIMD) window size: gestione della window in caso di congestione Slow start: ad inizio connessione (in TCP Tahoe anche dopo una congestione) si procede ad una immissione di dati nella rete con throughput crescente (probing delle capacità di rete) Fast retransmit: rilevazione veloce della perdita di un pacchetto TCP-UDP - 29 Copyright: si veda nota a pag. 2

60 CC: AIMD (1) Nel momento in cui si verifica una congestione non è opportuno ritrasmettere l intera window questo può portare ad un peggioramento della congestione Additive Increase (Congestion Avoidance phase) il numero di dati trasmessi aumenta linearmente (la window aumenta linearmente) E utilizzata a run-time, in modo che il TCP occupi progressivamente tutta la banda disponibile sul canale Multiplicative Decrease: E il meccanismo utilizzato nel momento in cui viene rilevata una congestione (perdita di pacchetti): viene ritrasmessa una quantità di dati ridotta, per evitare di peggiorare ancora la congestione Il meccanismo è di tipo esponenziale decrescente Si ritrasmette metà della window Se scatta nuovamente il timeout si ritrasmette un quarto della window Si procede fino a quando la ritrasmissione permessa è di un solo segmento TCP-UDP - 30 Copyright: si veda nota a pag. 2

61 TCP Congestion Avoidance Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 1 perform slowstart 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs 3: Transport Layer 3b-27

62 CC: AIMD (2) Implementazione: si definiscono 2 nuove window receiver_window: esprime il numero di MSS inviabili in base alla window corrente congestion_window: esprime il numero di MSS inviabili nel caso di congestione In ogni momento si ha: Allowed_window = min (receiver_window, congestion_window) In caso di congestione congestion_window viene dimezzata (fino a 1 MSS min) retransmission_timer (backoff timer) per i segmenti che rimangono compresi nella window: viene aumentato in modo esponenziale (raddoppio) ogni volta che va in timeout (quindi anche quando la Congestion Window è ormai a 1 segmento) TCP-UDP - 31 Copyright: si veda nota a pag. 2

63 CC: AIMD and Congestion Avoidance Fase di probing della rete, per cercare di ottenere il massimo throughput il TCP suppone di essere in una situazione critica, ossia molto vicino al massimo rate ammesso Questa fase è conosciuta dal fatto che precedentemente c è stata una congestione in presenza di una window simile a quella attuale In questa fase la congestion window viene incrementata di un MSS ogni RTT ( 1 MSS ogni window di dati trasmessi) è circa equivalente ad un incremento di MSS/cwnd bytes ogni pacchetto (segmento) Tasso di incremento molto ridotto Si vuole evitare di incorrere nuovamente in un packet loss Algoritmo proposto da Nagle (1987) TCP-UDP - 32 Copyright: si veda nota a pag. 2

64 Congestion Control: Slow Start (1) Garantisce una crescita graduale del bit rate Teoricamente sarebbe possibile trasmettere l intera window; questo però potrebbe dare origine a congestioni Si preferisce incrementare gradualmente il rate, in modo da evitare, se possibile, questo problema Crescita esponenziale Entra in azione sia dopo una congestione sia all apertura di una connessione Nel caso si provenga da una congestione non è opportuno riportare il bit rate a quello precedente la congestione in quanto può dare origine a oscillazioni TCP-UDP - 33 Copyright: si veda nota a pag. 2

65 TCP Slowstart Slowstart algorithm initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) RTT Host A Host B one segment two segments four segments exponential increase (per RTT) in window size (not so slow!) loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP) time 3: Transport Layer 3b-26

66 Congestion Control: Slow Start (2) Congestion Window Viene inizializzata ad 1 Viene incrementata di una unità (1MSS) ad ogni arrivo di un ACK (--> crescita esponenziale, 1 MSS ogni MSS di dati trasmessi) Arrivo di un pacchetto: trasmissione di 2 nuovi pacchetti Il primo viene trasmesso per il principio di conservazione dei pacchetti Il secondo viene trasmetto perché si vuole incrementare il rate della connessione Esempio Inizio: congestion= 1 --> trasmette 1 segmento Riceve 1 ack --> congestion = 2 --> può trasmettere fino a 2 segmenti Dopo la trasmissione di questi 2 segmenti, riceve 2 ack --> congestion viene incrementata di due --> congestion = 4 --> può trasmettere fino a 4 segmenti TCP-UDP - 34 Copyright: si veda nota a pag. 2

67 Congestion Control: Slow Start (3) Incremento graduale della Congestion Window: ad un certo punto inizia a prevalere la receiver_window Questa viene comunicata, di volta in volta, dall altro host remoto in base alla sua capacità di ricevere traffico Nel caso ideale, receiver_window = infinito nel caso in cui si arrivi da una congestione, quando cwnd raggiunge un valore pari alla metà del valore della window relativa a quando si è verificata la congestione si entra nella fase di congestion avoidance TCP-UDP - 35 Copyright: si veda nota a pag. 2

68 Congestion Control: Fast Retransmit Algoritmo per accorgersi di un probabile pacchetto perso senza aspettare il timeout Funzionamento Ad ogni pacchetto ricevuto, il receiver manda un ACK Se il sender riceve 3 ACK uguali, ritrasmette il pacchetto immediatamente seguente all ACK stesso (e solo quello) Gli ACK sono cumulativi e la ricezione di 3 ACK significa che il ricevitore ha correttamente ricevuto almeno altri 3 pacchetti che non può ancora confermare perché gli manca un pacchetto intermedio Vantaggi: si snellisce la ritrasmissione senza aspettare il timeout Svantaggi qualche volta il pacchetto è semplicemente in ritardo e quindi potrebbe essere fatta una ritrasmissione inutile Non funziona nel caso di multiple losses TCP-UDP - 36 Copyright: si veda nota a pag. 2

69 Congestion Control: FreeBSD 3.3 /* * When new data is acked, open the congestion window. * If the window gives us less than ssthresh packets * in flight, open exponentially (maxseg per packet). * Otherwise open linearly: maxseg per window * (maxseg^2 / cwnd per packet). */ { register u_int cw = tp->snd_cwnd; register u_int incr = tp->t_maxseg; if (cw > tp->snd_ssthresh) incr = incr * incr / cw; tp->snd_cwnd = min(cw + incr, TCP_MAXWIN<<tp->snd_scale); } Questa è una cwnd; dovrà poi essere confrontata con la massima window accettabile dal receiver TCP-UDP - 37 Copyright: si veda nota a pag. 2 Maximum Segment Size Entra solo durante la congestion avoidance (cwnd maggiore del precedente valore nel quale si è verificata la congestione diviso per due) Il pacchetto è considerato sempre pari a MSS [netinet/tcp_input.c]

70 TCP: le evoluzioni (1) 4.2BSD (1983) Prima release ampiamente utilizzata di TCP/IP 4.3BSD (1986) Seconda release, con miglioramenti sulle performance 4.3BSD Tahoe TCP (1988) Slow Start, Congestion Avoidance (AIMD), Fast Retransmit 4.3BSD Reno TCP (1990) Algoritmi precedenti più Fast Recovery Altre funzionalità: TCP header prediction, SLIP header compression, routing table changes [UNIX Network Programming, vol 1, pg 20] TCP-UDP - 38 Copyright: si veda nota a pag. 2

71 TCP: le evoluzioni (2) NewReno TCP Miglioramenti al RENO, senza tuttavia l introduzione di SACK (Selective Acnolowledgement) migliora le performance, ma è ancora limitato quando ci sono più losses all interno della stessa window TCP SACK Selective Acknowledge TCP Vegas Sviluppato presso l università dell Arizona Adatta la TCP Window alle condizioni attuali della rete, in base al throughput atteso e a quello misurato 4.4BSD (1993) Altre funzionalità: multicasting, long fat pipe modifications TCP-UDP - 39 Copyright: si veda nota a pag. 2

72 Fast Recovery Impedisce l attivazione dello Slow Start dopo il Fast Retransmit Se la perdita non è rilevata con timeout, significa che probabilmente la rete è ancora in grado di portare traffico (non è in congestione acuta) Finestra di congestione: ridotta a metà del valore rilevato nel Fast Retransmit (alla ricezione del 3 dup acks) più il numero di dup acks che sono stati rilevati TCP Reno Se la congesione è dovuta a timeout, si comporta come TCP Tahoe (cwnd= 1) Se la congestione è dovuta a Fast Retransmit, adotta il Fast Recovery TCP-UDP - 40 Copyright: si veda nota a pag. 2

73 Cwnd (bytes) TCP: esempi di comportamento Congestion avoidance phase Drops Slow start TCP Tahoe time Cwnd (bytes) Slow start Drops Congestion avoidance phase TCP Reno (no timeout) time TCP-UDP - 41 Copyright: si veda nota a pag. 2

74 Note sul Throughput del TCP (1) Il massimo throughput ottenibile in condizioni ideali è pari a max_window / RTT Idealmente max_window vale infinito; in realtà spesso è molto al di sotto di 64KB (Windows usa normalmente 16KB) Nel caso di connessioni su lunghe distanze le curve precedenti potrebbero non avere la congestion avoidance phase Solo slow start + steady state, con cwnd = max_window Allo start-up di una connessione non esiste la congestion avoidance (solo Slow start) TCP-UDP - 42 Copyright: si veda nota a pag. 2

75 Note sul Throughput del TCP (2) Il throughput del TCP è decisamente bursty Se i routers hanno buffering di tipo drop-tail, le sorgenti tendono a sincronizzarsi e il throughput della rete scende nuovamente RED (Random Early Detection): algoritmo di buffering per evitare sorgenti TCP sincronizzate TCP e UDP convivono male su uno stesso canale UDP tende a mangiare tutta la banda disponibile perchè non adatta il suo rate E necessario ricorrere ad altri sistemi (ad esempio meccanismi hardware nei routers) per limitare il problema di queste sorgenti greedy TCP-UDP - 43 Copyright: si veda nota a pag. 2

76 AIMD TCP congestion avoidance: AIMD: additive increase, multiplicative decrease increase window by 1 per RTT decrease window by factor of 2 on loss event TCP Fairness Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 TCP connection 2 bottleneck router capacity R 3: Transport Layer 3b-28

77 Why is TCP fair? Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally R equal bandwidth share Connection 2 throughput Connection 1 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase R 3: Transport Layer 3b-29

78 Effects of TCP latencies Q: client latency from object request from WWW server to receipt? TCP connection establishment data transfer delay Notation, assumptions: Assume: fixed congestion window, W, giving throughput of R bps S: MSS (bits) O: oject size (bits) no retransmissions (no loss, no corruption) Two cases to consider: WS/R > RTT + S/R: ACK for first segment in window before window s worth of data sent WS/R < RTT + S/R: wait for ACK after sending window s worth of data sent 3: Transport Layer 3b-30

79 Effects of TCP latencies Case 1: latency = 2RTT + O/R Case 2: latency = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] 3: Transport Layer 3b-31

80 Alcuni problemi del TCP (1) Error detection TCP utilizza gli stessi meccanismi per Error control Flow control In presenza di un pacchetto perso non è possibile distinguere se È stato scartato da un router, dovuto ad una congestione È stato scartato per un errore di trasmissione (ad esempio su un link wireless) Proposte: riservare un bit ECN (Explicit Congestion Notification) nell header Il TCP capisce se il pacchetto mancante è dovuto ad una congestione; solo in questo caso dimezza la finestra di trasmissione TCP-UDP - 44 Copyright: si veda nota a pag. 2

81 Alcuni problemi del TCP (2) Satellite links TCP deve essere pesantemente modificato per funzionare su link satellitari La durata del 3-way handshake non è trascurabile su tali tipi di connessioni (meglio non fare traffico Web con HTTP 1.0) Il meccanismo a finestra non è adatto nel caso di alti RTT: è necessario aumentare il TCP Maximum Window Size per mezzo dell opzione Window Scaling Option Congestion Window memory TCP mantiene il valore della cwnd, anche nel caso in cui la sorgente sia idle per molto tempo (es. immissione dati in input) Le condizioni della rete potrebbero essere cambiate, quindi potrebbero verificarsi delle congestioni TCP-UDP - 45 Copyright: si veda nota a pag. 2