RFC 4638-ausgehandelte MRU hat keinen Effekt

Die Telekom hat, so weit ich weiss mal angestrebt Baby Jumbo Frames einzusetzen, das ganze dann aber abgeblasen, unklar warum und in welchem Zustand die Implementierung ist.

Allerdings muss halt auch O2 mitspielen, da Deine PPPoE Verbindung an deren PPPoE-Servern terminiert wird…

Die 1522 Byte Ethernetframegroesse allerdings ist kein Zeichen fuer RFC 4638, sondern schlicht die L2 Ethernetframegroesse mit 802.1Q VLAN tag (Wikipedia hat eine Graphik). Wenn MRU 1500 tatsaechlich funktioniert, dann ware die tatsaechliche Framegrosse mit VLAN Tag bei 1530 Octets... 

Danke für die beiden hilfreichen Antworten! Stimmt, 1522 Bytes Framegröße mit VLAN bedeutet MRU 1492. Und die Formulierung “ausschließlich das Protokoll PPPoE gemäß RFC 2516” kann man tatsächlich so verstehen, dass auch keine Erweiterungen wie RFC 4638 unterstützt werden. Der erklärte Hintergrund mit der geplanten, aber abgebrochenen Einführung von RFC 4638 bei der Telekom erklärt auch die PPP-Max-Payload-Tags.

Also muss man sich bei Telekom-DSL wohl mit der geringfügig kleineren MRU von 1492 abfinden. Schade, dabei gibt es auch Anbieter im Ausland, die es geschafft haben, RFC 4638 anzubieten.

Ja, wobei ich immer noch hoffe, dass PPPoE irgendwann ganz abgeschafft wird, das ist relativ aufwendig fuer einen Router und letztlich unnoetige Arbeit. Allerdings ist das Reseller-Model der Telekom komplett auf PPPoE zugeschnitten, so dass ich realistisch davon ausgehe, dass PPPoE noch lange bei uns bleiben wird….

Hallo @lukas19 ,

es freut mich dass wir deine Frage hier beantworten konnten und dies dir hoffentlich weitergeholfen hat. Wenn du in Zukunft ein Anliegen oder wieder ein Fragezeichen hast, dann melde dich gerne wieder bei uns.

Schöne Grüße, Sven

Ich kann die Beobachtungen von Lukas19 vollumfänglich bestätigen. Die PPPoE Verbindung legt ein Verhalten an den Tag, das konform zu RFC 4638 Abschnitt 3 ist:

An optional PPPoE tag, "PPP-Max-Payload", allows a PPPoE client to override this default behavior by providing a maximum size for the PPP payload it can support in both the sending and receiving directions.  When such a tag is received by the PPPoE server, the server MAY allow the negotiation of an MRU larger than 1492 and the use of an MTU larger than 1492…

Das ist auch genau das, was bei der initialen Aushandlung des Links geschieht:

Dec 25 05:00:04 egw ppp[1053]: [link0] PPPoE: Set PPP-Max-Payload to '1500'
Dec 25 05:00:04 egw ppp[1053]: [link0] PPPoE: Connecting to ''
Dec 25 05:00:04 egw ppp[1053]: PPPoE: rec'd ACNAME "STGxxx"
Dec 25 05:00:04 egw ppp[1053]: [link0] PPPoE: rec'd PPP-Max-Payload '1500'
Dec 25 05:00:04 egw ppp[1053]: [link0] PPPoE: connection successful

===> MRU größer 1492 darf ausgehandelt werden

