Vorlesung: Netzwerke (TK) WS 2011/12 Kapitel 5 Ende-zu-Ende-Protokolle Session 17

Transkript

1 Vorlesung: Netzwerke (TK) WS 2011/12 Kapitel 5 Ende-zu-Ende-Protokolle Session 17 Prof. Dr. Michael Massoth [Stand: ] 17-1

2 17-2 ACHTUNG: Testat_4 am Dienstag, den Referenzmodelle (OSI, Hybrid, TCP/IP) Hardware-Bausteine bzw. Kopplungselemente Strukturierte Verkabelung Ethernet (inkl. CSMA/CD) und WLAN Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN) Internetworking (inkl. IPv4-Adressierung und Subnetting) Ende-zu-Ende-Protokolle (UDP + TCP) 17-2

3 17-3 ACHTUNG: Testat_5 am Dienstag, den Referenzmodelle (OSI, Hybrid, TCP/IP) Hardware-Bausteine bzw. Kopplungselemente Strukturierte Verkabelung Ethernet (inkl. CSMA/CD) und WLAN Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN) Internetworking (inkl. IPv4-Adressierung und Subnetting) Ende-zu-Ende-Protokolle (UDP + TCP) 17-3

4 17-4 Lernziele heute : Zuverlässige Zustellung: Stop-and-Wait-Algorithmus und Sliding Window (Grundlagen) Lernziele im Detail: Zuverlässige Zustellung verstehen und anwenden können Sliding-Window-Algorithmus für Sender und Empfänger mit Variablenverwaltung verstehen und anwenden können 17-4

5 17-5 TCP [Transmission Control Protocol ] TCP Sequenz- und Bestätigungsnummern Zuverlässiger Datentransfer TCP-Flusskontrolle Pipelining und Sliding-Window TCP-Überlastkontrolle 17-5

6 17-6 Lernziele heute: Transmission Control Protocol (TCP) Lernziele im Detail: TCP als zuverlässiges Byte-Strom-Protokoll mit integrierter Flusskontrolle verstehen, erklären und anwenden können TCP mit variablem Sliding-Window-Algorithmus und integrierter Flusskontrolle verstehen, erklären und anwenden können 17-6

7 Zuverlässiger Datenaustausch 17-7 Ein Paket wird versendet und ein Timer gesetzt Kommt es beim Empfänger an wird eine Bestätigung gesendet Läuft der Timer ab bevor Bestätigung ankommt wird erneut gesendet Nachteil: Ineffiziente Nutzung der Bandbreite 17-7

8 Zuverlässiger Datentransfer mit Pipelining (1) 17-8 Gegenüberstellung von Stop-and-Wait und Pipelining: Zuverlässiger Datentransfer mit Pipelining: Da die vielen zwischen Sender und Empfänger im Transit befindlichen Pakete als das Füllen einer Pipeline betrachtet werden können, wird diese Technik Pipelining genannt. 17-8

9 Zuverlässiger Datentransfer mit Pipelining (2) 17-9 Zuverlässiger Datentransfer mit Pipelining Konsequenzen: Die Sender- und Empfängerseite benötigen einen Puffer für mehr als ein Segment. Als Minimum muss der Sender die bereits übertragenen, aber noch nicht bestätigten Segmente zwischenspeichern. Bereich der Sequenz- und Bestätigungsnummern muss entsprechend vergrößert werden. 17-9

10 TCP Sliding Window (1) Fenstergröße = Anzahl von Bytes, die ein Host übertragen kann, während er auf eine Bestätigung wartet Größeres Fenster ermöglicht dem Host, mehr Daten zu übertragen, während eine Bestätigung noch aussteht Sliding bezieht sich darauf, dass die Fenstergröße während der TCP-Session dynamisch ausgehandelt wird effizientere Ausnutzung der Bandbreite 17-10

11 Sliding-Window-Algorithmus allgemein Sender Receiver Sender weist jedem Paket (hier: TCP-Segment) eine Sequenznummer (Engl. Sequence Number) zu mit der Beschriftung Seq Für jedes übertragene Paket setzt der Sender auch einen Timer und überträgt dieses Paket (TCP-Segment) erneut, wenn der Timer vor dem Eingang eines ACK abläuft 17-11

12 Sender and Receiver State Sender Receiver Max ACK received Next seqnum Next expected Max acceptable Sender window Receiver window Sent & Acked Sent Not Acked Received & Acked Acceptable Packet OK to Send Not Usable Not Usable 17-12

