QoS-Paketplaner...was ist das?

Ich mach ja fast jede woche oder jeden monat den rechner platt, d.h alles runter und wieda raus :smiley: ist so ein hobby :smiley:
Bloß jedes mal bei der beim installieren… wundere ich mich wozu ich eigentlich bei einer dfü-verbindung über modem dieses QoS-paketplaner brauche… oder wenn ich im netztwerk bin wo zu ichs dort brauche? ich habe aber angst es zu deinstallieren bevor gar nix mehr geht…
kann mir jemand erklären wozu das ding da ist… und wo man das nur bräuchte?

mit freundlichen Grüßen Arni

Hi,

Bloß jedes mal bei der beim installieren… wundere ich mich
wozu ich eigentlich bei einer dfü-verbindung über modem dieses
QoS-paketplaner brauche

Also, wenn ich mein FreeBSD installiere, ist da nicht von „QoS-Paketplaner“ zu finden, und vom Windows 3.11 her kenn ich den auch nicht. Soll heissen: zukünftig wäre die Angabe des verwendeten Betriebssystems hilfreich.

kann mir jemand erklären wozu das ding da ist… und wo man das
nur bräuchte?

Zufällig weiß ich, daß Windows XP solchen Schmonzes mitbringt - das ist ungefähr das erste, was ich von diesem System wieder deinstalliere.
Der QoS-Paketplaner soll dafür sorgen, daß die Netzwerkverbindung nie ganz dicht gemacht wird, so dass auch, wenn Du z.B. 100 Downloads laufen hast, Du immer noch Webseiten besurfen kannst. Eigentlich totaler Bullshit bei einem Desktop-System - vor allem führt das dazu, daß Du eben nie die volle Bandbreite nutzen kannst.

Fazit: Hau wech den Driss. Du machst nix kaputt, und es fehlt Dir auch nirgends.

Gruß,

Malte.

Danke für die Hilfe. :smile: Sorry das ich nicht dazu geschrieben habe, dass ich Windows Xp Pro benutze :wink: Aber schlaue Exemplare wie du bekommen des auch soo raus :smiley:
Danke… danke auch für die schnelle Antwort :smiley:

Hallo Malte,

Der QoS-Paketplaner soll dafür sorgen, daß die
Netzwerkverbindung nie ganz dicht gemacht wird, so dass auch,
wenn Du z.B. 100 Downloads laufen hast, Du immer noch
Webseiten besurfen kannst. Eigentlich totaler Bullshit bei
einem Desktop-System - vor allem führt das dazu, daß Du eben
nie die volle Bandbreite nutzen kannst.

Hier muss ich dir einmal wiedersprechen !

Der QoS-Paketplaner garantiert auf Anfrage eine minimale Bandbreite für eine bestimmte Verbindung. Dies ist z.B. für VoIP wichtig, damit ein Download dir nicht das Gespräch abklemmt oder wenn man Internet-Radio hören möchte wärend dem Download.
Wenn der QoS-Paketplaner richtig implementiert ist, belegt er keinerlei Bandbreite von sich aus. Zudem ist das auch gar kein Firlefranz welcher von MS erfunden wurde.

Hier etwas Grundlagen:
http://www.e-technik.fh-wiesbaden.de/~gross/MMN4MI/M…

MfG Peter(TOO)

Hi Peter,

Hier muss ich dir einmal wiedersprechen !

Immer gerne!

Der QoS-Paketplaner garantiert auf Anfrage eine minimale
Bandbreite für eine bestimmte Verbindung. Dies ist z.B. für
VoIP wichtig, damit ein Download dir nicht das Gespräch
abklemmt oder wenn man Internet-Radio hören möchte wärend dem
Download.

Also, derlei funktioniert bei mir auch ohne QoS-Paketplaner immer ganz gut - ist das nicht eigentlich ne generische Aufgabe des IP-Stacks, die Bandbreite zu verteilen?

Wenn der QoS-Paketplaner richtig implementiert ist, belegt er
keinerlei Bandbreite von sich aus. Zudem ist das auch gar kein
Firlefranz welcher von MS erfunden wurde.

Der QoS-Paketplaner wurde schon von M$ gefirlefanzt - aber QoS oder Traffic Shaping ist natürlich nichts neues oder gar M$-proprietäres, das ist schon richtig.
Trotzdem halte ich das auf einem Desktop-System für überflüssig - auf Servern oder Routern kann das jedoch mitunter sehr nett sein.