Dec 25 05:00:04 egw ppp[1053]: [link0] Link: UP event
Dec 25 05:00:04 egw ppp[1053]: [link0] LCP: Up event
Dec 25 05:00:04 egw ppp[1053]: [link0] LCP: state change Starting --> Req-Sent
Dec 25 05:00:04 egw ppp[1053]: [link0] LCP: SendConfigReq #177
Dec 25 05:00:04 egw ppp[1053]: [link0]   PROTOCOMP
Dec 25 05:00:04 egw ppp[1053]: [link0]   MRU 1500
Dec 25 05:00:04 egw ppp[1053]: [link0]   MAGICNUM 0x6490ce53
Dec 25 05:00:04 egw ppp[1053]: [link0] LCP: rec'd Configure Request #128 (Req-Sent)
Dec 25 05:00:04 egw ppp[1053]: [link0]   MRU 1492
Dec 25 05:00:04 egw ppp[1053]: [link0]   AUTHPROTO PAP
Dec 25 05:00:04 egw ppp[1053]: [link0]   MAGICNUM 0x17c119d4
Dec 25 05:00:04 egw ppp[1053]: [link0] LCP: SendConfigAck #128
Dec 25 05:00:04 egw ppp[1053]: [link0]   MRU 1492
Dec 25 05:00:04 egw ppp[1053]: [link0]   AUTHPROTO PAP
Dec 25 05:00:04 egw ppp[1053]: [link0]   MAGICNUM 0x17c119d4
Dec 25 05:00:04 egw ppp[1053]: [link0] LCP: state change Req-Sent --> Ack-Sent
Dec 25 05:00:04 egw ppp[1053]: [link0] LCP: rec'd Configure Ack #177 (Ack-Sent)
Dec 25 05:00:04 egw ppp[1053]: [link0]   PROTOCOMP
Dec 25 05:00:04 egw ppp[1053]: [link0]   MRU 1500
Dec 25 05:00:04 egw ppp[1053]: [link0]   MAGICNUM 0x6490ce53

===> MRU von 1500 wurde ausgehandelt

Dec 25 05:00:04 egw ppp[1053]: [link0] LCP: state change Ack-Sent --> Opened
Dec 25 05:00:04 egw ppp[1053]: [link0] LCP: auth: peer wants PAP, I want nothing

Es können über diesen Link Pakete mit einer PPPoE Payload von 1500 versendet werden. Bei Verwendung von IPv4 echo request / reply Paketen ist die maximale Nutzlast für ein ICMP Paket bei 1500 bytes abzüglich des IP Headers von 20 Bytes und des ICMP Headers von 8 Bytes gleich 1472 Bytes.

Ping von einer Maschine mit DSL Anbindung (FreeBSD), ICMP Paket mit Do-not-fragment Bit und einer ICMP echo-request Payload von 1472 Bytes zu einem Server im Internet:

# ping -Ds 1472 45.136.xx.xx
PING 45.136.xx.xx (45.136.xx.xx): 1472 data bytes
1480 bytes from 45.136.xx.xx: icmp_seq=0 ttl=56 time=11.449 ms
1480 bytes from 45.136.xx.xx: icmp_seq=1 ttl=56 time=11.259 ms
1480 bytes from 45.136.xx.xx: icmp_seq=2 ttl=56 time=11.268 ms

Beobachtung mit tcpdump auf dem Server im Internet:

# tcpdump -penni ens3 host 93.130.yy.yy and icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:50:19.672614 84:03:28:62:58:18 > 06:b8:67:44:52:71, ethertype IPv4 (0x0800), length 1514: 93.130.yy.yy > 45.136.xx.xx: ICMP echo request, id 55839, seq 0, length 1480
22:50:19.672784 06:b8:67:44:52:71 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 1514: 45.136.xx.xx > 93.130.yy.yy: ICMP echo reply, id 55839, seq 0, length 1480

Das ICMP Paket kommt vollständig an. D.h. auf der Upload Seite des Pfades werden tatsächlich PPPoE Pakete mit einer Payload von 1500 Bytes transportiert.

Der Server schickt ein ebenso großes Antwortpaket weg. Das wird allerdings nicht in einem Stück empfangen, sondern wird auf dem Weg fragmentiert. Tcpdump auf dem Client, der den obigen ICMP Request verschickt:

# tcpdump -vvv -penni pppoe0 host 45.136.xx.xx and icmp
tcpdump: listening on pppoe0, link-type NULL (BSD loopback), capture size 262144 bytes
22:50:19.666920 AF IPv4 (2), length 1504: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1500)
    93.130.yy.yy > 45.136.xx.xx: ICMP echo request, id 55839, seq 0, length 1480
22:50:19.678470 AF IPv4 (2), length 1496: (tos 0x0, ttl 56, id 34381, offset 0, flags [+], proto ICMP (1), length 1492)
    45.136.xx.xx > 93.130.yy.yy: ICMP echo reply, id 55839, seq 0, length 1472