13 TCP Flusskontrolle und Sliding Window Merke: Die TCP Variante des Sliding Window Algorithmus gewährleistet: 1. Die zuverlässige Übertragung von Daten in einem Byte-Strom 2. Die Übertragung der Daten in der richtigen Reihenfolge 3. Eine Flusskontrolle zwischen Sender und Empfänger Integrierte Flusskontrolle: Bei TCP wird keine feste Sliding- Window Größe benutzt, sondern dem Sender vom Empfänger advertised (bekannt gemacht). Dies geschieht durch das Feld AdvertisedWindow im TCP- Header Empfänger wählt einen geeigneten Wert für AdvertisedWindow auf der Grundlage des Speicherplatzes aus, der der Verbindung für die Zwischenspeicherung von Daten zugewiesen ist 17-13

14 TCP Sliding-Window (1) Sending application Receiving application LastByteWritten TCP LastByteRead TCP LastByteAcked LastByteSent NextByteExpected LastByteRcvd (a) (b) Sending side (a): LastByteAcked LastByteSent LastByteSent LastByteWritten Buffer bytes between LastByteAcked and LastByteWritten 17-14

15 TCP Sliding-Window (2) Sending application Receiving application LastByteWritten TCP LastByteRead TCP LastByteAcked LastByteSent NextByteExpected LastByteRcvd (a) (b) Receiving side (b): LastByteRead NextByteExpected NextByteExpected LastByteRcvd +1 Buffer bytes between NextByteRead and LastByteRcvd 17-15

16 TCP Flow Control Window Sender Application TCP Receiver Application TCP Sender's Window Receiver's Window IP IP lastbytefromapplication lastbytetoapplication lastbytesent nextbyteexpected lastbyteacknowledged lastbytereceived 17-16

17 TCP Timer im Überblick TCP Timer im Überblick: Retransmission Timer (Timeout => RTO) Nach Ablauf des Timers werden unbestätigte Datenpakete erneut gesendet Reconnection Timer Minimale Zeit, die gewartet werden muss, um eine Verbindung abzubauen und sie erneut zur gleichen Zieladresse wieder aufzubauen Window Timer Maximale Zeit, die verstreichen darf, um nach einer Bestätigung von Datenpaketen die Fenstergröße auf einen neuen Wert umzustellen Retransmit Syn Timer Maximale Zeit, die verstreichen muss, um nach einem erfolglosen Verbindungsaufbauversuch einen erneuten Connection Request zu starten Give Up Timer Nach Ablauf dieses Timers wird die Verbindung abgebaut, wenn keine Datenpakete vom Zielknoten bestätigt werden 17-17

18 TCP Fehlerbehandlung TCP Fehlerbehandlung: Die Fehlerbehandlung erfolgt durch Go-Back-N TCP arbeitet mit positiven Quittungen, die Summenquittungen darstellen (für die Menge erfolgreich übertragener Bytes) Dies bedeutet, dass ab dem ersten, nicht quittierten Paket alle Pakete wiederholt werden 17-18

19 Datenfluss Buffer Buffer TCP Modul TCP Modul 17-19

20 Datenfluss Korrekte und fehlerfreie Übertragung: Sender erhält für jedes gesendete Paket ein ACK (Quittung), besteht aus ACK-Flag=1 und ACK-Nummer ACK-Nummer = Seq-Nummer + Größe Payload in Byte Folgende Seq-Nummer = ACK 17-20

21 Datenfluss: Fehlerfreie Übertragung Empfänger Buffer SEQ=1 Daten: 1460 Byte SEQ=1, ACK=1461, Daten: 0 Byte SEQ=1461 Daten: 1460 Byte SEQ=2, ACK=2921, Daten: 0 Byte Sender Buffer

22 Datenfluss: Fehler bei Übertragung Empfänger Buffer SEQ=1 Daten: 1460 Byte SEQ=1, ACK=1461, Daten: 0 Byte SEQ=1461 Daten: 1460 Byte SEQ=2, ACK=2921, Daten: 0 Byte SEQ=2921 Daten: 1460 Byte Sender Buffer SEQ=4381 Daten: 1460 Byte SEQ=3, ACK=2921, Daten: 0 Byte SEQ=5841 Daten: 1460 Byte SEQ=4, ACK=2921, Daten: 0 Byte SEQ=2921 Daten: 1460 Byte SEQ=5, ACK=7301, Daten: 0 Byte Timer abgelaufen Retransmission Paket

