1&1 Mobilfunknetz technische Aspekte (VoLTE, Wifi Calling, Roaming & uvm.)

Abgesehen davon hoher RTT und Packet loss.

Der Fachkräftemangel schlägt hier ganz offensichtlich durch. Der kleine Netzbetreiber bekommt nicht die Leute ran, die er bräuchte, um Dinge wie RCS zum Laufen zu bringen. Dazu passen solche Firewalleinstellungen wie sie aus der PCWELT- und CHIP-Anleitung stammen könnten, damit die bösen Hacker nicht mit ICMP angreifen.

Das ist nicht unbedingt auf die jeweiligen Kräfte zurückzuführen. Hier z.B. ein traceroute aus dem Wissenschaftsnetz:

@ ~ % traceroute www.google.de
traceroute to www.google.de (172.217.19.67), 64 hops max, 40 byte packets
 1  160.45.18.66 (160.45.18.66)  5.904 ms  1.688 ms  0.933 ms
 2  160.45.240.172 (160.45.240.172)  3.015 ms  1.224 ms
    160.45.240.171 (160.45.240.171)  3.421 ms
 3  130.133.250.9 (130.133.250.9)  3.098 ms  1.138 ms
    130.133.250.13 (130.133.250.13)  2.878 ms
 4  fub-wan2-te0-0-0-24.router.fu-berlin.de (160.45.246.45)  3.865 ms  1.804 ms  1.638 ms
 5  192.86.163.218 (192.86.163.218)  4.676 ms  1.950 ms  1.835 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  cr-tub2-hundredgige0-2-0-0-3001.x-win.dfn.de (188.1.235.241)  5.021 ms  2.101 ms  2.063 ms
13  cr-han2-be7.x-win.dfn.de (188.1.144.137)  9.224 ms  6.917 ms  6.587 ms
14  74.125.147.200 (74.125.147.200)  12.728 ms  13.504 ms  11.589 ms
15  192.178.99.221 (192.178.99.221)  13.322 ms
    108.170.255.69 (108.170.255.69)  15.109 ms
    192.178.99.221 (192.178.99.221)  10.612 ms
16  209.85.244.219 (209.85.244.219)  13.905 ms
    209.85.245.203 (209.85.245.203)  14.089 ms
    209.85.244.219 (209.85.244.219)  11.510 ms
17  ham02s17-in-f3.1e100.net (172.217.19.67)  11.274 ms  10.231 ms  10.242 ms

Innerhalb unseres LANs siehst Du die Hops noch, im Übergangsnetz (Berliner Wissenschaftsnetz BRAIN) nicht mehr, und erst am Übergabepunkt zum DFN (Deutsches Forschungsnetz) gibt es wieder Feedbacks.

Auch wenn der trace im DFN unvollständig ist, man sieht den Weg der Daten: Von der FU Berlin geht es über Hannover (cr-han2) nach Hamburg zu Google (ham02). Schaut man in der Peering-Datenbank des DFN nach (https://www.peeringdb.com/net/279), dann ist der Weg zwar nicht optimal - es gäbe am Berliner BCIX einen direkten Weg zu Google - und so werden ein paar ms "verschenkt".

1&1 Versatel wäre eigentlich noch besser aufgestellt (siehe https://www.peeringdb.com/net/684 , da fehlen nur Peerings in München), aber leider wird aktuell für das 5G Netz nur ein PDN-GW (Public Data Network Gateway) betrieben und vermutlich ein weiteres im Hot-Standby, so dass sämtlicher IP-Traffic im 1&1 Netz - egal ob im eigenen Netz oder o2 Roaming oder im Internationalen Roaming - über dieses Gateway läuft, was physikalisch mutmaßlich in Dortmund oder Düsseldorf steht.

Die öffentlichen IP-Adressen stammen laut Ripe aus dem Block 61.8.128.0/22 (siehe https://apps.db.ripe.net/db-we…w&searchtext=61.8.128.205) und sind somit auch nicht geographisch über Deutschland hinweg verteilt. 1&1 Kunden, die sich in der Region zwischen Ruhrgebiet und Hessen aufhalten ist das sicher optimal - wer jedoch in Berlin oder München unterwegs ist hat (im Vergleich zu o2 oder Telekom) mindestens +10ms Latenz.

Zitat von kammann

1&1 Versatel wäre eigentlich noch besser aufgestellt (siehe https://www.peeringdb.com/net/684 , da fehlen nur Peerings in München), aber leider wird aktuell für das 5G Netz nur ein PDN-GW (Public Data Network Gateway) betrieben und vermutlich ein weiteres im Hot-Standby, so dass sämtlicher IP-Traffic im 1&1 Netz - egal ob im eigenen Netz oder o2 Roaming oder im Internationalen Roaming - über dieses Gateway läuft, was physikalisch mutmaßlich in Dortmund oder Düsseldorf steht.

Ich würde mir vorstellen das die Server in Montabaur stehen und direkte Glasfaseranbindungen nach Franfurt und Düsseldorf haben.

Zitat von kammann

Die öffentlichen IP-Adressen stammen laut Ripe aus dem Block 61.8.128.0/22 (siehe https://apps.db.ripe.net/db-we…w&searchtext=61.8.128.205) und sind somit auch nicht geographisch über Deutschland hinweg verteilt. 1&1 Kunden, die sich in der Region zwischen Ruhrgebiet und Hessen aufhalten ist das sicher optimal - wer jedoch in Berlin oder München unterwegs ist hat (im Vergleich zu o2 oder Telekom) mindestens +10ms Latenz.

Das kann man aber auch als Vorteil sehen, denn dann ist man anonymer im Netz unterwegs.

Heute bekam ich eine Meldung auf meinem Xiaomi 11 Lite dass ab sofort für die 1&1-SIM-Karte RCS verfügbar wäre. Tatsächlich scheint es aktiv zu sein. Konnte es aber mangels Gegenstelle noch nicht testen.

Bei mir scheint es nun auch aktiv zu sein (Original 1&1 SIM). Es werden die Google-Server verwendet. Sprachnachrichten fuktionieren einwandfrei in beide Richtungen, getestet von und zu Congstar.

Zitat von kammann

Schaut man in der Peering-Datenbank des DFN nach (https://www.peeringdb.com/net/279), dann ist der Weg zwar nicht optimal - es gäbe am Berliner BCIX einen direkten Weg zu Google - und so werden ein paar ms "verschenkt".

Nur weil zwei AS am selben IX sind, heißt das noch lange nicht, dass sie dort ein Peering vereinbart haben. Ich meine sogar, dass Google vor kurzem erst seinen Rückzug u.a. vom BICX (sowie MegaIX Berlin und Düsseldorf) angekündigt hat.

Zitat von kammann

1&1 Versatel wäre eigentlich noch besser aufgestellt (siehe https://www.peeringdb.com/net/684 , da fehlen nur Peerings in München), aber leider wird aktuell für das 5G Netz nur ein PDN-GW (Public Data Network Gateway) betrieben und vermutlich ein weiteres im Hot-Standby, so dass sämtlicher IP-Traffic im 1&1 Netz - egal ob im eigenen Netz oder o2 Roaming oder im Internationalen Roaming - über dieses Gateway läuft, was physikalisch mutmaßlich in Dortmund oder Düsseldorf steht.

Die Frage ist ja eh, solange man noch den Großteil des Traffics per Roaming (noch o2, bald VF) abwickelt, ob sich regional verteilte PDN-GW lohnen oder man die nicht lieber in die Nähe der Roaming-Interkonnektionen platziert?