Gruß,

Malte.

Hallo Malte,

Also, derlei funktioniert bei mir auch ohne QoS-Paketplaner
immer ganz gut - ist das nicht eigentlich ne generische
Aufgabe des IP-Stacks, die Bandbreite zu verteilen?

Trotzdem halte ich das auf einem Desktop-System für
überflüssig - auf Servern oder Routern kann das jedoch
mitunter sehr nett sein.

Jain, der IP-Stack kann nur die Bandbreite unter den von ihm verwalteten Ports verteilen, nicht die im Netzwerk selbst.

Ok, ein kleines Beispiel:
Gegeben: Rechner A, B, ein VoIP-Phone und ein Router im gleichen Netzsegment.
Telefoniert wird jetzt vom VoIP-Phone über den Router irgendwohin.
Gleichzeitig machst du ein Backup von Rechner A auf Rechner B.

Wie können nun die IP-Stacks auf Rechner A und B dem IP-Phone bandbreite zusichern und was nützt QoS auf dem Router ?

MfG Peter(TOO)

Hi,

Trotzdem halte ich das auf einem Desktop-System für
überflüssig - auf Servern oder Routern kann das jedoch
mitunter sehr nett sein.

Jain, der IP-Stack kann nur die Bandbreite unter den von ihm
verwalteten Ports verteilen, nicht die im Netzwerk selbst.

Ja, aber damit wird doch der QoS-Paketplaner auf einem Desktopsystem hinfällig, oder nicht?

Ok, ein kleines Beispiel:
Gegeben: Rechner A, B, ein VoIP-Phone und ein Router im
gleichen Netzsegment.

Also drei Komponenten plus Router, ja?

Telefoniert wird jetzt vom VoIP-Phone über den Router
irgendwohin.
Gleichzeitig machst du ein Backup von Rechner A auf Rechner B.

Wie können nun die IP-Stacks auf Rechner A und B dem IP-Phone
bandbreite zusichern und was nützt QoS auf dem Router ?

Rechner A und B bekommen doch vom Telefonat gar nichts mit und umgekehrt. Da IP-Phone macht ne Verbindung zum/über den Router auf und gut is. Das Backup von A und B interessiert da gar nicht - das machen die unter sich aus. Allenfalls auf dem Switch treffen die beiden verbindungen zusammen, aber dafür sind Switches ja non-blocking - also alles kein Problem, nicht?

Gruß,

Malte.

Hi,

'n Abend,

Trotzdem halte ich das auf einem Desktop-System für
überflüssig - auf Servern oder Routern kann das jedoch
mitunter sehr nett sein.

Ich musz Dir leider auch wiedersprechen.

Jain, der IP-Stack kann nur die Bandbreite unter den von ihm
verwalteten Ports verteilen, nicht die im Netzwerk selbst.

Das ist so leider nicht ganz richtig. Der IPstack hat von ports keine Ahnung. Der behandelt Pakete nach FIFO, zumindest default. (Du darfst hier gerne einwerfen, dasz *BSDs das anders machen. Dann werde ich gruen vor Neid.)

Ja, aber damit wird doch der QoS-Paketplaner auf einem
Desktopsystem hinfällig, oder nicht?

NACK.

Ok, ein kleines Beispiel:
Gegeben: Rechner A, B, ein VoIP-Phone und ein Router im
gleichen Netzsegment.

Also drei Komponenten plus Router, ja?

Welcher router kann/macht QoS fuer Kunden?

Telefoniert wird jetzt vom VoIP-Phone über den Router
irgendwohin.
Gleichzeitig machst du ein Backup von Rechner A auf Rechner B.

Wie können nun die IP-Stacks auf Rechner A und B dem IP-Phone
bandbreite zusichern und was nützt QoS auf dem Router ?

Zwischen 4 und 3 siehts so aus: beide applications ballern den IPstack mit Paketen zu. Davon sind ganz viele vom backup und zwischendurch mal ein paar vom Telephon, weil das einfach weniger schickt. Noch anschaulicher wird das mit dem backup und ssh: das backup fuettert den stack mit Paketen voll, irgendwann drueckt user mal eine Taste und der ssh client haengt ganz hinten ein Paket dazu. Bis das durch die queue ist, ist er alt und grau.

