-10

Qualitätsklassen nur für eingehende Pakete verbindungsorientierter Protokolle


Damit z.B. VoIP, IPTV und weitere Services zuverlässig angeboten werden können, ist ein Qualitätsmanagement nötig. Dieses Qualitätsmanegement darf aber nicht dazu führen, dass Wettbewerbsverzerrungen im Internet stattfinden. So dürfen z.B. finanzstarke Serviceprovider schwächeren Konkurrenten nicht einfach die Bandbreite abklemmen können.

Damit dennoch innovative neue Services angeboten werden können, sollen Qualitätsklassen erlaubt werden, allerdings nur für verbindungsorientierte Protokolle wie TCP und dort wiederum nur für eingehende Pakete. In allen anderen Fällen sollen Qualitätsklassen verboten werden.

Begründung: Auch heute ist es so, dass ein gewöhnlicher Nutzer viel mehr Daten aus dem Internet herunterläd, als selber hochläd. Dadurch, dass es nur für die eingehenden Pakete unterschiedliche Qualitätsklassen gibt, ist somit die Qualität der Datenübertragung im Wesentlichen unabhängig vom Serviceanbieter. Somit ist dafür gesorgt, dass es zu keinen allzugroßen Wettbewerbsverzerrungen kommen kann.

Allerdings ist auch eine zuverlässige Nutzung von z.B. VoIP möglich, dort müssten z.B. die Telefonierenden lediglich über ein verbindungsorientiertes Protokoll (z.B. TCP) kommunizieren und jeder sorgt dann bei den eigenen eingehenden Paketen für die gewünschte Qualität.

Die Regelung ist auf verbindungsorientierte Protokolle beschränkt, da bei verbindungslosen Protokollen, der Empfänger nicht steuern kann, welche Pakete ihm zugeschickt werden.

TCP ist ein verbindungsorientiertes Protokoll und auch das am häufigsten momentan eingesetzte (HTTP setzt auf TCP auf). Somit ist die Einschränkung auf verbindungsorientierte Protokolle, wie TCP, nicht wesentlich.