22:50:19.678485 AF IPv4 (2), length 32: (tos 0x0, ttl 56, id 34381, offset 1472, flags [none], proto ICMP (1), length 28)
    45.136.xx.xx > 93.130.yy.yy: ip-proto-1

Das ICMP Antwort-Paket wird in zwei Fragmenten erhalten, wobei im zweiten Paket die 8 Bytes geliefert werden, die im ersten Paket abgeschnitten wurden. D.h. auf dem Rückweg (Download Pfad) ist die PPPoE Payload 1492 und nicht 1500.

Es sieht also so aus, als wäre RFC 4638 zwar implementiert worden, aber das Resultat arbeitet nicht wie erwartet. Das ist auf dem Papier kein Problem, weil in der Schnittstellenbeschreibung wird RFC 4638 mit keinem Wort erwähnt, aber die Einschränkung scheint nicht in den Fähigkeiten des Anschlusses begründet zu liegen, sondern in seiner Konfiguration durch den ISP.

Hallo zusammen

@LineNoise vielen Dank für die Mühe und die Aufbereitung. Nutzt du VPN Dienste im großen Stil, oder warum würdest du den MTU Wert gerne größer als 1492 setzen? Einfach nur weil es geht? Außer VPN fällt mir eigentlich kein Grund dafür ein an diesen Standardwerten irgendetwas zu verändern (ich gebe aber auch zu, das ich da augenscheinlich nicht so tief in der Materie stecke wie du und @lukas19)

VG Matze    

Hallo,

@o2_Matze es gibt einen wichtigen Grund, warum eine MTU von 1500 sehr sinnvoll ist. Dazu muss ich etwas ausholen:

1.) Ein IPv4-Paket kann grundsätzlich eine Größe zwischen 68 und 65535 Bytes haben (RFC 791).

2.) IPv4-Pakete werden über verschiedenste physische Netzwerktechnologien übertragen, die ihrerseits eigene Frame- oder Paketgrößen aufweisen können. Ein Ethernet-Frame ist z. B. maximal 1518 Bytes groß, wovon bis zu 1500 Bytes für Daten genutzt werden können. Die Maximum Transfer Unit (MTU) eines Ethernetanschlusses beträgt daher 1500 Bytes. (Ja, es gibt Jumbo Frames, auf die wir später noch kurz eingehen, wenn wir über RFC 4638 gesprochen haben, aber vereinfachend kann man sagen, dass Ethernet immer eine MTU von 1500 Bytes hat.)

3.) Ein IPv4-Paket bis zu einer Größe von 1500 Bytes kann in einem Stück über eine Ethernet-Leitung transportiert werden. Ein IPv4-Paket mit einer Größe von 1510 Bytes müsste jedoch z. B. in zwei Ethernet-Pakete aufgeteilt werden, wobei das erste Paket 1500 Bytes und das zweite die restlichen 10 Bytes sowie einen zusätzlichen IPv4-Header (20 Bytes) aufnimmt. Dieser Vorgang wird als "Fragmentierung" bezeichnet.

4.) Ein Router sitzt zwischen zwei oder mehr Netzen und leitet IPv4-Pakete, die er auf einem Interface empfängt, über ein anderes Interface weiter, das näher am Ziel des Pakets liegt.

5.) Ein Router kann in die Situation kommen, dass er auf der einen Seite ein IPv4-Paket mit einer Größe von 1500 Bytes empfängt, es jedoch über eine Leitung weiterleiten soll, deren MTU z.B. 1492 Bytes statt 1500 Bytes beträgt. Prinzipiell würde der Router das Paket nun fragmentieren und in zwei Teilen in Richtung Empfänger senden.

6.) Fragmentierung wurde bereits vor langer Zeit als unerwünscht erkannt, da sie die CPU in Routern belastet, während einfaches Weiterleiten von Paketen weniger CPU-Leistung erfordert oder bei besonders hohen Anforderungen sogar vollständig in Hardware und unabhängig von der CPU implementiert sein kann. In jedem Fall erhöht die Fragmentierung die Anzahl der zu verarbeitenden Pakete. Auch auf der Empfängerseite sorgt Fragmentierung für Mehraufwand, da Fragmente vom Betriebssystem zusammengesetzt werden müssen, bevor die Daten an höhere Protokollschichten weitergeleitet werden können. Zudem hat jedes Fragment den Overhead eines zusätzlichen IP-Headers von 20 Bytes, was den Gesamtdurchsatz der Leitung reduziert. Um diese Probleme zu beseitigen, wurde die Path MTU Discovery (RFC 1911) entwickelt.

