Reti di calcolatori e Sicurezza Transport Layer Part

Reti di calcolatori e Sicurezza -- Transport Layer --- Part of these slides are adapted from the slides of the book: Computer Networking: A Top Down Approach Featuring the Internet, 2 nd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2002. (copyright 1996 -2002 J. F Kurose and K. W. Ross, All Rights Reserved) Transport Layer 1

Chapter 3: Transport Layer Our goals: r understand principles behind transport layer services: m m multiplexing/demultipl exing reliable data transfer flow control congestion control r learn about transport layer protocols in the Internet: m m m UDP: connectionless transport TCP: connection-oriented transport TCP congestion control Transport Layer 2

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 3

Transport services and protocols r provide logical communication network data link physical al ic g lo d en d- en network data link physical po s an tr rt between app processes running on different hosts r transport protocols run in end systems m send side: breaks app messages into segments, passes to network layer m rcv side: reassembles segments into messages, passes to app layer r more than one transport protocol available to apps m Internet: TCP and UDP application transport network data link physical Transport Layer 4

Transport vs. network layer r network layer: logical communication between hosts r transport layer: logical communication between processes m relies on, enhances, network layer services Household analogy: 12 kids sending letters to 12 kids r processes = kids r app messages = letters in envelopes r hosts = houses r transport protocol = Ann and Bill r network-layer protocol = postal service Transport Layer 5

Internet transport-layer protocols r reliable, in-order delivery (TCP) network data link physical po rt r services not available: m delay guarantees m bandwidth guarantees s an no-frills extension of “best-effort” IP network data link physical tr m d en d- delivery: UDP en r unreliable, unordered al m network data link physical ic m congestion control flow control connection setup g lo m application transport network data link physical Transport Layer 6

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 7

Un primo servizio r Network = trasferimento di dati tra host della rete m Host identificato in modo univoco da un indirizzo IP r Come si fa a traferire i dati ricevuti ai processi che li hanno richiesti? m Multiplexing -- demultiplexing Transport Layer 8

Porte e processi r Porta identifica in modo univoco un processo in esecuzione su di un host m Porte di “sistema”: 0 – 1023 m FTP – 21, HTTP – 80, m RFC 1700 r Applicazioni di rete m Porte maggiori di 1024 Transport Layer 9

Multiplexing/demultiplexing segment – unità di trasferimento di dati delle entità coinvolte al livello del trasporto TPDU: transport protocol data unit application-layer data segment header segment Ht M Hn segment P 1 M application transport network P 3 Demultiplexing: invio dei segmenti ricevuti ai processi receiver M M application transport network P 4 M P 2 application transport network Transport Layer 10

Multiplexing/demultiplexing Multiplexing (host invio): Raccogliere i dati, Inviarli in rete con l’indirizzo corretto Demultiplexing (host recezione): Inviare i msg ricevuti al socket corretto = socket application transport network link = process P 3 P 1 application transport network P 2 P 4 application transport network link physical host 1 physical host 2 physical host 3 Transport Layer 11

Demultiplexing: modalità di funzionamento r host riceve un msg IP (datagrams) m Ogni datagram è caratterizzato da una coppia di indirizzi IP (mittente, destinatario) m ogni datagram come paylod ha un msg di trasporto m Msg del trasporto ha le informazioni dulle porte del mittente e del destinatario r Indirizzi IP & porte sono utilizzate per inviare il msg al socket corretto 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format Transport Layer 12

Connectionless demultiplexing r Creazione del socket (in un qualche modo) r Socket UDP sono identificati da: (dest IP address, dest port number) r Alla recezione del segmento UDP: m m Si contralla la porta di destinazione Invia il segmento al socket in ascolto su quella porta r datagrams con IP e porta del mittente diverse possono essere inviati allo stesso socket. Transport Layer 13

Connectionless demux Datagram. Socket server. Socket = new Datagram. Socket(6428); P 3 SP: 6428 DP: 9157 SP: 6428 DP: 5775 SP: 9157 client IP: A P 1 P 3 DP: 6428 server IP: C SP: 5775 DP: 6428 Client IP: B Transport Layer 14

Connection-oriented demux r TCP socket sono identificati m m source IP address source port number dest IP address dest port number r Host in recezione utilizza queste quattro informazioni per inviare il msg a destinazione r Server puo’ operare in modalità multithreading (pertanto sono attivi diversi socket) m Ogni socket attivo è identificato in modo univoco da quadrupla di valori Transport Layer 15

Connection-oriented demux (cont) P 3 SP: 80 DP: 9157 client IP: A SP: 9157 DP: 80 P 1 P 4 SP: 80 DP: 5775 server IP: C SP: 5775 DP: 80 Client IP: B Transport Layer 16

