La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Transport Layer3-1 Reti di calcolatori e Sicurezza -- Transport Layer --- Part of these slides are adapted from the slides of the book: Computer Networking:

Presentazioni simili


Presentazione sul tema: "Transport Layer3-1 Reti di calcolatori e Sicurezza -- Transport Layer --- Part of these slides are adapted from the slides of the book: Computer Networking:"— Transcript della presentazione:

1 Transport Layer3-1 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 (copyright J.F Kurose and K.W. Ross, All Rights Reserved)

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

3 Transport Layer3-3 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

4 Transport Layer3-4 Transport services and protocols r provide logical communication 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 application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport

5 Transport Layer3-5 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

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

7 Transport Layer3-7 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

8 Transport Layer3-8 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

9 Transport Layer3-9 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

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

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

12 Transport Layer3-12 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 source port #dest port # 32 bits application data (message) other header fields TCP/UDP segment format

13 Transport Layer3-13 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 Si contralla la porta di destinazione m 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.

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

15 Transport Layer3-15 Connection-oriented demux r TCP socket sono identificati m source IP address m source port number m dest IP address m 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

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

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

18 Transport Layer3-18 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

19 Transport Layer3-19 UDP: User Datagram Protocol [RFC 768] 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 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

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

21 Transport Layer3-21 UDP checksum 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 Obiettivo: scoprire eventuali errori di trasmissione

22 Transport Layer3-22 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

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

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

25 Transport Layer3-25 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. state 1 state 2 event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event event actions

26 Transport Layer3-26 Rdt1.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 packet = make_pkt(data) udt_send(packet) rdt_send(data) extract (packet,data) deliver_data(data) Wait for call from below rdt_rcv(packet) sender receiver

27 Transport Layer3-27 Rdt2.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 acknowledgements (ACKs): receiver invia al sender un messaggio di recezione (senza errori) del pacchetto m negative acknowledgements (NAKs): receiver invia al sender un messaggio di errore m Sender trasmette nuovamente il pacchetto quando riceve un messaggio NAK r Novità (protocolli ARQ) m error detection m receiver feedback (ACK,NAK) m Ritrasmissione

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

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

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

31 Transport Layer3-31 rdt2.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 Sender sends one packet, then waits for receiver response stop and wait

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

33 Transport Layer3-33 rdt2.1: receiver, handles garbled ACK/NAKs Wait for 0 from below sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Wait for 1 from below 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) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Duplicato!!!!

34 Transport Layer3-34 rdt2.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

35 Transport Layer3-35 rdt2.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 Informazioni di stato m “receiver must explicitly include seq # of pkt being ACKed” r ACK duplicato (lato sender) = NAK: ristrasmissione del pkt corrente

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

37 Transport Layer3-37 rdt3.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

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

39 Transport Layer3-39 rdt3.0: esempio

40 Transport Layer3-40 rdt3.0: esempio

41 Transport Layer3-41 rdt3.0 r rdt3.0 funziona correttamente ma esibisce dei problemi di efficienza relativi all’uso della banda di trasmissione

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

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

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

45 Transport Layer3-45 Protocolli “sliding window”

46 Transport Layer3-46 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

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

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

49 Transport Layer3-49 GBN in action

50 Transport Layer3-50 Selective Repeat r receiver invia ACK di tutti i pkt ricevuti correttamente. m Buffer per gestire l’ordine dei pacchetti m Sender invia nuovamente i pkt senza ACK m 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

51 Transport Layer3-51 Selective repeat: sender, receiver windows

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

53 Transport Layer3-53 Selective repeat

54 Transport Layer3-54 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

55 Transport Layer3-55 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

56 Transport Layer3-56 TCP: Overview 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 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

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

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

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

60 Transport Layer3-60 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?  SampleRTT : measured time from segment transmission until ACK receipt m ignore retransmissions  SampleRTT will vary, want estimated RTT “smoother”  average several recent measurements, not just current SampleRTT

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

62 Transport Layer3-62 Example RTT estimation:

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

64 Transport Layer3-64 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

65 Transport Layer3-65 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 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 */ Pseudo Codice

66 Transport Layer3-66 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 timeout events m duplicate acks r Initially consider simplified TCP sender: m ignore duplicate acks m ignore flow control, congestion control

67 Transport Layer3-67 TCP sender events: data rcvd from app: r Create segment with seq # r seq # is byte-stream number of first data byte in segment r start timer if not already running (think of timer as for oldest unacked segment)  expiration interval: TimeOutInterval timeout: r retransmit segment that caused timeout r restart timer Ack rcvd: r If acknowledges previously unacked segments m update what is known to be acked m 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