Rechner A und B bekommen doch vom Telefonat gar nichts mit und
umgekehrt. Da IP-Phone macht ne Verbindung zum/über den Router
auf und gut is. Das Backup von A und B interessiert da gar
nicht - das machen die unter sich aus. Allenfalls auf dem
Switch treffen die beiden verbindungen zusammen, aber dafür
sind Switches ja non-blocking - also alles kein Problem,
nicht?

Aber beide Verbindungen muessen durch den gleichen Flaschenhals: den IPstack. Und hier kann klassisches QoS helfen: es baut mehrere Flaschenhaelse, parallel. Das routing entscheidet jetzt, in welchen Hals ein Paket kommt. Entscheidungskriterium kann dabei z. B. das TOS-field oder ein MARK aus dem netfilter (o. ae., abhaengig vom OS) sein. Die queuing discipline entscheidet dann, von welchem Flaschenhals wann genommen wird. Ergebnis kann sein, dass die ssh-Pakete sich an den backup-Paketen vorbeimogeln, was fuer interaktive applications wie ssh oder VoIP essentiell ist.

Weitere Infos gibt’s im LARTC (trotzdem das L fuer Baeh-Pfui-Linux steht kannst Du ja vielleicht trotzdem mal reinschauen): http://www.lartc.org/howto/lartc.cookbook.interactiv…
HTH,
Gruss vom Frank.

Moin.

Trotzdem halte ich das auf einem Desktop-System für
überflüssig - auf Servern oder Routern kann das jedoch
mitunter sehr nett sein.

Ich musz Dir leider auch wiedersprechen.

Dürft ihr ja alle sehr gerne, ich hab’s nur immer noch nicht verstanden.

Jain, der IP-Stack kann nur die Bandbreite unter den von ihm
verwalteten Ports verteilen, nicht die im Netzwerk selbst.

Das ist so leider nicht ganz richtig. Der IPstack hat von
ports keine Ahnung. Der behandelt Pakete nach FIFO, zumindest
default. (Du darfst hier gerne einwerfen, dasz *BSDs das
anders machen. Dann werde ich gruen vor Neid.)

Hier widersprichst Du Peter, nicht mir. Wie der BSD-Stack Pakete bearbeitet, muss ich nachsehen.

Ja, aber damit wird doch der QoS-Paketplaner auf einem
Desktopsystem hinfällig, oder nicht?

NACK.

Warüm nischt?

Ok, ein kleines Beispiel:
Gegeben: Rechner A, B, ein VoIP-Phone und ein Router im
gleichen Netzsegment.

Also drei Komponenten plus Router, ja?

Welcher router kann/macht QoS fuer Kunden?

Hä?

Telefoniert wird jetzt vom VoIP-Phone über den Router
irgendwohin.
Gleichzeitig machst du ein Backup von Rechner A auf Rechner B.

Wie können nun die IP-Stacks auf Rechner A und B dem IP-Phone
bandbreite zusichern und was nützt QoS auf dem Router ?

Zwischen 4 und 3 siehts so aus: beide applications ballern den
IPstack mit Paketen zu. Davon sind ganz viele vom backup und
zwischendurch mal ein paar vom Telephon, weil das einfach
weniger schickt. Noch anschaulicher wird das mit dem backup
und ssh: das backup fuettert den stack mit Paketen voll,
irgendwann drueckt user mal eine Taste und der ssh client
haengt ganz hinten ein Paket dazu. Bis das durch die queue
ist, ist er alt und grau.

Ich seh immer noch nicht, wo Backup-Datenfluß und IP-Telephonie-Datenfluß zusammentreffen.

Rechner A und B bekommen doch vom Telefonat gar nichts mit und
umgekehrt. Da IP-Phone macht ne Verbindung zum/über den Router
auf und gut is. Das Backup von A und B interessiert da gar
nicht - das machen die unter sich aus. Allenfalls auf dem
Switch treffen die beiden verbindungen zusammen, aber dafür
sind Switches ja non-blocking - also alles kein Problem,
nicht?

Aber beide Verbindungen muessen durch den gleichen
Flaschenhals: den IPstack.

Durch WESSEN IP-Stack? Rechner A, Rechner B und das IP-Phone sind drei Komponenten mit jjeweils eigenem IP-Stack, richtig?

