„Explicit Congestion Notification“ – Versionsunterschied
| [gesichtete Version] | [gesichtete Version] |
K →Einzelnachweise: fix iw |
tk k |
||
| Zeile 1: | Zeile 1: | ||
'''Explicit Congestion Notification''' ('''ECN''') ist eine Erweiterung der beiden [[Netzwerkprotokoll]]e [[Internet Protocol]] (IP) und [[Transmission Control Protocol]] (TCP) zur [[Network congestion avoidance|Überlastkontrolle]]. Es wurde im Jahr 2001 als [[Request for Comments]] im Status eines [[Vorgeschlagener Standard|vorgeschlagenen Standards]] veröffentlicht.<ref |
'''Explicit Congestion Notification''' ('''ECN''') ist eine Erweiterung der beiden [[Netzwerkprotokoll]]e [[Internet Protocol]] (IP) und [[Transmission Control Protocol]] (TCP) zur [[Network congestion avoidance|Überlastkontrolle]]. Es wurde im Jahr 2001 als [[Request for Comments]] im Status eines [[Vorgeschlagener Standard|vorgeschlagenen Standards]] veröffentlicht.<ref name="RFC3168" /> Mittels ECN kann ein [[Router]] durch das Setzen eines Bits im [[IP-Header]] eine drohende Überlast mitteilen. Im IP-Header verwendet ECN zwei Bits aus dem ehemaligen [[IP-Header#TOS (Type of Service)|TOS-Byte]]. Im TCP-Header werden zwei Bits aus einem 6-bit breiten Block verwendet, der für zukünftige Verwendung reserviert ist. |
||
Sind alle Router auf dem Weg zwischen Quelle und Senke ECN-fähig, lässt sich mit diesem Verfahren die Anzahl der wegen Überlast verworfenen Pakete reduzieren, indem die Senke die vom Router angezeigte Überlastgefahr der Quelle zurückmeldet, woraufhin diese die Datenrate reduziert. |
Sind alle Router auf dem Weg zwischen Quelle und Senke ECN-fähig, lässt sich mit diesem Verfahren die Anzahl der wegen Überlast verworfenen Pakete reduzieren, indem die Senke die vom Router angezeigte Überlastgefahr der Quelle zurückmeldet, woraufhin diese die Datenrate reduziert. |
||
== Kompatibilität == |
== Kompatibilität == |
||
Wer ECN einsetzt, sollte sich bewusst sein, dass manche Administratoren die geänderte Semantik des TOS-Bytes durch den RFC 3168 im September 2001 noch nicht realisiert haben. Auch gehen Router und [[Firewall]]s selbst namhafter Unternehmen teilweise unvorhersehbar mit den ECN-Bits um. Es besteht daher die Gefahr, dass eine Verbindung mit eingeschaltetem ECN nicht zustande kommt. |
Wer ECN einsetzt, sollte sich bewusst sein, dass manche Administratoren die geänderte Semantik des TOS-Bytes durch den <nowiki>RFC 3168</nowiki><ref name="RFC3168" /> im September 2001 noch nicht realisiert haben. Auch gehen Router und [[Firewall]]s selbst namhafter Unternehmen teilweise unvorhersehbar mit den ECN-Bits um. Es besteht daher die Gefahr, dass eine Verbindung mit eingeschaltetem ECN nicht zustande kommt. |
||
ECN kann nur genutzt werden, wenn beide Hosts ihre Bereitschaft dazu erklären. Das Verfahren verwendet ein ECN-Bit, um (explizit) den Stau anzuzeigen, statt die Pakete vom [[Netzwerk-Scheduler]] mit [[Random early detection|RED-Algorithmus]] nur zu verwerfen. Die sendende Station kann daraufhin ihren Datenstrom bewusst drosseln. Durch die dedizierte Information (ECN-Bit) wird die Leitungsqualität nicht künstlich verschlechtert, wie es bei RED der Fall ist, allerdings beherrschen nicht alle Netzwerkteilnehmer das ECN-Verfahren und verwerfen daher Pakete, die das ECN-Bit gesetzt haben. Da das korrekte Verhalten für den Fall von nicht-ECN-fähigen Komponenten das Ignorieren des ECN-Bits wäre, arbeiten diese Geräte nicht standardkonform. |
ECN kann nur genutzt werden, wenn beide Hosts ihre Bereitschaft dazu erklären. Das Verfahren verwendet ein ECN-Bit, um (explizit) den Stau anzuzeigen, statt die Pakete vom [[Netzwerk-Scheduler]] mit [[Random early detection|RED-Algorithmus]] nur zu verwerfen. Die sendende Station kann daraufhin ihren Datenstrom bewusst drosseln. Durch die dedizierte Information (ECN-Bit) wird die Leitungsqualität nicht künstlich verschlechtert, wie es bei RED der Fall ist, allerdings beherrschen nicht alle Netzwerkteilnehmer das ECN-Verfahren und verwerfen daher Pakete, die das ECN-Bit gesetzt haben. Da das korrekte Verhalten für den Fall von nicht-ECN-fähigen Komponenten das Ignorieren des ECN-Bits wäre, arbeiten diese Geräte nicht standardkonform. |
||
| Zeile 15: | Zeile 15: | ||
== Einzelnachweise == |
== Einzelnachweise == |
||
<references |
<references> |
||
<ref name="RFC3168"> |
|||
{{RFC-Internet |RFC=3168 |Titel=The Addition of Explicit Congestion Notification (ECN) to IP |Datum=2001-09}} |
|||
</ref> |
|||
</references> |
|||
[[Kategorie:Internet Protocol]] |
[[Kategorie:Internet Protocol]] |
||
Aktuelle Version vom 13. Mai 2024, 14:32 Uhr
Explicit Congestion Notification (ECN) ist eine Erweiterung der beiden Netzwerkprotokolle Internet Protocol (IP) und Transmission Control Protocol (TCP) zur Überlastkontrolle. Es wurde im Jahr 2001 als Request for Comments im Status eines vorgeschlagenen Standards veröffentlicht.[1] Mittels ECN kann ein Router durch das Setzen eines Bits im IP-Header eine drohende Überlast mitteilen. Im IP-Header verwendet ECN zwei Bits aus dem ehemaligen TOS-Byte. Im TCP-Header werden zwei Bits aus einem 6-bit breiten Block verwendet, der für zukünftige Verwendung reserviert ist.
Sind alle Router auf dem Weg zwischen Quelle und Senke ECN-fähig, lässt sich mit diesem Verfahren die Anzahl der wegen Überlast verworfenen Pakete reduzieren, indem die Senke die vom Router angezeigte Überlastgefahr der Quelle zurückmeldet, woraufhin diese die Datenrate reduziert.
Kompatibilität
Wer ECN einsetzt, sollte sich bewusst sein, dass manche Administratoren die geänderte Semantik des TOS-Bytes durch den RFC 3168[1] im September 2001 noch nicht realisiert haben. Auch gehen Router und Firewalls selbst namhafter Unternehmen teilweise unvorhersehbar mit den ECN-Bits um. Es besteht daher die Gefahr, dass eine Verbindung mit eingeschaltetem ECN nicht zustande kommt.
ECN kann nur genutzt werden, wenn beide Hosts ihre Bereitschaft dazu erklären. Das Verfahren verwendet ein ECN-Bit, um (explizit) den Stau anzuzeigen, statt die Pakete vom Netzwerk-Scheduler mit RED-Algorithmus nur zu verwerfen. Die sendende Station kann daraufhin ihren Datenstrom bewusst drosseln. Durch die dedizierte Information (ECN-Bit) wird die Leitungsqualität nicht künstlich verschlechtert, wie es bei RED der Fall ist, allerdings beherrschen nicht alle Netzwerkteilnehmer das ECN-Verfahren und verwerfen daher Pakete, die das ECN-Bit gesetzt haben. Da das korrekte Verhalten für den Fall von nicht-ECN-fähigen Komponenten das Ignorieren des ECN-Bits wäre, arbeiten diese Geräte nicht standardkonform.
QUIC
Das Transportprotokoll QUIC führt eine Staukontrolle durch und kann für diesen Zweck die ECN-Markierung aus dem IP-Header als Überlastsignal interpretieren.[2]
Alternative
Ein ähnliches Verfahren ist das DEC-Bit.
