RvS3

Question 1

Transport: Anwendungsprozess-Kommunikation

Accepted Answer

Funktionalität "Ende-zu-Ende" Anwendungsprozesse kommunizieren: Adressierung Anwendungsnachrichten Anwendungsanforderungen Vielfältige Anwendungsanforderungen Video, Audio, HDTV, Dateien, Steuerbefehle Vielfältige Kommunikationstechnik ISDN, ATM, DSL, Ethernet, FDDI, Kabel, Glas, ... "Universeller" Transportdienst Anwendungs- und Technikunabhängig Dienstgüte/Quality of Service

Question 2

Transportschicht

Accepted Answer

IP-Adresse: Stationsadresse Transportadresse: Stationsadresse & Dienstart & Portnummer 2 Dienste, 2 Protokolle: UDP - Datagramm, TCP - Verbindungen Qualitäts - und Kostenkontrolle Multiplexen/Demultiplexen IP-PDU trägt T-PDU: IP-Quelladresse, IP-Zieladresse, weitere IP-Kontrollparameter IP-Nutzdaten = T-PDU Quellportnummer, Zielportnummer, weitere T-Kontrollparameter T-Nutzdaten = Anwendungs-PDU

Question 3

UDP - User Datagram Protocol

Accepted Answer

Verbindungslos, Relativ unzuverlässig, nicht reihenfolgentreu einfacher Dienst einfaches Protokoll, wenig Overhead PDU-Format: 1 UDP-Segmente (32 Bit) Header Quellportnummer Zielportnummer Länge Prüfsumme Inhalt T-Nutzdaten

Question 4

Internet-Prüfsumme: Verfälschungserkennung

Accepted Answer

Berechnung der Checksummen von UDP-Datagrammen, TCP-Segmenten und IP-Datagrammen. UDP-Datagramme (optional) Prüfsumme über alle realen Headerfelder (Source-, Destination-Port, Length) Pseudeo-Headerfelder (IP-Source-, Destination-Adress,...) Datenfeld TCP-Segmente Prüfsumme über alle Headerfelder (Source-, Destination-Port, Sequence-, Ack-Number,...,Options) Pseudo-Headerfelder (IP-Source-, Destination-Adress,...) Datenfeld IP-Datagramme Prüfsumme über alle Headerfelder (Version, IHL, ..., Source-, Destination-Adress, ..., Options) jedoch nicht über das Datenfeld

Question 5

Internet-Prüfsumme: Berechnung

Accepted Answer

Berechnung der Internet Checksum 1. Benachbarte Octets (8 Bit-Wörter = Bytes), die in die Checksumme eingehen, werden paarweise zu 16-Bit-Integers zusammengefügt. Bei einer ungeraden Anzahl Octets wird mit einem Null-Octet aufgefüllt.2. Das Checksummenfeld selbst ist mit Nullen gefüllt.3. Die 16 Bit-Einerkomplement-Summe über alle beteiligten 16-Bit-Wörter wird berechnet und deren Einerkomplement in das Checksummenfeld geschrieben.4. Um die Checksumme zu überprüfen, wird die 16-Bit Einerkomplement- Summe über dieselben Octets berechnet. Wenn alle Stellen des Ergebnisses 1 sind (111 . . . 1 = −0, s. u.), ist der Check erfolgreich. Unabhängigkeit von der Byte-Reihenfolge,ParallelisierbarkeitAnpassen an Änderungen ohne totale Neuberechnung

Question 6

Internet-Prüfsumme: Teilaspekte

Accepted Answer

