QoS - wie in der FBF realisiert?

[mode]

Hallo,

Es gibt ja mehrere Moeglichkeiten ein QoS / eine Paketpriorisierung zu realisieren. Wie macht die FBF das?
Mir sind 2 Moeglichkeiten bekannt.
A) Die Box verwirft einfach wenn sie QoS macht nicht priorisierte Pakete und zwingt damit die Gegenseite diese neu zu senden und somit auch langsamer zu senden.
B) Das ToS Byte. Genauer gesagt der DSCP Bereich dessen.

Oder ist es so das beide moeglichkeiten gemeinsam genutzt werden? A um die "kleine DSL Leitung" frei zu halten und B damit das VoIP Signal auf seinem Weg durch das Internet nicht in den Stau geraet?

Noch eine Frage, wenn das QoS doch so gut funktioniert, warum dann UDP? Dann wuerde doch eine TCP Verbindung nicht viel langsamer sein und es wuerden keine Pakete verloren gehen. Auf der anderen Seite - wenn ein Paket erstmal neu gesendet werden muss, dann ist es in der Regel eh schon zu spaet da der Empfaenger es nicht mehr auswerten wird, da schon nachfolgende Pakete behandelt wurden um die Latenz klein zu halten.

Freue mich auf alle Tips zu dem Thema - ich halte die Tage darueber einen Vortrag


Gruss

Mode

 

[DirkKn]

Dann wuerde doch eine TCP Verbindung nicht viel langsamer sein

Natürlich, denn Du musst die Pakete ja erst bestätigen, bevor die Kommunikation weitergeht und dann tust du dir mit einem kontinuierlichen Datenstrom schon schwer. Die wenigen verlorenen Pakete sind bei VoIP ja nicht wichtig.

 

[Novize]

Die Box geht hin und schaut im Sendestack, welche Pakete da drin sind und sendet die die Pakete mit Priorität "3" als erstes. Wenn dann noch Zeit ist, werden die Pakete mit Priorität "2" gesendet. danach Priorität "2" danach "0". Wie schnell das von statten geht, hängt natürlich von Deinem Upload zusammen.
Weiterhin schaue mal in die Ar7.cfg:
Priorität "3" haben dort VoIP-pakete
Priorität "2" haben die Ack-Packete
Priorität "1" haben http-Requests, ICPM und DNS-Abfragen
Priorität "0" hat der ganze Rest
Siehe Abschnitt out_rules

Hereinkommende Pakete werden nicht priorisiert (alles hat Priorität "0"),
da die Box darauf keinen Einfluss hat. Das müsste der DSL-Provider handlen...

 

[mode]

Eingehende Pakete werden doch druch einen Trick priorisiert, oder? Falls ein VoIP Gespraech beginnt und der Downstream voll ist, beginnt die Box damit empfangene Pakete des Downloads zu verwerfen und dies dem Sender (Provider) mitzuteilen. Daraufhin sendet dieser langsamer so dass Bandbreite frei wird. Anders kann es ja garnicht gehen, sonst wuerde jeder Fullspeed Download ja im Gespraech hoerbar werden.

 

[Novize]

Meines Wissends nach nicht.
Der Download läuft doch sowieso langsamer, als die interne Weiterleitung an die einzelnen PCs. Damit ist das DSL (auch in Download-Richtung) das Nadelöhr. Wenn die Box dann die Pakete verwirft und dies dem Provider mitteilt, dann sendet dieser die Pakete doch noch einmal und damit wird der Download-Kanal noch voller. Und wenn der Provider diese Pakete langsamer neu sendet, dann hilft das auch nichts.
Es läuft so ab, daß auch bei Downloads Ack-Pakete an den Sender zurückgeschickt werden (ist ja TCP, kein UDP), Da diese aber verzögert zurückgesendet werden (vorrang hat ja VoIP), sollte im Normalfall genug Luft auch im Download sein.
Siehe oben oberste Prio hat VoIP, dann Ack, dann http, dann der Rest.
Desweiteren ist ein Fullspeed-Download in einem Gespräch hörbar. Bei einem mehr, bei anderen weniger.

 