Und hier kann klassisches QoS
helfen: es baut mehrere Flaschenhaelse, parallel. Das routing
entscheidet jetzt, in welchen Hals ein Paket kommt.
Entscheidungskriterium kann dabei z. B. das TOS-field oder ein
MARK aus dem netfilter (o. ae., abhaengig vom OS) sein. Die
queuing discipline entscheidet dann, von welchem Flaschenhals
wann genommen wird. Ergebnis kann sein, dass die ssh-Pakete
sich an den backup-Paketen vorbeimogeln, was fuer interaktive
applications wie ssh oder VoIP essentiell ist.

Weitere Infos gibt’s im LARTC (trotzdem das L fuer
Baeh-Pfui-Linux steht kannst Du ja vielleicht trotzdem mal
reinschauen):
http://www.lartc.org/howto/lartc.cookbook.interactiv…

Ich schaue gern, hab auch schon mit QoS herumgespielt (damals um die Filesharing-Aktivitäten meiner Ex-Gattin etwas zu beschränken). Den Sinn und Nutzen auf dem Desktop hab ich trotzdem noch nicht verstanden - wie oft kommt das denn beim normalen arbeiten so vor, daß die Leitung wirklich dicht ist und man auf irgendeine interaktive Anwendung wirklich warten muß?

Gruß,

Malte.

Moin.

Mahlzeit,

Das ist so leider nicht ganz richtig. [IPstack, FIFO]

Hier widersprichst Du Peter, nicht mir.

Ich weisz.

Welcher router kann/macht QoS fuer Kunden?

Hä?

