What's new

[Release] FreshJR Adaptive QOS (Improvements / Custom Rules / and Inner workings)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
I'm actually quite saddened to hear the relase is delayed I was quite looking forward to it, would it be possible to perhaps relase the script without IPv6 as a beta relase then the full version once the IPv6 conundrum is resolved?
What is it you intend to beta? He said hes hit a roadblock and its not going to work or at least currently doesnt.
 
What is it you intend to beta? He said hes hit a roadblock and its not going to work or at least currently doesnt.
He's it a roadblock with IPv6, not the other changes.
 
@Sinner / @Vexira , A partial release is possible but currently it is in a half finished state.

Eg.

If not intending to use rules with local device filtering elements, the other fields are working correctly with IPv6 connections.

If requiring rules with that perform filtering on local device elements, statefull IPv6 is indeed a functioning work around. (This hasn't been implemented since I don’t like statefull IPv6).

--

I do not want to spend the time tailoring the code to work with statefull IPv6 if there exists an alternate way to implement stateless operation.

I am experimenting with different approaches. Simply put, its delayed until I figure out the path to take. With programming, half finished doesn't cut it. Why waste time going to wrong direction.
 
Last edited:
I am experimenting with different approaches. Simply put, its delayed until I figure out the path to take. With programming, half finished doesn't cut it. Why waste time going to wrong direction.
I prefer this approach as well. Better wait until you are totally happy with it. No rush at this end.
 
@FreshJR would it perhaps make sense for another point release (i.e. 8.9) to add "port 853" support? Since there are many users who are on the new Merlin 384.11 beta (for DoT purposes) - and I'm not sure what's happening with DNS-over-TLS queries on the current version of your script - are they being whitelisted, or could those packets conceivably be grouped in with lower-priority traffic groups? (thus resulting in lag etc)
 
@FreshJR would it perhaps make sense for another point release (i.e. 8.9) to add "port 853" support? Since there are many users who are on the new Merlin 384.11 beta (for DoT purposes) - and I'm not sure what's happening with DNS-over-TLS queries on the current version of your script - are they being whitelisted, or could those packets conceivably be grouped in with lower-priority traffic groups? (thus resulting in lag etc)

yeh there is that maybe and the manual change ive done to mine to the game downloads I believe there the sport/dport was wrong... this one was definitely a good fix at a minimum.
 
@FreshJR would it perhaps make sense for another point release (i.e. 8.9) to add "port 853" support? Since there are many users who are on the new Merlin 384.11 beta (for DoT purposes) - and I'm not sure what's happening with DNS-over-TLS queries on the current version of your script - are they being whitelisted, or could those packets conceivably be grouped in with lower-priority traffic groups? (thus resulting in lag etc)
Thank you for better articulating what I meant to ask for an incremental relase, I was thinking that it would be nice if the burst options were added to this 8.9 theoretical relase.
 
Good news is that I am actively working on the script.

I will dedicate the time preparing a fully functioning release, one that will NOT attempt to work around the inability of local device identification when using stateless IPv6, even if it means erasing the newly created code later :confused:

I can almost guarantee stateless IPv6 will require bulky structural changes with creative logic.
 
Last edited:
Good news is that I am actively working on the script.

I will dedicate the time preparing a fully functioning release, one that will NOT attempt to work around the inability of local device identification when using stateless IPv6, even if it means erasing the newly created code later :confused:

I can almost guarantee stateless IPv6 will require bulky structural changes with creative logic.
It's a shame my ISP doesn't have IPv6 support yet which annoys me because of a couple of reasons if I had it I'd try to he the first to offer you a testing ground for it, be the guinea pig for any nessicary tests.

Maybe reason I want IPv6 is so I don't have to worry about Nat.
 
It's a shame my ISP doesn't have IPv6 support yet which annoys me because of a couple of reasons if I had it I'd try to he the first to offer you a testing ground for it, be the guinea pig for any nessicary tests.

Maybe reason I want IPv6 is so I don't have to worry about Nat.

You do know that both endpoints need to use IPv6 for it to take effect.

Games will remain ipv4 for quite some time due to legacy reasons.
 
You do know that both endpoints need to use IPv6 for it to take effect.

Games will remain ipv4 for quite some time due to legacy reasons.
Yes I am I did a bit of research, I was wondering why my Xbox was harping on about tedro and IPv6 tunneling, it made me wonder why my Xbox one had a tedro under upnp, something about Microsoft using ipv4 to 6 tunneling or something.
 
You do know that both endpoints need to use IPv6 for it to take effect.

Games will remain ipv4 for quite some time due to legacy reasons.
But also thank you for all the hard work you already have put into this project it's made adaptive QoS amazing.
 
Yes I am I did a bit of research, I was wondering why my Xbox was harping on about tedro and IPv6 tunneling, it made me wonder why my Xbox one had a tedro under upnp, something about Microsoft using ipv4 to 6 tunneling or something.

Teredo allows you to talk with IPv6 servers even though you are operating on IPv4.

It does so by connecting you to a Microsoft proxy via ipv4. The proxy sends/receives data to remote hosts via ipv6 but encapsulates traffic into ipv4 before relaying it to/from you.



Now the question is does Microsoft force all xbox data to be ipv6, or is toredo just used for certain cases, more specifically is teredo only used to communicate with ipv6 only Microsoft servers that are performing a small subset of features within the Xbox live environment.

(Answer: Teredo is most likely present as a fallback when requiring the ability for ipv4 clients to talk to Microsoft servers that do NOT have an ipv4 address. This means it is only used for for match making servers, notifications, in game messages, etc, but not the critical ingame data)




If all Xbox data was actually mandated to be ipv6 and if Xbox was hosting teredo relays for any ipv4 user and mandating their use, then why would NAT type matter?
(Answer: It wouldn’t as the teredo tunnels would always transverse NAT configuration)

This means that Microsoft obviously choose the cheap route and does NOT route game data via teredo for ipv4 users. (Tunneling all game data would be expensive)

Combination Table - Cheap Method

Code:
Host             Client               Connection
IPv6+IPv4        IPv6+IPv4            IPv6
IPv6+IPv4        IPv6                 IPv6
IPv6+IPv4        IPv4                 IPv4

IPv6             IPv6+IPv4            IPv6
IPv6             IPv6                 IPv6
IPv6             IPv4                 (Toredo or exclude IPv4 player from joining match)
 
IPv4             IPv6+IPv4            IPv4
IPv4             IPv6                 (Toredo or exclude IPv6 player from joining match)
IPv4             IPv4                 IPv4

Combination Table - Expensive Method

Code:
Host             Client               Connection
IPv6+IPv4        IPv6+IPv4            IPv6
IPv6+IPv4        IPv6                 IPv6
IPv6+IPv4        IPv4                 (Toredo && Nat issues impossible)

IPv6             IPv6+IPv4            IPv6
IPv6             IPv6                 IPv6
IPv6             IPv4                 (Toredo && Nat issues impossible)
  
IPv4             IPv6+IPv4            (Toredo && Nat issues impossible)
IPv4             IPv6                 (Toredo && Nat issues impossible)
IPv4             IPv4                 (Toredo && Nat issues impossible)
 
Last edited:
Teredo allows you to talk with IPv6 servers even though you are operating on IPv4.

It does so by connecting you to a Microsoft proxy via ipv4. The proxy sends/receives data to remote hosts via ipv6 but encapsulates traffic into ipv4 before relaying it to/from you.



Now the question is does Microsoft force all xbox data to be ipv6, or is toredo just used for certain cases, more specifically is teredo only used to communicate with ipv6 only Microsoft servers that are performing a small subset of features within the Xbox live environment.

(Answer: Teredo is most likely present as a fallback when requiring the ability for ipv4 clients to talk to Microsoft servers that do NOT have an ipv4 address. This means it is only used for for match making servers, notifications, in game messages, etc, but not the critical ingame data)




If all Xbox data was actually mandated to be ipv6 and if Xbox was hosting teredo relays for any ipv4 user and mandating their use, then why would NAT type matter?
(Answer: It wouldn’t as the teredo tunnels would always transverse NAT configuration)

This means that Microsoft obviously choose the cheap route and does NOT route game data via teredo for ipv4 users. (Tunneling all game data would be expensive)

Combination Table - Cheap Method

Code:
Host             Client               Connection
IPv6+IPv4        IPv6+IPv4            IPv6
IPv6+IPv4        IPv6                 IPv6
IPv6+IPv4        IPv4                 IPv4

IPv6             IPv6+IPv4            IPv6
IPv6             IPv6                 IPv6
IPv6             IPv4                 (Toredo or exclude IPv4 player from joining match)
 
IPv4             IPv6+IPv4            IPv4
IPv4             IPv6                 (Toredo or exclude IPv6 player from joining match)
IPv4             IPv4                 IPv4

Combination Table - Expensive Method

Code:
Host             Client               Connection
IPv6+IPv4        IPv6+IPv4            IPv6
IPv6+IPv4        IPv6                 IPv6
IPv6+IPv4        IPv4                 (Toredo && Nat issues impossible)

IPv6             IPv6+IPv4            IPv6
IPv6             IPv6                 IPv6
IPv6             IPv4                 (Toredo && Nat issues impossible)
 
IPv4             IPv6+IPv4            (Toredo && Nat issues impossible)
IPv4             IPv6                 (Toredo && Nat issues impossible)
IPv4             IPv4                 (Toredo && Nat issues impossible)
Which would explain why they seem to have implemented it in windows 10 also as part of the Xbox networking components I've seen a lot of discussion regarding this, it seems to be some what an important component of thier networking for Xbox live seeing as it has significantly changed since I played during the Xbox 360 eara, any way thanks for the explanation.

But oddly I have see Nat become an issue when the port wasn't being forwarded the one that the Xbox users or the app in windows which replaces games for windows Live.


So technically in theory once IPv6 becomes the norm they could just drop a patch to have native support enabled for the clients that can use it natively while keeping tedro as the middle man translator for the remaining ipv4 clients, hmmmm....

This makes me wonder how much overhead the running processes would have on connections in general and if it's accounted for by QoS as in the game traffic can be detected event though it's being tunneled, seems like I have a lot of reading to do now:):):)
 
