Selection der ToS/CoS Code points

[VOIP-Freak]

Hallo,

zum Beispiel der Fritzbox Fon läßt die Einstellung des type of service fields z. B. in IP Version 4 zu. Dem Einsatz von DiffServ, dem priorisierenden Routing im Netz der Netze, stehen die Ausrüster der Netzhardware und die ServiceProvider, die das dann bezahlen müssen, noch skeptisch gegenüber.

Dennoch hat man bei einigem Equipment auf der Customer Seite, zum Beispiel auch beim geliebten Windows XP einige Vorsorge getroffen.

Von DiffServ gibt es einige RFCs (request for comments) der IETF (internet engineering task force). Die Strategie die dahinter steckt ist, man teilt zunächst den grossen Batzen an Bits in verschiedene Tubes oder Rows ein. So wie man sich zum Beispiel anstellt, bei der Essensausgabe von verschiedenen Menüs. Innerhalb der Qeue vergibt man weitere Prioritäten. Das bedeutet, wenn die Qeue vollläuft beginnt man gezielt, nach den "niederwertigsten" Paketen zu suchen und löscht diese zuerst. Sagen wir mal, "Wenn zum Beispiel der Koch keine Vorräte mehr hat, um für alle nachzukochen."

Das ToS field umfasst 4 Stellen und läßt somit 32 Values zu. Eine immense Vielzahl an Kodierungsmöglichkeiten. Die ICANN, dass ist eine "Behörde" in den Staates, die einige Dinge im Internet verwaltet, "sieht vor", dass das TOS Value 0010 (dezimal 2) für maximized reliability und 1000 für minimized delay steht.

Also was spricht dagegen, 0010 für die SIP Signalisierung und 1000 für die rtp-Sprachdaten zu verwenden?:noidea:

Andere Vorschläge?

Einen schönen Tag

 

[VOIP-Freak]

Selection der ToS/CoS Code points [update]

Hallo,

mal auch auf die Gefahr hin, dass ich hier Selbstgespräche führe.

Zusatz:
Die Päckchen mit dem ToS 0010 also die, die die Signalisierung insich tragen, dürfen erst als letztes gelöscht werden.

Die Pakete mit dem ToS field 1000 müssten beim Schlange stehen immer als erstes wieder "ausgespeichert" werden, also vor gelassen werden.

Conculsion in einer Routerumgebung :
Im Überlastscenario bei Bandbreitenengpässen könnte man eine maximale Anzahl, wenn auch lausige Verbindungen aufbauen. Wenn der User dann aber mit der Qualität nicht zufrieden ist, wird er vermutlich auflegen und sich die Situation von selbst normalisieren. Bis es dann soweit ist, könnte man mit einer reinvite den Ressourcenhunger der Sprachcodecs z. B. über die Reihenfolge G.711 -->G.726 -->G.728 -->G.729 -->G.723.X begrenzen. So etwas habe ich allerdings in der Praksis noch nicht gesehen. Dieses dynamische Verhalten kann die Box vermutlich nicht.

Im Normalobetrieb besteht der hauptsächliche Vorteil, ein minimales Delay für die Voicepakete zu erreichen.

In diesem Sinne - einen schönen Tag
VoIP-Freak