Re: Ethernet bounding

On Mon, Jan 14, 2002 at 08:47:13AM +0100, Mirko Richter wrote:
> Am Samstag 12 Januar 2002 19:54 schrieb Bernd Walter:
> > On Sat, Jan 12, 2002 at 01:35:26PM +0100, Mirko Richter wrote:
> > > Am Freitag 11 Januar 2002 19:52 schrieb Oliver Fromme:
> > > > Andreano, Marco <hwkanm(at)handwerkskammer-freiburg.de> wrote:
> > Das Spielchen funktioniert nicht Fehlerfrei.
> > Du kannst damit nicht ausschliessen, daß die Packetreihenfolge
> > umsortiert wird.
> > Wenn die Reihenfolge durcheinandergerät kommt das einem Packetverlust
> > gleich.
>
> Der TCP/IP-Stack fängt sowas problemlos ab, insofern das "Durcheinander" im
> Rahmen bleibt. -> Sonst würde ja auch das ganze Internet nicht funktionieren.

Richtig.
Das macht jedoch in jedem Fall Mechanismen wie delayed acks kaputt, sorgt
für effektiv verkleinerte Windows.
Es gibt jede Menge unangenehmer Probleme dadurch.
Schliemstenfalls wird dadurch ein Packetverlust provoziert.

Abgesehen davon gibt es mehr als nur TCP - andere haben auch ihre Probleme
damit.

> Verschiedene Routen bedeuten da ja auch, das sie Pakete in unterschiedlicher
> Reihenfolge eintrudeln, na und, dan werden Sie halt vom empfänger wieder
> richtig "zusammengebastelt".

Im Internet werden Packete auch nicht derart durcheinandergerüttelt wenn
alles richtig konfiguriert ist. Provider mögen stabile Routen.
Das hier denoch einiges im Argen ist kann man deutlich sehen:

        3054107 packets received
                1627983 acks (for 1738841223 bytes)
                37513 duplicate acks
                0 acks for unsent data
                2207143 packets (1989258034 bytes) received in-sequence
                5306 completely duplicate packets (2574141 bytes)
                241 old duplicate packets
                1296 packets with some dup. data (338532 bytes duped)
                51762 out-of-order packets (47593798 bytes)
                1375 packets (1375 bytes) of data after window
                1375 window probes
                47995 window update packets
                90 packets received after close
                363 discarded for bad checksums
                0 discarded for bad header offset fields
                0 discarded because packet too short

> Selbst bei M$ funtioniert das (nach 20 Jahren Ignoranz gegenüber TCP/IP).

Natürlich können die mit Packetverlusten umgehen und natürlich wollen auch
die das derartige Fehler möglichst früh abgefangen werden.

> Bei einem Download von 1GByte großen Dateien von 4 Clients aus gleichzeitig,
> liefen alle 4 Verbindungen mit jeweils 11 MByte/s.

Klar.

> > Reines Round-Robin ist ein Kartenhaus das jederzeit zusammenbrechen kann.
> > Typischerweise bleiben Daten von oder zu einer bestimmten MAC oder IP
> > auf dem gleichen Interface um das Problem in den Griff zu bekommen.
>
> Ist da eben nicht so.

Was nicht gut ist.

> > > Ich habe das schon oft genug mit Linux gemacht. Das funktioniert ganz
> > > gut. Bei einem Squid-Proxy erreichten wir damit locker 30-35 MByte/s
> > > Durchsatz (4x 3c905 im Bonding).
> >
> > Für einen Proxy ist das auch vollkommen OK, weil du genügend Sessions
> > hast.
>
> Das funktioniert auch bei einer einzelnen Verbindung, als wir sowas das erste
> mal gemacht haben, haben wir es auch entsprechend intensiv getestet.
> Wir haben's unter anderem mit FTP probiert:
>
>
> 4x 100Mbit Modem 14,4 kBit
> Server <-------> Switch <-----> Router <--------> Notebook
> 1x 10 Mbit
>
> dort kann man den einzelnen Paketen zusehen, wie sie abwechselnd über die
> einzelnen Links blubbern (hin und auch zurück).