23 Datenfluss Einigung im Vorfeld (Windowsize): Z. B. 5 * Bytes ACK Buffer => Datenverlust 17-23

24 Datenfluss Abhilfe: Windowfeld auf 0 (Zero Window) Window=0 ACK, SEQ=1, ACK 7301, Window = 7300 ACK, SEQ=1, ACK Buffer 17-24

25 Sequenz/Acknowlegde Verlauf Sender Empfänger 500 Bytes, Seq=x Seq=y, ACK=1, Ack=x Bytes, Seq=x+500 Seq=y+1, ACK=1, ACK=x

26 Acknowledge / positive Quittungen Solange ACK nicht eingegangen ist, darf kein neues Paket gesendet werden Kommt kein ACK-Paket, so ist entweder das Paket verloren gegangen oder das ACK-Paket verloren In beiden Fällen wird das Paket wiederholt nach einem RetransmissionTimeOut (RTO) Es gilt: RTO < SRTT + 4 * RTTVAR SRTT: gemittelte Roundtrip-Time RTTVAR: Mittlere Abweichung der Roundtrip-Time Startwerte für RTO zwischen 2,5 und 3 sec (RFC 2988) 17-26

27 Window-Feld Datendurchsatz ist bei Quittierung jedes Pakets relativ niedrig Zuverlässige Verbindung bedeutet, dass der Empfänger bei Überlast den Sender drosseln können muss Window-Size durch Empfänger im ACK-Paket legt die neue Anzahl der sendbaren Bytes fest 17-27

28 Windowsize ms Übertragungsdauer HOST 1 HOST 2 H1 sendet 1000 Bytes an H2 Dauer = 100ms H2 sendet ACK zurück Dauer = 100ms H1 sendet 1000 Bytes an H2 Dauer = 100ms H2 sendet ACK zurück Dauer = 100ms Datendurchsatz = Bytes in 400ms, damit also Bytes/s, egal, wie schnell die Leitung ist! 17-28

29 Windowsize ms Übertragungsdauer HOST 1 HOST 2 H1 sendet Bytes an H2 Dauer = 100ms H2 sendet ACK zurück Dauer = 100ms H1 sendet Bytes an H2 Dauer = 100ms H2 sendet ACK zurück Dauer = 100ms Datendurchsatz = Bytes in 400ms, damit also Bytes/s, egal, wie schnell die Leitung ist! 17-29

30 Windowsize ms Übertragungsdauer HOST 1 HOST 2 H1 sendet 1000 Bytes an H2 Dauer = 100ms H1 sendet 1000 Bytes an H2 Dauer = 100ms H1 sendet 1000 Bytes an H2 Dauer = 100ms H2 sendet ACK zurück Dauer = 100ms Datendurchsatz = Bytes in 400ms, damit also Bytes/s 17-30

31 17-31 TCP [Transmission Control Protocol ] TCP Sequenz- und Bestätigungsnummern Zuverlässiger Datentransfer TCP-Flusskontrolle Pipelining und Sliding-Window TCP-Überlastkontrolle 17-31

32 17-32 Lernziele heute: Transmission Control Protocol (TCP) Lernziele im Detail: TCP Slow Start und Congestion Avoidance verstehen, erklären und anwenden können Unterschied zwischen Flusskontrolle und Congestion Control (dt. Stau- bzw. Überlastkontrolle) verstehen und erklären können 17-32

33 TCP-Überlastungsüberwachung (a) (b) Ein schnelles Netz, das an einen Empfänger mit geringer Kapazität weiterleitet. Ein langsames Netz, das an einen Empfänger mit hoher Kapazität weiterleitet

34 TCP Slow Start and Congestion Avoidance window size slow start congestion avoidance threshold new threshold time timeout occurs 17-34

35 TCP Slow Start window size congestion avoidance slow start threshold new threshold time timeout occurs 17-35

36 TCP Slow Start (1) Problem: Sliding-Window funktioniert nur im selben LAN sehr gut Probleme bei Kommunikation über Zwischensysteme (Router), mit langsameren Verbindungen Ansatz: TCP Slow Start 17-36

37 TCP Slow Start (2) TCP Slow Start Prinzip: Algorithmus überwacht Kommunikation Sender erweitert TCP-Modul um ein Congestion Window (cwnd) und eine Slow Start Threshold Size (ssthresh) CWND wird bei jedem ACK erhöht (2 0, 2 1, 2 2, ) Sender kann maximal das Minimum von CWND und Windowsize an Daten senden Wird ein Paketverlust festgestellt, wird CWND auf letztbekannte funktionierende Größe zurückgesetzt 17-37

