Gelöst
UDP RTP massive Paketverluste im Downstream von AWS
vor einem Jahr
Hallo,
ich arbeite seit Jahren für eine US Firma im WebRTC/Videokonferenzbereich als Entwickler. Seit einigen Tagen verzeichnet meine DSL Verbindung massive RTP Paketverluste, z.B. beim Download von RTSP Media von einem in der AWS-Cloud gehotsteten RTSP Server.
Ich habe ein kleines Testprogramm geschrieben, dass die RTP Packet Losses ausgibt und dieses zeigt mir, dass die Packet Losses 100% nur in der Downstream Relation auftreten. Mein DSL Upstream verzeichnet keinen packet loss wenn er bei AWS ankommt.
Das Problem trifft besonders UDP Verbindungen, aber auch TCP Verbindungen scheinen massiv beeinträchtigt (nicht so stark, wie UDP).
Heute habe ich versucht, herauszubekommen, ob meine DSL Verbindung das Problem sein könnte. Aus folgenden Gründen schliesse ich das aus:
- Ich habe einen parallelen Tunnel (tailscale) von meiner Entwicklungsmaschine auf den AWS Server und alles was da durchgeht ist in beiden Richtungen fehlerfrei.
- Das Problem tritt auch in getetherten Verbindungen auf, hier mein iPhone 15 Pro mit Telekom 5G SIM. Hier werden zwar Downstream UDP Verbindungen gar nicht erst zugelassen, aber TCP ist ebenso gestört
- Ich war heute in einem McDonalds Restaurant und habe die Tests dort über den dortigen Telekom Hotspot gefahren. Identische Ergebnisse. UP ok, DOWN fail
- Zusätzlich war ich noch bei REWE (M3? Verifox?). Dasselbe Symptom wie bei tethered Telekom: UDP geht nicht, TCP Downstream gestört.
Ich kann alles belegen und die entsprechende Testapp z.V. stellen.
Ich hätte nur gern meine stabilen Verbindungen zurück. Region ist übrigens Nord-Berlin
PS: Ich vergass zu erwähnen, dass Kollegen in den USA und in Spanien identische Tests gefahren haben und keinerlei Probleme festgestellt haben. Und - das Problem trifft nicht nur eine spezielle EC2 Instanz. Mehrere unter meiner Kontrolle stehende Maschinen zeigen diese Ausfälle, insbesondere in WebRTC Sessions (stark UDP RTP lastig).
554
44
Das könnte Ihnen auch weiterhelfen
vor 6 Jahren
1693
2
2
971
0
2
1107
2
7
vor einem Jahr
Hast Du eine Backup-Leitung über einen anderen Provider zur Verfügung? Solltest Du eineml ausprobieren. Insbesondere, wenn die Kollegen in den anderen Ländern keine Probleme haben. Klingt für mich nach einem Peering Problem der Telekom in Richtung AWS.
6
Antwort
von
vor einem Jahr
Hast Du eine Backup-Leitung über einen anderen Provider zur Verfügung? Solltest Du eineml ausprobieren. Insbesondere, wenn die Kollegen in den anderen Ländern keine Probleme haben. Klingt für mich nach einem Peering Problem der Telekom in Richtung AWS.
Hast Du eine Backup-Leitung über einen anderen Provider zur Verfügung? Solltest Du eineml ausprobieren. Insbesondere, wenn die Kollegen in den anderen Ländern keine Probleme haben. Klingt für mich nach einem Peering Problem der Telekom in Richtung AWS.
Diese Vermutung hat schon ein Freund geäussert, der bei der DTAG arbeitet.
Das mit den "anderen Providern" würde ich gleichsetzen mit "mal bei Mäcces und mal bei REWE" getestet
Ggf. gehen noch einige Bäcker hier mit Free Wifi, wenn das noch weiter eskaliert werden muss.
Antwort
von
vor einem Jahr
Es sollte in dem Fall kein Ungleichgeweicht zwischen UDP und TCP geben und wenn dann sollte eher TCP schlechter sein.
Es sollte in dem Fall kein Ungleichgeweicht zwischen UDP und TCP geben und wenn dann sollte eher TCP schlechter sein.
Sagen wir so: Ich sehe Bildfehler auch mit TCP, aber TCP kann wohl einiges durch Repeats ausregeln. Bei UDP ist der Loss sofort sichtbar im Bild.
Danke für die "Anteilnahme" soweit
Antwort
von
vor einem Jahr
Ggf. bei einem Freund oder Kollegen über Vodafone, EON, Deutsche Glasfer oder ähnlich vergleichend probieren.
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
Aus folgenden Gründen schliesse ich das aus: - Ich habe einen parallelen Tunnel (tailscale) von meiner Entwicklungsmaschine auf den AWS Server und alles was da durchgeht ist in beiden Richtungen fehlerfrei. - Das Problem tritt auch in getetherten Verbindungen auf, hier mein iPhone 15 Pro mit Telekom 5G SIM. Hier werden zwar Downstream UDP Verbindungen gar nicht erst zugelassen, aber TCP ist ebenso gestört - Ich war heute in einem McDonalds Restaurant und habe die Tests dort über den dortigen Telekom Hotspot gefahren. Identische Ergebnisse. UP ok, DOWN fail - Zusätzlich war ich noch bei REWE (M3? Verifox?). Dasselbe Symptom wie bei tethered Telekom: UDP geht nicht, TCP Downstream gestört. Ich kann alles belegen und die entsprechende Testapp z.V. stellen.
Aus folgenden Gründen schliesse ich das aus:
- Ich habe einen parallelen Tunnel (tailscale) von meiner Entwicklungsmaschine auf den AWS Server und alles was da durchgeht ist in beiden Richtungen fehlerfrei.
- Das Problem tritt auch in getetherten Verbindungen auf, hier mein iPhone 15 Pro mit Telekom 5G SIM. Hier werden zwar Downstream UDP Verbindungen gar nicht erst zugelassen, aber TCP ist ebenso gestört
- Ich war heute in einem McDonalds Restaurant und habe die Tests dort über den dortigen Telekom Hotspot gefahren. Identische Ergebnisse. UP ok, DOWN fail
- Zusätzlich war ich noch bei REWE (M3? Verifox?). Dasselbe Symptom wie bei tethered Telekom: UDP geht nicht, TCP Downstream gestört.
Ich kann alles belegen und die entsprechende Testapp z.V. stellen.
Das klingt eher danach, dass dein Messaufbau einen Fehler hat.
100% Loss zeigt eher, dass die Verbindung irgendwo geblockt wird, statt das es einen "Verlust" gibt.
3
Antwort
von
vor einem Jahr
100% Loss zeigt eher
ich glaube nicht dass er 100 % Loss meint, sondern dass die Loss nur (also zu 100%) im Downstream auftreten
Kann mich aber irren
Antwort
von
vor einem Jahr
Wer spricht von 100% loss?
Antwort
von
vor einem Jahr
So war es gemeint.
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
der Tracert gibt auch nicht wirklich Aufschluss, es geht wohl über ein Privates Netz und taucht dann einfach in Deutschland wider auf.
Spricht eigentlich für ein direktes Peering zur Telekom
Einzig auffälliges ist. die Ehrenrunde zwischen hop 7 und 10. Möglicherweise ist das was ausgefallen
0
vor einem Jahr
Momentan ist etwas Ruhe eingekehrt und die Verluste sind nicht mehr so massiv wie gestern noch, mal sehen, wie sich das entwickelt.
Danke Euch erst mal
1
Antwort
von
vor einem Jahr
Gestern war Feiertag ...
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
Interessant. Jetzt momentan ist absolute Fehlerfreiheit. Irgendein "Zwischenhobel" an der Grenze?
So soll das sein... So kenne ich das auch...
0
vor einem Jahr
hat sich der Tracert vom Server zum client nun verändert
0
vor einem Jahr
Irgendwie schon...
0
vor einem Jahr
na, war hat ne Routingstörung - soll vorkommen - evtl Leitung defekt.
Vermutlich über Ersatzstrecke geroutet die dann dicht. war.
0
Akzeptierte Lösung
akzeptiert von
vor einem Jahr
Denke ich auch. War nur so verdammt lange, seit Dienstag...
Erst mal Entwarnung. Problem gelöst bis auf Weiteres.
Vielen Dank an alle Helfer für die hilfreichen Kommentare
Schönes Wochenende allen
1
Antwort
von
vor einem Jahr
Hallo @neil.young,
vielen lieben Dank für die Rückmeldung. Freut mich, dass alles einwandfrei funktioniert. Daumen sind gedrückt. Bei allen weiteren Fragen melde dich bitte. Schönes Wochenende an alle.
Viele Grüße
Dilber S.
Uneingeloggter Nutzer
Antwort
von
vor einem Jahr
Nun ja, die Freude war nur von kurzer Dauer. Jetzt ist wieder alles so, wie eingangs gemeldet.
BTW: Hier sagte mal jemand, dass das Problem symmetrisch auch TCP treffen müssten. Er hatte Recht. Nur, dass die Packet Losses hier minimal sind. Das Problem ist trotzdem zu "sehen", denn Life-Videostreams verhalten sich faktisch wie in Zeitlupe: Wg. der hohen Verluste und der nachfolgenden Wiederübertragungen im TCP verzögert sich alles sehr sichtbar.
1
Antwort
von
vor einem Jahr
Hallo @neil.young,
hast du mal einen aktuellen Tracert für uns?
Schöne Grüße
Hakan
Uneingeloggter Nutzer
Antwort
von
Uneingeloggter Nutzer
Frage
von