7.) Bei der Path MTU (PMTU) Discovery gemäß RFC 1911 wird im Header jedes vom Host gesendeten IPv4-Pakets das DF-Bit ("Do not Fragment") gesetzt, das alle Router auf dem Weg anweist, das Paket auf keinen Fall zu fragmentieren. Wenn ein Router auf dem Weg feststellt, dass das Paket größer ist als die MTU der Leitung, über die es gesendet werden müsste, fragmentiert der Router das Paket nicht, sondern verwirft es. Stattdessen sendet der Router ein ICMP-"Destination Unreachable"-Paket mit dem Code "fragmentation needed and DF set" an den Absender. Im ICMP-Paket gibt der Router die MTU der Leitung an, über die das Paket aufgrund seiner Größe nicht gesendet werden konnte. Wenn der sendende Host dieses ICMP-Paket erhält, sendet er das Paket und alle nachfolgenden Pakete mit einer Größe, die zur neu erlernten Path MTU passt. Das bedeutet, dass alle weiteren Pakete vom Router ohne Fragmentierung weitergeleitet werden können. Dieser Vorgang kann sich auch mehrfach wiederholen, bis die gelernte PMTU klein genug ist, sodass die Pakete ohne Fragmentierung zwischen Quelle und Ziel übertragen werden können.

8.) Ein Host wählt als anfängliche PMTU die MTU des Interfaces, über das ein Paket versendet wird. Heutzutage ist dies in der Regel ein Ethernet-Interface mit einer MTU von 1500 Bytes. Die anfängliche PMTU beträgt daher 1500 Bytes.

9.) Damit eine andere PMTU gelernt werden kann, ist es entscheidend, dass Router die relevante ICMP-Nachricht senden (was praktisch immer der Fall ist) und der Host die ICMP-Nachricht empfangen kann. Letzteres ist überraschend oft nicht der Fall, da vor dem Host oft eine falsch konfigurierte Firewall steht, die alle ICMP Pakete verwirft. Auch solche, die man wirklich nicht wegwerfen sollte. Dies führt zu einem typischen Fehlerbild: Da kleine Pakete den Pfad zwischen Server und Client passieren können, funktioniert z. B. ein Login via IMAP oder SSH, aber die Verbindung hängt in dem Moment, in dem größere Datenmengen übertragen werden sollen. Bei SSH reicht oft schon das Auflisten eines Verzeichnisses, und bei IMAP genügt der Versuch, eine E-Mail zu lesen. Die Ursache dafür ist nun klar: Der Host sendet IP-Pakete mit gesetztem DF-Bit, die größer sind als die aktuell verfügbare PMTU. Die Router auf dem Weg möchten den Host darüber informieren, aber die ICMP-Pakete werden von einer Firewall verworfen. Der Host erfährt also nichts von dem Problem und sendet weiterhin zu große Pakete, bis die Verbindung in einen Timeout fällt und geschlossen wird.

10.) Die Ethernet-Technologie hat auch die Welt der Weitverkehrsnetze erobert. Das bedeutet, dass ein IPv4-Paket mit <= 1500 Bytes inzwischen zuverlässig fragmentierungsfrei durch das gesamte Internet transportiert werden kann – bis auf eine Ausnahme: PPPoE-Verbindungen. Da PPPoE einen Overhead von 8 Bytes hat, aber wie der Name schon sagt über Ethernet stattfindet, beträgt die effektive MTU einer PPPoE-Verbindung 1492 Bytes.

Nach dieser ausführlichen Einführung können wir also festhalten, dass die PMTU einer Verbindung, die eine PPPoE-Strecke involviert, 1492 Bytes beträgt, während der Rest des Internets (oft fälschlicherweise) davon ausgeht, dass die PMTU mindestens 1500 Bytes beträgt. Aufgrund fehlkonfigurierter Firewalls kann die korrekte PMTU oft nicht zuverlässig gelernt werden, und das Interneterlebnis vieler PPPoE-Nutzer wäre ziemlich bescheiden. Daher gibt es eine Reihe von (unschönen) Workarounds:

1.) DF-Bit ignorieren und trotzdem fragmentieren (habe ich so noch nicht gesehen).

2.) TCP-MSS-Fix (RFC 879). Hierbei wird beim TCP-Handshake auf dem DSL-Router die Maximum Segment Size für beide Richtungen angepasst, sodass die resultierenden TCP-Pakete plus IP-Header immer in die MTU der PPPoE-Verbindung passen. Dies hilft natürlich nur für TCP, nicht für andere Protokolle. Bei VPN-Clients wird oft von Anfang an eine kleinere PMTU angenommen, und die resultierende ineffiziente Bandbreitennutzung wird als notwendiges Übel akzeptiert.

Dieser ganze Aufwand und die einhergehenden Ineffzienzen könnte entfallen, wenn auch PPPoE-Verbindungen eine MTU von 1500 Bytes hätten und ohne Fragmentierung oder funktionierende PMTU Discovery am Internet teilnehmen könnten. Dies ist die Motivation hinter RFC 4638.

(Und hier kommen wir noch kurz zu den Jumbo Frames: Damit PPPoE Pakete mit einer Nutzlast von 1500 Bytes in ein Ethernet Paket passen, müssen die beteiligten Intefaces Jumbo Frames mit einer MTU von mindestens 1508 Bytes erlauben. Das stellt für gewöhnlich kein Problem dar.)

MfG

LineNoise

Dafür ist aber kein RFC4638 erforderlich, da PMTUD bereits erkennt dass eine MTU von 1492 zu verwenden wäre.

Genau, das ist aber eher ein Firewall problem, und kein RFC4638 Problem. Auch hier ist RFC4638 nicht erforderlich, sondern Firewall Regeln, die den benötigten Traffic (ICMP bzw. die für PMTUD erforderlichen ICMP-Types) für PMTUD durchlassen.

Genau, Ethernet hat nach wie vor eine Payload von 1500 Bytes, PPP(oE) erfordert eben die Einkapselung der hierfür nötigen 8 Bytes, was für uns als Kunden dann eben bedeutet, dass wir eine effektive Payload von 1492 Bytes (1500 Bytes Ethernet Payload - 8 Bytes PPPoE) haben. Das ist allerdings dem Infrastrukturbetreiber geschuldet, da dieser nach wie vor auf PPPoE setzt und bisher kein Anzeichen existiert, dass sich etwas daran ändern würde. Das Projekt “TeraStream” wurde scheinbar ja abgebrochen…

Auch ich finde PPPoE sollte in modernen Netzen zugunsten DHCP (z.B.) weichen. Da haben wir aber als Kunde hierzulande aus verschiedenen Gründen wenig Hebel.

Du kanns ins Kabelnetz wechseln, dort wird DHCP verwendet, man erhält dort demnach dann auch eine 1500 Byte Ethernet Payload (gerne korrigieren wenn das nicht korrekt sein sollte). Auch im Ausland migrieren ISPs von PPPoE weg, aber diese ISPs sind hierzulande und vor allem weder bei dir noch bei mir mit eigene Infrastruktur vertreten/verfügbar. Wir haben hier an der Stelle keine Wahl, wir müssen uns mit der Infrastruktur des Infrastrukturbetreiber abfinden, und diese erfordert nun mal PPPoE.

Genau, da sind wir wieder beim Thema Firewall. PMTUD existiert (imho) gerade wegen solchen Konstellationen auf Transport- und Access-ebene wie PPPoE, da man eben nicht davon ausgehen kann, dass das gesamte Internet Fragmentierungsfrei mit eine Payload von 1500 Bytes erreicht.

Dazu ganz uneigennützig ( ;) ) habe  ich zum Thema PMTUD und Fragmented Packet Delivery bereits ein Thread aufgemacht. Aber auch hier, ist das Thema RFC4638 kein “prerequisite”.

> Dafür ist aber kein RFC4638 erforderlich, da PMTUD bereits erkennt dass eine MTU von 1492 zu verwenden wäre.

RFC 4638 ist erforderlich, wenn man eine MTU von 1500 haben will aus den oben genannten Gründen. Gerade und insbesondere weil PMTUD nicht zuverlässig arbeitet. Thema verfehlt.

Etwas haben wollen ist nicht etwas haben müssen.