Multiplexing/demultiplexing host A source port: x dest. port: 23 server B source port: 23 dest. port: x Source IP: C Dest IP: B source port: y dest. port: 80 telnet app Web client host A Web client host C Source IP: A Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Web server B Web server Transport Layer 17

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 18

UDP: User Datagram Protocol r Protocollo di trasporto essenziale r Servizio di tipo “best effort” r Segmenti UDP : m perdere m senza ordine r connectionless: m no handshaking m Ogni segmento UDP è gestito in modo totalmente independente dagli altri segmenti [RFC 768] Quando è necessario utilizzare UDP? r Non c’è la necessità di stabilire una connessione r Applicazioni semplici: non abbiamo bisogno di informazioni di stato r Header dei segmenti piccoli r Nessun controllo per evitare i problemi di congestione Transport Layer 19

UDP r Multimedia m Possono permettersi una perdita di informazione. Length, in bytes of UDP r Chi utilizza UDP segment, m DNS including r Aggiungere un meccanismo header di affidabilità ad UDP m error recover al livello delle applicazioni 32 bits source port # dest port # length checksum Application data (message) UDP segment format Transport Layer 20

UDP checksum Obiettivo: scoprire eventuali errori di trasmissione Sender: r Segmenti sono visti come sequenze di interi di 16 bit r checksum: complemento ad 1 della somma di tutti gli interi che compongono il segmento r Checksum-value viene inserito nel campo del segmento denominato checksum Receiver: r Calcola il valore di checksum del segmento r Controlla se il valore calcolato corrisponde al valore memorizzato nel campo checksum del segmento: m NO - error detected m YES - no error detected. m Potrebbero essere presenti altri errori Transport Layer 21

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 22

Trasferimento affidabilke r Punto importante nei livelli app. , transport, link. r Una delle problematiche piu’ importanti del networking Transport Layer 23

Reliable data transfer: RDT rdt_send(): invocata dal livello delle applicazioni send side udt_send(): trasferire pacchetti su di un canale non affidabile deliver_data(): invia i dati ai livelli superiori receive side rdt_rcv(): chiamata al momento della recezione dei pacchetti Transport Layer 24

Automi e trasferimento affidabile r Trasferimento di dati (unidirezionale) m Ma con meccanismi di controllo del flusso. r Sender e receiver sono specificati da automi a stati finiti. event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event state 1 event actions state 2 Transport Layer 25

Rdt 1. 0: reliable transfer over a reliable channel r Il canale di trasmissione è affidabile m no bit erros m no loss of packets r Sender e receiver (fanno le ovvie cose!!) Wait for call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) sender Wait for call from below rdt_rcv(packet) extract (packet, data) deliver_data(data) receiver Transport Layer 26

Rdt 2. 0: channel with bit errors r Il canale puo’ modificare il valore dei bit presenti nei pacchetti m UDP checksum r Come vengono determinati questi errori di trasmissione: m m m acknowledgements (ACKs): receiver invia al sender un messaggio di recezione (senza errori) del pacchetto negative acknowledgements (NAKs): receiver invia al sender un messaggio di errore Sender trasmette nuovamente il pacchetto quando riceve un messaggio NAK r Novità (protocolli ARQ) m error detection m receiver feedback (ACK, NAK) m Ritrasmissione Transport Layer 27

rdt 2. 0: la specifica (FSM) rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && is. NAK(rcvpkt) Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && is. ACK(rcvpkt) L sender receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt, data) deliver_data(data) udt_send(ACK) Transport Layer 28

rdt 2. 0: assenza di errori rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && is. NAK(rcvpkt) Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && is. ACK(rcvpkt) L rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt, data) deliver_data(data) udt_send(ACK) Transport Layer 29

rdt 2. 0: Scenario con errore rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && is. NAK(rcvpkt) Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && is. ACK(rcvpkt) L Anche detti protocolli Stop-and-Wait rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt, data) deliver_data(data) udt_send(ACK) Transport Layer 30

rdt 2. 0 ha un fatal flaw! Cosa succede quando I messaggi ACK/NAK sono corrotti? r sender non è in grado di sapere cosa è successo al receiver r Si possono duplicare i messaggi trasmessi Come rimediare? r sender ACKs/NAKs e receiver’s ACK/NAK? Cosa accade in caso di perdita del sender ACK/NAK? Gestione dei messaggi duplicati: r sender aggiunge ad ogni pacchetto il sequence number r receiver non trasmette alle applicazioni i pacchetti duplicati stop and wait Sender sends one packet, then waits for receiver response Transport Layer 31

