Diskussion:Traffic-Shaping

Fehlende Informationen

Also zunächst mal macht die Telekom gar nichts. Speedports sind (alle?) gebrandete AVM-Geräte. Und AVM selbst hat keine Ahnung und nutzt nur das Shaping im Linuxkernel, genauso wie der Wondershaper. Von dem (sicherlich am meistgenutzten) Shaping im Linuxkernel wird hier überhaupt nichts erwähnt. Dort findet die Hauptarbeit statt. Mir kommt das ebenfalls so vor, als käme hier ein guter Teil der PR-Abteilung von AVM & Co. Ich behaupte hier mal, ein Betrag im Sinne von "Linux kanns - AVM nutzts" entspräche wesentlich mehr den Tatsachen.

Was man noch erwähnen könnte: Wird ein externes Modem verwendet oder ist intern der DSL Chip über z.B. Ethernet angebunden, muß zunächst die Bandbreite softwareseitig begrenzt werden, damit der "Stau" beim Shaper passiert, der damit den Traffic begrenzen kann. Das sind typischerweise ganz wenig, etwa 5%. Diese kann man z.B. beim Wondershaper einstellen.

(nicht signierter Beitrag von 88.68.219.40 (Diskussion) 13:27, 10.10.2011)

tcp window size

Nun ja, tcp window size hat mit dem "traffic shaping", wie es in manchen Modems verwendet wird, nun ueberhaupt nichts zu tun. Insofern ist das Beispiel mit dem download etwas fehl am Platz.
In ADSL ist traffic shaping an zwei Stellen moeglich - auf der ATM Seite (CBR, PCR, usw), und im Internetprotokoll (TOS bits oder diffserv). Letzteres hat nur einen Effekt, wenn das Netzwerk auf Vermittlungsseite die entsprechenden bits auch verarbeitet, was bislang in der Regel nicht der Fall ist.
Uebrigens aendert sich die ping-Zeit praktisch nicht, wenn man die Groesse des TCP Fensters aendert. --68.125.49.171

Doch, für Traffic Shaping ist die Window Size von Bedeutung, denn ihre Anpassung ist ein wesentliches Mittel zur Steuerung des Datenflusses. Es mag sein, dass es ADSL-Modems gibt, die unter Traffic Shaping etwas anderes verstehen; so, wie es im Markt eingeführt ist, kann ich Dir aber nicht zustimmen. Traffic Shaping setzt keine Unterstützung durch zwischen den Kommunikationspartnern liegende Netzwerkkomponenten voraus. Traffic Shaping und QoS sind nicht dasselbe. Ansonsten stimme ich Dir aber zu - der behauptete Sachzusammenhang zwischen Latenz und Erhöhung der Window Size besteht nicht, ohne weitere Bedingungen hinzuzudenken. -- Jant 16:23, 15. Aug 2005 (CEST)

Ich denke nicht, dass das Anwendungsbeispiel gut Thema passt. In der Einleitung steht, dass Traffic Shaping ohne Steuerinformationen der Gegenseite auskommt. Die ACKs, von denen das Sliding-Window abhängt, sind aber doch so eine Steuerinformation und somit passt das Beispiel wohl eher zu Datenflusskontrolle. Letztendlich hängt das wohl davon ab, wie weit man den Begriff fasst. Aber so wie der Artikel im Moment aussieht ist das doch ein Widerspruch oder? --Decay 18:43, 13. Mai 2007 (CEST)

Die TCP-Fenstergröße ist ein reiner Flußkontrollemechanismus der in beiderseitigem! Einvernehmen der Verbindungsendpunkte skaliert wird. Er steuert den Fluß im gemeinsamen Interesse, um ein Übersättigen der Verbindung(en) zu vermeiden. Man kann natürlich generell dabei auch unfair spielen. Zum Shaping würde es erst werden, wenn Das Fenster erzwungen größenbeschränkt wird, und zwar nicht mittelbar durch (andere) Shapingverfahren, sondern umittelbar indem Knoten entlang des Pfades die Parameter aktiv verändern. Merke: Shaping ist das direkte erzwingen von Verkehrsregeln. (nicht signierter Beitrag von 93.205.208.240 (Diskussion) 00:12, 4. Mär. 2017 (CET))

Diverses

Auf der Homepage von cFos gibt es Bilder die angeblich zur freien Verwendung sind, ließen diese sich hier nicht nutzen?

Anmerkung eines Gastes: Englischer Beitrag auf Wikipedia: http://en.wikipedia.org/wiki/Traffic_shaping

Werbung

Die letzten zwei Abschnitte enthalten mMn kaum neutrale Informationen. Ich sehe nicht, dass die cFos Software irgendeine Relevanz hat. Es gibt doch viele solche Software und Hardware, die mit entsprechender Software ausgestattet ist. Daher bin ich für eine Löschung der beiden Abschnitte. -- 84.167.14.203 23:56, 27. Aug. 2009 (CEST)