Solved
UDP RTP massive Paketverluste im Downstream von AWS
1 year ago
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
This could help you too
6 years ago
1693
2
2
971
0
2
1108
2
7
1 year ago
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
Answer
from
1 year ago
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.
Answer
from
1 year ago
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
Answer
from
1 year ago
Ggf. bei einem Freund oder Kollegen über Vodafone, EON, Deutsche Glasfer oder ähnlich vergleichend probieren.
Unlogged in user
Answer
from
1 year ago
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
Answer
from
1 year ago
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
Answer
from
1 year ago
Wer spricht von 100% loss?
Answer
from
1 year ago
So war es gemeint.
Unlogged in user
Answer
from
1 year ago
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
1 year ago
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
Answer
from
1 year ago
Gestern war Feiertag ...
Unlogged in user
Answer
from
1 year ago
Interessant. Jetzt momentan ist absolute Fehlerfreiheit. Irgendein "Zwischenhobel" an der Grenze?
So soll das sein... So kenne ich das auch...
0
1 year ago
hat sich der Tracert vom Server zum client nun verändert
0
1 year ago
Irgendwie schon...
0
1 year ago
na, war hat ne Routingstörung - soll vorkommen - evtl Leitung defekt.
Vermutlich über Ersatzstrecke geroutet die dann dicht. war.
0
Accepted Solution
accepted by
1 year ago
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
Answer
from
1 year ago
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.
Unlogged in user
Answer
from
1 year ago
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
Answer
from
1 year ago
Hallo @neil.young,
hast du mal einen aktuellen Tracert für uns?
Schöne Grüße
Hakan
Unlogged in user
Answer
from
Unlogged in user
Ask
from