rdt 2. 1: sender, handles garbled ACK/NAKs rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && is. ACK(rcvpkt) Wait for call 0 from above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && is. ACK(rcvpkt) L rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || is. NAK(rcvpkt) ) udt_send(sndpkt) Wait for ACK or NAK 0 L Wait for ACK or NAK 1 Wait for call 1 from above rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) Transport Layer 32

rdt 2. 1: receiver, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq 0(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) extract(rcvpkt, data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq 1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Duplicato!!!! sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq 1(rcvpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq 0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) extract(rcvpkt, data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Transport Layer 33

rdt 2. 1 Sender: r Pacchetti con numero di sequenza (basta un solo bit di informazione) r Stati: m In ogni stato si deve ricordare il numero di sequenz (0 o 1) Receiver: r Deve controllare se il pacchetto è duplicato m Ogni stato mantiene informazione su quale numero di sequenza si attende Transport Layer 34

rdt 2. 2: Protocollo NAK-free r Come rdt 2. 1 ma. . . r Invece di inviare un msg NAK, il receiver invia un msg di ACK per l’ultimo pacchetto ricevuto correttamente m m Informazioni di stato “receiver must explicitly include seq # of pkt being ACKed” r ACK duplicato (lato sender) = NAK: ristrasmissione del pkt corrente Transport Layer 35

rdt 2. 2: sender e receiver (in pillole) rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && Wait for call 0 from above rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq 1(rcvpkt)) sndpkt = make_pkt(ACK 1, chksum) udt_send(sndpkt) Wait for 0 from below ( corrupt(rcvpkt) || is. ACK(rcvpkt, 1) ) udt_send(sndpkt) Wait for ACK 0 sender FSM fragment rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && is. ACK(rcvpkt, 0) receiver FSM fragment L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq 0(rcvpkt) extract(rcvpkt, data) deliver_data(data) sndpkt = make_pkt(ACK 0, chksum) udt_send(sndpkt) Transport Layer 36

rdt 3. 0: Canali con errori e perdita di pacchetti Ipotesi aggiuntive: Il canale di trasmissione puo’ perdere pacchetti (dati o ACK) m checksum, seq. #, ACK, sono sufficienti? Come si gestisce la perdita di pacchetti? m sender attende un certo periodo di tempo prima di trasmettere nuovamente l’informazione Una possibile soluzione: sender rimane in attesa per un periodo di tempo ragionevole r I pkt vengono trasmessi nuovamente se non viene ricevuto un ACK in questo periodo di tempo r Se la consegna del pkt (ACK) è solo ritardata (non avviene perdita) m Duplicazione: gestita tramite il # di sequenza m receiver specifica il # di sequenza del pkt ricevuto r countdown timer Transport Layer 37

rdt 3. 0 sender rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && is. ACK(rcvpkt, 1) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || is. ACK(rcvpkt, 0) ) timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && is. ACK(rcvpkt, 0) stop_timer timeout udt_send(sndpkt) start_timer L Wait for ACK 0 Wait for call 0 from above L rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || is. ACK(rcvpkt, 1) ) Wait for ACK 1 Wait for call 1 from above rdt_send(data) rdt_rcv(rcvpkt) L sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer Transport Layer 38

rdt 3. 0: esempio Transport Layer 39

rdt 3. 0: esempio Transport Layer 40

rdt 3. 0 r rdt 3. 0 funziona correttamente ma esibisce dei problemi di efficienza relativi all’uso della banda di trasmissione Transport Layer 41

rdt 3. 0: stop-and-wait sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R RTT first packet bit arrives last packet bit arrives, send ACK arrives, send next packet, t = RTT + L / R Transport Layer 42

Pipeline Pipelining: il mittente invia un certo numero di pacchetti senza attendere il relativo ACK m m Operare correttamente con i # di sequenza Buffer (mittente e destinatario) r Due tipi di protocolli: go-Back-N, selective repeat Transport Layer 43

Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R RTT first packet bit arrives last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3! Transport Layer 44

Protocolli “sliding window” Transport Layer 45

Go-Back-N Sender: r Header; k-bit per memorizzare i numeri di sequenza dei pkt. r Si permette di avere una “finestra fino ad N”, di pkt consecutivi in cui non è stato ricevuto il relativo ack r ACK(n): ACK cumulativo dei pkt con # minore di n r timer per i pkt in trasmissione r timeout(n): trasmettere il pkt n e tutti i pkt nella parte superiore della finestra di trasmissione Transport Layer 46

GBN: lato sender rdt_send(data) L base=1 nextseqnum=1 if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum, data, chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) Wait rdt_rcv(rcvpkt) && corrupt(rcvpkt) timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer Transport Layer 47