38 TCP Slow Start (3) TCP Slow Start: Start with Congestion Window cwnd = 1 (segment size announced by other side) On each successful ACK increment cwnd with cwnd cnwd + 1 Exponential growth of cwnd size, if all former segements are acknowledged successfully. Each RTT: cwnd 2 x cwnd Enter Congestion Avoidance (CA) when cwnd ssthresh (slow start threshold size) Merke: Für jeder erfolgreiche Quittung (ACK) wird das Congestion Window um eine Segmentgröße erhöht. Dadurch ergibt sich eine Verdopplung der Congestion Window Größe pro RTT. Limit ist das vom Empfänger festgelegte Empfangsfenster! 17-38

39 TCP Slow Start (4) sender cwnd 1 1 RTT 2 data packet ACK receiver cwnd cwnd + 1 (for each ACK) 17-39

40 TCP Congestion Avoidance window size congestion avoidance slow start threshold new threshold time timeout occurs 17-40

41 Congestion Avoidance (1) Congestion Avoidance (dt. Vermeidung von Überlast): Annahme: TCP geht davon aus, dass Pakete durch Überlast im Netz verloren gehen. Paketverlust durch Transmissionsfehler < 1% Ein Verlust beruht also auf Verlust in Zwischensystemen (Paketdrop / Bufferoverflow) Verlust wird durch RetransmissionTimeout (RTO) und Empfang von doppelten ACKs (=duplizierte Quittungen) festgestellt Congestion Avoidance und Slow Start eigentlich separate Funktionen, werden aber zusammen implementiert 17-41

42 Congestion Avoidance (2) Congestion Avoidance: Starts when cwnd ssthresh On each successful ACK: cwnd cwnd + 1/cwnd Linear growth of cwnd. Each RTT: cwnd cwnd

43 Congestion Avoidance (3) sender cwnd 1 2 data packet ACK receiver 1 RTT 3 4 cwnd cwnd + 1 (for each cwnd ACKS) 17-43

44 Congestion Avoidance (4) SSTHRESH = CWND = 1 SSTHRESH = min(window, CWND) / 2 (mindestens aber 2 Segmente) Sende min(window, CWND) Daten Inc(CWND) (Slow Start) Paketverlust durch Timeout Nein CWND <= SSTHRESH Ja CWND = 1 Ja Paketverlust Nein Ja Nein Conguesten Avoidance Slow Start Bis CWND = SSTHRESH CWND = CWND + 1/CWND (max. 1 pro RTT) 17-44

45 TCP-Überlastungsüberwachung

46 Slow Start and Congestion Avoidance (5) Slow Start und Congestion Avoidance: [Siehe dazu Abb.] Die maximale Segmentgröße ist Byte (= 1 MSS) Anfangs umfasst das Überlastungsfenster (Cwnd) 64 KByte, dann findet ein Timeout statt, so dass der Schwellenwert auf 32 KByte gesetzt wird. [Soweit die Vorbedingungen!!!] Das Überlastungsfenster startet bei 1 MSS (= 1 KByte) und wächst nach dem TCP Slow Start Algorithmus exponentiell bis es den Schwellenwert (= Threshold hier bei 32 KByte) erreicht. Ab dem Schwellenwert übernimmt der TCP Congestion Avoidance Algorithmus und das Überlastungsfenster steigt nur noch linear. Segment 13 hat kein Glück und geht verloren. Es kommt zu einem Timeout. Der Schwellenwert wird auf die Hälfte der aktuellen Fenstergröße gesetzt (inzwischen 40 KByte, d. h. die Hälfte ist 20 KByte). TCP Slow Start beginnt wieder von neuem (bei 1 )

47 Slow Start and Congestion Avoidance (6) Slow Start und Congestion Avoidance: Slow Start Threshold Size (ssthresh): ssthresh = minimum(window,cwnd)/2, mindestens aber 2 Segmente 17-47

48 Flow Control and Congestion Control Flow Control (Flusskontrolle): Soll verhindern, dass ein Sender zeitiger, schneller oder mehr Daten schickt als der Empfänger verarbeiten kann Begrenzung der Datenmenge Congestion Control (Überlastkontrolle): Funktion der Netzwerkschicht zur Regelung des Datenflusses zwischen zwei Netzteilnehmern Begrenzung der Übertragungsrate Verhindert, dass zu viele Daten in das Netz eingespeist werden und dadurch Vermittler oder Verbindungen überlastet werden Merke: Flusskontrolle ist ein Ende-zu-Ende-Problem, während Überlastkontrolle die Interaktion zwischen Hosts und Netzwerken betrifft