Optionale Checksummenberechnung für UDPWie codiert UDP, dass eine Checksumme nicht berechnet worden ist?Wenn keine Checksumme berechnet worden ist, wird als Checksumme 000 . . . 0 übertragen. Falls die errechnete Checksumme 000 . . . 0 ist, wird das Checksummenfeld auf 1111 . . . 1 gesetzt. Beide werden bedeuten im Einerkomplement 0 bzw. −0. Neuberechnung der IP-Datagramm-Checksumme an jedem Hop?An jedem Hop wird die Time-to-Live eines IP-Datagramms dekrementiert. Damit verändert sich auch die Checksumme. Muss diese an jedem Hop neu berechnet werden?Nein. Wegen der Assoziativität und der Invertierung genügt es, den Wert, um den die TTL verringert wurde, zu addieren:C0 = C + (−m) + m0 = C + (m0 − m)wobei C alte, C0 neue Checksumme, m alte und m0 neue TTL.

Question 7

rdt1.0

Accepted Answer

Zuverlässiger Basisdienst Einfaches Weitergeben genügt Wenn Basisdienst schon zuverlässig ist: Verfälschungsfrei Verlustfrei Phantomfrei Duplikatfrei Vertauschungsfrei

Question 8

rdt2.0

Accepted Answer

Basisdienst nicht verfälschungsfrei (Bitfehler) Fehlerbehandlung allgemein: 1. Erkennen 2. Beheben Verfälschungsbehandlung: A) ARQ (Automatic Repeat Request) Verfahren Fehlererkennung: Fehlererkennender Code Fehlerbehebung: Wiederholung, eingeleitet durch Rückmeldungen B) FEC (Forward Error Correction) Verfahren Fehlerkorrigierender Code ARQ Stop and Wait - Protokoll: 1. Sende Nachricht 2. Warte auf Quittung (ACK/NAK) Weiter bei 1. Entscheidender Mangel von rdt2.0: Was passiert, wenn ACK/NAK fehlerhaft? Sender weiß nicht, was empfangen wurde Neusenden nicht möglich, wegen evtl. Doppelübertragung Lösung des Problems? Paket erneut senden, falls ACK/NAK beschädigt Evlt. Doppelübertragungen korrekt empfangener Pakete Behandlung von Doppelübertragungen? Sender nummeriert Pakete (Sequenznummern)

Question 9

rdt2.1

Accepted Answer

Sequenzzahlen (0...1) Bewertung von rdt2.1 Sender Fügt Sequenznummer zu jedem Paket hinzu Muss jedes empfangene ACK/NAK auf Korrektheit überprüfen Hat die doppelte Anzahl von Zuständen Empfänger Muss Pakete auf doppelte Übertragung untersuchen Weiß nicht, ob der Sender das ACK/NAK empfangen hat

Question 10

rdt2.2

Accepted Answer

Nur positive Quittungen, keine NAKs Funktionalität wie rdt2.1, ohne NAKs zu nutzen Statt eines NAKs, sendet der Empfänger ein ACK für das letzte fehlerfrei empfangene Paket Auf doppelte ACKs reagiert der Sender wie auf NAKs: Erneutes Senden des aktuellen Pakets

Question 11

rdt3.0

Accepted Answer

Basisdienst, auch verlustbehaftet Neue Annahme Der zugrundeliegende Kanal kann Pakete (Daten oder ACKs) verlieren. Wie wird mit Verlusten umgegangen? Sender wartet, bis er sicher ist, dass Daten oder ACK verloren sind und sendet Paket erneut. Wie lange muss er warten, bis er sicher sein kann? Sender wartet nur eine festgelegte Zeit auf ein ACK -> Timer starten Erneutes Senden, wenn bis Timeralarm kein ACK empfangen wurde Wenn ein Paket oder ACK nicht verloren waren, sondern nur verzögert, so wird das Paket doppelt gesendet -> dies wird wegen der Sequenznummer erkannt Sequenznummer muss auch im ACK angegeben werden Bewertung: rdt3.0 bietet die angestrebte Funktionalität (zuverlässigke Übertragung über ein zuverlässiges Medium) Die Leistung ist grauenvoll (vorhandene Ressourcen werden nicht genutzt!)

Question 12

Pipeline-Protokolle

Accepted Answer

