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, 2nd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2002. (copyright 1996-2002 J.F Kurose and K.W. Ross, All Rights Reserved) Transport Layer

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

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

Transport services and protocols provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical Transport Layer

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

Internet transport-layer protocols reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP services not available: delay guarantees bandwidth guarantees application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical Transport Layer

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

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

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

Multiplexing/demultiplexing segment – unità di trasferimento di dati delle entità coinvolte al livello del trasporto TPDU: transport protocol data unit Demultiplexing: invio dei segmenti ricevuti ai processi receiver P3 P4 application-layer data M M application transport network segment header P1 P2 M M application transport network application transport network segment H t M H n segment Transport Layer

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

Demultiplexing: modalità di funzionamento host riceve un msg IP (datagrams) Ogni datagram è caratterizzato da una coppia di indirizzi IP (mittente, destinatario) ogni datagram come paylod ha un msg di trasporto Msg del trasporto ha le informazioni dulle porte del mittente e del destinatario 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

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

Connectionless demux DatagramSocket serverSocket = new DatagramSocket(6428); Client IP:B P3 client IP: A P1 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 DP: 5775 SP: 5775 Transport Layer

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

Connection-oriented demux (cont) P3 client IP: A P3 P4 P1 P1 SP: 80 DP: 9157 SP: 80 DP: 5775 SP: 9157 SP: 5775 DP: 80 DP: 80 Client IP:B server IP: C Transport Layer

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

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

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

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

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

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

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

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

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

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

Rdt2.0: channel with bit errors Il canale puo’ modificare il valore dei bit presenti nei pacchetti UDP checksum Come vengono determinati questi errori di trasmissione: 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 Novità (protocolli ARQ) error detection receiver feedback (ACK,NAK) Ritrasmissione Transport Layer

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

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

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

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

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

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

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

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

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

rdt3.0: Canali con errori e perdita di pacchetti Ipotesi aggiuntive: Il canale di trasmissione puo’ perdere pacchetti (dati o ACK) checksum, seq. #, ACK, sono sufficienti? Come si gestisce la perdita di pacchetti? 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 I pkt vengono trasmessi nuovamente se non viene ricevuto un ACK in questo periodo di tempo Se la consegna del pkt (ACK) è solo ritardata (non avviene perdita) Duplicazione: gestita tramite il # di sequenza receiver specifica il # di sequenza del pkt ricevuto countdown timer Transport Layer

rdt3.0 sender L L L L rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L L Wait for call 0from above Wait for ACK0 timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer stop_timer Wait for ACK1 Wait for call 1 from above timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer L Transport Layer

rdt3.0: esempio Transport Layer

rdt3.0: esempio Transport Layer

rdt3.0 rdt3.0 funziona correttamente ma esibisce dei problemi di efficienza relativi all’uso della banda di trasmissione Transport Layer

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

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

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

Protocolli “sliding window” Transport Layer

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

GBN: lato sender L Wait rdt_send(data) 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) L base=1 nextseqnum=1 timeout Wait start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && corrupt(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer Transport Layer

GBN: lato receiver default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) L Wait expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) 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 # ACK duplicati Variabile di stato: expectedseqnum out-of-order pkt: discard -> no buffering! ACK pkt con il piu’ alto seq # Transport Layer

GBN in action Transport Layer

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

Selective repeat: sender, receiver windows Transport Layer

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

Selective repeat Transport Layer

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

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 point-to-point: one sender, one receiver reliable, in-order byte stream: no “message boundaries” pipelined: TCP congestion and flow control set window size send & receive buffers 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 Transport Layer

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

Il segment TCP Connessione: window + flow control Flags Checksum (SrcPort, SrcIPAddr, DsrPort, DstIPAddr) window + flow control acknowledgment, SequenceNum, RcvdWinow Flags SYN, FIN, RESET, PUSH, URG, ACK Checksum pseudo header + TCP header + data Sender Data (SequenceNum) Acknowledgment + RcvdWindow Receiver Transport Layer

simple telnet scenario 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 Host A Host B User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 time simple telnet scenario Transport Layer

TCP Round Trip Time and Timeout Q: how to set TCP timeout value? longer than RTT but RTT varies 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 SampleRTT will vary, want estimated RTT “smoother” average several recent measurements, not just current SampleRTT Transport Layer