Wenn PMTUD unzuverlässig arbeitet, liegt es nicht an eine fehlende RFC4638 implementierung, sondern an eine fehlerhafte Firewall Konfiguration. Folglich muss man kein Payload von 1500 Bytes haben, man hätte es aber gerne. Letzteres kann ich wie gesagt auch verstehen.

Ich hätte auch gerne eine Ethernet Payload von 1500, kriege sie aber nicht, solange mein Infrastrukturbetreiber auf dessen Infrastruktur o2 sein Produkt “o2 Home S/M/L/XL/XXL” realisiert PPPoE voraussetzt. Es wurde bereits hier im Thread kommuniziert, dass RFC2516 umgesetzt wird, RFC4638 aber nicht. Auch das wird explizit in der Schnittstellenbeschreibung angegeben.

Ich bleibe aber bei meine Aussage, für korrekt funktionierenden Path MTU Discovery (PMTUD) ist RFC4638 nicht erforderlich.

Ergänzend dazu:

Würde o2 einen Ethernet Payload von 1500 Bytes ermöglichen (wie ist jetzt zweitrangig), würde PMTUD auch nicht Anwendung finden, da bereits der gesamte Path einen Payload von 1500 unterstützt, was ein normalen Ethernet Frame entspricht.

Vor meinem Beitrag ist eine ausführliche Schilderung der Situation: Es ist implementiert, es wird ausgehandelt, es hat nur leider keine Wirkung im Downstream. Im Upstream ist die MTU danach 1500. Vielleicht ein wenig an der Lesekompetenz arbeiten?

Das ist ebenso korrekt wie bedeutungslos für das technische Problem in dieser Diskussion.

Meine Lesekompetenz reicht aus, um daraus den Schluss zu ziehen, dass ich küftig keine technische Diskussion mit dir eingehe (bis ich das wieder irgendwann vergesse).

Man könnte höchstens o2 anrechnen, dass sie bei RFC2516 inkonsistent sind und im Upstream baby jumbo frames erlauben, die eigentlich dann fragmentiert werden sollten. Das natürlich sofern die Aussage zutrifft, dass eben baby jumbo frames im Upstream fragmentierungsfrei weiterleiten/erlauben. Hat jedoch mit PMTUD erstmal aber nichts zu tun.

Eine vertane Lerngelegenheit.

Sie sind nur insofern inkonsistent, dass sie die Aushandlung einer höheren MRU nach RFC 4638 erlauben, dann aber der Anschluss nicht wie erwartet arbeitet. Die korrekte Lösung wäre entweder die Aushandlung nicht anzubieten oder nach der Aushandlung wie erwartet mit einer höheren MRU in beide Richtungen zu arbeiten.

Das ist richtig. Und vollkommen bedeutungslos im Sinne der eigentlichen Diskussion.

IMHO ist das Hauptproblem hier der Vorleister. Die Tekekom bietet das schlicht fuer ihre reseller nicht an, zumindest nicht ueber L3-BSA wie O2 ihn nutzt. Bei L2-BSA kann der Reseller zwishen PPPoE und DHCP waehlen und damit das Problem umschiffen.

Fuer L3-BSA gilt wohl aus Sicht der Telekom (IP-BSA 2016-Vertrag, Anhang A Stand: 23.12.2020, V06 1

LB IP-BSA-Gate, IP-BSA 2016_(2120)_V06-01_AnhA_LB_Gate.docx):

2.5 Rahmenlänge

Die übertragbare PPPoE-Rahmenlänge beträgt maximal 1.500 Byte (gleich PPPoE-MTU 1492 Byte

zuzüglich Header). Die verwendete Maximum Transmission Unit (MTU) für PPPoE ist 1492 Bytes.

 Die Telekom hatte wohl mal mit der Idee geliebaeugelt Baby-Jumboframes zu unterstuetzen, das ganze aber wohl halbfertig wieder eingemottet.

Kann es schaden, RFC4638 im Support-Menu der Fritzbox zu aktivieren, auch wenn es (noch) nicht unterstützt wird, oder kommt es dann zu Performance/Latenz-Problemen? 

Hallo zusammen, 
das ist ja eine muntere Diskussion. 😊
Auch wenn ich nur einen Bruchteil hiervon verstehe. 
Wie sieht es denn mit der Antwort auf renteks Frage aus ? 
Gruß, Solveig