For time-critical data transmissions (e.g. voice telephony => VoIP, games), UDP is more suitable than TCP. Most speed tests are based on TCP and are therefore not very informative.

After an intensive check of the home network installation and the removal/checking of any interfering firewalls/routers (including personal firewall on the Windows computer), I recommend calling the Swisscom hotline and requesting an on-site check of the fiber optic installation by a Swisscom representative. Technician.

If Swisscom cannot solve this problem satisfactorily, I recommend switching to a fiber optic provider that does not require a router and supports network neutrality (for example Init7/Fiber7):

https://netzpolitik.org/tag/routerzwang/

[http://www.nzz.ch/nzzas/nzz-am-sonntag/machtkampf-um-den-verkehr-im-internet-1.18543510](http://www.nzz.ch/nzzas/nzz-am- sunday/power-struggle-over-traffic-on-the-internet-1.18543510)

https://www.fiber7.ch/de/fiber7-technologie/fiber7-hardware/

[https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-das-Thema/Lancom-Glas Fiber-Router-%C3%BCber-Swisscom-Bluewin-m%C3%B6glich/m-p/448171#M1 056](https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-das-Thema/Lancom-Glasfibro-Router-%C3%BCber-Swisscom-Bluewin-m%C3%B6glich/m-p/448171 #M1056)

The big advantage of the fiber optic internet connection is that you are spoiled for choice of fiber optic providers and this is where the market plays.

Swisscom TV also uses UDP:

http://www.tuxone.ch/search/label/pfSense

If the downstream of UDP over fiber optics were actually as error-prone as measured with IPerf(3), the television picture would be disturbed (visible colored blocks, black picture, colored image strips).

Since Swisscom TV apparently works perfectly, there is either a problem in the home network or Swisscom is deliberately throttling the UDP data traffic in the downstream direction:

[https://community.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397658](https://community.swisscom.ch/t5/Archiv- Internet/Very-strong-UDP-throttling-in-the-network/td-p/397658)

Swisscom apparently implements this throttling in its Internet box.

\=> And so we once again have a strong argument for switching to a fiber optic provider without the need for a router!

Swisscom doesn’t throttle anything, but TV and VoIP have a higher priority (QoS) compared to the rest of the data traffic.

---

@hed wrote:

Swisscom does not throttle anything, but TV and VoIP have a higher priority (QoS) compared to the rest of the data traffic.

---

The IPerf(3) measurements show “black and white” that the UDP data traffic in the downstream direction is throttled to around 655 kbit/s. Independent of the current IPerf(3) measurements, other Swisscom fiber optic private customers have also noticed this UDP throttling (100KBytes/sec => around 1 to 2 MBit/s) with the Swisscom Internet box:

[https://community.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397658](https://community.swisscom.ch/t5/Archiv- Internet/Very-strong-UDP-throttling-in-the-network/td-p/397658)

QoS only comes into effect when the data packets accumulate in a network component. In the current case, this would be the case if the data traffic in the downstream direction is > 100 Mbit/s, which cannot be achieved with Swisscom TV alone. The IPerf(3) measurements were deliberately carried out with a UDP data stream of 95 instead of 100 Mbit/s so that no queue congestion could form in any network component and the QoS could distort the measurement.

For the IPerf(3) measurements, the fiber optic cable must be unloaded (idle). The measuring computer should be the only home network participant on the Internet box.

Is the firmware of the Swisscom Internet-Box up to date?

[https://www.swisscom.ch/de/privatkunden/hilfe/loesung/firmware-aktualisierungen-fuer-ihre-internet-box.html](https://www.swisscom.ch/de/privatkunden/hilfe/ solution/firmware-updates-for-your-internet-box.html)

IPerf(3) measurements over the mobile network with a Swisscom SIM card show high packet loss rates in the downstream direction with a UDP packet size of 8 kilobytes. With IPerf(3) the default setting of the UDP packet size is 8 kilobytes.

First, reduce the UDP packet size significantly below the MTU value using the IPerf parameter “-l” (Ethernet: 1500 bytes, PPPoE: < 1493 bytes):

https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

leads to acceptable packet loss rates (< 1%). The reason for this behavior is probably IP fragmentation:

https://de.wikipedia.org/wiki/IP-Fragmentation

If IPv4 packets have to be fragmented by network components (the receiving side has a larger MTU value than the sending side), the fragmentation and the subsequent assembly/reassembly of the IPv4 packets leads to performance losses. Therefore, some IP routers/firewalls do not accept fragmented IPv4 packets for performance reasons and to protect against DoS attacks:

https://en.wikipedia.org/wiki/IP_fragmentation_attack

https://de.wikipedia.org/wiki/Denial_of_Service

In IPv6, IP routers are not allowed to fragment IP packets. TCP transmissions adapt the IP packet size to the smallest MTU of the transmission path:

https://de.wikipedia.org/wiki/Transmission_Control_Protocol

UDP has no mechanism for detecting the smallest MTU in the transmission path.

Why the MTU on the Swisscom fiber optic connection is not 1500 bytes is a mystery to me. Does Swisscom use PPP for fiber optic connections?

https://de.wikipedia.org/wiki/Point-to-Point_Protocol

For UDP data transmission, the Internet connection via the television cable network (EuroDOCSIS) has an advantage. My IPerf(3) measurements on the EuroDOCSIS cable modem in downstream measurements with 65507 byte UDP packets show normal packet loss rates around 1%. UDP packets may have a maximum size of 65507 bytes:

https://de.wikipedia.org/wiki/User_Datagram_Protocol

It looks like Swisscom is using PPPoE for the fiber optic connection:

[http://documents.swisscom.com/product/1000260-Connectivity\_Geraete\_/Documents/ Specifications/Centro_Business_PPPoE_Passthrough-de.pdf](http://documents.swisscom.com/product/ 1000260-Connectivity_Geraete_/Documents/ Specifications/Centro_Business_PPPoE_Passthrough-de.pdf)

https://de.wikipedia.org/wiki/PPP_over_Ethernet

According to the IPerf(3) measurements, the use of PPPoE leads to massive packet losses with large UDP packets (> approx. 1400 bytes). The following offers a solution to the “big UDP packet problem”:

a) Use of a fiber optic connection from a third party without the need for a router

b) OR the implementation of a PPPoE-free fiber optic connection: removal of the Swisscom Internet box and the use of a media converter copper Ethernet <-> fiber optic Ethernet

[https://community.swisscom.ch/t5/Archiv-Internet/Sehr-starkes-UDP-throttling-im-Netz/td-p/397658](https://community.swisscom.ch/t5/Archiv- Internet/Very-strong-UDP-throttling-in-the-network/td-p/397658)

[https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-das-Thema/Lancom-Glas Fiber-Router-%C3%BCber-Swisscom-Bluewin-m%C3%B6glich/m-p/448171#M1 056](https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-das-Thema/Lancom-Glasfibro-Router-%C3%BCber-Swisscom-Bluewin-m%C3%B6glich/m-p/448171 #M1056)

I doubt that large UDP packets > 1400 bytes are used for the games and therefore no measure a) or b) is necessary. The only way to be certain here is to analyze the network traffic recordings with Wireshark:

https://www.wireshark.org/

If the IPerf(3) measurements with UDP packets < 1400 bytes in the downstream direction prove that the fiber optic connection is functioning properly (packet loss rate < 0.01% and jitter < 1 millisecond) AND the games do not use UDP packets > 1400 bytes, then this is the case The ball is back in the court of the network operator (Swisscom), their peering partners and the game server operators.

@GrandDixence

FTTH still has a VLAN on it. That’s why there should actually be 4 bytes left.

DHCP is used for private customers.

So theoretically the maximum MTU there is 1496

I have a PPPoE termination over FTTH and VLAN. I would have 1492. Effectively but only 1488 because of the VLAN.

That’s how it is with me.

But no one from Swisscom has ever confirmed this 😉 I just said that you should actually adapt the config sheets for firewalls accordingly.

It would be cool for someone to test the effective MTU on their FTTH private customer connection.

http://www.tp-link.com/en/article/?faqid=190

tiibor

I wanted you to just copy and paste and find out for yourself. That it is just a measurement error. My colleague above has already explained why -l x is so important in UDP.

Well I’m just with a small one. Bandwidth blessed. But I think with fine tuning of the values ​​-b and -l you will now reach the max. Unless there really is an L1 problem on site. But based on your description this can be ruled out.

Because the traceroute/MTR to easo.ea.com is also OK, i.e. no routing problem is visible. Can this definitely be ruled out?

Also that you didn’t write that everything with the box is slow. But rather just a game in particular. Indicates a problem with the game server itself! Due to the lack of hardware, I can’t say anything precise about it.

Now I would create another trouble ticket with all the new findings from the game provider and see if there is more to come this time. If you write again everything is ok. ask how you can check this yourself?

iperf3 -u -R -c ping.online.net -b 20M

[ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.01 sec 192 KBytes 1.56 Mbits/sec 10,698 ms 252/276 (91%)
[ 4] 1.01-2.01 sec 80.0 KBytes 655 Kbits/sec 5,897 ms 296/306 (97%)
[ 4] 2.01-3.01 sec 80.0 KBytes 655 Kbits/sec 3,433 ms 295/305 (97%)
[ 4] 3.01-4.01 sec 80.0 KBytes 654 Kbits/sec 2,143 ms 295/305 (97%)
[ 4] 4.01-5.01 sec 80.0 KBytes 656 Kbits/sec 1,435 ms 295/305 (97%)
[ 4] 5.01-6.01 sec 80.0 KBytes 655 Kbits/sec 0.986 ms 295/305 (97%)
[ 4] 6.01-7.01 sec 80.0 KBytes 655 Kbits/sec 0.741 ms 295/305 (97%)
[ 4] 7.01-8.01 sec 80.0 KBytes 655 Kbits/sec 0.810 ms 296/306 (97%)
[ 4] 8.01-9.01 sec 80.0 KBytes 655 Kbits/sec 0.855 ms 295/305 (97%)
[ 4] 9.01-10.01 sec 80.0 KBytes 655 Kbits/sec 0.569 ms 295/305 (97%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.01 sec 23.8 MBytes 20.0 Mbits/sec 0.569 ms 2909/3023 (96%)
[ 4] Sent 3023 datagrams

iperf Done.

iperf3 -u -R -c ping.online.net -b 20M -l 1420

[ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 1.31 MBytes 11.0 Mbits/sec 0.848 ms 506/1477 (34%)
[ 4] 1.00-2.00 sec 1.24 MBytes 10.4 Mbits/sec 0.795 ms 895/1811 (49%)
[ 4] 2.00-3.00 sec 1.24 MBytes 10.4 Mbits/sec 6,828 ms 903/1822 (50%)
[ 4] 3.00-4.00 sec 1.25 MBytes 10.4 Mbits/sec 0.730 ms 829/1749 (47%)
[ 4] 4.00-5.00 sec 1.25 MBytes 10.5 Mbits/sec 0.829 ms 789/1709 (46%)
[ 4] 5.00-6.00 sec 1.25 MBytes 10.5 Mbits/sec 0.831 ms 837/1757 (48%)
[ 4] 6.00-7.00 sec 1.25 MBytes 10.4 Mbits/sec 0.764 ms 863/1783 (48%)
[ 4] 7.00-8.00 sec 1.25 MBytes 10.5 Mbits/sec 0.707 ms 878/1798 (49%)
[ 4] 8.00-9.00 sec 1.25 MBytes 10.5 Mbits/sec 0.783 ms 806/1726 (47%)
[ 4] 9.00-10.00 sec 1.25 MBytes 10.4 Mbits/sec 0.772 ms 833/1753 (48%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 23.8 MBytes 20.0 Mbits/sec 1,481 ms 8259/17606 (47%)
[ 4] Sent 17606 datagrams

Host Loss% Snt Last Avg Best Wrst StDev
….
14. easo.ea.com 0.0% 310 111.7 111.7 109.9 149.5 2.8

---

@Tux0ne wrote:

It would be cool for someone to test the effective MTU on their FTTH private customer connection.

http://www.tp-link.com/en/article/?faqid=190

---

With the test according to the link as an iway.ch private customer (via DHCP) fiber optic network EWZ I get 1472, so the optimal value is 1472+28= MTU 1500.? Whatever that’s good for…

Then you have no.11q tagging on the ew Zürinet and DHCP as access technology, so 1500 is good for IPv4.

But I’m actually asking about FTTH Swisscom customers or one on the BBCS-F network.

There you have.11q tagging and the MTU can’t be 1500.

So just be aware of it when you get into problems. Not even related to this thread but in general.

---

@Tux0ne wrote:

@GrandDixence

FTTH still has a VLAN on it. That’s why there should actually be 4 bytes left.

Theoretically the maximum MTU there is 1496

---

The statement is not entirely correct: When using VLAN according to IEEE 802.1Q over Ethernet, the maximum amount of user data remains 1500 bytes and thus the MTU remains at 1500 bytes. VLAN according to IEEE 802.1Q over Ethernet has no influence on the MTU value. When using VLAN, the Ethernet frame simply becomes 4 bytes larger (1522 bytes instead of 1518 bytes):

https://de.wikipedia.org/wiki/Virtual_Local_Area_Network

https://de.wikipedia.org/wiki/IEEE_802.1Q

Only when using “double tagging” does the MTU decrease to 1496 when using VLAN according to IEEE 802.1Q over Ethernet:

https://en.wikipedia.org/wiki/IEEE_802.1Q

[http://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html#frame2](http://www.cisco.com/c/ en/us/support/docs/lan-switching/8021q/17056-741-4.html#frame2)