GBN: lato receiver default udt_send(sndpkt) L Wait expectedseqnum=1 sndpkt = make_pkt(expectedseqnum, ACK, chksum) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt, expectedseqnum) extract(rcvpkt, data) deliver_data(data) sndpkt = make_pkt(expectedseqnum, ACK, chksum) udt_send(sndpkt) expectedseqnum++ ACK viene inviato per i pkt corretti aventi il piu’ slto numero seq # m m ACK duplicati Variabile di stato: expectedseqnum r out-of-order pkt: m discard -> no buffering! m ACK pkt con il piu’ alto seq # Transport Layer 48

GBN in action Transport Layer 49

Selective Repeat r receiver invia ACK di tutti i pkt ricevuti correttamente. m m m Buffer per gestire l’ordine dei pacchetti Sender invia nuovamente i pkt senza ACK Sender attiva timer per ogni pkt senza ACK r La finestra del sender: m N # di sequenza consecutivi m Limite superiore alla dimensione della finestra Transport Layer 50

Selective repeat: sender, receiver windows Transport Layer 51

Selective repeat sender data from above : receiver pkt n in [rcvbase, rcvbase+N-1] r if next available seq # in r send ACK(n) timeout(n): r in-order: deliver (also window, send pkt r resend pkt n, restart timer ACK(n) in [sendbase, sendbase+N]: r mark pkt n as received r if n smallest un. ACKed pkt, advance window base to next un. ACKed seq # r out-of-order: buffer deliver buffered, in-order pkts), advance window to next not-yet-received pkt n in [rcvbase-N, rcvbase-1] r ACK(n) otherwise: r ignore Transport Layer 52

Selective repeat Transport Layer 53

Selective repeat r seq #’s: 0, 1, 2, 3 r window size=3 r receiver non riesce a discriminare i due comportamenti r Window di dimensione inferiore allo spazio dei numeri di sequenza Transport Layer 54

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 55

TCP: Overview r point-to-point: m one sender, one receiver r reliable, in-order byte stream: m no “message boundaries” r pipelined: m TCP congestion and flow control set window size r send & receive buffers RFCs: 793, 1122, 1323, 2018, 2581 r full duplex data: m bi-directional data flow in same connection m MSS: maximum segment size r connection-oriented: m handshaking (exchange of control msgs) init’s sender, receiver state before data exchange r flow controlled: m sender will not overwhelm receiver Transport Layer 56

TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) source port # dest port # sequence number acknowledgement number head not UA P R S F len used checksum Receive window Urg data pnter Options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept application data (variable length) Transport Layer 57

Il segment TCP r Connessione: m (Src. Port, Src. IPAddr, Dsr. Port, Dst. IPAddr) r window + flow control m acknowledgment, Sequence. Num, Rcvd. Winow Data(Sequence. Num) Sender Receiver Acknowledgment + Rcvd. Window r Flags m SYN, FIN, RESET, PUSH, URG, ACK r Checksum m pseudo header + TCP header + data Transport Layer 58

TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte in segment’s data ACKs: m seq # of next byte expected from other side m cumulative ACK Q: how receiver handles out-of-order segments m A: TCP spec doesn’t say, - up to implementor Host B Host A User types ‘C’ Seq=4 2, ACK = 79, da ta ata = d , 3 4 K= C 79, A = q e S host ACKs receipt of echoed ‘C’ = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=4 3, ACK =80 simple telnet scenario Transport Layer time 59

TCP Round Trip Time and Timeout Q: how to set TCP timeout value? r longer than RTT m but RTT varies r too short: premature timeout m unnecessary retransmissions r too long: slow reaction to segment loss Q: how to estimate RTT? r Sample. RTT: measured time from segment transmission until ACK receipt m ignore retransmissions r Sample. RTT will vary, want estimated RTT “smoother” m average several recent measurements, not just current Sample. RTT Transport Layer 60

TCP Round Trip Time and Timeout Estimated. RTT = (1 - )*Estimated. RTT + *Sample. RTT r Exponential weighted moving average r influence of past sample decreases exponentially fast r typical value: = 0. 125 Transport Layer 61

Example RTT estimation: Transport Layer 62

TCP Round Trip Time and Timeout Setting the timeout r Estimted. RTT plus “safety margin” m large variation in Estimated. RTT -> larger safety margin r first estimate of how much Sample. RTT deviates from Estimated. RTT: Dev. RTT = (1 - )*Dev. RTT + *|Sample. RTT-Estimated. RTT| (typically, = 0. 25) Then set timeout interval: Timeout. Interval = Estimated. RTT + 4*Dev. RTT Transport Layer 63

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 64