49 17-49 Lernziele heute: Transmission Control Protocol (TCP) Lernziele im Detail: TCP Silly Window Syndrom verstehen und erklären können TCP Nagle-Algorithmus verstehen, erklären und anwenden können TCP Karn/Partridge-Algorithmus verstehen und erklären können TCP Jacobson/Karels-Algorithmus verstehen und erklären können 17-49

50 17-50 TCP [Transmission Control Protocol ] Das Silly-Window-Syndrom Nagle-Algorithmus Karn/Partridge-Algorithmus Jacobson/Karels-Algorithmus 17-50

51 Das Silly-Window-Syndrom Silly-Window-Syndrom (dt. Dummes-Fenster-Syndrom): Tritt auf, wenn große Datenmengen an die sendende TCP-Instanz übergeben werden, während eine interaktive Anwendung am empfangenden Ende die Daten nur Byte für Byte einlesen kann

52 Silly-Window-Syndrom (1) Sender Receiver Problem: Aggressive Ausnutzung jedes beliebig verfügbaren Fensters Sender verschickt sehr kleine Segmente (z. B. 1 Byte), Empfänger bestätigt Sender schickt wieder sehr kleines Segment, usw. kleine Segmente mit viel Overhead verbleiben (für lange Zeit) im System Tritt nur auf, wenn entweder der Sender ein kleines Segment überträgt, oder der Empfänger das Fenster nur wenig öffnet 17-52

53 Silly-Window-Syndrom (2) Das Silly-Window-Syndrom (Problembeschreibung): Der Empfänger sendet ein Zero Window an den Sender, da sein Buffer voll ist. Die Anwendung beim Empfänger liest allerdings nur zwei Byte aus dem Buffer. Der Empfänger schickt ein TCP-Header mit Window=2 (Window Update) an den Sender und fordert gleichzeitig die zwei Byte an. Der Sender kommt der Aufforderung nach und schickt die zwei Byte in einem 42 Byte großen Paket (mit IP-Header und TCP-Header) an den Empfänger. Damit ist der Buffer des Empfängers wieder voll und er schickt wieder ein Zero Window an den Sender. Die Anwendung liest jetzt zum Beispiel hundert Byte aus dem Buffer. Der Empfänger schickt wieder ein TCP-Header mit einem kleinen Window-Wert an den Sender. Dieses Spiel setzt sich immer wieder fort und verschwendet Bandbreite, da nur sehr kleine Pakete versandt werden

54 Abhilfe auf Empfängerseite Abhilfe gegen Silly-Window-Syndrom auf Empfängerseite von Dave Clark (1982): Empfänger darf nur Window = 0 senden, oder wartet mit Window-Update bis mind. ein MSS im Puffer frei ist Also die Regel lautet: Nachdem ein Fenster mit Größe = 0 bekannt gegeben wurde, muss der Empfänger solange warten, bis Platz im Umfang von einer Maximum Segment Size (MSS) vorhanden ist, bevor er wieder ein offenes Fenster bekannt gibt MSS von TCP: Maximal Byte Payload MSS von TCP über Ethernet: Byte Payload 17-54

55 Nagle-Algorithmus (1) Abhilfe gegen Silly-Window-Syndrom auf Senderseite von Nagle (1984): Ist ein Segment voll, dann schicke es Ist ein Segment nicht voll, dann schicke es erst, wenn du genug Daten hast, oder keine unbestätigten Pakete mehr unterwegs sind Anmerkung: Nagle-Algorithmus ist eine einfache, selbst-taktende Lösung 17-55

56 Nagle-Algorithmus (2) Nagle-Algorithmus im Detail: Anwendung hat sendebereite Daten produziert Einfache, einheitliche Regel für die Entscheidung, wann übertragen werden soll: Falls sowohl die verfügbaren Daten als auch das Fenster MSS, dann Sende ein volles Segment Andernfalls Falls unbestätigte Daten anstehen, dann puffere die neuen Daten, bis ein ACK ankommt Andernfalls Anmerkung: Sende alle neuen Daten sofort Nagle-Algorithmus kann durch setzen der TCP_NODELAY-Option ausgeschaltet werden 17-56

