Institut für Kommunikationsnetze und Rechnersysteme - Universität ...

– 90 –
• Der Auf- und Abbau von TCP-Verbindungen mit Hilfe von Steuerpaketen sowie die TCP-
Verbindungssteuerung, d. h. die Überwachung des Verbindungsauf- und abbaus durch
Zustandsautomaten auf der Sender- und Empfängerseite, werden nicht modelliert. Dieser
Verzicht ist gerechtfertigt, solange sowohl bei der Modellierung der Anwendungsebene
(siehe Abschnitte 4.2.2.2 und 4.2.2.3) als auch in Bezug auf die Leistungsmetriken (siehe
Abschnitt 4.3.2) die Betrachtung der Datenübertragungsphase im Vordergrund steht.
• Auf die Modellierung von Betriebssystemeigenschaften, wie z. B. eine Beschränkung des
Sendepuffers oder nicht verschwindende Einschreib- und Auslesezeiten bei Sende- und
Empfangspuffern, wird verzichtet, um eine Konzentration auf TCP-Eigenschaften zu
erleichtern. Ein Modell, das solche Eigenschaften berücksichtigt, wurde in [116] entworfen.
• Mechanismen wie Persistence Timer oder Keep-Alive Timer, die nur in speziellen, hier nicht
relevanten Situationen zum Tragen kommen [259], werden im Modell nicht berücksichtigt.
• Zahlreiche Optionen und Erweiterungen, die experimentelle TCP-Implementierungen teilweise
bieten, z. B. die Verwendung von expliziter Überlastanzeige (explicit congestion notification,
ECN) oder von Zeitstempeln zur Messung der Umlaufzeit (round trip time, RTT),
werden im hier eingesetzten TCP-Modell nicht berücksichtigt.
Trotz dieser Einschränkungen stehen bei der Modellierung von TCP noch eine Reihe von
Optionen zur Auswahl, die z. T. einen nicht unerheblichen Einfluss auf die Ergebnisse von Leistungsuntersuchungen
haben.
Modellierung der Flusssteuerung
In Simulationswerkzeugen ist häufig eine paketorientierte TCP-Flusssteuerung implementiert,
d. h. es wird angenommen, dass Pakete eine feste Länge entsprechend der maximalen
Segmentgröße (maximum segment size, MSS) haben und jedes Paket durch eine Sequenznummer
gekennzeichnet ist. Demgegenüber arbeitet die Flusssteuerung in realen Implementierungen
byteorientiert, wodurch Paketlängen auch kleiner als
nicht unbedingt Vielfache von
Modell.
L MSS
L MSS
L MSS
sein können und Fenstergrößen
sein müssen. Letzteres gilt auch für das hier verwendete
Überlaststeuerungs-Algorithmen
Um Überlast zu vermeiden oder auf eine Überlastsituation zu reagieren, stehen auf der TCP-
Senderseite Algorithmen bereit, die am Beginn der Übertragung, nach einem Timeout sowie
nach Paketverlusten die Größe des Sendefensters begrenzen. Die Realisierung erfolgt mit Hilfe
des Überlastfensters (congestion window, CWnd), dessen Größe mit
bezeichnet werden
soll. Die Größe des Sendefensters W bestimmt sich aus dem Minimum von und der
W R
Größe des vom Empfänger mitgeteilten Fensters (receiver advertised window, RWnd).
W C
W C