TCP: Sender Pseudo Codice 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 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 compute 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 */ Transport Layer 65

TCP reliable data transfer r TCP creates rdt service on top of IP’s unreliable service r Pipelined segments r Cumulative acks r TCP uses single retransmission timer r Retransmissions are triggered by: m m timeout events duplicate acks r Initially consider simplified TCP sender: m m ignore duplicate acks ignore flow control, congestion control Transport Layer 66

TCP sender events: data rcvd from app: r Create segment with seq # Se scade un timer, lo r seq # isrifaccio byte-stream ripartire con valore time-out doppio. number ofdifirst data Se ok, risettato al valore byte in segment ottenuto con estimated. RTT e dev. RTT r start timer if not already running (think of timer as for oldest unacked segment) r expiration interval: Time. Out. Interval timeout: r retransmit segment that caused timeout r restart timer Ack rcvd: r If acknowledges previously unacked segments m m update what is known to be acked start timer if there are outstanding segments Transport Layer 67

Next. Seq. Num = Initial. Seq. Num Send. Base = Initial. Seq. Num loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number Next. Seq. Num if (timer currently not running) start timer pass segment to IP Next. Seq. Num = Next. Seq. Num + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > Send. Base) { Send. Base = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ TCP sender (simplified) Comment: • Send. Base-1: last cumulatively ack’ed byte Example: • Send. Base-1 = 71; y= 73, so the rcvr wants 73+ ; y > Send. Base, so that new data is acked Transport Layer 68

TCP: retransmission scenarios Host A 2, 8 by tes da t Seq=92 timeout a =100 X ACK loss Seq=9 2, 8 by tes da ta 100 Sendbase = 100 Send. Base = 120 = ACK Send. Base = 100 time Host B Seq=9 Send. Base = 120 lost ACK scenario 2, 8 by Seq= 100, 2 tes da ta 0 byte s data 0 10 = K 120 = C K A AC Seq=92 timeout Seq=9 timeout Host A Host B time 2, 8 by tes da ta 20 K=1 AC premature timeout Transport Layer 69

TCP retransmission scenarios (more) Host A Host B Seq=9 timeout 2, 8 by Send. Base = 120 Seq=1 tes da ta =100 K C A 00, 20 bytes data X loss 120 = ACK time Cumulative ACK scenario Transport Layer 70

TCP ACK generation [RFC 1122, RFC 2581] Event at Receiver TCP Receiver action Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Delayed ACK. Wait up to 500 ms for next segment. If no next segment, send ACK Arrival of in-order segment with expected seq #. One other segment has ACK pending Immediately send single cumulative ACK, ACKing both in-order segments Arrival of out-of-order segment higher-than-expect seq. #. Gap detected Immediately send duplicate ACK, indicating seq. # of next expected byte Arrival of segment that partially or completely fills gap Immediate send ACK, provided that segment startsat lower end of gap Transport Layer 71

Fast Retransmit r Time-out period often relatively long: m long delay before resending lost packet r Detect lost segments via duplicate ACKs. m m Sender often sends many segments back-toback If segment is lost, there will likely be many duplicate ACKs. r If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: m fast retransmit: resend segment before timer expires Transport Layer 72

Fast retransmit algorithm: event: ACK received, with ACK field value of y if (y > Send. Base) { Send. Base = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } a duplicate ACK for already ACKed segment fast retransmit Transport Layer 73

Commenti r ACK comulativi r Sender m Sendbase = piu’ piccolo numero di sequenza dei segmenti trasmessi ma di cui non si è ancora ricevuto ACK m Nextseqnum = numero di sequenza del prossimo dato da inviare Transport Layer 74

TCP vs GBN r Sender invia i segmenti 1, 2, …, N. Assumiamo che i segmenti arrivino correttamente al destinatario. r ACK(n) viene perduto (unico ACK perduto) r GBN trasmette nuovamente i segmenti ? ? r TCP trasmette nuovamente i segmenti ? ? Transport Layer 75

TCP vs GBN r Sender invia i segmenti 1, 2, …, N. Assumiamo che i segmenti arrivino correttamente al destinatario. r ACK(n) viene perduto (unico ACK perduto) r GBN trasmette nuovamente i segmenti n, n+1 , …, N r TCP trasmette nuovamente al piu’ il segmento n (se il timeout di n scatta prima dell’arrivo di ACK(n+1)) Transport Layer 76

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 77

TCP Flow Control r receive side of TCP connection has a receive buffer: flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast r speed-matching r app process may be service: matching the send rate to the receiving app’s drain rate slow at reading from buffer Transport Layer 78

TCP Flow control: how it works r Rcvr advertises spare (Suppose TCP receiver discards out-of-order segments) r spare room in buffer room by including value of Rcv. Window in segments r Sender limits un. ACKed data to Rcv. Window m guarantees receive buffer doesn’t overflow = Rcv. Window = Rcv. Buffer-[Last. Byte. Rcvd Last. Byte. Read] Transport Layer 79

Sliding Window Sending application Receiving application TCP Last. Byte. Written Last. Byte. Acked Last. Byte. Sent r Sending side m Last. Byte. Acked < = Last. Byte. Sent m Last. Byte. Sent < = Last. Byte. Written m buffer bytes between Last. Byte. Acked and Last. Byte. Written TCP Last. Byte. Read Next. Byte. Expected Last. Byte. Rcvd r Receiving side m Last. Byte. Read < Next. Byte. Expected m Next. Byte. Expected < = Last. Byte. Rcvd +1 m buffer bytes between Next. Byte. Read and Last. Byte. Rcvd Transport Layer 80

TCP Flow Control: variabili di stato r Send buffer size: Max. Send. Buffer r Receive buffer size: Max. Rcv. Buffer r Receiving side m Last. Byte. Rcvd - Last. Byte. Read < = Max. Rcv. Buffer m Advertised. Window = Max. Rcv. Buffer - (Next. Byte. Expected Next. Byte. Read) r Sending side m Last. Byte. Sent - Last. Byte. Acked < = Advertised. Window m Effective. Window = Advertised. Window - (Last. Byte. Sent Last. Byte. Acked) m Last. Byte. Written - Last. Byte. Acked < = Max. Send. Buffer m block sender if (Last. Byte. Written - Last. Byte. Acked) + y > Max. Sender. Buffer Transport Layer 81

TCP Controllo del flusso: azioni r Inviare ACK all’arrivo di segmenti r Se ho finito di spedire e ho Advertised. Window = 0? m Problema: il ricevente non sapra’ mai se ho di nuovo spazio nel buffer m il ricevente se ha Advertised. Window = 0 continua a spedire ack fino a che si libera il buffer Transport Layer 82

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 83

TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r initialize TCP variables: m seq. #s m buffers, flow control info (e. g. Rcv. Window) r client: connection initiator Socket client. Socket = new Socket("hostname", "port number"); r server: contacted by client Socket connection. Socket = welcome. Socket. accept(); Three way handshake: Step 1: client host sends TCP SYN segment to server m specifies initial seq # m no data Step 2: server host receives SYN, replies with SYNACK segment server allocates buffers m specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data m Transport Layer 84

TCP Connection Management (cont. ) Closing a connection: client closes socket: client. Socket. close(); client close Step 1: client end system close FIN timed wait FIN, replies with ACK. Closes connection, sends FIN ACK sends TCP FIN control segment to server Step 2: server receives server ACK closed Transport Layer 85

TCP Connection Management (cont. ) Step 3: client receives FIN, replies with ACK. m client closing Enters “timed wait” will respond with ACK to received FINs server FIN ACK Step 4: server, receives closing FIN Note: with small modification, can handle simultaneous FINs. timed wait ACK. Connection closed. ACK closed Transport Layer 86

TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle Transport Layer 87

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 88

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

Le caratteristiche del problema m m Risorse allocate per evitare la congestione Controllo della congestione se (e quando) si manifesta Source 10 -M 1 bps Ethe rnet Router 1. 5 -Mbps T 1 link Destination DI Source 2 s FD Mbp - 100 r Implementazione m Host (protocolli del livello di trasporto) m Router (politiche per la gestione delle code) r Quale modello di servizio m best-effort (Internet) m Qo. S quality of service (Futuro) Transport Layer 90

Contesto m m Sequenze di pacchetti che viaggiono nella rete Router hanno poca informazione sullo stato della rete Source 1 Router Destination 1 Router Source 2 Router Destination 2 Source 3 Transport Layer 91

Causes/costs of congestion: scenario 1 Host A r two senders, two receivers r one router, infinite buffers r no retransmission Host B lout lin : original data unlimited shared output link buffers r large delays when congested r maximum achievable throughput Transport Layer 92

Troughput per la connessione r Throughput per la connessione = numero di byte al secondo al receiver in funzione della velocità di spedizione r Grandi ritardi quando la velocità dei pacchetti in arrivo è prossima alla capacità del router Transport Layer 93

Causes/costs of congestion: scenario 2 r one router, finite buffers r sender retransmission of lost packet Host A lin : original data lout l'in : original data, plus retransmitted data Host B finite shared output link buffers Transport Layer 94

Congestione r La velocità del sender è uguale al carico offerto dalla rete r Sender deve ristramettere pacchetti per compensare le perdite Costo della congestione: r Maggiore carico per la trasmissione dei pacchetti Transport Layer 95

Cause della Congestione r Quattro sender r multihop r Timeout + ritrasmissione Cosa succede quando aumenta il carico offerto dalle rete? Quando il carico offerto a B è elevato il troughput della connessione A-C risulta zero: il buffer in R 2 è sempre pieno Transport Layer 96

Costo della Congestione r Quando un pacchetto è perso lungo un percorso la capacità di trasmissione dei router lungo il percorso è sprecata!! Transport Layer 97

Causes/costs of congestion: scenario 3 H o st A l o u t H o st B Another “cost” of congestion: r when packet dropped, any “upstream transmission capacity used for that packet wasted! Transport Layer 98

Politiche di gestione delle code r First-In-First-Out (FIFO) m Non abbiamo alcuna politica di gestione che dipende dalle caratteristiche dei pacchetti r Fair Queuing (FQ) m Meccanismi di strutturazione del flusso dei pacchetti m Un pacchetto non puo’ mai superare la capacità del router m Code con priorità (WFQ) Flow 1 Flow 2 Round-robin service Flow 3 Flow 4 Transport Layer 99

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

Chapter 3 outline r 3. 1 Transport-layer services r 3. 2 Multiplexing and demultiplexing r 3. 3 Connectionless transport: UDP r 3. 4 Principles of reliable data transfer r 3. 5 Connection-oriented transport: TCP m m segment structure reliable data transfer flow control connection management r 3. 6 Principles of congestion control r 3. 7 TCP congestion control Transport Layer 101

TCP: Controllo della Congestione r Idea di base: si controlla la velocità di trasmissione controllando il numero dei segmenti trasmessi ma di cui non si è ancora ricevuto ACK: W r Maggiore è il valore di W maggiore è il throughput della connessione. r Quando si verifica una perdita di segmento allora si diminuisce il valore W Transport Layer 102

TCP Controllo della congestione r Due fasi m slow start (partenza lenta) m congestion avoidance (annullamento della congestione) r Valori da considerare: m Congwin m threshold: soglia che segnala il passaggio tra le due fasi Transport Layer 103

Controllo della congestione r Limite superiore alle trasmissioni dei segmenti Last. Byte. Sent-Last. Byte. Acked Cong. Win r In formula rate = Cong. Win Bytes/sec RTT r Cong. Win è il valore dinamico della funzione che misura la congestione della rete Transport Layer 104

TCP: Controllo della Congestione r La banda di trasmissione è limitata dalla dimensione della finestra di congestione Congwin: Congwin r w segmenti di dimensione MSS trasmessi in un RTT: throughput = w * MSS Bytes/sec RTT Transport Layer 105

Additive Increase/Multiplicative Decrease (AIMD) r Modificare dinamicamente il carico offerto r Variabile di stato (della connessione): Congestion. Window m m increase Congestion. Window when congestion goes down decrease Congestion. Window when congestion goes up r Informazioni di stato che cambiano in modo dinamico Transport Layer 106

AIMD r Come si manifesta la congestione? r Timeout m timeout è il segnale di perdita di qualche pacchetto. m Perso pacchetto decremento moltiplicativo della finestra m Ok incremento additivo della finestra Transport Layer 107

TCP AIMD multiplicative decrease: cut Cong. Win in half after loss event additive increase: increase Cong. Win by 1 MSS every RTT in the absence of loss events: probing Long-lived TCP connection Transport Layer 108

TCP Slow Start r When connection begins, Cong. Win = 1 MSS m m Example: MSS = 500 bytes & RTT = 200 msec initial rate = 20 kbps r When connection begins, increase rate exponentially fast until first loss event r available bandwidth may be >> MSS/RTT m desirable to quickly ramp up to respectable rate Transport Layer 109

TCP Slowstart Host A initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR Cong. Win > threshold) RTT Slowstart algorithm Host B one segme nt two segme nts four segme nts r Incremento esponenziale (in termini del RTT) della finestra r Perdita di pacchetti: timeout (Tahoe TCP), ACK triplicati (Reno TCP) time Transport Layer 110