57 Verwaltung von Timern in TCP (a) (b) Wahrscheinlichkeitsdichte der Ankunftszeiten von Bestätigungen (ACKs) auf der Sicherungsschicht (Layer 2, MAC-Schicht). Wahrscheinlichkeitsdichte der Ankunftszeiten von Bestätigungen (ACKs) für TCP 17-57

58 Abschätzung von Round-Trip-Times RTT-Muster (Samples) und RTT-Durchschnitt (Average) [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.36] 17-58

59 Adaptive Neuübertragung Adaptive Neuübertragung (Original-Algorithmus): Konzept: Ermittele ständig den gleitenden Durchschnitt der RTT und berechne daraus den (Retransmission) Timeout-Wert Vorgehen im Detail: Messe SampleRTT für jedes Segment/ACK-Paar Berechne den gleitenden (gewichteten) Durchschnitt von RTT EstimatedRTT a x EstimatedRTT + (1 - a) x SampleRTT - wobei a zwischen 0.8 und Parameter a wird gewählt, um EstimatedRTT zu glätten TCP benutz EstimatedRTT, um den Timeout relative konservativ zu berechnen: TimeOut := 2 x EstimatedRTT 17-59

60 Karn/Partridge-Algorithmus (1) Problem bei Berechnung von EstimatedRTT: Ein ACK bestätigt in Wirklichkeit keine Übertragung, sondern nur den Empfang von Daten Mit anderen Worten: Wenn ein Segment erneut übertragen wird und anschließend ein ACK beim Sender ankommt, lässt sich nicht feststellen, ob das ACK mit der ersten oder zweiten Übertragung des Segments in Verbindung gebracht werden soll Ansatz: Überlast ist die wahrscheinlichste Ursache für verlorene Segmente, was bedeutet, dass die TCP-Quelle nicht zu aggressiv auf einen Timeout (Retransmission Timer) reagieren sollte 17-60

61 Karn/Partridge-Algorithmus (2) Sender Receiver Sender Receiver Original transmission Original transmission Retransmission ACK Retransmission ACK (a) (b) Karn/Partridge-Algorithmus: a) Zusammenhang des ACK mit der ursprünglichen Übertragung b) Zusammenhang des ACK mit der Neuübertragung 17-61

62 Karn/Partridge-Algorithmus (3) Lösung: Wann immer TCP ein Segment erneut überträgt, setzt die Messung der RTT aus SampleRTT wird nur für Segmente gemessen, die einmal gesendet (und bestätigt) wurden Lösung im Detail: Jedes Mal, wenn TCP erneut überträgt, dann setzt es den nächsten Timeout auf das Doppelte des letzten, statt auf die letzte Estimated RTT 17-62

63 Jacobson/Karels-Algorithmus (1) Problem: Starke Netzüberlast im Internet Ansatz: Zusammenhang zwischen Timeout und Überlast Wenn der Timeout zu früh abläuft, wird ein Segment möglicherweise unnötig erneut übertragen, wodurch das Netzwerk noch stärker belastet wird Hauptproblem der ursprünglichen RTT-Berechnung: Varianz der SampleRTT wurde nicht in Betracht gezogen Weichen die Messwerte (samples) nur wenig voneinander ab, dann dürfte die EstimatedRTT (geschätzte RTT) zuverlässig sein damit kein Grund vorliegen RTT mit 2 zu multiplizieren Bei großen Schwankungen der SampleRTT ist 17-63

64 Jacobson/Karels-Algorithmus (2) Berechnung von mittlerer RTT (Mittelwert) und Schwankungen: Differenz = SampleRTT - EstimatedRTT EstimatedRTT = EstimatedRTT + (d x Differenz) Abweichung Abweichung + d x ( Differenz - Abweichung) - wobei d eine Zahl zwischen 0 und 1 ist TCP berechnet den Timeout-Wert als Funktion von EstimatedRTT und Abweichung: TimeOut = m x EstimatedRTT + f x Abweichung - wobei m = 1 und f = 4 TimeOut = EstimatedRTT + 4 x Abweichung 17-64

65 Jacobson/Karels-Algorithmus (2) Ergebnis: Bei geringen Schwankungen der RTT liegt Timeout nahe bei der EstimatedRTT Bei großen Schwankungen dominiert der Term Abweichungen Bemerkung: Algorithmus nur so gut wie die Granularität (Genauigkeit) der rechnerinternen Uhr (z. B. bei Unix 500 ms) Genauer Timeout-Mechanismus ist wichtig für Congestion Control 17-65

66 17-66 Vielen Dank für Ihre Aufmerksamkeit! Noch Fragen? Fragen und Diskussion 17-66