Neues Paket schon senden, bevor ACK eingetroffe ist. Aber nicht beliebig viele, da Pakete gespeichert werden müssen. Umfang der Sequenznummern erhöhen. Sliding-Window Protokolle Sendekredit Summenquittung Wiederkehrende Laufnummern Go back n Protokoll K-bit Sequenznummern im Paket-Header (Adressarithmetik modulo 2^K) Fenster von bis zu N nicht bestätigten Paketen ACK für Paket n bestätigt alle Pakete, die bis zu Paket n gesendet wurden (Sammel-ACK, Cumulative-ACK) Ein Timer läuft jeweils für das älteste nicht bestätigte Paket, bei Eintreffen eines ACKs wird Timer neu gestartet (sofern noch nicht alle ACKs eingetroffen) Bei Timerablauf Wiederholung aller noch nicht bestätigten Pakete. ACK für das korrekt empfangene Paket mit der größtenSequenznummer Empfang von Paketen in falscher Reihenfolge:Wegwerfen, ACK für Paket mit größter Sequenznummer, das inrichtiger Reihenfolge empfangen wurde, senden Selective Repeat Empfänger bestätigt jedes korrekt empfangene Paket, deren Sequenznummern im Fenster liegen puffert Pakete, die in falscher Reihenfolge empfangen wurden ignoriert andere Pakete liefert Pakete aus, die in richtiger Reihenfolge empfangen wurden Sender sendet nur unbestätigte Pakete erneut setzt einen Time für jedes Paket sendet Paket, wenn nächste Sequenznummer im Fenster liegt sendet bei Timeout Paket nochmals und startet Timer neu markiert bestätigte Pakete verschiebt das Fenster, wenn Paket mit kleinster Sequenznummer bestätigt wird Sende-Fenster besteht aus N konsekutiven Sequenznummern begrenzt die Anzahl gesendeter unbestätigter Pakete

Question 13

Mechanismen zur Unterstützung zuverlässiger Übertragungen

Accepted Answer

Prüfsummen Fehlererkennung Timer Verluste, aber doppelte Übertragungen möglich Sequenznummern Lücken im Paketstrom und doppelte Übertragungen können erkannt werden ACKs Bestätigung des korrekten Empfangs unter Nutzung der Sequenznummern. Auch kumulativ möglich. NAKs Empfänger teilt Sender mit, dass bestimmtes Paket nicht korrekt empfangen wurde. Alternative ausbleibendes ACK + Timeout Fenster, Pipelining Effizienzsteigerung und Flusskontrolle

Question 14

Verbindungsorientierter Transport im Internet: TCP

Accepted Answer

Zieldienst Zuverlässiger Duplex-Bytestrom-Transfer Basisdienst Internet - Unzuverlässiger Transfer von IP-Paketen -> Protokollmechanismen zur zuverlässigen Übertragung a la rdt3.0 Verbindungsverwaltung: Aufbau über 3-Wege-Handshake, Abbau über close je Richtung Voll-Duplex und Piggy-Backing Stau- und Flusskontrolle

Question 15

TCP: Time Out Wert und RTT-Schätzung

Accepted Answer

Wie setzte TCP den Timeout-Wert? Zu klein -> unnötige Wiederholungen Zu groß -> unnötiges Warten, langsame Reaktion Der Wert muss größer RTT sein, aber nicht wesentlich größer! (RTT ändert sich jedoch) Wie kann RTT geschätzt werden? SampleRTT: Zeitspanne vom Absenden eines Segments bis zum Empfang des ACKs (ohne Berücksichtigung von Wiederholungen) SampleRTT: ändert sich bei jedem Paket. Besser (gewichteter) Durchschnitt über die letzten RTTs (moving average) Berechnung: Die Timeout-Zeitkonstante soll an Hand der Round Trip Time festgelegt werden: tto= RTT+Sicherheitsabstand RTT-Schätzung: EstimatedRTT := (1 − α) * EstimatedRTT + α * SampleRTT• Exponential weighted moving average: Einfluß alter Messungen fällt exponentiell• typischer Wert: α = 0.125

Question 16

TCP: Verbindungsverwaltung