NAT is an issue since they are not using to teredo for game data. They are using it for small segments of XBL sparsely.

They don’t need to drop a patch to disable it. Once a client has an IPv6 address, teredo tunneling should not be used as its not needed.

The overhead is an extra hop and some headers stuck onto the packet. Yes it would be accounted for in QoS since it shows up as a regular udp IPv4 packet when it reaches your router.
 
NAT is an issue since they are not using to teredo for game data. They are using it for small segments of XBL sparsely.

They don’t need to drop a patch to disable it. Once a client has an IPv6 address, teredo tunneling should not be used as its not needed.

The overhead is an extra hop and some headers stuck onto the packet. Yes it would be accounted for in QoS since it shows up as a regular udp IPv4 packet when it reaches your router.
I was wondering that but like you said it must be minimal since I'm getting pretty good ping in battlefield one on Xbox which seems strange to me.

But Ive been theorising that it's only use on games like halo and gears since they seem to more or less use the Microsoft networking not sure what other games it applys to, from what I can see is that ea is using more or less thier own infrastructure over Microsoft since battlefield one seems identical to the pc version in that regard granted I could be wrong.
 
More likely they don’t use it at all for game p2p data to save money.

Toredo could have been enabled interface level for all traffic if they wanted.
 
More likely they don’t use it at all for game p2p data to save money.