Un raffinamento del servizio Idea: r Dopo la ricezione di tre ACK duplicati: m Cong. Win viene dimezzata m La finestra viene fatta crescere in modo lineare r Ma dopo un timeout: m Cong. Win diventa 1; finestra cresce esponenzialmente fino al raggiungimento della soglia. • 3 ACK dup. sono una indicazione che la rete è in grado di trasmettere segmenti • timeout dopo tre ack duplicati è un evento preoccupante sullo stato della congestione della rete m La Transport Layer 111

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 Transport Layer 112

Refinement (more) Q: When should the exponential increase switch to linear? A: When Cong. Win gets to 1/2 of its value before timeout. Implementation: r Variable Threshold r At loss event, Threshold is set to 1/2 of Cong. Win just before loss event Transport Layer 113

Conclusione r Cong. Win ha un volore minore di Threshold, allora in sender è nella fase di slow-start e la finestra cresce in modo esponenziale. r Cong. Win ha un volore maggiore di Threshold, il sendere è nella fase di congestion-avoidance e la finestra cresce in modo lineare. r Al manifestarsi di ACK triplicato il valore di, Threshold diviene Cong. Win/2 e Cong. Win diviene Threshold. r Al manifestarsi di un timeout, Threshold diviene Cong. Win/2 e Cong. Win diviene 1 MSS. Transport Layer 114