Ich weisz nicht, wie mein provider darauf reagiert, wenn ich bei ihm anfrage, dasz er bestimmten traffic von mir bevorzugt weiterleiten soll. Evtl. routetet er mit Hilfe des TOS-fields, aber dasz mueszten die Anwendungen dann auch noch richtig setzen. (Manche tun das sogar: interaktives ssh setzt (IIRC) IPTOS_LOWDELAY, scp IPTOS_THROUGHPUT (-> /usr/include/linux/ip.h o. ae.) Der meiste traffic (eg. dns, smtp, http, nntp… alles mehr oder minder ‚interaktive‘ Anwendungen) wird aber als normal-service ins Internet geschickt.

Wie können nun die IP-Stacks auf Rechner A und B dem IP-Phone
bandbreite zusichern und was nützt QoS auf dem Router ?

Ich weisz nicht genau, wie Peter das Beispiel meinte, aber mir scheint, hier liegt ein Miszverstaendnis vor. Ein IP-Telephon ist natuerlich ein eigenstaendiges Geraet, welches mit dem router verbunden ist. Da macht es natuerlich keinen Sinn, auf einem der hosts zu shapen. Das ist nur sinnvoll, wenn zwei Anwendungen auf einem host sich die volle Bandbreite teilen muessen.

Zwischen 4 und 3 siehts so aus: beide applications ballern den
IPstack mit Paketen zu. Davon sind ganz viele vom backup und
zwischendurch mal ein paar vom Telephon, weil das einfach
weniger schickt. Noch anschaulicher wird das mit dem backup
und ssh: das backup fuettert den stack mit Paketen voll,
irgendwann drueckt user mal eine Taste und der ssh client
haengt ganz hinten ein Paket dazu. Bis das durch die queue
ist, ist er alt und grau.

Ich seh immer noch nicht, wo Backup-Datenfluß und
IP-Telephonie-Datenfluß zusammentreffen.

Ich beziehe mich hier auf zwei Anwendung, die zwischen zwei Rechnern kommunizieren. Z. B. ein filetransfer und eine shell zum/vom anderen Rechner. Da kommen sowohl die Pakete vom Transfer als auch von der shell zusammen in den buffer des ipstacks.

Durch WESSEN IP-Stack? Rechner A, Rechner B und das IP-Phone
sind drei Komponenten mit jjeweils eigenem IP-Stack, richtig?

Vergisz das Phone. Es macht nur Sinn, wenn beider traffic durch einen stack musz

Ich schaue gern, hab auch schon mit QoS herumgespielt (damals
um die Filesharing-Aktivitäten meiner Ex-Gattin etwas zu
beschränken

Soziale Probleme, technische Masznahmen… gut, dasz Du dann doch noch eine soziale Loesung gefunden hast. :wink:

). Den Sinn und Nutzen auf dem Desktop hab ich
trotzdem noch nicht verstanden - wie oft kommt das denn beim
normalen arbeiten so vor, daß die Leitung wirklich dicht ist
und man auf irgendeine interaktive Anwendung wirklich warten
muß?

Staendig: bei jedem upload ohne QoS lahmt die shell zu remote hosts, auf den newsserver musz ich ewig warten, 'ne mail beim server abliefern braucht Geduld. Natuerlich nicht, wenn das alles mit GBit verbunden ist.

Gruss vom Frank.

Hi,

Welcher router kann/macht QoS fuer Kunden?

Hä?

Ich weisz nicht, wie mein provider darauf reagiert, wenn ich
bei ihm anfrage, dasz er bestimmten traffic von mir bevorzugt
weiterleiten soll.

Achso, Du meinst im Heimuser-Umfeld. Okay. In dem Moment, wo da mehr als ein Rechner online geht, gehört das dann schon auf’s Heim-Gateway, nicht? Bleibt also der Fall der standalone-PCs mit Internetanbindung. Hm. Ich hab grad mal auf der BSD-Mailingliste nachgefragt, wie das unter BSD läuft und was die so dazu sagen.

Wie können nun die IP-Stacks auf Rechner A und B dem IP-Phone
bandbreite zusichern und was nützt QoS auf dem Router ?

Das ist nur sinnvoll, wenn zwei
Anwendungen auf einem host sich die volle Bandbreite teilen
muessen.

Okay, zumindest das hab ich richtig im Kopf. Vielleicht meinte Peter auch ein Softphone, das ging aber so nicht klar hervor, und bei „IP Phone“ seh ich erstmal ein Telefon mit Netzwerkbuchse.

Ich seh immer noch nicht, wo Backup-Datenfluß und
IP-Telephonie-Datenfluß zusammentreffen.

Ich beziehe mich hier auf zwei Anwendung, die zwischen zwei
Rechnern kommunizieren. Z. B. ein filetransfer und eine shell
zum/vom anderen Rechner. Da kommen sowohl die Pakete vom
Transfer als auch von der shell zusammen in den buffer des
ipstacks.

Okay. Ich seh die Problematik. Inwiefern kann der QoS-Paketplaner von Windows XP hier helfen? Wie kann man den konfigurieren? Gibt’s da irgendwo Informationen?

Ich schaue gern, hab auch schon mit QoS herumgespielt (damals
um die Filesharing-Aktivitäten meiner Ex-Gattin etwas zu
beschränken

Soziale Probleme, technische Masznahmen… gut, dasz Du dann
doch noch eine soziale Loesung gefunden hast. :wink:

Och, das war zunächst tatsächlich nur ein technisches Problem - soll sie files sharen, wie sie lustig ist. Nur das ich dann nicht mehr surfen konnte hat mich gestört. Im Endeffekt war die soziale Lösung dann aber doch stark indiziert :smile:

). Den Sinn und Nutzen auf dem Desktop hab ich
trotzdem noch nicht verstanden - wie oft kommt das denn beim
normalen arbeiten so vor, daß die Leitung wirklich dicht ist
und man auf irgendeine interaktive Anwendung wirklich warten
muß?

Staendig: bei jedem upload ohne QoS lahmt die shell zu remote
hosts, auf den newsserver musz ich ewig warten, 'ne mail beim
server abliefern braucht Geduld. Natuerlich nicht, wenn das
alles mit GBit verbunden ist.

Machst Du QoS auf Deinem Desktop? Wenn ja, womit macht ihr das unter Linux denn so? Ich kenne unter BSD nur dummynet und altq, die sich beide in die jeweiligen Paketfilter integrieren (dummynet -> ipfw, altq -> ipfilter).

Gruß,

Malte,

Ich weisz nicht, wie mein provider darauf reagiert, wenn ich
bei ihm anfrage, dasz er bestimmten traffic von mir bevorzugt
weiterleiten soll.

Achso, Du meinst im Heimuser-Umfeld.

Wobei die meisten Heim-user irgendwelche SOHO-router haben. Ich kenne da keinen, der QoS kann (YMMV). Auf meinem Dach steht ein WRT54G (AP), der kann auch routen. Im webfrontend ist von QoS nichts zu finden, dank der aufbohrten firmware sind die notwendigen tools aber trotzdem drauf.

Trotzdem ist es natuerlich Quatsch, wenn im Netz die Rechner unabhaengig QoS machen. Ich weisz nicht, ob es sowas wie distributed QoS gibt, dasz sie sich untereinander Bandbreite zuspielen oder so.

Okay. In dem Moment, wo da mehr als ein Rechner online geht,
gehört das dann schon auf’s Heim-Gateway, nicht?

Ja. Wobei das gateway AFAIK keine Moeglichkeit hat, die Reihenfolge zu beinfluszen, wie die Pakete meinen IPstack verlassen. Da der Flaschenhals aber i. A. der uplink ist…

Ich hab grad mal auf der BSD-Mailingliste nachgefragt, wie
das unter BSD läuft und was die so dazu sagen.

Irgendwer hat mal behauptet, *BSD waere ganz toll dokumentiert (SCNR).

Okay, zumindest das hab ich richtig im Kopf. Vielleicht meinte
Peter auch ein Softphone, das ging aber so nicht klar hervor,
und bei „IP Phone“ seh ich erstmal ein Telefon mit
Netzwerkbuchse.

ACK.

Inwiefern kann der QoS-Paketplaner von Windows XP hier
helfen? Wie kann man den konfigurieren?

Weisz nicht. Wenn ich das naechste mal Windows boote schaue ich nach.

Gibt’s da irgendwo Informationen?

Vielleicht hier (oder im Windows-Brett :wink:: http://search.microsoft.com/search/results.aspx?qu=qos

Machst Du QoS auf Deinem Desktop?

Ach, so’n Quatsch. :wink: Tatsaechlich habe ich ein gateway fuer sowas.

Wenn ja, womit macht ihr das unter Linux denn so?

tc + ip + iptables

(dummynet -> ipfw, altq -> ipfilter).

Hier kann man mit iptables (komplexere) Regeln bauen und damit Pakete markieren (nicht wirklich, die Markierung gilt nur im host) und am TOS rumspielen, ip ist ein route auf Steroiden und wirft Pakete in unterschiedliche queues, einerseits zwar nach einfacheren Regeln als iptables, aber gluecklicherweise zusammen mit der Markierung vom iptables und tc (traffic control) manipuliert die queuing disciplines, also wie Pakete aus den einzelnen queues genommen werden.

Ich denke, die *BSDs koennen das aehnlich.

HTH,
Gruss vom Frank.

Hallo Malte,

Rechner A und B bekommen doch vom Telefonat gar nichts mit und
umgekehrt. Da IP-Phone macht ne Verbindung zum/über den Router
auf und gut is. Das Backup von A und B interessiert da gar
nicht - das machen die unter sich aus. Allenfalls auf dem
Switch treffen die beiden verbindungen zusammen, aber dafür
sind Switches ja non-blocking - also alles kein Problem,
nicht?

Wie kommst du darauf, dass ein Switch vorhanden ist ???
Wo ist der Switch in einem W-LAN zu installieren (OK, wer will schon W-LAN, aber trotzdem)??

Wie haben bis jetzt von IP und QoS gesprochen.
Zumindest besteht, nach meinen bisherigen Imformationen, kein zwingender Zusammenhang zwischen (TCP/)IP und der Netzwerk-Technologie/-Topologie.

MfG Peter(TOO)

Hallo Malte,

Rechner A und B bekommen doch vom Telefonat gar nichts mit und
umgekehrt. Da IP-Phone macht ne Verbindung zum/über den Router
auf und gut is. Das Backup von A und B interessiert da gar
nicht - das machen die unter sich aus. Allenfalls auf dem
Switch treffen die beiden verbindungen zusammen, aber dafür
sind Switches ja non-blocking - also alles kein Problem,
nicht?

Wie kommst du darauf, dass ein Switch vorhanden ist ???
Wo ist der Switch in einem W-LAN zu installieren (OK, wer will
schon W-LAN, aber trotzdem)??

Okay, da hast Du Recht. Allerdings gibt es noch nicht sehr lange und nicht sehr viele IP-Phones, die wireless können :wink: Und die „wired“ IP-Phones, die ich kenne, verlangen alle Twisted Pair -> ergo: Hub oder Switch notwendig.

Wie haben bis jetzt von IP und QoS gesprochen.
Zumindest besteht, nach meinen bisherigen Imformationen, kein
zwingender Zusammenhang zwischen (TCP/)IP und der
Netzwerk-Technologie/-Topologie.

Das ist korrekt. „Aber“ siehe oben :smile:

Gruß,

Malte.