Alma Mater Studiorum - Universita' di Bologna Sede di Cesena

Presentazione sul tema: "Alma Mater Studiorum - Universita' di Bologna Sede di Cesena"— Transcript della presentazione:

1 Alma Mater Studiorum - Universita' di Bologna Sede di Cesena
Reti di Calcolatori Il layer di Trasporto - COTS Vedi: A.S. Tanenbaum, Computer Networks, 4th ed., Prentice Hall, sez. 6, pagg M.T. Rose, The open book, Prentice Hall, cap. 3 e 5, pagg e D. Comer, Internetworking con TCP/IP - Principi, protocolli e architetture, vol. 1, Addison-Wesley, 4a ed., cap. 13, pagg Copyright © by Claudio Salati. Lez. 3

2 Il Layer di Trasporto Tanenbaum:
The Transport Layer is not just another layer. It is the heart of the whole protocol hierarchy. Its task is to provide reliable (N.B.: in realta' esiste anche un CLTS), cost effective data transport from the source machine to the destination machine (N.B.: in realta' “from the source to the destination module of a distributed application”), independently of the physical network or networks currently in use. To provide this goal, the Transport Layer makes use of the services provided by the Network Layer. Just as there are 2 types of Network Service, CONS and CLTS, there are also 2 types of Transport Service. COTS is similar to CONS in many ways. Furthermore CLTS is also very similar to CLNS. If the TS is so similar to the NS why are there 2 distinct layers? Why is one layer not adequate?

3 OSI Reference Model Transport Transport

4 Layer di Rete e di Trasporto
"End-to-end services (Network & Transport Layer) are concerned with data transfer, thus with moving octets (8-bit values) form an ES to another (N.B.: in realta' NS e TS hanno funzioni diverse). The syntax and semantics of those octets are unimportant: bits are bits. N.B.: questo significa che stiamo assumendo che i byte siano fatti nello stesso modo ovunque! It is difficult to separate the functionality of the 2 key layers involved in providing end-to-end (data transfer) services. In realta: NS is concerned with moving octets from an ES to another. TS is concerned with moving octets from a module to another of a distributed application. This is because of the unfortunate history of the OSI end-to-end services: there have been 2 technopolitical camps with very different views of the lower-layer infrastructure.“ (Rose) Lo scontro deriva dal fatto che in OSI sia il Transport che il Network Layer possono fornire sia un servizio CO che un servizio CL. Ovviamente il protocollo per fornire il servizio di Trasporto CO e' molto diverso se si usa CONS o CLNS: OSI prevede 5 (cinque) diversi protocolli di trasporto CO!

5 Layer di Rete "NS is responsible for moving data from one ES to another, hiding the technology of the subnetworks that must be traversed. The primary goal of the NS is to provide transparency in 2 forms: transparency over the topology of the network; and, transparency over the transmission media used in each subnetwork that comprises the network." (Rose) N.B.: ma prestazioni e affidabilita' del NS cambiano molto a seconda che esso sia fornito da una LAN o da una internet geografica! NL implica 2 funzioni fondamentali: routing: in base all'indirizzo destinazione decidere lungo quale percorso instradare la comunicazione perche' essa possa giungere a buon fine; switching: commutare i messaggi della comunicazione secondo il percorso deciso dalla funzione di routing.

6 I DUE APPROCCI AI SERVIZI END-TO-END
Il partito CONS: Il Network Layer fornisce il CONS, Il Transport Layer, per fornire il COTS, si fida del CONS, e si limita a gestire TSAP e connessioni di Rete. "An ES is little more than a spectator with regard to use of the protocols that make up the end-to-end data transfer services. "If the underlying NS is also CO, then the Transport protocol supporting COTS can be trivial." (Rose) Il partito CLNS: Il Network Layer fornisce il CLNS, Il Transport Layer, per fornire il COTS, deve gestire in proprio il recupero degli errori e la sequenzializzazione dei messaggi, poiche' il CLNS non fornisce alcuna garanzia. "An ES is the most important player, as it has the final responsibility for robust communication. "Use of CLNS requires sophisticated algorithms in the Transport protocols that provide COTS." (Rose)  Nel mondo Internet c'e' solo il partito CLNS.

7 Layer di Rete e di Trasporto
In teoria una NSDU e una TSDU possono essere di lunghezza arbitraria, ma in pratica sono di lunghezza finita e la lunghezza della NSDU e' spesso piu' piccola di quella della TSDU, per cui il livello di Trasporto deve comunque gestire segmentazione e riassemblaggio delle TSDU. "TP0 does nothing more than Transport addressing (ma questa e’ una funzione fondamentale!) and segmentation." (Rose) Esistono comunque due distinzioni fondamentali tra NS e TS: NS si occupa della comunicazione tra processori (nodi della rete), mentre TS si occupa della comunicazione tra processi (programmi, applicazioni). "The Transport code runs entirely on the users' machines (ES), but the Network Layer mostly runs on the routers (IS), which are operated by the carrier." (Tanenbaum)

8 Layer di Rete e di Trasporto
Tanenbaum, argomento 1: "What happens if the Network Layer offers inadequate service? The users have no real control over the Network Layer. The only possibility is to put on top of the Network Layer another layer (allocato sugli ES! Quindi sotto il controllo degli utenti della rete!) that improves the quality of the service. In essence, the existence of the Transport Layer makes it possible for the TS to be more reliable than the underlying NS." Tanenbaum, argomento 2: "Thanks to the Transport Layer, application programmers can write code according to a standard of service primitives and have these programs work on a wide variety of networks, without having to worry about dealing with different subnetwork interfaces (qualita' eterogenea del NS, vedi ad es. Reti OSI di classe A e B). For this reason, many people have traditionally made a distinction between layers 1 through 4 on the one hand and layers above 4 on the other."

9 Layer di Rete e di Trasporto
"The bottom 4 layers can be seen as the Transport Service provider (lower network infrastructure), whereas the upper layers are the Transport Service user (upper network infrastructure). This distinction of provider vs. user puts the Transport Layer in a key position, since it forms the major boundary between the provider and user of the reliable transmission service." (Tanenbaum) Per rendere la distinzione veramente efficace occorrerebbe che l'API del TS fosse standardizzata: In questo modo i programmi utente sarebbero portabili su diversi ES. Implementativamente, i livelli 2-4 sono realizzati (normalmente) come parte del sistema (in spazio kernel), i livelli superiori (5-7) sono realizzati (normalmente) nello spazio utente (o come processi autonomi o, molto piu’ frequentemente, come librerie linkate al codice utente).

10 OSI TRANSPORT LAYER E TRANSPORT SERVICE
OSI prevede sia un COTS (Connection-Oriented Transport Service) che un CLTS (ConnectionLess Transport Service). Il TS viene offerto su TSAP (Transport Service Access Point). Un TSAP e' identificato da un indirizzo a 2 componenti: un transport selector (TSEL), che e' un nome che ha significato locale e serve a distinguere un TSAP locale dall'altro (e quindi un cliente del TS dall'altro) a parita' di NSAP (e, quindi, di protocollo di trasporto), uno o piu' network address (NSAP, quello/i della protocol entity di Trasporto). COTS prevede le primitive (i servizi) per gestire le tre fasi di instaurazione della connessione, trasferimento dati, rilascio della connessione.

11 PROTOCOLLI OSI DI TRASPORTO
COTS fornisce un servizio affidabile end-to-end indipendentemente dal NS che ha a disposizione. Data la variabilita' di caratteristiche del NS, per fornire la stessa interfaccia COTS sono stati definiti 5 diversi CO Transport Protocols (TP): TP0, ..., TP4. TP0, TP1, TP2 e TP3 possono operare solo sul CONS. TP4 puo' operare sia su CONS che su CLNS, ma in realta' e' pensato per operare su CLNS. Durante la fase di instaurazione della connessione le entita' di Trasporto negoziano quale TP utilizzare. Questo consente ad implementazioni sofisticate di offrire servizi di qualita' superiore pur mantenendo la compatibilita' con implementazioni piu' povere.