TCP Round Trip Time and Timeout EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Exponential weighted moving average influence of past sample decreases exponentially fast typical value:  = 0.125 Transport Layer

Example RTT estimation: Transport Layer

TCP Round Trip Time and Timeout Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT: DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Then set timeout interval: TimeoutInterval = EstimatedRTT + 4*DevRTT Transport Layer

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

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 */ TCP: Sender Pseudo Codice Transport Layer

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

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

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

TCP: retransmission scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout lost ACK scenario Host B X time Host A Host B Seq=92 timeout Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 Sendbase = 100 Seq=92, 8 bytes data SendBase = 120 Seq=92 timeout ACK=120 SendBase = 100 SendBase = 120 premature timeout time Transport Layer

TCP retransmission scenarios (more) Host A Seq=92, 8 bytes data ACK=100 loss timeout Cumulative ACK scenario Host B X Seq=100, 20 bytes data ACK=120 time SendBase = 120 Transport Layer

TCP ACK generation [RFC 1122, RFC 2581] Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed expected seq #. One other segment has ACK pending Arrival of out-of-order segment 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, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment startsat lower end of gap Transport Layer

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

Fast retransmit algorithm: event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = 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

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

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

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

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

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

TCP Flow control: how it works Rcvr advertises spare room by including value of RcvWindow in segments Sender limits unACKed data to RcvWindow guarantees receive buffer doesn’t overflow (Suppose TCP receiver discards out-of-order segments) spare room in buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] Transport Layer

Sliding Window Sending side Receiving side Sending application LastByteWritten TCP LastByteSent LastByteAcked Receiving application LastByteRead LastByteRcvd NextByteExpected Sending side LastByteAcked < = LastByteSent LastByteSent < = LastByteWritten buffer bytes between LastByteAcked and LastByteWritten Receiving side LastByteRead < NextByteExpected NextByteExpected < = LastByteRcvd +1 buffer bytes between NextByteRead and LastByteRcvd Transport Layer

TCP Flow Control: variabili di stato Send buffer size: MaxSendBuffer Receive buffer size: MaxRcvBuffer Receiving side LastByteRcvd - LastByteRead < = MaxRcvBuffer AdvertisedWindow = MaxRcvBuffer - (NextByteExpected - NextByteRead) Sending side LastByteSent - LastByteAcked < = AdvertisedWindow EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked) LastByteWritten - LastByteAcked < = MaxSendBuffer block sender if (LastByteWritten - LastByteAcked) + y > MaxSenderBuffer Transport Layer

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

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

TCP Connection Management Three way handshake: Step 1: client host sends TCP SYN segment to server specifies initial seq # no data Step 2: server host receives SYN, replies with SYNACK segment server allocates buffers specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data 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(); Transport Layer

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

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

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

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

Principles of Congestion Control 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! Transport Layer

Le caratteristiche del problema Risorse allocate per evitare la congestione Controllo della congestione se (e quando) si manifesta Implementazione Host (protocolli del livello di trasporto) Router (politiche per la gestione delle code) Quale modello di servizio best-effort (Internet) QoS quality of service (Futuro) Destination 1.5-Mbps T1 link Router Source 2 1 100-Mbps FDDI 10-Mbps Ethernet Transport Layer

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

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

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

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

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

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

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

Causes/costs of congestion: scenario 3 Host A lout Host B Another “cost” of congestion: when packet dropped, any “upstream transmission capacity used for that packet was wasted! Transport Layer

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

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

Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control Transport Layer

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

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

Controllo della congestione Limite superiore alle trasmissioni dei segmenti LastByteSent-LastByteAcked  CongWin In formula CongWin è il valore dinamico della funzione che misura la congestione della rete rate = CongWin RTT Bytes/sec Transport Layer

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

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

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

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

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

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

Un raffinamento del servizio Idea: 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 Dopo la ricezione di tre ACK duplicati: CongWin viene dimezzata La finestra viene fatta crescere in modo lineare Ma dopo un timeout: CongWin diventa 1; La finestra cresce esponenzialmente fino al raggiungimento della soglia. Transport Layer

TCP Congestion Avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 Transport Layer

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

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

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

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 loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 2 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R Transport Layer

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

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

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 = 2RTT + O/R Transport Layer

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

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

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

TCP Delay Modeling (3) Transport Layer

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

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

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

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

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