Toredo could have been enabled interface level for all traffic if they wanted.
I half wonder if it's being used in Titanfall 2 though I'll check the router to make sure it's being prioritise correctly, incase it's what is causing my erratic ping, or it's being pushed out of region and I'm connecting to random people.
 
I half wonder if it's being used in Titanfall 2 though I'll check the router to make sure it's being prioritise correctly, incase it's what is causing my erratic ping, or it's being pushed out of region and I'm connecting to random people.

Well when playing a multiplayer match, you are actually connecting to random player in match who is acting as host.

The host receives packets from all players.
He processes the aggregate of this information.
He sends out updated the world information to all clients.

If the host has a poor internet connection, everyone experiences high pings and delays. The delays/pings are caused on the host side and not issues on the client side.

Multiplayer gaming is not p2p.
It’s centralized, so you can’t just look at your own internet performance when gaming.

Games with dedicated servers are reliable.
Games using a random player in the match as a host are a toss up.

(Eg. We make good hosts due to reserving bandwidth for game applications)
 
Thank you for all you do. Found this thread and followed the setup guide with no hiccups. Running on an RT-AC88U connected to an MB8600 on Docsis 3.1 and Bufferbloat is now in the A to A+ range. Will continue to test and check in as IPv6 is rolled in.
 
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top