12 Classi di reti secondo OSI
Perche' sono definiti 4 TP diversi per operare su CONS? Perche' le implementazioni reali di CONS differiscono per qualita'. OSI definisce 3 classi di reti. Reti di classe A: rilevano come un errore qualsiasi perdita di dati. Non duplicano, desequenzializzano, o corrompono dati. La probabilita' di errore effettiva e' bassa. Una rete di classe A fornisce il CONS con qualita' accettabile. Reti di classe B: differiscono dalle reti di classe A perche' la probabilita' di perdita effettiva e' piu' alta di quanto (localmente) considerato tollerabile (e.g. a causa della fragilita' delle connessioni). Anche una rete di classe B fornisce il CONS, ma non con un livello di qualita' accettabile. Reti di classe C: forniscono il CLNS e quindi non offrono alcuna garanzia di non perdere, duplicare o desequenzializzare dati. I TP OSI CO si differenziano per la capacita' di operare su reti di classi diverse, e per le modalita' con cui utilizzano il NS.

13 Classi di reti secondo IP?
Il protocol layer IP prevede solo un servizio CL. L’architettura di rete internet prevede che il Network Layer debba fornire solo un servizio CL, considera cioe’ solo reti di classe C. Anche alle singole sottoreti l’architettura internet richiede solo di fornire un servizio CL, di classe C. Se una sottorete e’ capace di fornire anche un servizio CO, questo non viene utilizzato da IP, se e’ disponibile anche un servizio CL. e’ sottoutilizzato da IP, se il servizio CO e’ l’unico fornito dalla sottorete. IP in realta’ fa anche fatica ad utilizzare sottoreti CO perche’ deve assorbire la complessita’ aggiuntiva della gestione di connessioni senza poterne sfruttare i vantaggi.

14 PROTOCOLLI OSI DI TRASPORTO: TP0
Puo' operare solo su reti di classe A. Fornisce solo le funzioni di segmentazione e riassemblaggio. (oltre che, ovviamente, quella di addressing, cioe' la capacita' di distinguere un TSAP dall'altro e una connessione dall'altra) Ogni connessione di Trasporto e' associata ad una connessione di Rete. (non c'e' alcun multiplexamento di diverse connessioni di Trasporto tra i due ES su un'unica connessione di Rete)

15 PROTOCOLLI OSI DI TRASPORTO: TP1
Puo' operare su reti di classe A e B. In caso di disconnessione spontanea di Rete, non deve necessariamente abortire la connessione di Trasporto, ma e' in grado di recuperare l'errore (quale tipo di errore? Perdita! Si assume che NS sia adeguato dal punto di vista di non-desequenzializzazione e non-duplicazione). "When TPDU are sent, each TPDU is numbered and then retained until an ack is received from the remote Transport entity. The ack takes the form of a special TPDU. When a Network disconnect occurs, the Transport provider may decide to establish a new Network connection and then resume the Transport connection by resending those PDUs that haven't been acknowledged.“ (Rose)

16 PROTOCOLLI OSI DI TRASPORTO: TP2 e TP3
E' l'equivalente di TP0 ma Effettua il multiplexing delle connessioni di Trasporto tra due nodi su una unica connessione di Rete. Perche' e' conveniente il multiplexing? Perche' pago una sola connessione di Rete anche se sto utilizzando diverse connessioni di Trasporto su di essa.  TP3: E' la combinazione di TP2 e TP1. Combina la funzione di de/multiplexing con quella di recupero di errori per disconnessione del Network Service.

17 PROTOCOLLI OSI DI TRASPORTO: TP4
E' in grado di operare su reti di classe C. E' l'analogo OSI di TCP. In pratica e' poco adatto ad operare su reti CONS. Offre servizi di error detection (opzionalmente) e recovery. "TP4 achieves reliability through retransmission. The trick is knowing when to retransmit. If data is lost in the network and the sending Transport entity retransmits too slowly, then throughput suffers. If data is lost due to congestion in the network and the Transport entity retransmits too quickly then it merely adds to the congestion and throughput gets even worse! Hence, sophisticated protocols of this variety employ adaptive algorithms to predict the latency characteristics of the network, which may fluctuate considerably because of other traffic." (Rose)

18 PROTOCOLLI Internet DI TRASPORTO: TCP
E' l'equivalente Internet del protocollo OSI TP4. E' progettato per offrire un COTS affidabile basandosi sui servizi di un Layer di Rete CL e non affidabile (IP). Il servizio implementato da TCP si differenzia dal COTS OSI per alcuni punti fondamentali (per il resto e' analogo al COTS OSI definito nella lezione 1). Adesso: Esistono anche altri protocolli di trasporto CO nell’architettura di rete Internet (e.g. per gestire reti piu’ veloci che per essere utilizzate in modo efficiente richiedono finestre di trasmissione piu’ grandi). Esistono varianti del TCP (e.g. per gestire ACK selettivi). ma il corso prende in considerazione solo il TCP tradizionale.

19 TCP vs. TP4 OSI .1 Differenze tra TCP e TP4 OSI:
I dati trasferiti tra i due end-point TCP sono costituiti da uno stream continuo di byte anziche’ da una sequenza di messaggi, come e' nel caso di COTS OSI. TCP (sia lato TX che lato RX) e' libero di segmentare/aggregare le richieste di trasmissione dei byte dello stream come piu' gli conviene. E se due moduli di una applicazione distribuita hanno bisogno di comunicare a messaggi? Come fa un ricevitore a capire dove finisce un messaggio e dove inizia l’altro? In caso di tentativo simultaneo di setup della connessione da parte dei due ES le due richieste sono matchate da TCP ed e' creata un'unica connessione. Puro buon senso, quello che manca ai comitati di standardizzazione. In pratica, in un mondo client-server asimmetrico, il problema e’ irrilevante, tanto che lo scenario non e’ nemmeno realizzabile facilmente sull’interfaccia socket.

20 TCP vs. TP4 OSI .2 Differenze tra TCP e TP4 OSI:
La procedura di disconnessione e' "ordinata" e bilaterale, anziche' essere brusca e unilaterale, come e' nel caso di COTS OSI. E' responsabilita' dei clienti del COTS OSI assicurarsi che tutti i dati di cui e' stata chiesta la trasmissione siano stati effettivamente ricevuti prima di chiedere la chiusura della connessione. Puro buon senso, quello che manca ai comitati di standardizzazione. Di norma, la connessione non viene monitorata (testata) quando i clienti non la utilizzano effettivamente (quando non richiedono la trasmissione di dati). La protocol entity si accorge che la connessione e’ caduta solo a seguito di un tentativo di trasmissione. Questo comportamento deriva dal fatto che TCP e’ stato progettato quando i bit trasmessi in rete erano preziosi! Differenza interna: una connessione TCP e’ identificata solo dagli indirizzi delle porte ai suoi estremi, mentre in TP4 una connessione ha un suo identificatore specifico. Conseguenze?

21 Recupero degli errori: PDU persi o corrotti
La tecnica fondamentale per il recupero degli errori di trasmissione e' indicata come conferma di ricezione positiva con ritrasmissione (positive acknowledgement with retransmission) Il lato ricevente deve comunicare al lato mittente l'avvenuta ricezione di dati tramite un PDU di ACKnowledgement. Il lato mittente, quando spedisce un PDU informativo, avvia un timer. Se il timer scade prima che il mittente riceva l'ACK al proprio PDU informativo, il mittente ritrasmette il PDU (il mittente assume che il PDU sia andato perso o danneggiato). Se il lato ricevente riceve un PDU danneggiato, lo ignora (lo scarta, di solito in un Layer piu’ basso del Trasporto). Se il lato ricevente riceve un PDU che aveva gia' ricevuto, lo scarta ma lo riscontra al mittente. N.B.: la procedura di recupero degli errori in caso di PDU persi o corrotti puo' portare alla ricezione ripetuta di uno stesso PDU.

22 Recupero degli errori: PDU duplicati
In realta' non c'e' solo il problema dei PDU (anche quelli di ACK) persi o corrotti. I PDU possono essere ritardati dalla rete (la rete "ha memoria"). I PDU (compresi quelli di ACK) possono anche essere duplicati (e.g. causa ritrasmissione da parte del mittente, o perche' il routing di una sottorete e' basato sul flooding). PDU informativi duplicati possono (devono poter) essere riconosciuti. I PDU informativi devono essere identificati univocamente (e.g. numerando ciascuno di essi con un numero progressivo). Il lato ricevente deve ricordare quali PDU informativi ha gia' ricevuto. Se il lato ricevente riceve un PDU informativo che aveva gia' ricevuto, lo riscontra al mittente ma lo scarta. Ogni PDU di ACK riporta esplicitamente il numero del/i PDU informativo/i che riscontra.

23 Finestra a scorrimento: efficienza di banda
Un protocollo con conferma di ricezione positiva semplicistico spreca una quantita' enorme di banda disponibile perche' utilizza la rete in modo half-duplex. Il lato trasmissione non trasmette il prossimo PDU informativo fino a che non ha ricevuto l'ACK del PDU precedente. Il trasmettitore puo' pero' essere autorizzato a trasmettere un certo numero di PDU informativi anche senza avere ricevuto un ACK (prima di doversi fermare in attesa dell'ACK). Il lato trasmissione ha una certa finestra di credito di trasmissione. Quando il trasmettitore riceve un ACK fa scorrere in avanti la sua finestra di credito (non e’ proprio esatto: vedi seguito). "Poiche' un protocollo a finestra di scorrimento ben ottimizzato mantiene la rete completamente satura di pacchetti (se il trasmettitore e' piu' veloce della rete!), ottiene una velocita' di trasferimento sostanzialmente maggiore rispetto ad un semplice protocollo con conferma di ricezione positiva." (Comer)