Wenn die Packete gleichlang sind wird selbsverständlich in der Regel
auch das zuerst angefangene zuerst ankommen - Packete müssen aber nicht
immer gleichlang sein.
Mit einem FTP Download kann man das nur bedingt simulieren.
Interessant wird es z.B. dann wenn die Clientanwendung nicht mitkommt
und der Sender recht oft das Receivewindow auffüllt und kleine
Endpackete schickt - Browser sind typische Kandidaten.

> > Was du nicht erwarten kannst ist, daß du z.B. eine einzelne FTP
> > Übertragung mit der Bandbreite aller Interfaces hinbekommst.
>
> klar ein einzelner (Client-)Rechner wird das ja wohl auch kaum hinbekommen.
> Dort bremsen dann ganz andere Sachen, wie HD's, PCI-Bus ... .
>
> Für die Clientrechner ist nun mal (meist) bei 100Mbit Schluß, was IMHO auch
> völlig ausreicht (auch wenn die Hersteller von GE und ATM was anderes
> behaupten).

Genau deshalb macht die Einschränkung auf eine Sessionverteilung auch
keine tragischen Nachteile.

> Auf der Cebit hatte sowas auch mal DLink (so glaube ich) mit 4 DE570TX(je 4x
> 10/100Mbit) also 16x 100MBit gezeigt, und das lief auch da :)
>
> > > Kann mir allerdings nicht vorstellen, warum's nicht gehen sollte.
> > >
> > > > Es gibt Switche, die sowas können, und die natürlich auch
> > > > obszöne Summen Geld kosten.
> > >
> > > Die brauchen dazu halt die entsprechende "Inteligenz" und das kostet nun
> > > mal Geld. Für's Heimnetzwerk also nicht unbedingt zu empfehlen.
> >
> > FEC kann heutzutage eigendlich fast jeder Managebare Switch.
> ^^^^^
> Nicht unbedingt das!
>
> "Port-Truncing" können die meisten.
> ----> Nur ds die Ansätze der Hersteller da wieder mal
> ziemlich verschieden sind :(

FEC erwartet nun wirklich keine Magie vom Hersteller.
Wenn ein Switch Trunking in irgendeiner Art kann, aber kein FEC ist das
für mich ein Grund ein Produkt nicht zu kaufen.
Hersteller die nur proprietären Kram können mag ich nicht, zumal FEC
nun wirklich nichts wildes zu implementieren ist.

> > > > Aber wenn Du sowas _wirklich_ benötigst und das Geld hast,
> > > > kannst Du genausogut eine GigaBit-Ethernetkarte kaufen.
> > > > Ist viel einfacher.
> > >
> > > Geht auch nicht immer.
> >
> > Wenns geht ist es allerdings meist besser, weil 1. ein richtiges
> > Interface ohne die ganzen Nachteile und 2. weil Gbit Interfaces
> > wesentlich besser Optimiert sind.
>
> Und was mache ich, wenn mir 1Gbit nicht mehr reicht?
> (meine Dual-Alpha hat nämlich keine Probleme den Gbit-Link
> "vollzublasen" - aber momentan reichts noch :) )
>
> Dan kann ich entweder:
> 1. einfach 2 (oder mehr) Gbit-Interfaces nehmen
> oder
> 2. warten, bis es 10 Gbit gibt.

Wenn du mit mehr als 2Gbit zwischen 2 Rechnern Daten verschicken willst
solltest du dich fragen ob Ethernet die richtige Wahl ist.
Wenn du mehrere Clients hast ist eine Sessionbasierte Bündelung auch
wieder kein Problem - bei Gbit wirst du ausserdem ohne Session-
verteilung aufgrund der großen Sendebuffer viel schneller mit
Round-Robin auf die Nase fallen.

Out-of-order Behandlung ist nicht mehr als ein Workaround um einen
Netzwerkfehler schneller in den Griff zu bekommen.
Das ist keineswegs eine Entschuldigung das Netzwerkdesign schleifen
zu lassen - In-order ist immer noch am besten.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message