Institut für Kommunikationsnetze und Rechnersysteme - Universität ...
Institut für Kommunikationsnetze und Rechnersysteme - Universität ...
Institut für Kommunikationsnetze und Rechnersysteme - Universität ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
– 122 –<br />
Puffermanagement<br />
elastischer Verkehr Echtzeitverkehr<br />
...<br />
...<br />
Scheduler<br />
Bild 5.2: Lösung mit integriertem Scheduling <strong>und</strong> Puffermanagement<br />
dem TCP-Quellen in Anwesenheit von nicht adaptiven UDP-Strömen ihre Senderate reduzieren,<br />
verhindert werden könnte. Allerdings bedarf es dann zur Festlegung der Aufteilung der<br />
Linkbandbreite (d. h. der Gewichte des FQ-Schedulers) eines Adaptionsmechanismus. Wird<br />
statt dessen Echtzeitverkehr statisch priorisiert, kann das zum völligen „Aushungern“ der elastischen<br />
Verkehrsströme führen. Darüber hinaus hat ein hierarchischer Ansatz gr<strong>und</strong>sätzlich<br />
den Nachteil höherer Komplexität in Bezug auf die Realisierung. Aus diesen Gründen ist es<br />
vorteilhaft, wenn eine Architektur eingesetzt wird, wie sie in Bild 5.2 skizziert ist. Dabei gibt<br />
es nur einen Scheduler <strong>und</strong> ein gemeinsames Puffermanagement <strong>für</strong> alle Klassen. Die Klassen<br />
<strong>für</strong> elastischen Verkehr unterscheiden sich dann von denen <strong>für</strong> Echtzeitverkehr nur durch<br />
andere Werte <strong>für</strong> die Parameter des gleichen Verfahrens. Allerdings ist es erforderlich, dass –<br />
wie im Bild angedeutet – die beiden Teile, Scheduler <strong>und</strong> Puffermanagement, eng miteinander<br />
kooperieren.<br />
5.3 Weighted Earliest Due Date<br />
Zur Lösung des in den vorigen Abschnitten geschilderten Problems der relativen Differenzierung<br />
wird ein Verfahren vorgeschlagen, das als Weighted Earliest Due Date (WEDD) bezeichnet<br />
wird. Die Gr<strong>und</strong>züge von WEDD wurden vom Autor erstmals in [30] im Zusammenhang<br />
mit der Differenzierung von Echtzeitverkehr präsentiert. Dieser Anwendungsfall entspricht<br />
dem Szenario nach Bild 5.1, wobei durch WEDD der rechte Teil der dort skizzierten Architektur<br />
abgedeckt wird. Im Rahmen dieser Arbeit kommt WEDD als integriertes Scheduling- <strong>und</strong><br />
Puffermanagement-Verfahren entsprechend Bild 5.2 zur Anwendung, d. h. es wird auch zur<br />
Differenzierung von elastischem Verkehr eingesetzt.<br />
5.3.1 Gr<strong>und</strong>sätzliches Verhalten<br />
Wie der Name andeutet, kann WEDD als eine Erweiterung der in Abschnitt 3.2.1.1 beschriebenen<br />
EDD-Strategie angesehen werden. Genau wie bei EDD kann jeder Dienstgüteklasse<br />
eine bestimmte maximale Verzögerung<br />
δ i<br />
zugeordnet werden. Während allerdings im Fall von
Change language