Das Transmission Control Protocol

Mehr als drei Jahrzehnte nach der Standardisierung durch die Internet Engineering Task Force (IETF) ist das Transmission Control Protocol (TCP) als ein verbindungsorientiertes Transport-- protokoll, das speziell zur Bereitstellung eines zuverlässigen Bytestroms zwischen zwei End-- punkten in einem unzuverlässigen paketvermittelndem Kommunikationsnetzwerk entwickelt wurde, immer noch das am meisten eingesetzte zuverlässige Transportprotokoll im heutigen Internet. Kernpunkte der heutigen TCP--Spezifikation ist TCP’s Fähigkeit die Senderate entspre-- chend der im Netzwerk wahrgenommenen Überlast anzupassen. Mangels eines zuverlässigen expliziten Feedbacks durch das Netzwerk wertet TCP traditionell hierzu den Verlust von Seg-- menten als implizites Anzeichen von Überlast im Netzwerk. Gemäß der Spezifikation besitzt TCP zwei verschiedene Methoden, um den Verlust von Segmenten im Netzwerk feststellen zu kön-- nen. Zum einen baut TCP’s Congestion Control und Loss Recovery auf dem Empfang von Duplica-- te Acknowledgments (DUPACKs) auf, die aus der Sicht des Senders ein Anzeichen dafür sind, dass der Empfänger Segmente aufgrund von Paketverlusten außer der Reihe (out--of--order) emp-- fängt. Nach dem Empfang von drei konsekutiven DUPACKs, überträgt TCP mittels Fast Retrans-- mit das älteste unbestätigte Segment erneut und führt anschließend Fast Recovery zur Reduzie-- rung und schnellen Wiederherstellung der Senderate aus. Zum anderen unterhält TCP einen Retransmission Timer, der neben der Reduzierung der Senderate die erneute Übertragung von Segmenten veranlasst, falls diese nicht vor Ablauf des Retransmission Timer bestätigt werden.

Sowohl für den Fall des Retransmission Timeout (RTO) als auch für den Fall des Fast Retrans-- mit/Fast Recovery gibt es jedoch Situationen, die dazu führen, dass TCP’s Congestion Control und Loss Recovery fälschlicherweise ausgeführt werden können. Zum einen bedeutet dies, dass TCP’s Senderate unnötig reduziert wird, zum anderen, dass Segmente erneut übertragen werden, die bereits korrekt empfangen wurden. Das Problem der Spurious Retransmissions. Während die Problematik eines Spurious Retransmission Timeout, das heißt Spurious Retransmissions, die durch einen fälschlicherweise ausgelaufenen Retransmission Timer verursacht werden, große Aufmerksamkeit innerhalb der IETF erfahren hat, sowohl in Form einer Erkennung durch den Eifel Detection Algorithmus, der Erkennung anhand von Duplicate Selective Acknowledgments (DSACKs) oder dem Forward RTO--Recovery (F--RTO) Algorithmus, als auch in Form einer entspre-- chende Reaktion durch den Eifel Response Algorithmus, ist die Problematik eines Spurious Fast Retransmit/Fast Recovery, das heißt Spurious Retransmissions, die aus einem fälschlicherweise ausgeführten Fast Retransmit/Fast Recovery resultieren, weit weniger oft Gegenstand der Stan-- dardisierung gewesen. Tatsächlich legen jedoch zahlreiche Studien und Messungen zu der Cha-- rakteristika eines Netzwerkpfads im Internet dar, dass es infolge von Packet Reordering zu ei-- nem fälschlicherweise ausgeführten Fast Retransmit/Fast Recovery kommen kann.

Wenngleich ausschließlich bezogen auf die Prävalenz des Reordering im Internet die Resultate der einzelnen Studien durchaus unterschiedlich sind, zeigen sowohl aktive Messungen als auch passive Messungen, dass das Problem des Packet Reordering heutzutage nicht als singuläres oder pathologisches Phänomen ignoriert werden kann. Nicht nur weil die negativen Auswirkun-- gen, die das Reordering auf TCP’s Congestion Control und Loss Recovery hat – die unnötige Übertragungswiederholung durch Fast Retransmit, sowie die unnötige Reduzierung der Sende-- rate durch Fast Recovery – de facto die Anforderung an die darunter liegende Internet-- und Netzzugangsschicht stellt, die Ordnung der empfangenen Pakete zu wahren, ist in vielen Situati-- onen der generelle Grundsatz, Packet Reordering zu vermeiden, eine zusätzliche Bürde, durch die mögliche Potentiale ungenutzt bleiben. Beide, sowohl die Internet-- als auch die Netzzugangs-- schicht würden von einer Transportschicht profitieren, der eine strikte in--order Reihenfolge der Segmente nicht mehr garantiert werden muss, indem die Protokolle der einzelnen Netzwerk-- schichten künftig parallele Techniken intensiver einsetzen werden als bislang.

Bekanntermaßen können, abgesehen vom F--RTO Algorithmus, der lediglich der Erkennung von Spurious Retransmissions dient, die das Resultat eines Spurious RTO sind, die beiden anderen oben genannten Erweiterungen des TCP Loss Recovery, der Eifel Detection Algorithmus und die Erkennung anhand von DSACKs, prinzipiell dazu eingesetzt werden, Packet Reordering anhand dessen primären Symptoms, die Spurious Fast Retransmits, zu erkennen. Eine exklusive Erken-- nung des wahrgenommen Packet Reordering ist jedoch nicht ausreichend, um den negativen Auswirkungen, die das Reordering auf TCP’s Congestion Control und Loss Recovery hat, zu be-- gegnen. Es bedarf einer anschließenden proaktiven oder reaktiven Maßnahme gegenüber dem Reordering, um die negativen Auswirkungen entweder a priori zu verhindern oder a posteriori zu reduzieren. Beides, weder eine proaktive noch eine reaktive Maßnahme, ist jedoch von der IETF in den obigen Dokumenten spezifiziert worden. Andererseits hat die TCP Maintenance and Minor Extensions (TCPM) Arbeitsgruppe der IETF mit TCP--NCR einen Algorithmus vorgestellt, mittels dem Spurious Fast Retransmits ohne additionale Erkennung a priori verhindert werden können. TCP--NCR zeichnet sich zwar durch eine effiziente Vermeidung von Spurious Fast Ret-- ransmits aus, gleichzeitig besitzt der Algorithmus jedoch den entschiedenen Nachteil, dass das standard Congestion Control und Loss Recovery Verhalten permanent geändert wird, gleichgül-- tig ob Packet Reordering im Netzwerk präsent ist oder nicht, so dass insgesamt eine breiter Ein-- satz des Algorithmus im Internet sehr unwahrscheinlich ist.