Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: cbdeakin on March 23, 2022, 10:39:17 PM
-
Are there any VDSL modems that can do this?
Basically, I discovered that my VDSL2 line has 1-2% packet loss (I can see this in various applications like Google Stadia and other streaming services), and I'm fairly sure it's on the upstream part of the connection, which is not interleaved (the downstream is). It's enough to cause stuttering and input delays in the stream.
I realise this will seem strange to a few people on these forums, as many users (particularly gamers), seem to want to remove interleaving from their lines, but I think there are reasons why you might want it to be enabled on your line (particularly if G.INP is not an option). I think my line would be fine with interleaving enabled on the upstream, because latency is only 9-10ms to websites like bbc.co.uk.
My line has never had G.INP enabled, which I suspect would've helped a lot to reduce packet loss on the line (note - I've confirmed it's not my own network causing the packet loss and my PC has an ethernet connection to my router).
I'd appreciate any advice from the experts on this! I'm hoping that it's possible to force on interleaving with a telnet or SSH command on some modems. I suppose the other thing it would be useful to know, is how effective interleaving is at actually preventing packet loss on ADSL and VDSL lines.
-
The stuttering on the streaming is downstream, Stadia's streaming doesn't care about upstream. Changing the upstream won't help you :(
-
I'd have to agree, upstream would cause input misses not stuttering. Streaming services will be using UDP as you wan't no re-transmissions (from the server, re-transmission from the DSLAM is likely fast enough to be an improvement rather than detriment) on a live feed, but that means if you lose a few packets on the way it will likely skip that corrupt frame to avoid garbage on the screen.
-
The interesting thing about this problem, is that if I set my upload speed to 500kbps, packet loss on the line is virtually 0.
I first noticed this when I ran this online networking test here:
https://www.measurementlab.net/p/ndt-ws.html
Which reported 0 packets lost and 0 bytes lost when limited to 500kbps upload. If I increased the upload bandwidth, it would start reporting lost bytes and sometimes retransmitted packets.
Then I ran these settings in Stadia and noticed the same thing, virtually no packet loss (with tons of latency).
-
Why is Stadia using so much upstream, assuming there isn't something else up? Your kit only needs to be sending controller inputs?
Stadia only uses upstream for those inputs. The stream itself doesn't have any acknowledgement. How's your router?
-
Has to be said, I never had much luck with any streaming service and I tried Geforce Now, Stadia and Shadow.
Stadia particularly was annoying as it would work fine then suddenly the picture go all blocky and eventually lose the connection entirely. Not been too keen on trying them since seeing as I have a beefy gaming PC, but there was one game that was Stadia exclusive I was enjoying until that started.
At the time I had Zen and Plusnet, both exhibited the same problem at the same time. Doubt it was pfSense at fault as it had been working fine at first and still would periodically, just not long enough to get a full play session in. I think I even tried over Three 4G with the same result.
-
Why is Stadia using so much upstream, assuming there isn't something else up? Your kit only needs to be sending controller inputs?
Stadia only uses upstream for those inputs. The stream itself doesn't have any acknowledgement. How's your router?
Good point. I suppose it's the SQM (I'm using FQ_Codel, as it works much better on Stadia than que disciplines such as Cake), I've heard that can require a fair bit of upload (2mbps) for it to work well
-
Has to be said, I never had much luck with any streaming service and I tried Geforce Now, Stadia and Shadow.
I strongly agree, certainly true in my case for both Geforce Now and Stadia. I'm fairly sure that Google have the best servers / infrastructure of any streaming service though. I assume your connection doesn't have G.INP enabled as you are on an ECI cabinet. It's hard to prove definitively, but I suspect that G.INP is probably helping to avoid this problem on a lot of FTTC lines (especially if the SNR is low, hence lower bit rate).
The best results I've had so far on Stadia, were with a per packet overhead of 256 and an upload limit of 2500kbps.
I had a chat with my ISP, they reckon interleaving wouldn't help, and might even increase the amount of lost packets (I suppose because of the chopping up and reassembling of packets that happens when interleaving is used).
-
I strongly agree, certainly true in my case for both Geforce Now and Stadia. I'm fairly sure that Google have the best servers / infrastructure of any streaming service though. I assume your connection doesn't have G.INP enabled as you are on an ECI cabinet. It's hard to prove definitively, but I suspect that G.INP is probably helping to avoid this problem on a lot of FTTC lines (especially if the SNR is low, hence lower bit rate).
Its possible it would be WAY better now as my errors are insanely low since I had my drop wire replaced. I kinda doubt though that the problem was my end considering it was so severe and across three ISPs at the same time period.
-
Signal errors dont increase or decrease with throughput normally, just would be more noticeable in the form of packet loss.
So some things here I think need to be clearer.
Are we talking CRC errors on the upstream or just packet loss? The two are not the same thing.
When you see the packet loss what is the utilisation of the downstream and upstream in respect to the line capacity?
-
Signal errors dont increase or decrease with throughput normally, just would be more noticeable in the form of packet loss.
Exactly this.
You get the same/similar number of CRC/ES while downloading/uploading at full speed for 24 hours as you would having a modem synced but with no router connected, no PPP connection, no traffic being sent or received for 24 hours.
-
Hi guys.
To clarify, the packet loss occurred on Stadia regardless of whether or not CRC errors / errored seconds were logged by the modem in the same time period.
Had another visit from 2 Openreach engineers earlier (I told my ISP about the packet loss, and asked them if they could do anything specifically at the exchange / FTTC cabinet). The engineers said the fault had been logged as 'low speed' when they turned up ;D
Anyway, they told me that the line is aluminium and so the impression I got was that there isn't much they can do, regarding the packet loss (they also mentioned that my line was connected to a 'distribution point' shared by 10 other lines).
They offered to enable interleaving on the upstream part of the connection (one of them said he sometimes used to enable interleaving on ADSL connections to reduce packet loss), so I will see what difference this makes. Latency has increased by 19ms (now around 29ms to bbc.co.uk). So, hopefully that won't harm things too much.
Aluminium cables apparently aren't twisted, so I assume this means they are prone to noise / interference.
So, aluminium line on a ECI cabinet, only the best for us ::). Apparently the best you can get out of an aluminium line in our street is 60mbps downstream (which admittedly, isn't that bad).
-
So, a little update:
Amazingly, interleaving appears to have solved my packet loss issue (0-0.001% reported in Google Stadia) on my crappy aluminium line :)
I will keep testing it. It looks like it was applied on both the downstream and upstream.
Might even be able to play at 4K Nope
-
Not really amazing given its what interleaving exists for.
-
I'm getting around 20ms of additional latency, according to my line parameters (Delay value):
(https://i.imgur.com/GgUo6ZN.jpg)
-
Curious, I've never seen a delay more than 8ms each way.
-
I suppose I'm lucky in a way that the line is only a few hundred meters, as this helps to keep the total latency down (getting latencies between 30-40ms in Stadia, which is considered 'good').
-
Not sure distance makes a difference on VDSL other than a higher chance of interference along the line, the mechanisms for mitigating it remain the same either way and that's where the majority of the latency comes from.
-
So, the interleaving got removed on the upstream about an hour ago and the additional delay is just 8ms now.
hopefully it won't be completely crap again, but I won't hold my breath. My ISP said it would remain active, but it still seems to be controlled dynamically by Openreach.
EDIT - Yup, just started a Stadia stream and it's losing thousands of packets again in just 4-5 minutes, and the stream feels glitchy again. So, it seems to need the upstream interleaving to be enabled... Very specific problem.
-
I don't know how you are going to get around this as DLM is an automated process. I'm actually surprised that the engineer could manually apply interleaving - unless they actually just did a DLM reset which I believe applies it by default on an ECI cabinet, and DLM has now decided the upstream side is good enough not to need it?
-
Yes, the DLM system is hardly a precision tool (doesn't care if the line is copper or aluminium).... I couldn't resist the opportunity for a pointless moan :D
I don't think it was a line reset, the Openreach engineer specifically requested applying (only) upstream interleaving. I think they just applied standard interleaving on both the downstream and upstream.
I've certainly given my ISP a challenge.
-
Doesnt make sense to me unless a piece of your networking equipment is generating noise when active, powerline networking or something else.
But you have a resolution which is the main thing.
-
Well, from what I've heard, aluminium cables are prone to noise /interference so I assume that's the cause.
-
I don't think it was a line reset, the Openreach engineer specifically requested applying (only) upstream interleaving. I think they just applied standard interleaving on both the downstream and upstream.
Like we've said though, NOBODY has the ability to do this, its entirely down to DLM to decide interleaving or not, it cannot be manually overridden.
The only options you have are stability profiles (how many errors DLM will ignore before turning on interleaving and how aggressive it is) or a DLM reset.
-
Like we've said though, NOBODY has the ability to do this, its entirely down to DLM to decide interleaving or not, it cannot be manually overridden.
The only options you have are stability profiles (how many errors DLM will ignore before turning on interleaving and how aggressive it is) or a DLM reset.
That's my understanding too - I think a DLM reset was performed.
-
Well, from what I've heard, aluminium cables are prone to noise /interference so I assume that's the cause.
Aluminium doesn’t carry higher frequencies well and loss per Meter is greater. I don’t think however it’s more prone to interference.
-
Indeed. The killer is when aluminium and copper are jointed - it creates an impedance mismatch and you end up with literal signal reflections increasing noise.
-
The engineer specifically made a request remotely to change the interleaving. The tech support lady answered on the other end to confirm the interleaving changes.
The other line stats remained the same after the change. Surely no need to debate that?
The options discussed were interleaving and interleaving high. I've no idea what difference there is between these.
The problem I have at the moment, is my ISP is currently having trouble getting in touch with Openreach via their 'portal'.
-
The engineer specifically made a request remotely to change the interleaving. The tech support lady answered on the other end to confirm the interleaving changes.
The other line stats remained the same after the change. Surely no need to debate that?
We debate it because all evidence suggests this is impossible, the engineer at best can request a DLM reset and in general its down to the ISP. Only the ISP can request profile changes and AFAIK none of them guarantees interleaving, though as mentioned a DLM or profile change might enable interleaving by default but nothing to stop DLM turning it off again. Interleaving is entirely down to DLM, it cannot be manually changed.
-
You might be right. It's certainly seems like new territory for my ISP.
-
It sounds from the OP that the DCOE (Dedicated Centre Of Excellence?), which is who Openreach engineers contact to have any changes made (port swaps, DLM resets etc) , can manually set a specific DLM profile.
When the OP said earlier in the thread...
They offered to enable interleaving on the upstream part of the connection (one of them said he sometimes used to enable interleaving on ADSL connections to reduce packet loss), so I will see what difference this makes.
I was thinking to myself that isn't possible perhaps the engineer is indeed getting mixed up with ADSL, but then he posted a screenshot of interleaving enabled on the upstream.
I've certainly never seen a DLM reset result in both downstream and upstream interleaving. On an ECI cabinet it's always just downstream interleaving that's enabled.
If that's the case they can manually set the profile then it does seem a rather pointless exercise if the DLM continues to run and a few days later simply changes the current profile to remove the manually set change.
There was quite a few DLM related briefings for CP's during 2021 which might also explain it.
https://www.openreach.co.uk/cpportal/updates/briefings?t=category:briefings/super-fast-access
They included a new DLM Stability Policy Trial (https://www.openreach.co.uk/cpportal/updates/briefings/superfast/nga00621) started in June, extended in October (trialing a new/different stability policy)
There was also a DLM Reset Process Improvement Trial (https://www.openreach.co.uk/cpportal/updates/briefings/superfast/nga01421) started in December.
It's possible this new stability policy trial starts with upstream interleaving and that's why the OP had it but also possible the DCOE manually set that profile.
I wonder if BlackSheep is around and could enlighten us as to whether the DCOE has the ability to manually set a specific DLM profile (interleaving on/off, G.INP on/off, SNRM target) and if so whether they can make that change permanent and effectively disable the DLM from making further changes.
It's certainly something I've never seen before and wasn't aware was possible but if anyone could do such a thing it would be the DCOE.
-
@j0hn - That all sounds very interesting.
I guess I'll see if my ISP is able to offer any further help.
-
I googled 'DCOE openreach' and found this:
https://www.cvf.openreach.co.uk/orpg/home/aboutus/ourorganisation/businessinfo.do
'We also have an offshore team based in Pune, India'.
The engineer said that the tech support team they work with is based in India.
So, quite likely to be the DCOE that the engineer called.
-
It would certainly be irregular, people can spend months trying to get Openreach to fix much worse problems than what you had and never get referred to that team.
-
Well, we rely on Openreach to get lines up to a certain standard. Most lines should be able to handle video streaming comfortably (especially syncing over 20-30mbps downstream), if they don't I think it's Openreach's responsibility to fix it if possible, because they own and maintain the lines.
I hope you aren't going to go on about latency again ;D
-
Sorry about the Spanish Inquisition you've been getting on this, cbdeakin. I don't understand it but, then, don't have any desire to do the research that might fill me in so will live in blissful ignorance. Hope it's all getting sorted! :fingers:
-
Cheers.
-
I'm sure I could have done a better job of explaining the reasoning, coming off a bit aggressive has always been a problem I struggled with.
The thing is, several members of this forum have likely the largest collective knowledge of how Openreach manage things than anywhere else on the Internet and what you were told by the engineer contradicts countless other peoples experiences and what we know about how DLM and line profiles work.
Its not that we were denying you were told what you were, just that there have been so many occasions where engineers make claims that are completely wrong, or explain poorly causing misunderstandings. Most engineers don't actually know how the DLM works, its not their job to, DLM exists for the very purpose of not needing people to manually tweak things and from past experiences prevents any such tweaking.
If this permanently solves your problem then that's great, but as mentioned earlier, generally any change in procedures has to also be documented to the ISPs. While yes its up to Openreach to maintain the line to the best of their ability, they generally can't just make random changes that the ISP is not expecting as that can result in a lot of questions from customers that the ISP then cannot answer. So until proven otherwise its best to assume this was a DLM reset and interleaving could get removed again.
-
Thanks for your reply Alex. It's all good, no explanation needed. I appreciate your knowledge and experience (and from other members also) regarding how the DLM system works.
You're right of course, it's fairly likely that the DLM will simply undo any changes that Openreach / Openreach engineers attempt to make, as the system is designed to control these things automatically, and adjust them over time based on errors, resyncs etc.
If it can't be enabled as seems likely, I'll just adjust my expectations accordingly!
It's probably fair to say that I tend to be too optimistic when dealing with technology related problems, especially since this is not something I can solve myself.
Sure would be nice, if it 'just worked' though :)
-
To answer the initial query...
Are there any VDSL modems that can do this?
I believe the Asus DSL models with the Mediatek chipsets like the DSL-AC68U, can possibly do this.
It wasn't something I personally tinkered with but I think Ixel was forcing fastpath when the DLM had interleaved his line a number of years ago.
It's not a simple UI change though and involves sending commands over Telnet and possibly even running a special app from Asus.
It might be worth a search if that is the only way to fix your issue.
It's not a modem I personally recommend to people as I found it to be quite unstable on my line but others like it.
-
I have a DSL-N16 (mediatek chipset) that I was using before as a modem/router. It was quite good and worked surprisingly well on my line, but doesn't work in modem bridge mode. There's definitely some useful commands that allow the user to do things like restrict which VDSL2 frequency bands / spectrum is used.
Haven't been able to find the thread (with Ixel's posts) that might highlight the telnet commands I would need to use to potentially change interleaving settings, yet.
-
Had an email back from my ISP, they seem to be saying that it's impossible to permanently enable interleaving (if not set already by the DLM), so I suppose that's that.
They say it's upto Openreach to upgrade their network, which I tend to agree with (even if this isn't realistically going to happen).
It's been interesting to learn that actually, despite what a lot of people were saying on other forums, packet loss in this case is to do with the line itself (nothing to do with other factors, such as the ISP, or home network setup). Aluminium lines are not well understood it seems, I'm sure many people don't know they are even in use.
-
Hang on, wouldn't changing the DLM stability profile to 'stable' likely cause interleaving to be applied on the downstream / upstream after a short time? There's definitely errored seconds on both the downstream and upstream.
Probably worth asking my ISP to look at this again, since it might work.
These stability profiles are mentioned here:
https://kitz.co.uk/adsl/DLM.htm#dlm_stability_level
Wonder if any ISPs still use the 'Stable' option?
What's interesting about this option, is it is described as "Prioritise stability over speed for IPTV".
Cuckoo is likely using the 'NGA Standard Profile', as they make use of Talktalk's business network.
-
Had an email back from my ISP, they seem to be saying that it's impossible to permanently enable interleaving (if not set already by the DLM), so I suppose that's that.
They say it's upto Openreach to upgrade their network, which I tend to agree with (even if this isn't realistically going to happen).
It's been interesting to learn that actually, despite what a lot of people were saying on other forums, packet loss in this case is to do with the line itself (nothing to do with other factors, such as the ISP, or home network setup). Aluminium lines are not well understood it seems, I'm sure many people don't know they are even in use.
That seems what we would expect here. In ADSL you could have the ISP set SNRM and interleave but not on VDSL which is what other posters have said. At lest that’s been confirmed to you now.
Your next post about stability is an option, but rarely is interleave added upstream so you will likely end up with worse downstream performance and no change to upstream
-
I think interleaving rarely gets enabled on the upstream, probably because the thresholds on most lines are set high enough for that to be avoided.
It seems that Zen Internet does offer the 'stable' profile option, according to this:
https://support.zen.co.uk/kb/Knowledgebase/Fibre-Optic-Broadband-FTTC-What-is-DLM-and-how-does-it-work
Plusnet seems able to make these changes on request also:
https://community.plus.net/t5/Fibre-Broadband/what-stability-profile-are-we-on-and-can-we-change-it/td-p/1488251
-
As I understand it they try to avoid interleaving on upstream as some modems are buggy and don't like it.
-
It's a shame Plusnet isn't offering to let people trial G.INP anymore on ECI cabinets (this was part of an Openreach trial).
EDIT - Actually, I think G.INP never worked on the upstream on this equipment anyway ::)
-
It's a shame Plusnet isn't offering to let people trial G.INP anymore on ECI cabinets (this was part of an Openreach trial).
EDIT - Actually, I think G.INP never worked on the upstream on this equipment anyway ::)
Even on Huawei cabinets it is quite unusual to see G.INP on the upstream side. I've seen it twice I believe on my connection, following high error rates, and even then it didn't last more than a day or so before DLM removed it again.
-
It's a shame Plusnet isn't offering to let people trial G.INP anymore on ECI cabinets (this was part of an Openreach trial).
EDIT - Actually, I think G.INP never worked on the upstream on this equipment anyway ::)
Of course it’s not Plusnet that stopped G.INP, OR stopped the trial as it didn’t work in all scenarios. G.INP has never been successfully implemented on ECI cabs despite attempts to make it so.
-
Indeed. The killer is when aluminium and copper are jointed - it creates an impedance mismatch and you end up with literal signal reflections increasing noise.
Would you think it possible to create enoigh noise to interleave a line?
My own line was repaired after it had a very low sync (documented here on kitz), and not that long after, there was sudden noise that appeared. What I do know about the line that approx the last 50m is ali, the rest before it is copper. The engineer on the fault had to redo joints. The new issue has never been reported of course as I dont think it falls outside of openreach specification. (lost some sync speed but still 25mbit above handover, and stability is fine).
Also talking about odd DLM profiles, if people are willing to search, back in the days I was on plusnet I had a fault which had me syncing very low and the service test itself failed on the basis of a sudden loss of speed exceeding the threshold, well the DLM ended up configuring FEC on the line but without interleaving delay, I have never seen even a single other VDSL line configured in that way. If I remember right that configuration remained until the fault was fixed by the speed boost engineer who also did a DLM reset (my install engineer) and I have never seen it since.
-
So, I never did manage to switch to Plusnet (I was going to choose a more stable DLM profile setting), due to the online order process failing several times.
Anyway, it looks like it won't be necessary now :)
I think I may have stumbled on some router SQM settings (I use OpenWrt on a Raspberry Pi 4) that appear to prevent packet loss on my FTTC line, here's the results in Google Stadia after a 20 min session:
https://i.imgur.com/lKlqixt.jpg
Here are the settings I'm currently using:
https://i.imgur.com/WbqmJbw.jpg
The Ingress setting above is particularly important it seems. I'm guessing it basically increases the maximum amount of downstream packets allowed per second, or maybe it's related to the number of traffic flows allowed.
and this:
https://i.imgur.com/UM0jKCK.jpg
I need to test this option more, but I think a value of around 256 (highest possible setting) is necessary for maximum reliability in this case. Increasing this setting reduces bandwidth a bit, and increases latency sometimes, but in my view, it's well worth it.
This was tested with the FQ_Codel que discipline, which gives better results than other options on my line.
-
Do we have any OpenWRT experts on these forums that can explain what inputting "flows 100000" for the ingress and egress (for the settings shown above) actually does?
-
I certainly can't make head nor tail of it, SQM is supposed to be about sharing bandwidth fairly and keeping latency low. If its changing packet loss, that has to be a side-effect somehow.
CAKE prevents the queue building up and ensures fair access by using a variation of codel to control delay (latency) on individual flows.
I'm not exactly sure what a "flow" is or if you are increasing or decreasing it from default. I honestly wouldn't expect it to make any difference unless the link is maxed out.
Pet Packet Overhead AFAIK is to do with calculating the REAL bandwidth vs your link rate. Not sure if increasing it is really any different to just setting egress and ingree values lower.
I wonder if its doing something with the MTU causing packets to be smaller?
-
That was a good tip about the Link Layer Adaption. I've set it to 0 now, and the downstream bandwidth to 39000 kbps (down from 43000kbps).
The latency appears to be steady now :)
-
Do we have any OpenWRT experts on these forums that can explain what inputting "flows 100000" for the ingress and egress (for the settings shown above) actually does?
Its a limit for concurrent flows. What happens when its reached though no idea. But that will be plenty for a consumer connection.
-
The only drawback seems to be increased latency, which I presume would only get worse if I added another 0.
I haven't noticed increased latency during a stream with my current settings, only on Waveform's bufferbloat test, for the upstream only (300ms under load!).
Reducing both settings to 'flows 10000' results in around 0.7% packet loss on Mlab's speed test. When I tested it in stadia with this amount, it was a similar story.
-
Its a limit for concurrent flows. What happens when its reached though no idea. But that will be plenty for a consumer connection.
I was thinking more what the definition of a flow is in this context is. I was wondering if perhaps the more flows allowed the smaller chunks its splitting the data into, thus its sending smaller packets which is somehow mitigating the packet loss? Seems kinda unlikely though as the traffic were talking about is incoming, unless this configuration is somehow triggering the other end to use smaller packets, I don't see how its having an impact on a connection that isn't heavily loaded.
-
This is what shows up in OpenWRT's log if I just input '100000'
user.notice SQM: ERROR: cmd_wrapper: tc: FAILURE (1): /sbin/tc qdisc add dev ifb4pppoe-WAN parent 1: handle 110: fq_codel limit 1001 target 5000us interval 100000us noecn flows 1024 100000
user.notice SQM: ERROR: cmd_wrapper: tc: LAST ERROR: What is "100000"? Usage: ... fq_codel [ limit PACKETS ] [ flows NUMBER ] [ memory_limit BYTES ] [ target TIME ] [ interval TIME ] [ quantum BYTES ] [ [no]ecn ] [ ce_threshold TIME ] [ drop_batch SIZE ]
-
So, the settings I'm using so far are FQ_Codel for the Que discipline.
ECN on for both upstream and downstream. Needed to deal with network congestion, especially on the upstream.
DSCP packet options enabled.
'Advanced option string to pass to the ingress queueing disciplines' = 'flows 100000000'
With the egress equivalent option left blank.
Per Packet Overhead = 0
It's working really well, no hiccups. I don't know yet if there will be any negative side effects to setting the ingress queuing to such a high figure.
-
Has anyone else tried to use OpenWRT (SQM in particular) to resolve/avoid packet loss issues?
I'm guessing this would probably work on other routers with SQM also, but maybe not quite so well.
-
An example of a flow is a TCP connection. A flow is a set of related packets that form part of a conversation. UDP based application layer protocols can be examples of flows where many packets share the same source and destination addresses. In IPv6 there is a header field that is supposed to identify particular flows. However when the standard was released, the suggested correct usage of the flow field was very poorly defined so it has never been used much. There has been some guidance since then. One suggestion is to take source and destination address and ports, if TCP, and the IP protocol number, then take that 5-tuple and hash it all down to n bits, and the result would be your flow id. In the case of the IPv6 flow header iirc n is 20 bits, and if the result is zero then we make it 1, as zero means ‘unused’. Supposedly routers could possibly use this flow id to help with the routing process.
However routers and firewalls might have a firewall id that is any number of bits wide; it could be an index into a table, or an address. Just comparing two calculated or explicitly declared flow ids to see if two packets belong to the same flow (conversation) would be quicker than comparing all the address and port fields (if TCP), and if it’s the same flow then the latest packet would suffer the same fate as the previous one, being blocked or let through, or NATed.
It’s been a long time since I thought about this so I hope that my memory has not failed me.
-
So a flow would be similar to a NAT state?
-
No. If you’re a NAT translator you might associate the two concepts though. Flows are more general and don’t presume the existence of any NAT. A firewall using flows and hashing might just find this a faster way of doing lookup for the rule it needs to use. I haven’t heard th4 term used in conjunction with NAT; that was just my own deduction.
-
That's pretty much what I meant, that they are similar and might tie into each other on a router in some way as they're both working on the packet filtering layer.
-
I've had to keep retuning my SQM settings, as the VDSL2 line packet loss /line stability seems to fluctuate over days/ weeks. The 'Link Layer Adaption' option has made this process generally quicker.
I'm wondering how much of this is to do with the line being aluminium, and how much of it is just problems with VDSL2 related noise (including crosstalk) in general... I've found that resetting the VDSL2 modem could sometimes increase the amount of packet loss reported, then the settings needed adjusting once more. I suppose it's possible that the line has just gotten worse over time.
-
If you got packet loss due to the broadband tech such as errors on a DSL line, traffic shaping wont do anything for the packet loss.
If you got packet loss due to local congestion, basically high utilisation on your line, thats when it "may" help.
VDSL in this country is a "up to" service, so potentially rebooting the modem could make symptoms worse if it syncs at a lower speed meaning easier to hit congestion conditions. But in most cases unless the conditions of the line have changed significantly or its DLM slowing things down, then fluctuations between resync's should be minimal.
-
It looks like Openreach have done something to my line, or maybe the local BT exchange (maybe in the last week?), because I don't seem to need SQM anymore to reduce the packet loss on my line (with the 'flows' command). I disabled it completely and the line reported 0% packet loss on Mlab's test and very small amounts of loss when streaming in Stadia (these seem to correspond with bursts of streaming traffic from other devices).
I'm currently limiting download speed via a smart switch to 40mbps to keep the latency relatively low when the line is under heavy use, and it's working well :)
-
I'm not sure if this will help anyone else, but configuring the SQM latency like this has solved my packet loss problems on a FTTC aluminium line:
(https://i.imgur.com/Ss35xH3.jpg)
The 'latency target' options seem to do much the same thing as the two options below them, but they are much easier to configure and optimise. Curiously, the latency Stadia / other game streaming services doesn't seem to be affected with the above settings (latency reported in Stadia was between 10 - 35ms, depending on bandwidth usage). I've tested it for a couple of months now with these settings.
The problem with many routers, is that they don't have an SQM option, nor configurable options like what you get on a router with OpenWRT installed on it. I had to use the 'simplest_tbf.qos' Queue setup script for these configurable options to work properly, combined with a small bandwidth limit on the downstream and upstream.
The impression I get is that many routers by default automatically drop a certain percentage of WAN packets over a certain latency, perhaps 40-50ms.