TCP Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 TCP connection 2 bottleneck router capacity R Transport Layer 115

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

Fairness (more) Fairness and UDP r Multimedia apps often do not use TCP m do not want rate throttled by congestion control r Instead use UDP: m pump audio/video at constant rate, tolerate packet loss r Research area: TCP friendly Fairness and parallel TCP connections r nothing prevents app from opening parallel cnctions between 2 hosts. r Web browsers do this r Example: link of rate R supporting 9 cnctions; m m new app asks for 1 TCP, gets rate R/10 new app asks for 11 TCPs, gets R/2 ! Transport Layer 117

Delay modeling Q: How long does it take to receive an object from a Web server after sending a request? Ignoring congestion, delay is influenced by: r TCP connection establishment r data transmission delay r slow start Notation, assumptions: r Assume one link between client and server of rate R r S: MSS (bits) r O: object size (bits) r no retransmissions (no loss, no corruption) Window size: r First assume: fixed congestion window, W segments r Then dynamic window, modeling slow start Transport Layer 118

Fixed congestion window (1) First case: WS/R > RTT + S/R: ACK for first segment in window returns before window’s worth of data sent delay = 2 RTT + O/R Transport Layer 119

Fixed congestion window (2) Second case: r WS/R < RTT + S/R: wait for ACK after sending window’s worth of data sent delay = 2 RTT + O/R + (K-1)[S/R + RTT - WS/R] Transport Layer 120