[mode]

Das mit den ACK Paketen die logischerweise spaeter gesendet werden ist natuerlich ein gutes Argument und kann dazu benutzt werden den Downstream frei zu halten.
Ich persoenlich höre beim Telefonieren einen FullSpeed Download mit 1 Thread bei DSL 3000 garnicht. Wenn hingegen ein Download mit vielen Threads laeuft (Esel etc) ist die Box mit ihrer Leistung am Ende und man kann kaum telefonieren.

Gruss

 

[DirkKn]

Wenn hingegen ein Download mit vielen Threads laeuft (Esel etc) ist die Box mit ihrer Leistung am Ende und man kann kaum telefonieren.

Hast Du die Box direkt am Splitter als Modem/Router hängen oder machst Du VoIP über LAN-A?

 

[Novize]

Ich persoenlich höre beim Telefonieren einen FullSpeed Download mit 1 Thread bei DSL 3000 garnicht

Wie gesagt: Bei einem mehr, bei anderen weniger (und bei Dir scheinbar (fast?) garnichts). Sei froh
Wenn Damit Deine Fragen bez. QoS beantwortet snd, dann editiere doch deinen ersten Beitrag ->erweitert und setzte ein [gelöst] vor Deinen Titel.
Die Community wird es Dir danken

 

[mode]

Mache ich auch wenn ich fertig gefragt habe.
Aber noch bin ich nich so weit ;-)

- Wo nach sortiert die FBF die Anfragen in die Prioritaetsstufen? Nach Anwendung, Port oder nach den dafuer vorhandenen Flags im IP Header?
- Werden die DSCP Flags im IP Header denn gesetzt so das die Daten von den weiteren Routern im Internet auch bevorzugt behandelt werden?


Gruss

MOde

 

[Novize]

Die Priorität wird nach den entsprechenden ausgehenden Ports festgelegt. Siehe Dir mal die ar7.cfg an! Da ist es genau aufgelistet.

 

[mode]

In der Tat Portnummern. Doch bei Prio 3 gibt es eine weitere Bedingung:
name = "fon-rtp";
filter = "udp[8] = 0x80 or udp port 5060";
priority = 3;
limiters = "default-out";

Was bedeutet denn udp[8]= 0x80?

Und werden hier die DSCP Flags fuer weitere Router im Internet gesetzt?

Gruss

Mode

 

[Novize]

Sorry, ab hier muss ich passen. da habe ich auch bei AVM noch nichts drüber gelesen :noidea:

 

[kolbem]

udp[8] verweist auf das 9. Byte im UDP Header - und genau da fangen die Nutzdaten an.
Also wird wohl das 1. Byte im RTP Header - zumindest für VoIP der Fritzbox - den Wert 0x80 haben.

Die genaue Zusammensetzung, damit 0x80 rauskommt, kann sich gerne einer selber austüfteln, dafür bin ich jetzt zu müde. http://www.ietf.org/rfc/rfc3550.txt

hier mal das ausschlaggebende Oktet bzw. Byte:

   version (V): 2 bits
      This field identifies the version of RTP.  The version defined by
      this specification is two (2).  (The value 1 is used by the first
      draft version of RTP and the value 0 is used by the protocol
      initially implemented in the "vat" audio tool.)

   padding (P): 1 bit
      If the padding bit is set, the packet contains one or more
      additional padding octets at the end which are not part of the
      payload.  The last octet of the padding contains a count of how
      many padding octets should be ignored, including itself.  Padding
      may be needed by some encryption algorithms with fixed block sizes
      or for carrying several RTP packets in a lower-layer protocol data
      unit.

   extension (X): 1 bit
      If the extension bit is set, the fixed header MUST be followed by
      exactly one header extension, with a format defined in Section
      5.3.1.

   CSRC count (CC): 4 bits
      The CSRC count contains the number of CSRC identifiers that follow
      the fixed header.

//edit:
achja, die Syntax der Regeln entspricht übrigends im Grossen und Ganzen der von Berkley Packet Filter und tcpdump und libpcap