24 Finestra a scorrimento: efficienza di banda
Nel caso del TCP la nozione di finestra di scorrimento e' piuttosto sofisticata (anche se TCP non utilizza ACK selettivi, vedi seguito). Il lato mittente: Ricorda quali sono i PDU informativi confermati. Mantiene un timer separato per ogni PDU non confermato. Quando fa scorrere la finestra in avanti oltrepassa tutti i PDU informativi confermati (ack cumulativo). Il lato ricevente: Mantiene una lista dei PDU informativi ricevuti. Accetta e memorizza un PDU informativo corretto anche se uno o piu' PDU precedenti non sono stati ancora ricevuti, ma non lo riscontra. Puo' riscontrare piu' di un PDU informativo in un unico colpo se riceve un PDU che precede logicamente (ed e’ adiacente ad) un PDU gia' prima ricevuto.

25 ACK e ritrasmissioni Il ricevente assembla i byte dati dei segmenti ricevuti per ricostruire lo stream trasmesso dal suo pari. Poiche' i datagram che contengono i segmenti possono andare persi o essere ricevuti fuori ordine la ricostruzione dello stream avviene grazie al numero di sequenza. In un qualunque momento il ricevente ha ricevuto un prefisso contiguo massimo dello stream; puo' avere ricevuto altri blocchi di byte, successivi al prefisso contiguo massimo, ma non adiacenti ad esso. Il ricevente conferma sempre (solo) la ricezione del prefisso contiguo massimo a quell'istante (ack cumulativo). Blocchi ricevuti correttamente ma che non non estendono il prefisso contiguo massimo sono memorizzati ma non sono riscontrati. La conferma avviene indicando come ACK l'indice nello stream del byte successivo all'ultimo byte del prefisso contiguo massimo (cioe' l'indice del primo byte mancante).

26 ACK cumulativo vs. ACK selettivo
TCP utilizza un metodo di riscontro cumulativo. TCP non ammette ACK selettivi, cioe' ACK relativi a byte successivi ma non contigui al prefisso contiguo massimo. Supponiamo che il mittente invii 10 segmenti e che il primo (solo il primo) vada perso. Quanti byte puo' riscontrare positivamente il ricevente? 0. Quanti segmenti deve ritrasmettere di conseguenza il mittente? Notare che dopo avere ricevuto il primo segmento ritrasmesso, il ricevente riscontrera' il prefisso fino all'ultimo byte del decimo segmento. Se il mittente ritrasmettesse piu' di un segmento occuperebbe inutilmente la rete. In base a questo argomento la prassi implementativa accettata indica che in caso di ritrasmissione il mittente deve ritrasmettere solo il segmento non riscontrato, quello per cui e’ scaduto il timer.

27 Finestra a scorrimento: controllo di flusso .1
L'utilizzo di un protocollo a finestra di scorrimento consente al TCP di risolvere anche un altro problema: Cosa succede se il lato ricevente e' meno veloce della rete e del lato mittente? Se la finestra del mittente e' abbastanza ampia il lato ricevente viene sovraccaricato di PDU che non riesce a processare! TCP receiver side TCP sender side send ack receive

28 Finestra a scorrimento: controllo di flusso .2
TCP consente al lato ricevente di controllare la dimensione della finestra del lato mittente, fino a chiuderla nel caso non abbia (buffer di) memoria sufficiente per ricevere e registrare nuovi PDU informativi. La dimensione della finestra di scorrimento non e' quindi fissa, ma puo' variare per adattarsi alla velocita' di processamento dei due ES. Ovviamente il lato ricevente non e' autorizzato a contraddire aperture di finestra effettuate in precedenza. Dire che ti concedo una finestra di n messaggi vuole dire che ho la capacita’ di bufferare gli n messaggi che ti autorizzo a inviarmi. Non posso concederti una finestra di n messaggi se non ho buffer di memoria sufficienti a contenerli. N.B.: ACK dei PDU e gestione della finestra devono poter essere disaccoppiati: il ricevitore deve potere anche riscontrare la ricezione di un PDU senza aprire la finestra del mittente (e viceversa).

29 Finestra a scorrimento: controllo di flusso .3
La dimensione della finestra di trasmissione lato Tx e’ determinata dalla capacita’ di bufferamento in ricezione lato Rx. La protocol entity TCP lato Rx riscontra un PDU informativo nel momento in cui ne ha potuto salvare il contenuto nel buffer di ricezione. Non quando il suo cliente locale lo legge effettivamente. Se non lo riscontrasse il pari lato Tx, scaduto il timeout di error recovery, lo ritrasmetterebbe, sprecando banda, e cio’ deve essere evitato. Quando il cliente locale della protocol entity lato Rx legge effettivamente dei byte informativi questi possono essere eliminati dal buffer di ricezione, liberando spazio per nuovi byte inviati dal pari lato Tx. E’ quindi l’operazione di lettura di byte ricevuti dalla rete effettuata dal cliente locale che porta la protocol entity lato Rx ad aprire la finestra di trasmissione del suo pari.

30 Finestra a scorrimento: 2 funzioni distinte e indipendenti
Sul meccanismo della finestra di scorrimento e sulla relativa numerazione dei PDU si appoggiano 2 funzioni diverse e indipendenti: La funzione di recupero degli errori tramite riscontro esplicito ed eventuale ritrasmissione in caso di mancato riscontro. La funzione di controllo di flusso tra i due end-point della connessione. Deve essere possibile: riscontrare la ricezione di un PDU informativo senza aprire ulteriormente la finestra per il mittente (per evitare inutili ritrasmissioni). aprire la finestra per il mittente senza riscontrare la ricezione di alcun PDU (se non c’e’ niente da riscontrare, ma si sono liberati buffer di memoria per la ricezione). riscontrare la ricezione di un PDU informativo e contestualmente aprire ulteriormente la finestra per il mittente. Il PDU che il lato ricevente invia al mittente deve contenere due campi diversi (per riscontro e controllo finestra) che citano la numerazione dei PDU informativi nella direzione di comunicazione opposta. Esercizio: rappresentare 3 scenari di interazione tra utenti e provider del Servizio di Trasporto su due nodi A e B in cui si verifichino le 3 situazioni indicate.

31 Trasmissione e ricezione sulla rete .1
Chiedere la trasmissione di n byte su una connessione non implica che questi n byte siano trasmessi immediatamente. Ad esempio perche’ la finestra di trasmissione e’ chiusa. Quello che succede e’ che gli n byte sono copiati in un buffer di trasmissione associato all’end-point locale della connessione. E se il buffer e’ gia’ pieno o non c’e’ posto per tutti gli n byte? Analogamente succede per la ricezione: i byte ricevuti dalla rete sono inseriti in un buffer di ricezione in attesa che il cliente del TCP chieda di acquisirli con una operazione di lettura. Domanda: perche’ per ogni endpoint e’ necessario l’utilizzo di buffer sia in trasmissione che in ricezione? TCP entity IP TCP entity end-point end-point write() TX buffer RX buffer read() RX buffer TX buffer