Diskussionen

  • mx880 ist dagegen
    +5

    Ich sehe in dem Vorschlag mehrere Probleme.

    Meiner Meinung nach ist die Vorraussetzung ein "Qualitätsmanagement" sei nötig nicht unbedingt zutreffend. Lediglich die Provider, die sich von solchen Mechanismen Profit versprechen, behaupten dies immer wieder. Den Beweis sind sie bis jetzt aber schuldig geblieben. Wenn es also überhaupt solch ein "Management" geben soll, dann bitte nur auf Grund von klaren Fakten.

    Die Begründung verstehe ich ehrlich gesagt nicht ganz. Ich nehme mal an mit "eingehende Pakete" sind Pakete gemeint, die von einem Anbieter z.B. zu einem DSL-Anschluss geschickt werden. Dabei lässt sich aber wunderbar die Verbindung des Anbieters X gegenüber der des Anbieters Y drosseln. Dadurch hat X gegenüber Y aber einen Marktnachteil, da seine Inhalte länger brauchen bis sie geladen sind. Es ist also egal wo differenziert wird, ob es nun beim Down- oder Upload passiert. Und wenn eben nur nach Kunden bzw. Anbietern differenziert wird, dann werden eben nur Kunden bzw. Anbieter diskriminiert. Diskriminiert wird immer.

    Den letzten Teil, die einschränkung auf TCP sei "nicht wesentlich" und man müsse VoIP "lediglich" über TCP laufen lassen halte ich für schlicht nicht haltbar. Gerade bei wie von den Providern behauptet "ausgereizten" Verbindungen würden die Resends von TCP das Ganze wahrscheinlich so ausbremsen, das VoIP nicht funktionieren würde, egal mit welchem "Management". Deshalb laufen auch VoIP, Internetradio und IPTV in der Regel über UDP.

    • Die Begründung verstehe ich ehrlich gesagt nicht ganz. Ich nehme mal an mit "eingehende Pakete" sind Pakete gemeint, die von einem Anbieter z.B. zu einem DSL-Anschluss geschickt werden. Dabei lässt sich aber wunderbar die Verbindung des Anbieters X gegenüber der des Anbieters Y drosseln.

      Nein, das wäre ja eine Absenderorientierte Priorisierung.

      Den letzten Teil, die einschränkung auf TCP sei "nicht wesentlich" und man müsse VoIP "lediglich" über TCP laufen lassen halte ich für schlicht nicht haltbar. Gerade bei wie von den Providern behauptet "ausgereizten" Verbindungen würden die Resends von TCP das Ganze wahrscheinlich so ausbremsen, das VoIP nicht funktionieren würde, egal mit welchem "Management". Deshalb laufen auch VoIP, Internetradio und IPTV in der Regel über UDP.

      Momentan läuft doch VoIP und IPTV nur deshalb über UDP, weil keine gesicherte Übetragungsrate gewährleistet werden kann und es somit klüger ist verspätete Pakete zu verwerfen. Die Beschränkung auf TCP ist nur deshalb enthalten, weil die Forderung mit UDP nicht möglich ist. Wenn UDP trotzdem geeigneter ist für VoIP etc, dann muss halt auf das Qualitätsmanagement verzichtet werden.

      • Also sollen eingehende Pakete Pakete vom Kunden-Router ins Netz sein?? Das verstehe ich nicht. Sollen dann bei einem verbindungsorientierten Protokoll nur eine Richtung priorisiert werden? Das macht doch keinen Sinn. Wenn man schon eine Transportklasse macht, dann für den gesamten Stream. Der läuft dann innerhalb dieser Verkehrsklasse.

        Bei echtzeitkritischen Anwendungen nimmt man kein TCP, weil es schlichtweg keinen Sinn macht. Warum sollte ich den erhöhten Aufwand treiben und ein Paket retransmitten, wenn es am Ziel sowieso nicht mehr gebraucht wird? Für eine gute Sprachqualität sollte man eine Einweglaufzeit von <= 120ms haben. Wenn ein Paket verloren geht, ist das bei einem Retransmit (ausgehend von üblichen Round Trip Delays und notwendiger Pufferung) nicht machbar. Ein Paket, dass nach 120 ms eintrifft, ist wie Paket Loss zu behandeln. Der wird durch entsprechende Codecs ausgeglichen und natürlich über eine entsprechend hochperformante Verbindung, womit wir wieder bei Qualitäten sind ...

  • VolkerSypli ist dagegen
    +3

    Das macht für mich überhaupt keinen Sinn. Abgesehen davon, dass es Sache des Netzbetreibers ist, wie er seinen Netzzugang dimensioniert/ausgestaltet, werden Qualitätsklassen - um stabile Übertragungsbedingugnen (Datendurchsatz) zu garantieren - nicht auf Protokollebene gesteuert. Wenn der Zugangsanbieter für bestimmte Dienste wie VoIP und IPTV garantierte Performanz haben will, werden die Pakete dieser Anwendungen in den Warteschlangen priorisiert. Bei einem Zugangsnetz über entsprechende Markierung der Pakete mit z.B. P-Bits. Es besteht keine Notwendigkeit eine Paket Inspektion auf die verwendeten Protokolle zu machen. Eine Filterung auf Protokolle und dann ein nachfolgendes Traffic Shaping oder sogar Blockierung macht doch nur Sinn, wenn der Anbieter des Netzzugangs ein bestimmtes Nutzungsprofil (z.B. max. 20% Traffic für Peer-to-Peer) erzwingen will. Hier geht es aber doch darum, dass bei einem Internetzugangsangebot, die Pakete von bestimmten Anwendungen bevorzugt innerhalb der grundsätzlich pro Anschluss bereitgestellten Übertragungskapazität transportiert werden. Und das auch nur, wenn solche Pakete dabei sind. Deswegen dauerhaft auf bestimmte Protokolle zu filtern, da man annimmt, dass diese protokolle nur von den zu bevorzugenden Anendungen benutzt werden, ist kein intelligenter Weg. Das ist erstens unnötig aufwendig und kann zweitens leicht umgangen (Tunnel) werden. Sinnvoll ist doch nur - neben einer intelligenten Priorisierung und Reservierung im Kunden-Router - entsprechenden "Transportkanäle" innerhalb des Netzes vorzusehen. Diese werden über den Vertrag geregelt. Der Kunde kauft bestimmte Transportklassen. Was er darin transportiert (VoIP, IPTV, Peer-to-Peer), das ist seine Sache. Die angesprochenen Wettbewerbsverzerrungen können auftreten, wenn innerhalb des Transportsystems auf Protokollebene gefiltert und bewusst diskriminiert wird.

    (Übrigens, in IP-Netzen kann ein Empfänger egal ob verbindungslos oder verbindungsorientiert nie steuern, welche Pakete ihm zugeschickt werden. Er kann nur beim Empfang filern/blocken.)

  • TAE ist dagegen
    +2

    Es ist ganz einfach zu erklären, warum dieser Vorschlag nicht zu akzeptieren ist. Er zielt darauf ab speziell TCP anders zu behandeln als UDP. Dafür müsste aber der Inhalt der IP-Kommunikation mitgelesen werden. IPSec würde das ganze Konzept wieder zunichte machen. Damit ist der Vorschlag von sich aus schonmal abzulehnen.

    Das Wettbewerbsverzerrungen das große Problem an angeblichen Qualitätsklassen ist, ist schon richtig und bekannt. Was auch gut beachtet wurde, ist, dass häufig der Flaschenhals bei der Verbindung zwischen Anbieter und Kunden inklusive dem Kupfer-DSL-Kabel und nicht im Backbone des Internets liegt.

    Würde allerdings jemand einfach seine Pakete für diese Verbindung "QoS"-marken können, würde dies andere Dienste möglicherweise diskriminieren. Daher sollte ein solches QoS nur vom Kunden ausgehen können. Gleichzeitig könnte dies so eine effiziente Abwehr von DoS-Angriffen ermöglichen.

  • FYI: IP Netze wie das Internet gehören zu den verbindungslosen Netzen mit eher stochastischer Wegeführung. Für QoS bemühen größere Carrier daher die EXP Bits des MPLS, welches bekanntlich dann das verbindungslose IP auf verbindungsorientierten Netzen trägt. Typische Klassen sind "Kurze Verzögerung" (LD), "Sprache" (Voice), "Geringe Verluste" (LL) und natürlich "Netz Management" (NM). Um so überladener der IP-Backbone des Multi Service Carriers ist, um so nötiger sind diese Techniken. Grob: Dicke Leitungen ohne QoS sind besser aber auch teurer, und der Kunde zahlt letztlich die Zeche. Btw. Mir persönlich ist von den wichtigen Carriern nur Sprint als reiner IP Carrier bekannt.

  • peter112007 ist dafür
    0

    Vorschlag: ist ein Qualitätsmanagement nötig -> soll ein Qualitätsmanagement eingeführt werden.

    Ziele könnten sein:

    • Vermeidung von grösseren Wettbewerbsverzerrungen

    • Belohnung/Bevorzugung "sparsamer" Nutzung und Nutzung ohne Umwege

    • Belohnung/Bevorzugung "energiesparender" Nutzung

    • Förderung der Selbstregulation

    • Beteiligung möglichst vieler Nutzergruppen

    ...

Versionen


    1. Sie können einen Vorschlag unterstützen oder ablehnen.

    2. Und ihn in Ihre Beobachtungsliste aufnehmen.

    3. Informationen über den Vorschlag einsehen...

    4. ...Schlagworte für diesen Vorschlag hinzufügen...

    5. ...oder den Vorschlag mit anderen per Facebook, Google+ oder Twitter teilen.

    6. Kommentare können Sie nicht nur bewerten...

    7. ...sondern auch dazu verfasste Antworten einsehen...

    8. ...selbst eine Antwort zu einem Argument schreiben...

    9. ... und neue Argumente einbringen.

    10. Oder aktiv den Vorschlag mitgestalten und Alternativen einbringen.