Accepted Answer

Schließen einer Verbindung via Socket.close() bei Client und Server Schritt 1 Client ruft Socket.close(), dies sendet TCP FIN-Kontrollsegment an Server Schritt 2 Server empfängt FIN, sendet ein ACK Server ruft Socket.close(), dies sendet TCP FIN-Kontrollsegment Schritt 3 Client empfängt FIN, antwortet ACK. Geht in den Zustand "Time Wait" Schritt 4 Server empfängt ACK. Verbindung beendet. Mit kleinen Änderungen können simultane ACKs verarbeitet werden.

Question 17

Überlastkontrolle und Flusskontrolle

Accepted Answer

Überlastkontrolle und Flusskontrolle sind zwei verschiedene Dinge! Flusskontrolle regelt die Senderate. Überlastkontrolle verhindert Stauverhalten. Überlastkontrolle verwendet Flusskontrolle: Messen der momentanen Belastung Berechnen des möglichen Flusses Entsprechendes Drosseln des Flusses Iteration

Question 18

Überlastkontrolle - Ansätze

Accepted Answer

Ende-zu-Ende Überlastkontrolle Keine explizite Ünterstützung durch die Vermittlungsschicht Überlastkontrolle wird durch Paketverlust und -verzögerung festgestellt und kann die Eingangsrate drosseln (d.h. Fenstergröße verkleinern) TCP muss diesen Ansatz verfolgen Überlastkontrolle im Netz (z.B. im ATM) Komponente der Vermittlungsschicht (Router) geben dem Sender explizit Feedback über Überlastzustände z.B. DECnet, TCP/IP ECN, ATM ABR Sender bekommt eine explizite Senderate zugeteilt AnmerkungStaukontrolle bedingt generell, dass die Lasterzeugung der einzelnen Teilnehmer mit steigender Gesamtlast exponentiell gedrosselt werden muss.

Question 19

Überlastkontrolle TCP

Accepted Answer

Steuerung der Übertragungsrate durch Anpassung der Sendefenstergröße w = Anzahl übertragener unbestätigter Segmente= LastByteSent – LastByteAcked Es muss geltenw ≤ aktuelle Sendefenstergrößed.h., ein Sender darf nur dann ein neues Paket senden, wenn die Fenstergröße noch nicht erschöpft ist. Die aktuelle Sendefenstergröße wird als Minimum aus 2 Werten bestimmt• Das Receiver-Window RcvWin entspricht dem vom Empfänger aktuell zugeteilten Kredit.• Das Congestion-Window CongWin wird vom Sender entsprechend der Staukontroll-Mechanismen bestimmt. Sendefenstergröße = min ( RcvWin, ConWin)

Question 20

TCP - Fairness

Accepted Answer

Ziel Wenn k TCP-Verbindungen sich eine Leitung mit Kapazität R teilen, die zum Flaschenhals wird, dann sollte jede Verbindung eine Kapazität von ungefähr R/k erhalten. Daher Zwei konkurrierende Verbindungen:• Additive Vergrößerung der Fenstergröße führt zu linearem Wachstum• Multiplikative Verkleinerung reduziert Fenstergröße proportional

Question 21

Fairness: UDP, TCP und vielfache Verbindungen

Accepted Answer

ParaUDP Multimedia-Anwendungen nutzen oft UDP (da sie Ratenreduzierung durch TCP vermeiden) UDP erlaubt es beliebig viele Pakete in das Netz zu Pumpen Damit ist UDP nicht fair, auch nicht gegenüber TCP-Verbindungen im Netz Parallele TCP-Verbindungen Anwendung kann mehrere TCP-Verbindungen gleichzeitig eröffnen (üblich bei Browsern) Bsp.: Kapazität R wird von 9 Verbindungen geteilt Neue Anwendung erhält R/10 bei 1 Verbindung R/2 bei 9 Verbindungen Parallele TCP-Verbindungen sind nicht fair.

RVS (Fach) / RvS3 (Lektion)