32 Trasmissione e ricezione sulla rete .2
E’ evidente che la finestra di trasmissione di un end-point non puo’ eccedere la quantita’ di memoria libera sul buffer di ricezione dell’altro end-point. Altrimenti l’end-point mittente sarebbe autorizzato a trasmettere dei byte che il ricevente non saprebbe dove mettere. Quando e’ che il ricevente apre la finestra di trasmissione del mittente? Quando si liberano dei byte nel suo buffer di ricezione. Cioe’ quando il cliente del TCP acquisce dei byte dal buffer di ricezione tramite una operazione di lettura IP TCP entity end-point TX buffer RX buffer write() read()

33 Scenario elementare di trasmissione / ricezione
IP tempo TCP entity TCP entity write() end-point end-point info TX buffer RX buffer ack read() end-point end-point TX buffer RX buffer window Quando il ricevente ha inserito i byte ricevuti in RX buffer puo’ generare ACK. Quando il mittente riceve ACK puo’ liberare i byte trasmessi ma ancora contenuti in TX buffer (per eventuali ritrasmissioni). Quando il cliente acquisisce i byte contenuti in RX buffer, questi byte possono essere liberati e di conseguenza la finestra di trasmissione del mittente puo’ venire aperta

34 Controllo di flusso e congestione
Il meccanismo del controllo di flusso consente al TCP di risolvere il problema della comunicazione tra due ES con diverse velocita' di processamento. Ma cosa succede se i due ES che comunicano sono piu' veloci della rete che li connette (di uno dei router lungo il path seguito dai loro datagram IP)? "Quando le macchine intermedie diventano sovraccariche, la condizione e' definita congestione. I meccanismi per risolvere la situazione sono chiamati meccanismi di controllo di congestione. TCP non ha un meccanismo esplicito per il controllo della congestione (la congestione e' un problema del Network Layer!). Ma, Un'implementazione TCP programmata accuratamente puo' rilevare e risolvere la congestione. Un'implementazione peggiore puo' peggiorarla!" (Comer) Il buon funzionamento della rete dipende dal buon comportamento degli ES connessi ! Naturalmente un IS puo’ essere anche congestionato dal traffico di diversi flussi di comunicazione indipendenti tra loro.

35 Controllo di flusso I meccanismi per il controllo di flusso e la regolazione della finestra di trasmissione servono a 3 diversi scopi: Utilizzo efficiente della banda di rete. Il trasmettitore puo’ inviare nuovi dati senza dovere attendere l’ACK di quelli inviati in precedenza. Regolazione della velocita’ di scambio dell’informazione tra gli end-point della comunicazione. L’entita’ di Trasporto in ricezione apre la finestra solo quando il cliente estrae dei dati dal buffer di ricezione. Se il cliente in ricezione e’ lento e non estrae dati, la finestra non viene riaperta. Contenimento dei fenomeni di congestione della rete. Vedi pagine seguenti.

36 PDU TCP (segmento) Identificazione della connessione
Identificazione dei dati trasmessi con il PDU Riscontro di dati ricevuti Dimensione della finestra di trasmissione per il pari

37 PDU TCP .1 I PDU del protocollo TCP sono chiamati segmenti:
ogni segmento e’ relativo ad una connessione e puo’ esistere ad un certo istante un’unica connessione tra gli stessi due end-point. La struttura dell’informazione trasportata da un segmento e’ descritta tramite una mappa di byte. La dimensione massima del segmento (e quindi della sua parte dati) viene contrattata al momento del set-up della connessione. Poiche' TCP trasporta uno stream continuo di byte, esso puo' assemblare, disassemblare, riassemblare diversamente (e.g. in caso di ritrasmissione), le richieste di trasmissione del cliente. Ogni segmento dati trasporta anche l'indice (numero di sequenza) del primo dei suoi byte all'interno dello stream. Ovvio che sia cosi’, TCP e’ stream oriented. In TPx ci sarebbe il numero del messaggio! Ogni segmento trasporta informazioni di protocollo relative ad entrambe le direzioni della comunicazione.

38 PDU TCP .2 Ogni PDU puo’ trasportare sia una informazione di ACK che una informazione di controllo della finestra (N.B.: dimensione massima della finestra: solo 216 byte, tanti nel 1980 ma molto pochi nel Su una rete a 1Gbps ci vuole meno di 1 ms per consumarla tutta, in assenza di aperture dal ricevente). L'informazione di ACK e quella di controllo della finestra sono separate: il ricevitore puo' riscontrare la ricezione di un PDU senza aprire la finestra del mittente. Poiche' TCP trasporta uno stream continuo di byte l'indicazione di ACK e quella di finestra presenti in un segmento sono espresse rispettivamente come indice di byte nello stream (del prossimo byte atteso, quello successivo al prefisso contiguo massimo gia’ ricevuto), numero di byte ricevibili a partire da quello indicato nell'ACK. Considerando l'ACK, deve essere cosi' perche' non solo TCP invia dati in segmenti di lunghezza variabile, ma in caso di ritrasmissione e' anche libero di riassemblarli, inviando piu' dati che nel segmento originale.

39 Timeout di ritrasmissione .1
Per ogni segmento dati che trasmette TCP avvia un timer. Se il timer termina senza che i dati del segmento siano riscontrati positivamente TCP assume che il segmento sia andato perso e lo ritrasmette. Quanto deve essere lungo il timer? Cioe’, dopo quanto tempo scatta il timeout? Il timer di ritrasmissione deve essere il piu' possibile vicino al round-trip delay ma non deve sottostimarlo. TCP non opera su un Data Link con round-trip delay fisso e calcolabile a priori. TCP opera su IP e il roud-trip delay puo' variare moltissimo da un datagram all'altro: Perche' le reti che connettono due ES possono essere estremamente eterogenee (LAN vs. internetwork). Perche' due datagram seguono percorsi diversi. Perche' il carico di rete incontrato (e quindi il tempo di attraversamento degli switch e dei router, anche lungo un medesimo percorso) e' diverso.

40 Timeout di ritrasmissione .2
TCP gestisce la variabilita' del roud-trip delay utilizzando un timer di ritrasmissione adattativo. "TCP tiene sotto controllo le prestazioni di ogni collegamento e ne deduce valori ragionevoli per i timeout: se le prestazioni di una connessione cambiano, TCP riesamina tali valori, ovvero si adatta alla variazione." (Comer) Per ogni segmento trasmesso TCP campiona (in base al relativo ACK) il round-trip delay relativo. L'implementazione canonica del TCP calcola lo RTT (Round Trip Time stimato) come una media pesata, che viene via via aggiornata dai nuovi campioni: RTT(k) =  * RTT(k-1) + (1- ) * RTTsample(k), con 0<<1 La risposta piu' o meno rapida alle variazione dipende dal valore di  piu' o meno vicino a 0. Il valore consigliato e' =7/8. Esercizio: Cosa succede se =1? E se =0?

41 Timeout di ritrasmissione .3
In base al valore corrente di RTT viene poi calcolato il Timeout di ritrasmissione. Ad esempio: Timeout =  * RTT, con >1 Quanto vale  ? Se  e' prossimo a 1 si rilevano in fretta eventuali perdite di segmenti, ma e' anche facile che si debbano effettuare ritrasmissioni inutili. La specifica originale indicava come valore consigliato =2.

42 Stima di RTT: problemi .1 L'algoritmo base per il calcolo del timeout di ritrasmissione non tollera un jitter (variazione del ritardo di rete) molto ampio. La variazione statistica (varianza)  del round-trip delay e' tanto maggiore quanto maggiore e' il traffico L (0L 1, espresso come frazione della capacita' della rete) ( e’ inversamente proporzionale a 1-L). La regola canonica per il calcolo del timeout non sopporta un traffico L>0.3. TCP adesso richiede che anche la variazione (la derivata) del RTT sia presa in considerazione per il calcolo del timeout, ottenendo cosi' un valore di timeout piu' adattativo. In realta', in pratica, anche se il valore medio del delay varia significativamente nel tempo, la variazione tra due datagram consecutivi e' molto piu’ contenuta.

