TalkTalk and DSCP and 19 second latency: Difference between revisions
(Created page with "<indicator name="Front">link=Category:Technical Documents|30px|Back up to the Technical Documents category</indicator> This page is about in intere...") |
mNo edit summary |
||
| Line 6: | Line 6: | ||
For some reason, TT's kit is reading IP DSCP marks from IPv4 packets inside PPPoE, and then putting them in a funny queuing setup which results in latency quickly increasing to over 19 seconds. |
For some reason, TT's kit is reading IP DSCP marks from IPv4 packets inside PPPoE, and then putting them in a funny queuing setup which results in latency quickly increasing to over 19 seconds. |
||
=in depth= |
|||
| ⚫ | |||
== Home network == |
|||
the cusotmer's home network is fairly typical, eg: |
|||
WiFi devices <-> Aruba AP22 <-> FireBrick 2900 <-> Huawei HG612 (bridge mode) |
|||
There are also a number of devices wired in via a switch and the FireBrick. |
|||
| ⚫ | |||
Our customer moved house in early 2021 and we provided a VDSL line, a FireBrick FB2900. The VDSL was supplied over TalkTalk backhaul. At the same time the customer installed a set of new Aruba access points to cover his new house in Wi-Fi. |
Our customer moved house in early 2021 and we provided a VDSL line, a FireBrick FB2900. The VDSL was supplied over TalkTalk backhaul. At the same time the customer installed a set of new Aruba access points to cover his new house in Wi-Fi. |
||
| Line 13: | Line 22: | ||
The customer put this down to something odd on their network until they finally decided to investigate further. |
The customer put this down to something odd on their network until they finally decided to investigate further. |
||
= The cause |
== The cause == |
||
pcaps revelealed that the Aruba access point was marking some traffic with the DSCP flag CS6 |
|||
== Things that were tried== |
|||
===...that didn't make a difference=== |
|||
* Disabling the "QoS" setting on the HG612 in bridge mode (still observe high latency) |
|||
* Reducing the "speed" of the PPPoE connection from the FB2900 to 85% of sync speed, hoping to avoid buffer-bloat anywhere in the me-to-A&A direction (still observe high latency) |
|||
* Using other wireless devices (I can repro the problem with the "live view" of some Nest Cameras and with web-based Stadia on a Chromebook) |
|||
* Dumping packets on the WAN interface of the FB2900 (I've confirmed that the FB2900 itself isn't introducing the extra latency) |
|||
===...that did make a difference=== |
|||
* Connecting the phone, running Stadia, via wired ethernet (high latency goes away because the problematic QoS marking has gone, DSCP field = 0) |
|||
* Setting a special feature on AAISP and the FireBrick - 'IP over LCP' - this sends the IP traffic as control frames. (high latency goes away) |
|||
== The cause of the latency== |
|||
Revision as of 19:19, 7 December 2021
This page is about in interesting problem that was reported to us, by a customer, in December 2021.
TL;DR
For some reason, TT's kit is reading IP DSCP marks from IPv4 packets inside PPPoE, and then putting them in a funny queuing setup which results in latency quickly increasing to over 19 seconds.
in depth
Home network
the cusotmer's home network is fairly typical, eg:
WiFi devices <-> Aruba AP22 <-> FireBrick 2900 <-> Huawei HG612 (bridge mode)
There are also a number of devices wired in via a switch and the FireBrick.
The Problem
Our customer moved house in early 2021 and we provided a VDSL line, a FireBrick FB2900. The VDSL was supplied over TalkTalk backhaul. At the same time the customer installed a set of new Aruba access points to cover his new house in Wi-Fi.
The Wi-Fi itself works very well. But since the install the customer soon noticed problems with some 'real time' applications such as webRTC, Google Stadia, Nest Camera video streaming. The problem was with latency, which was caused delays with the live streaming of video and audio.
The customer put this down to something odd on their network until they finally decided to investigate further.
The cause
pcaps revelealed that the Aruba access point was marking some traffic with the DSCP flag CS6
Things that were tried
...that didn't make a difference
- Disabling the "QoS" setting on the HG612 in bridge mode (still observe high latency)
- Reducing the "speed" of the PPPoE connection from the FB2900 to 85% of sync speed, hoping to avoid buffer-bloat anywhere in the me-to-A&A direction (still observe high latency)
- Using other wireless devices (I can repro the problem with the "live view" of some Nest Cameras and with web-based Stadia on a Chromebook)
- Dumping packets on the WAN interface of the FB2900 (I've confirmed that the FB2900 itself isn't introducing the extra latency)
...that did make a difference
- Connecting the phone, running Stadia, via wired ethernet (high latency goes away because the problematic QoS marking has gone, DSCP field = 0)
- Setting a special feature on AAISP and the FireBrick - 'IP over LCP' - this sends the IP traffic as control frames. (high latency goes away)