TCP Delay Modeling: Slow Start (1) Now suppose window grows according to slow start Will show that the delay for one object is: where P is the number of times TCP idles at server: - where Q is the number of times the server idles if the object were of infinite size. - and K is the number of windows that cover the object. Transport Layer 121

TCP Delay Modeling: Slow Start (2) Delay components: • 2 RTT for connection estab and request • O/R to transmit object • time server idles due to slow start Server idles: P = min{K-1, Q} times Example: • O/S = 15 segments • K = 4 windows • Q=2 • P = min{K-1, Q} = 2 Server idles P=2 times Transport Layer 122

TCP Delay Modeling (3) Transport Layer 123

TCP Delay Modeling (4) Recall K = number of windows that cover object How do we calculate K ? Calculation of Q, number of idles for infinite-size object, is similar (see HW). Transport Layer 124

HTTP Modeling r Assume Web page consists of: 1 base HTML page (of size O bits) m M images (each of size O bits) r Non-persistent HTTP: m M+1 TCP connections in series m Response time = (M+1)O/R + (M+1)2 RTT + sum of idle times r Persistent HTTP: m 2 RTT to request and receive base HTML file m 1 RTT to request and receive M images m Response time = (M+1)O/R + 3 RTT + sum of idle times r Non-persistent HTTP with X parallel connections m Suppose M/X integer. m 1 TCP connection for base file m M/X sets of parallel connections for images. m Response time = (M+1)O/R + (M/X + 1)2 RTT + sum of idle times m Transport Layer 125

HTTP Response time (in seconds) RTT = 100 msec, O = 5 Kbytes, M=10 and X=5 For low bandwidth, connection & response time dominated by transmission time. Persistent connections only give minor improvement over parallel connections. Transport Layer 126

HTTP Response time (in seconds) RTT =1 sec, O = 5 Kbytes, M=10 and X=5 For larger RTT, response time dominated by TCP establishment & slow start delays. Persistent connections now give important improvement: particularly in high delay bandwidth networks. Transport Layer 127

Chapter 3: Summary r principles behind transport layer services: m multiplexing, demultiplexing m reliable data transfer m flow control m congestion control r instantiation and implementation in the Internet m UDP m TCP Next: r leaving the network “edge” (application, transport layers) r into the network “core” Transport Layer 128