43 Algoritmo di calcolo di RTT e Timeout
Algoritmo di calcolo raccomandato: diff(k) = RTTsample(k) - RTT(k-1) RTT(k) = RTT(k-1) +  * diff(k) (N.B. la formula per il calcolo di RTT non e' cambiata. Basta sostituire  con (1-)). dev(k) = dev(k-1) +  * (|diff(k)| - dev(k-1)) = (1 - ) * dev(k-1) +  * |diff(k)| Timeout(k) = RTT(k) +  * dev(k) dove 0<<1con valore consigliato = 1/23 0<<1con valore consigliato = 1/22 valore consigliato di  = 4

44 Stima di RTT: problemi .2 In realta' la procedura per il calcolo di RTT deve essere ancora piu' complessa di quanto indicato. TCP utilizza uno schema di riscontro cumulativo, non selettivo-per-segmenti. A quale/i segmento/i e' relativo un riscontro? In caso di ritrasmissione, il riscontro e' relativo al segmento originale o alla ritrasmissione? (in realta' entrambe le assunzioni si rivelano fuorvianti) Supponiamo che l'associazione sia con il segmento originale: se ogni segmento viene perso almeno una volta RTT diverge, perche' ogni incremento porta ad un aumento del timeout, che a sua volta porta ad un ulteriore aumento di RTT. Supponiamo che l'associazione sia con il segmento ritrasmesso: questo provoca un decremento di RTT che a sua volta provoca un decremento di timeout, che quindi spirera' prima dell'ACK causando una ritrasmissione e l'associazione dell'ACK con la nuova ritrasmissione, e cosi' via. Ogni segmento viene cosi' trasmesso 2 volte (anche in assenza di perdite)!

45 Stima di RTT: algoritmo di Karn .1
Strategia per la gestione delle ritrasmissioni: Nel calcolo di RTT si devono ignorare campioni relativi a segmenti ritrasmessi. 2. Quindi in caso di necessita' di ritrasmissione il valore di RTT non viene aggiornato. 3. In caso di ritrasmissione, pero', il valore del timer di ritrasmissione (Timeout) viene disaccoppiato da quello di RTT. 4. Il valore di Timeout viene aumentato di un fattore moltiplicativo  ogni volta che si deve ritrasmettere un segmento (timer backoff). (normalmente, e' =2) 5. Quando alla fine il mittente riesce a ricevere un ACK relativo ad un segmento originale, il calcolo di un nuovo valore per RTT viene riabilitato e il Timeout viene riagganciato a RTT.

46 Stima di RTT: algoritmo di Karn .2
Per evitare che il Timeout cresca indefinitamente viene normalmente fissato amministrativamente un valore massimo. Dovrebbe essere maggiore del massimo round-trip delay possibile su Internet! E' ovvio che l'algoritmo di Karn non funzionerebbe se non disaccoppiasse Timeout da RTT: Altrimenti, in caso di rallentamento della rete con conseguente ritrasmissione di un segmento, dato che RTT non viene piu' aggiornato anche Timeout rimarrebbe di conseguenza invariato! Il che comporterebbe ulteriori ritrasmissioni per timeout. Fino alla caduta della connessione. N.B.: con l’aumentare delle ritrasmissioni la loro frequenza decresce esponenzialmente!

47 TCP e congestione .1 La congestione dei router e' un fenomeno che si verifica nel Layer di Rete, non in quello di Trasporto. Il Layer di Rete ha i suoi strumenti per fronteggiare la congestione: PDU di source squench ICMP. Politiche di scarto dei datagram in eccesso (nei router): Tail Drop, Random Early Discard. Anche senza interagire con il Livello di Rete TCP ha modo di accorgersi dell'esistenza di una situazione di congestione: E' costretto a ritrasmettere dei segmenti. TCP assume che ogni ritrasmissione sia dovuta a congestione. TCP stesso, autonomamente, a fronte di una situazione di congestione, puo' contribuire a risolverla. O a peggiorarla! Basta che effettui le ritrasmissioni previste senza applicare l’algoritmo di Karn! Gia’ l’algoritmo di Karn garantisce che in caso di congestione le ritrasmissioni siano rapidamente rallentate. Il problema e’ quindi limitare la trasmissione di nuovi byte anche se la finestra di trasmissione la autorizzasse.

48 I bei tempi andati Nelle reti TLC tradizionali non sarebbe mai stato concepibile che il malcomportamento di un ES potesse danneggiare il funzionalmento della rete. Infatti la rete a pacchetto TLC per eccellenza, la rete X.25: era connection oriented (a livello di Network Service); preallocava le risorse per ciascuna connessione, ma evitava che una singola connessione potesse accaparrarsi piu' risorse di quelle previste; poteva effettuare un controllo d'accesso limitando l'ingresso di nuovi utenti nel caso le risorse di rete risultassero sature. L'argomento di Tanenbaum: "What happens if the Network Layer offers inadequate service? The users have no real control over the Network Layer. The only possibility is to put on top of the Network Layer another layer (allocato sugli ES!) that improves the quality of the service". era quasi impensabile (vedi TP0-TP3 vs. TP4 nell'OSI).

49 TCP e congestione .2 Per contrastare fenomeni di congestione lo standard TCP raccomanda che ogni ES implementi due politiche: multiplicative decrease slow start Lo scopo di queste due politiche e' di: ridurre rapidamente la finestra effettiva di trasmissione (cioe’ la trasmissione di ulteriori byte sulla rete) in caso di percezione di congestione indipendentemente dalla disponibilita' del pari ricevente a ricevere altri dati N.B. la ritrasmissione di byte gia’ trasmessi e’ limitata dall’algoritmo di Karn riaprire la finestra effettiva di trasmissione abbastanza lentamente da evitare, al momento della fine della congestione, che tutti gli ES che avevano in precedenza limitato le proprie trasmissioni le riprendano cosi' rapidamente da ricreare la situazione di congestione

50 TCP e congestione .3 A fianco della finestra di trasmissione TCP mantiene anche una seconda finestra, detta finestra di congestione. La finestra di congestione serve, in caso di percezione di congestione, a limitare la finestra effettiva, quella davvero utilizzata per regolare la trasmissione dei dati (di nuovi dati), a valori piu' bassi di quanto indicato dalla finestra di trasmissione: finestra effettiva = min (finestra di trasmissione, finestra di congestione) In condizioni normali (non di congestione) il valore della finestra di congestione e' maggiore o uguale a quello della finestra di trasmissione:  finestra effettiva = finestra di trasmissione In caso di (per ogni) ritrasmissione (si assume che sia dovuta a congestione) la finestra di congestione viene dimezzata. La riduzione avviene per ogni ritrasmissione. In caso di congestione la finestra di congestione e quindi anche quella effettiva si riducono in modo esponenziale. Il valore minimo ammesso della finestra di congestione e' 1 segmento.

51 TCP e fine della congestione: slow start
La riapertura della finestra di congestione, e quindi della finestra effettiva, non avviene in modo moltiplicativo ma in modo additivo. Aprire la finestra in modo moltiplicativo porterebbe a instabilita' del sistema (oscillazioni tra congestione e rete scarica). Quando si comincia ad utilizzare una nuova connessione e dopo una fase di congestione, la finestra di congestione viene posizionata a 1 segmento, e viene incrementata di 1 segmento per ogni ACK ricevuto. Il nome slow start e' fuorviante: il traffico cresce rapidamente (in effetti la crescita non e' additiva ma esponenziale!). Dopo il primo ACK sono trasmessi 2 segmenti. Alla ricezione degli ACK relativi i segmenti trasmessi diventano 4, e cosi' via. La finestra di congestione cresce cosi' rapidamente che per rallentarne l'apertura, quando arriva a meta' del valore antecedente la fase di congestione, essa viene incrementata di 1 solo quando tutti i segmenti della finestra sono stati riscontrati.

52 TCP e fine della congestione: esempio (Tanenbaum)

53 Implementazione di un TSAP su Internet
Secondo OSI un TSAP e' un punto d'accesso al servizio del layer di Trasporto. Il concetto di TSAP e' implementato (circa) in Internet attraverso la nozione di porta di protocollo. Una porta di protocollo e' individuata attraverso una tripla: Un indirizzo IP del sistema su cui la porta si trova Il protocollo cui la porta e' relativa (TCP vs. UDP) Il numero della porta (un intero compreso tra 1 e ) ( TSEL OSI) Una porta identifica univocamente una applicazione che accede, tramite il servizio di Trasporto, alla rete. Nel TCP l'astrazione fondamentale e‘ la connessione, identificata dalla coppia di porte che si trovano ai suoi estremi, non la porta. TCP associa le comunicazioni (i TSAP) alle connessioni, non alle porte. Ogni porta puo' partecipare a diverse connessioni.  NSAP OSI

54 Porte e Connessioni Comer:
Dal punto di vista di un programmatore l'astrazione connessione e' significativa. Egli puo' creare un programma in grado di fornire un servizio concorrente a piu' connessioni simultaneamente, senza avere bisogno di numeri univoci di porta per ciascun collegamento. Le connessioni verso i diversi client avranno tutte uguale identificatore di porta lato server, ma identificatore diverso per ciascun client, e saranno quindi tutte distinguibili tra loro. La maggior parte dei sistemi fornisce accesso simultaneo al sistema di posta elettronica, consentendo a piu' computer di inviar loro in parallelo le mail. Poiche' il programma che accetta la posta in ingresso usa TCP per comunicare, anche se consente a piu' connessioni di avere luogo simultaneamente, deve utilizzare localmente solo una porta TCP. N.B.: un servizio viene offerto su una porta. Uno specifico cliente viene servito tramite una connessione che ha quella porta come uno dei suoi 2 end-point.

55 Connessioni Una connessione rappresenta una relazione tra 2 porte TCP, i suoi end-point. Dal punto di vista del protocollo TCP l’unico modo per identificare una connessione e’ tramite gli indirizzi dei suoi due end-point. Invece nei protocolli di trasporto OSI ad ogni connessione e’ associato anche un ulteriore identificatore che la rende distinguibile rispetto ad altre connessioni tra gli stessi end-point. Nota che la modalita’ TCP di identificare le connessioni e’ fonte di notevoli problemi (vedi seguito). Per evitare ambiguita’, ad ogni istante non possono esistere sulla rete piu’ connessioni tra gli stessi end-point. Le protocol entity TCP che gestiscono le porte agli estremi della connessione mantengono lo stato della connessione stessa. Il protocollo TCP in realta’ non gestisce porte ma solo connessioni. Una porta TCP non connessa e non in corso di dis/connessione (in particolare, una porta in stato Listening) viene marcata come connessa alla porta inesistente :0

56 +---------+ ---------\ active OPEN
| CLOSED | \ < \ \ create TCB | ^ \ \ snd SYN passive OPEN | | CLOSE \ \ | | \ \ create TCB | | delete TCB \ \ V | \ \ CLOSE | \ | LISTEN | | | delete TCB | | rcv SYN | | SEND | | | | | V snd SYN,ACK / \ snd SYN | |< >| | | SYN | rcv SYN | SYN | | RCVD |< | SENT | | | snd ACK | | | | | | rcv ACK of SYN \ / rcv SYN,ACK | | | | x | | snd ACK | V V | CLOSE | | ESTAB | | snd FIN | CLOSE | | rcv FIN V | | snd FIN / \ snd ACK | FIN |< >| CLOSE | | WAIT-1 | | WAIT | rcv FIN \ | rcv ACK of FIN | CLOSE | | snd ACK | | V x V snd FIN V |FINWAIT-2| | CLOSING | | LAST-ACK| | rcv ACK of FIN | rcv ACK of FIN | | rcv FIN | Timeout=2MSL | | x V x V \ snd ACK delete TCB >|TIME WAIT| >| CLOSED | TCP Connection State Diagram

57 O:\>netstat -a -n Connessioni attive Proto Indirizzo locale Indirizzo esterno Stato TCP : : LISTENING TCP : : LISTENING TCP : : LISTENING TCP : : LISTENING TCP : : ESTABLISHED TCP : : ESTABLISHED TCP : : ESTABLISHED TCP : : ESTABLISHED TCP : : ESTABLISHED TCP : : LISTENING TCP : : ESTABLISHED TCP : : ESTABLISHED TCP : : ESTABLISHED TCP : : ESTABLISHED TCP : : ESTABLISHED TCP : : TIME_WAIT TCP : : TIME_WAIT TCP : : TIME_WAIT TCP : : ESTABLISHED

58 TSAP e connessioni Nel mondo TCP un TSAP rappresenta una connessione.
Una porta non connessa (in stato “Listening”) e’ formalmente connessa alla porta remota :0. Che e’ evidentemente un indirizzo di porta fittizio, perche’ il numero di porta 0 non e’ ammesso non e’ ammesso come indirizzo remoto e ha un significato particolare quando utilizzabile come indirizzo locale. Una porta in stato “Listening” su qualunque indirizzo IP della macchina si considera che sia associata all’indirizzo IP Nel momento in cui una porta “Listening” diventa connessa le viene comunque attribuito un preciso indirizzo IP, quello relativo alla sottorete su cui e’ stata attivata la connessione. Quando una connessione in stato “Listening” si avvia a diventare connessa, TCP crea un’altra connessione in stato “Listening” per la stessa porta. 58

59 TCP e creazione di una connessione
Perche' e' difficile creare in modo affidabile una connessione TCP? Perche' il servizio fornito dal layer IP e' inaffidabile. In particolare e' possibile che datagram IP vengano non solo persi, ma anche ritardati e/o duplicati. Uno dei problemi che possono nascere in presenza di segmenti ritardati (eventualmente duplicati) e' il seguente: Segmenti ritardati dalla rete e relativi ad una vecchia connessione sono ricevuti quando una nuova connessione tra gli stessi end-point e' gia' stata stabilita. TCP, a differenza di OSI TPx, non utilizza un identificatore specifico di connessione, oltre ai due end-point, cosi’ da essere in grado di distinguere i segmenti relativi alla connessione corrente da quelli obsoleti. Caso estremo (Tanenbaum): tutti i segmenti inviati da un end-point di una connessione sono duplicati, e tutti i duplicati sono consegnati al destinatario ritardati ma in ordine, dopo che la connessione e' gia' stata chiusa. 59

60 Eliminazione di datagram obsoleti
E' possibile limitare a priori il tempo di vita di un datagram IP? Si' perche', se si evitano cicli, il numero di hop necessari per attraversare l'intera Internet e' finito. Basta inserire uno hop-count in ogni datagram e decrementarlo ogni volta che un router lo ritrasmette. Quando lo hop count raggiunge lo 0 il datagram deve essere cestinato. Equivalentemente si potrebbe marcare ogni datagram con un time-stamp. Ma questo e' piu' complesso in quanto richiederebbe che gli orologi di tutti i nodi della rete fossero sincronizzati. In effetti esiste un protocollo di internet per la sincronizzazione degli orologi (NTP), e funziona anche molto bene, ma l’utilizzo dell’hop-count e’ ovviamente molto piu’ efficiente. In realta' bisogna garantire anche che l'ACK di un segmento sia morto entro un tempo finito: indichiamo con Tmax il tempo di vita massimo di un segmento e del suo ACK.

61 TP4 OSI e creazione di una connessione
Basandosi sulla eliminazione dei datagram obsoleti e sul fatto che ogni volta che l’initiator chiede al responder l’apertura di una connessione marca la richiesta con un ID di connessione diverso e’ sufficiente che il responder mantenga memoria dell’ID di una connessione chiusa per un tempo Tmax. Ogni volta che riceve un richiesta di connessione il responder puo’ verificare facilmente se la richiesta e’ attuale o e’ obsoleta. Ma in caso di restart del responder? Il responder perde la lista delle connessioni chiuse per le quali possono ancora essere presenti nella rete dei segmenti obsoleti! Questo problema puo' essere risolto proibendo ad un end-system di attivare la rete dopo il boot per un periodo di tempo pari a Tmax. Ma in caso di restart dell’initiator? Come fa l’initiator a ricordarsi degli ID gia’ usati? Tramite il meccanismo dell’orologio contatore!

62 Il meccanismo dell’orologio contatore
Ogni macchina viene dotata di un contatore periodico autoincrementante (un orologio contatore). L’orologio contatore deve operare anche in caso di spegnimento della macchina. Il contatore deve avere un numero di bit sufficientemente grande. Nel caso di TP4 l’orologio contatore puo’ venire utilizzato per selezionare in modo sicuro un ID univoco per la prossima richiesta di connessione che viene generata sulla macchina. Ma in TCP le connessioni non sono marcate con un ID addizionale! Nel caso del TCP l’orologio contatore locale viene utilizzato da ciascun end-point per selezionare il valore iniziale del sequence number che esso usera’ in trasmissione. Il sequence number dei segmenti trasmessi in una connessione viene inizializzato con i bit piu' leggeri del contatore. Il numero di bit dell’orologio contatore deve quindi essere maggiore o uguare a 232, dimensione del sequence number TCP.

63 TCP e creazione di una connessione
E’ evidente che perche’ TCP funzioni bene lo spazio dei valori del sequence number deve essere talmente grande che quando una connessione riutilizza un valore il segmento che lo aveva gia' utilizzato e' gia' stato eliminato dalla rete. Bisogna cioe’ evitare che ci siano nella rete due segmenti relativi alla stessa connessione (cioe' agli stessi end-point), con uguale sequence number, ma indipendenti tra loro (non uno la ritrasmissione dell'altro). Se riuscissimo a fare questo anche il problema di realizzare una connessione sicura, evitando interazioni con segmenti relativi a connessioni passate tra gli stessi end-point, sarebbe risolto. Per ottenere questo TCP correla (limita) la velocita’ di trasmissione sulla connessione all’avanzamento dell’orologio contatore, cosi’ che l’orologio contatore sia sempre in grado di fornire un valore sicuro di sequence number iniziale in caso di chiusura ed immediata riapertura della connessione tra due end-point . E’ sufficiente che la il numero di byte trasmessi non ecceda il numero di tick di cui e’ avanzato l’orologio contatore. L’orologio contatore deve avanzare ad una velocita’ tale da non limitare la banda della connessione.

64 Creazione di una connessione: 3-way handshake
Ogni macchina sceglie in modo sicuro il sequence number iniziale (utilizzando il proprio orologio contatore). Le due macchine si scambiano i propri contatori (e confermano la ricezione del contatore dell'altra) con uno scambio di 3 segmenti. Esercizio: quali altri parametri devono essere concordati durante il protocollo di set-up? Esercizio: mappare la specifica del servizio T-CONNECT su questo scambio di PDU Send(SYN(seq=x)) Send(ACK(y+1)) Receive(SYN(seq=y)+ACK(x+1)) Receive(SYN(seq=x)) Send(SYN(seq=y)+ACK(x+1)) Receive(ACK(y+1))

65 Creazione di una connessione: 3-way handshake
Comer: Di solito il SW TCP su una macchina aspetta passivamente la sincronia (richiesta di apertura passiva della connessione) e il SW TCP su un'altra la inizia (richiesta di apertura attiva della connessione). La sincronia e' pero' progettata per funzionare anche se entrambe le macchine tentano di iniziare una connessione simultaneamente. (in ogni caso) Una volta che la connessione e' stata stabilita, i dati possono fluire in entrambe le direzioni: non esiste una macchina principale e una secondaria. Il protocollo deve usare un meccanismo di timeout e ritrasmettere le richieste andate perse. TCP ignora altre richieste di connessione (tra uno stesso paio di end-point) dopo che tra loro e' gia' stata stabilita una connessione. La sincronia svolge due importanti funzioni (+ altre: quali?): garantisce che entrambi i lati siano pronti a trasferire dati consente ad entrambi di concordare sui numeri di sequenza iniziali.

66 Connection Establishment (Tanenbaum)
Three protocol scenarios for establishing a connection using a three-way handshake. CR denotes CONNECTION REQUEST. Normal operation, Old CONNECTION REQUEST appearing out of nowhere. Duplicate CONNECTION REQUEST and duplicate ACK.

67 TCP e chiusura di una connessione .1
La procedura di disconnessione morbida (ordinata) deve consentire di chiudere una connessione dopo che le parti hanno trasmesso tutto cio' che dovevano trasmettere; ciascuna parte ha ricevuto tutto cio' che l'altra parte ha trasmesso. Le connessioni TCP sono viste a tutti gli effetti come due flussi indipendenti di dati, uno in ciascuna direzione. Quando un cliente TCP chiude la connessione, indica effettivamente che non ha piu' dati da trasmettere su di essa: chiede quindi la chiusura di una direzione della connessione. Prima di iniziare il protocollo di disconnessione l'entita' di protocollo TCP lato mittente aspetta di avere trasmesso tutti i dati pendenti; avere ricevuto tutti i relativi ACK dalla controparte.

68 TCP e chiusura di una connessione .2
Dopo che ha effettuato la richiesta di chiudere la connessione, il cliente non puo' piu' chiedere la trasmissione di altri dati. Il lato ricevente del TCP, quando riceve un segmento FIN lo riscontra; informa il proprio cliente che dalla connessione non arriveranno piu' altri dati (e.g. con una indicazione di EOF). Notare che se una connessione e' stata chiusa in una direzione, rimane pero' ancora aperta nell'altra. Dire che una direzione e' chiusa significa dire che e' chiusa a segmenti informativi: segmenti che non trasportano informazioni (e.g. semplici ACK) possono continuare a viaggiare in quella direzione. Una connessione e' effettivamente chiusa quando entrambe le sue direzioni sono state chiuse.

69 TCP e chiusura di una connessione .3
Send(FIN(seq=x)) Send(ACK(y+1)) Receive(FIN(seq=x)) Send(ACK(x+1)) Receive(ACK(y+1)) FromClient(close.req) ToClient(close.ind) Receive(ACK(x+1)) Send(FIN(seq=y)+ACK(x+1)) Receive(FIN(seq=y)+ACK(x+1)) N.B.: non esiste un servizio OSI di disconnessione ordinata

70 TCP e chiusura di una connessione .4
Naturalmente e' possibile che segmenti (di FIN e di ACK) vadano persi durante l'esecuzione del protocollo di disconnessione. Per recuperare la perdita di segmenti ci si basa su timer. Se il mittente del primo segmento di FIN non riceve un ACK entro lo scadere del timer, riprende il protocollo da capo. Dopo n tentativi falliti il mittente del primo segmento FIN chiude unilateralmente la connessione. La controparte non e' naturalmente informata di cio'. Se ne accorgera' nel caso sia ancora attiva e provi a comunicare perche' non otterra' risposta. Anche il mittente del secondo segmento di FIN, se non riceve un ACK entro lo scadere del timer, chiude unilateralmente la connessione. I timer di disconnessione sono normalmente collegati al tempo di vita massimo di un segmento.

71 TCP e chiusura non ordinata di una connessione
Una connessione puo' anche essere chiusa unilateralmente in modo brusco. In questo caso: non c'e' alcuna garanzia che precedenti richieste di trasmissione siano (state) onorate, ne' che tutti i dati trasmessi dall'altra parte siano stati ricevuti. In ogni caso una richiesta di abort della connessione da parte del cliente provoca l'invio di un segmento di protocollo (RST) all'altra parte per informarla della cosa. Un abort ha effetto in modo bidirezionale: interrompe le comunicazioni in entrambe le direzioni.

72 Scenario elementare di trasmissione / ricezione
IP TCP entity end-point TX buffer RX buffer write() read() info ack window tempo Quando il ricevente ha inserito i byte ricevuti in RX buffer puo’ (deve?) generare ACK. Quando il mittente riceve ACK puo’ liberare (elimina) i byte trasmessi ma ancora contenuti in TX buffer (per eventuali ritrasmissioni). Quando il cliente acquisisce i byte contenuti in RX buffer, questi byte possono essere liberati e di conseguenza la finestra di trasmissione del mittente puo’ (deve?) essere aperta. In realta’ l’apertura della finestra puo’ essere convenientemente dilazionata (per limitare l’overhead), tanto piu’ se la finestra stessa non era stata completamente chiusa.

73 Problemi di prestazioni: delayed ACK .1
Lo scenario di comunicazione elementare e’ molto inefficiente: Per ogni PDU informativo (contenente byte di payload) trasmesso viaggiano 2 PDU contenenti solo byte di overhead. Le prestazioni del TCP possono essere migliorate se il ricevente non trasmette subito l'ACK ad un segmento informativo ricevuto. Puo' comunque unificare ACK e apertura di finestra (che dovrebbe/potrebbe generare dopo la lettura dell'informazione del segmento da parte del cliente). Puo' trasmettere l'ACK facendone il piggyback su un segmento informativo trasmesso in direzione opposta . E.g. sul segmento contenente la risposta applicativa al segmento ricevuto. Ma perche’ dovrebbe esseci una risposta applicativa? Perche’ molti protocolli applicativi seguono il pattern request-reply, e.g. HTTP e RPC. Esempio: eco dei caratteri ricevuti in una applicazione di terminale remoto.

74 Problemi di prestazioni: delayed ACK .2
L’ACK comunque deve essere generato entro un tempo massimo, per evitare l’inutile ritrasmissione del PDU informativo. Ritardare la generazione di ACK puo' avere controindicazioni: Se il ritardo e' eccessivo puo' stimolare la inutile ritrasmissione di segmenti (ma questo, ovviamente non dovrebbe succedere). Puo' confondere il calcolo del round-trip delay (questo e’ inevitabile!). Lo standard TCP: Raccomanda di utilizzare la politica di delayed ACK. Specifica che l'inerzia di generazione di un ACK deve essere al massimo di 500 msec. N.B.: questo diventa un lower bound per RTT! La generazione di ACK deve essere immediata almeno ogni 2 segmenti. Esercizio: definire uno scenario in cui ACK e apertura di finestra risultino fisiologicamente contestuali.

75 Problemi di prestazioni: la sindrome della finestra scema
Supponiamo che un lato della connessione sia piu' veloce dell'altro e che la rete non ponga limiti significativi di banda. Consideriamo la trasmissione dal lato veloce a quello lento: Dopo un po' il buffer del lato ricevente sara’ completamente occupato e la finestra sara' chiusa. A questo punto il cliente lato ricevente legge un byte (dal buffer di ricezione della connessione). Di conseguenza il TCP lato ricevente genera un segmento di apertura di finestra di un byte. Il lato trasmittente invia immediatamente un segmento informativo contenente un byte, saturando di nuovo il buffer del lato ricevente. Il ciclo si ripete con il lato mittente che trasmette dati un byte alla volta, un byte per segmento. Si utilizza un PDU informativo per trasmettere 1 solo byte di payload (senza contare eventuali, conseguenti, PDU di overhead).

76 La sindrome della finestra scema, lato ricevente
Esistono contromisure lato ricevente. La strategia e': Non aprire la finestra per un numero di byte troppo piccolo. Aspettare ad aprire la finestra finche' la si possa aprire in modo abbastanza significativo. TCP definisce questa quantita' come: Almeno meta' della dimensione totale del buffer disponibile lato ricezione, oppure (il minimo dei due): Almeno la dimensione del massimo segmento consentito (MTU) (N.B.: cio’ garantisce il miglior rapporto payload/overhead possibile). La ricetta secondo Comer: Receive-Side Silly window Avoidance: before sending an updated window advertisment after advertising a 0-window (dopo avere bloccato il lato mittente), wait for space to become available to be at least 50% of the total buffer size or equal to a maximum-sized segment.

77 La sindrome della finestra scema, lato mittente .1
Esistono contromisure lato mittente. La strategia e': Cercare di evitare l'invio di segmenti informativi che contengano pochi dati. Cercare di evitarlo anche a fronte di singole richieste, da parte del cliente, di trasmissione di pochi byte. In questo caso, aspettare a soddisfare le singole richieste, cercando, con un singolo segmento trasmesso, di soddisfare contemporaneamente piu' di una richiesta di trasmissione del cliente. La ricetta secondo Comer (algoritmo di Nagle): Send-Side Silly window Avoidance: when a sending application generates additional data to be sent over a connection for which previous data has been transmitted but not acknowledged, place the new data in the output buffer as usual, but do not send additional segments until there is sufficient data to fill a maximum-sized segment. If still waiting to send when an acknowledgement arrives, send all data that has accumulated in the buffer.

78 La sindrome della finestra scema, lato mittente .2
Il principio e' che il tempo di isteresi per soddisfare una richiesta di trasmissione del cliente e' adattativo. Dipende dalla velocita' della rete. Dipende dalla velocita' della controparte. Dipende dal tipo di traffico generato dal cliente. Consideriamo i casi estremi: Per un file transfer il cliente mittente genera grandi quantita' di dati che saturano il segmento di massima dimensione. La trasmissione dei dati non viene quindi ritardata. Nel caso di un virtual terminal il cliente mittente genera un carattere alla volta. Il primo viene inviato immediatamente. Quelli successivi sono accumulati in attesa dell'ACK del primo, e non appena questo arriva sono immediatamente trasmessi in blocco. Dal punto di vista del cliente non c'e' una significativa percezione di ritardo.

79 Push dei dati e Algoritmo di Nagle
L’algoritmo di Nagle e’ utile per eliminare la sindrome della finestra scema ma rappresenta anche una politica generale capace di ottimizzare il rapporto payload/overhead. Vedi l’esempio Telnet (terminale virtuale). Infatti tutte le implementazioni di TCP implementano l’algoritmo di Nagle e, di default, lo applicano a tutte le connessioni. Esercizio: essendo attivo l’algoritmo di Nagle che differenza c’e’ tra N richieste, immediatamente in sequenza, di trasmissione di 1 byte e una singola richiesta di trasmissione di N byte? Dal punto di vista del carico di rete. Dal punto di vista del carico computazionale sui due end- system. Descrivere alcuni possibili scenari (per diverse velocita’ di end- system e rete).

80 Push dei dati e Algoritmo di Nagle
Ci sono applicazioni per le quali l'utilizzo dell'algoritmo di Nagle non e' appropriato: in una applicazione come X-term o VNC, ad esempio, il suo utilizzo causerebbe lo spostamento a scatti del mouse. In teoria TCP consente, tramite una operazione di push, di forzare la trasmissione dei dati. L'operazione di push pero' non by-passa l'algoritmo di Nagle. L'algoritmo di Nagle puo' essere disabilitato per una connessione attraverso una opportuna configurazione dell'entita' di protocollo TCP. Vedi l'opzione TCP_NODELAY della system call setsockopt() (lezione 4). L'algoritmo di Nagle viene normalmente disabilitato nelle applicazioni in tempo reale. Esercizio: supponiamo che sia MTU=1000 e che il processo mittente esegua in successione 4 operazioni di trasmissione, rispettivamente di 500, 500, 250, 500 byte. Come vengono effettivamente trasmessi questi byte in rete, e come vengono ricevuti dal processo destinatario se assumiamo che questo sia permanentemente in ricezione?

81 Interazione livello applicativo - TCP
TCP cerca di ottimizzare le prestazioni della rete qualunque siano le caratteristiche del dialogo applicativo, caratteristiche che ovviamente non possono essere limitate a priori. L’algoritmo di Nagle ha questo scopo, anche al di la’ del caso specifico della sindrome della finestra scema. Le caratteristiche dell’applicazione possono avere impatti significativi sulle prestazioni fornite da TCP. Ad esempio, se in un dialogo request-reply la risposta e’ sempre (o non e’ mai) generata in tempi sufficientemente brevi da consentire il piggybacking dell’ACK. Se l’applicazione disabilita le modalita’ operative normali di TCP se ne assume la responsabilita’ e ne subisce eventualemente le conseguenze. In caso di disabilitazione dell'algoritmo di Nagle non e’ piu’ vero che N operazioni di write da 1 byte l’una sono piu’ o meno equivalenti a 1 operazione di write da N byte. Dovra’ essere cura dell’applicazione minimizzare le operazioni di write.

82 Dati fuori banda (expedited data)
Il TCP fornisce un servizio di trasmissione affidabile di una sequenza continua e ordinata di byte. Puo' pero' essere significativo poter trasmettere dei dati che siano ricevuti dalla controparte al di fuori della sequenza: ad esempio se voglio inviare un comando di abort all'applicazione remota. Per consentire una cosa del genere il cliente puo' marcare una richiesta di trasmissione come urgente (out-of-band), e questa e' trasportata in un segmento che contiene anch'esso la marca di urgente (e che viene trasmesso immediatamente). TCP specifica che quando il lato ricevente riceve un segmento marcato urgente, esso deve entrare in stato di urgenza e informare immediatamente della cosa il cliente. A cosa servono i dati fuori banda se il processo destinatario non viene informato subito della loro ricezione? Come? Dipende dal sistema operativo, e.g. attraverso un signal. Quando il cliente lato ricevente ha letto tutti i dati urgenti viene informato della fine dello stato di urgenza.