68 Transport Layer3-68 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 start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ 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

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

70 Transport Layer3-70 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

71 Transport Layer3-71 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 Arrival of in-order segment with 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

72 Transport Layer3-72 Fast Retransmit r Time-out period often relatively long: m long delay before resending lost packet r Detect lost segments via duplicate ACKs. m Sender often sends many segments back-to- back m 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

73 Transport Layer3-73 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 } Fast retransmit algorithm: a duplicate ACK for already ACKed segment fast retransmit

74 Transport Layer3-74 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

75 Transport Layer3-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 ?? r TCP trasmette nuovamente i segmenti ??

76 Transport Layer3-76 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))

77 Transport Layer3-77 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

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

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

80 Transport Layer3-80 Sliding Window r Sending side  LastByteAcked < = LastByteSent  LastByteSent < = LastByteWritten  buffer bytes between LastByteAcked and LastByteWritten Sending application LastByteWritten TCP LastByteSentLastByteAcked Receiving application LastByteRead TCP LastByteRcvdNextByteExpected r Receiving side  LastByteRead < NextByteExpected  NextByteExpected < = LastByteRcvd +1  buffer bytes between NextByteRead and LastByteRcvd

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

82 Transport Layer3-82 TCP Controllo del flusso: azioni r Inviare ACK all’arrivo di segmenti  Se ho finito di spedire e ho AdvertisedWindow = 0? m 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

83 Transport Layer3-83 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

84 Transport Layer3-84 TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r initialize TCP variables: m seq. #s  buffers, flow control info (e.g. RcvWindow ) r client: connection initiator Socket clientSocket = new Socket("hostname","port number"); r server: contacted by client Socket connectionSocket = welcomeSocket.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 m server allocates buffers m specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data

85 Transport Layer3-85 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 FIN close closed timed wait

86 Transport Layer3-86 TCP Connection Management (cont.) Step 3: client receives FIN, replies with ACK. m 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 FIN server ACK FIN closing closed timed wait closed

87 Transport Layer3-87 TCP Connection Management (cont) TCP client lifecycle TCP server lifecycle

88 Transport Layer3-88 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

89 Transport Layer3-89 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!

90 Transport Layer3-90 Le caratteristiche del problema m Risorse allocate per evitare la congestione m Controllo della congestione se (e quando) si manifesta 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 QoS quality of service (Futuro) Destination 1.5-Mbps T1 link Router Source Mbps FDDI 10-Mbps Ethernet

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

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

93 Transport Layer3-93 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

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

95 Transport Layer3-95 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

96 Transport Layer3-96 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 R2 è sempre pieno

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

98 Transport Layer3-98 Causes/costs of congestion: scenario 3 Another “cost” of congestion: r when packet dropped, any “upstream transmission capacity used for that packet was wasted! HostAHostA HostBHostB o u t

99 Transport Layer3-99 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 Flow 3 Flow 4 Round-robin service

100 Transport Layer3-100 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 Two broad approaches towards congestion control:

101 Transport Layer3-101 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 segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

102 Transport Layer3-102 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

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

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

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

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

107 Transport Layer3-107 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

108 Transport Layer3-108 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

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

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

111 Transport Layer3-111 Un raffinamento del servizio r Dopo la ricezione di tre ACK duplicati:  CongWin viene dimezzata m La finestra viene fatta crescere in modo lineare r Ma dopo un timeout:  CongWin diventa 1; m La 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 Idea:

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

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

114 Transport Layer3-114 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.

115 Transport Layer3-115 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 TCP Fairness

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

117 Transport Layer3-117 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 new app asks for 1 TCP, gets rate R/10 m new app asks for 11 TCPs, gets R/2 !

118 Transport Layer3-118 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

119 Transport Layer3-119 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

120 Transport Layer3-120 Fixed congestion window (2) Second case: r 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]

121 Transport Layer3-121 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.

122 Transport Layer3-122 TCP Delay Modeling: Slow Start (2) Example: O/S = 15 segments K = 4 windows Q = 2 P = min{K-1,Q} = 2 Server idles P=2 times 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

123 Transport Layer3-123 TCP Delay Modeling (3)

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

125 Transport Layer3-125 HTTP Modeling r Assume Web page consists of: m 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)2RTT + 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 + 3RTT + 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)2RTT + sum of idle times

126 Transport Layer3-126 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.

127 Transport Layer3-127 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.

128 Transport Layer3-128 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”


Scaricare ppt "Transport Layer3-1 Reti di calcolatori e Sicurezza -- Transport Layer --- Part of these slides are adapted from the slides of the book: Computer Networking:"

Presentazioni simili


Annunci Google