Jump to content

This is the support site for Andrews & Arnold Ltd, a UK Internet provider. Information on these pages is generally for our customers but may be useful to others, enjoy!

TalkTalk and DSCP and 19 second latency: Difference between revisions

TalkTalk and DSCP and 19 second latency (view source)

Revision as of 20:08, 7 December 2021

4 bytes added ,  7 December 2021
m
no edit summary
mNo edit summary
mNo edit summary
 
=TL;DR=
For some reason, TTTalkTalk'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 on the route from the End User to A&A:
 
1408 bytes from x.x.x.x: icmp_seq=986 ttl=63 time='''19084.589 ms'''
 
== The Problem ==
Our customer moved house in early 2021 and we provided a VDSL line, a FireBrick FB2900. The VDSL was supplied over TalkTalk backhaulback-haul. 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 cause ==
pcaps revelealedrevealed that the Aruba access point was marking some traffic with the DSCP flag CS6, and when there was enough traffic latency would increasingly build up.
 
=== Show me ===
 
=== What's DSCP and CS6? ===
DSCP (Differentiated Services Code Point ) is a field in the header of IP packets. usually left empty, but a value can be added which will clasiffyclassify how the packets could be handeledhandled by network equipment that support QoS (Quality of Service). eg, important packets can be classified has high priority with the hope that they will be able to jump any queues on network routers and get to the destination as fast as possible.
 
CS6 is one of these classification, and CS6 is described as 'Network control' and is one of the highest classifications available.
 
===...that did make a difference===
* Connecting the phone, running Stadia, via wired ethernetEthernet (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)
 
=== Things that were not tried ===
*Migrating the line to BT backhaulback-haul - this would have fixed the problem for the customer, but would not have fixed the problem in the TalkTalk network or the Aruba access point. Being engineers - we like to fix problems!
 
== Further tests ==
With A&A having a lively IRC channel, we asked customers to try our ping test to see who far spread the problem was, we found out thatLthat:
* All AAISP TalkTalk VDSL lines tested showed latency
* All AAISP TalkTalk ADSL lines tested showed latency
* A TalkTalk business VDSL line provdidedprovided by TalkTalk direct showed latency
* A non-AAISP TalkTalk wholesale VDSL showddshowed latency
* No AAISP BT lines tested showed latency
* No AAISP Ethernet lines showed latency
 
===December 7th===
A&A got in touch with TalkTalk driectlydirectly by emailing TalkTalk's escalations department and our Service Manager. (There was no point in reporting an individual line fault via the normal channels for broadband fault.)
AA-Andrew
autoreview, Bureaucrats, editor, Interface administrators, reviewer, Administrators
12,270

edits

Retrieved from ‘http://support.aa.net.uk/Special:MobileDiff/15598’