Netcode and Network code needs optimizing. IPv6 connections need support.

Wreaken

What is netcode? It is a hard thing to explain to the general public who have no background in computer programming so I will make it as simple as I can.

The way that lag is "prevented" is that it is hidden. Information that does not exist yet (it happened in Australia, but you won't know for ~100+ milliseconds, because its traveling at only the speed of light to your computer) is simply made up. That's right, you make up the information, and your computer will play with the made up information.

In ~100 milliseconds, the information of your opponent will appear. Its a bit slow, but it should be enough to synchronize things just a little bit.

So really, a good "netcode" predicts what your opponent will do, and then displays it to you with reasonable accuracy. It can be cubic splines (in a FPS) or something similar... but at the end of the day, your netcode will have to make up information if your players want "low lag" in these conditions.

It is possible that maybe the netcoding of the game needs some fine tuning or optimizing.

Netcode has everything to do with the game basically all the way down to hit box checks on the target. Have you been running around ESO swinging at the target and not hitting anything even though you are standing on top of the target? Another example is when you run behind a solid object to line of sight the target, but still get hit by its ranged based projectiles, bad netcode. These are but some very trivial examples of how the netcode of the game needs some serious optimizing. I could go in to far greater detail, buff usage, location synchronization and in to technical issues revolving around transport layer protocols using TCP and UDP but I won't.

ZOS, you need to seriously get your Netcoding team on to this, people are claiming lag in many sceanrios that are netcode related simply because they don't know how to explain the situation any better.

If you are an avid gamer and have many games installed on your system and have no issues in other games both in the FPS world and MMO world with lag, but then you log in to ESO and have the above issues, then it can be only two things:

1. Network coding needs optimizing
2. Netcode needs optimizing

We also need IPv6 connections supported to go with this also please ZOS.

Please look in to these ZOS.

Wreaken

Anyone else?

Saerydoth

If you REAAAAAAAALY want to get technical, since we're for the most part using electrical signals, they do not travel at the speed of light. It's only the speed of light in a vacuum, and since they are travelling through a dielectric medium (copper wire usually), the speed is reduced to about 90-95% of the speed of light (depending on the medium).

I'm nitpicking of course. In a game like this, it is VERY difficult to predict what your opponent is going to do. That said, my experience is that this game handles lag better than WOW does. I do agree with you about ipv6 needing support.

Wreaken

While it is very hard to predict what your opponent is going to do from a PvP perspective, in a PvE environment it is actually quite easy for the systems in question to make up these values and determine what could be done due to the static nature of it.

The trick is to not over think it or try and have the system to bulky to over analyse it, but rather make sure the basics are flawless, moving, triggering actions, swings and misses on a hit box area etc. When netcoding, you are not trying to be a clairvoyant, but rather just make it feel less clunky and more fluid in regards to the ebb and flow of the push and pull in terms of combat and interaction with objects and opponents alike.

IPv6 in my honest opinion needs to be supported asap.

Vlas

Why does IPv6 need immediate support when it offers nothing relational to the game? IPv6 is Layer 3, which doesnt even touch Layer 4s TCP/UDP.

Hrithmus

All i know is that i have a SSD and download internet speed at 116mbps and upload at 40mbps and it takes me 3-4 minutes to load from screen to screen. I play on ultra settings.

I play guild wars 2 just fine with 0 lag and on ultra settings.

Vlas

You tried adding ESO.exe as a program exception to your Windows Firewall?

It works... trust me.

Kalston

IPv6... woot? How many people can even realistically use IPv6? Very very very very few.

Wreaken

louisrabierb16_ESO wrote: »

IPv6... woot? How many people can even realistically use IPv6? Very very very very few.

Just about every ISP on the market today supports IPv6, just not your average house hold user knows much about it.

Some of the benefits behind IPv6 are:
- No more NAT (Network Address Translation)
- Auto-configuration
- No more private address collisions
- Better multicast routing
- Simpler header format
- Simplified, more efficient routing
- True quality of service (QoS), also called "flow labelling"
- Built-in authentication and privacy support
- Flexible options and extensions
- Easier administration (say good-bye to DHCP)

Now, clearly some of these are not going to effect gaming and some do effect gaming.

The most common thing with IPv4 to IPv6 is the amount of traffic over IPv4 connections has reached its limit, hence the reason they started making IPv6 back in the 1990's. Because of the high amount of traffic on IPv4 connections today, it has caused natural congestion and overload, therefore, creating lag. IPv6 connections rectify this, and in time again, the same will repeat for IPv6, but over a longer period of time due to the structural nature of how IPv6 has been designed.

There is several games on the market today that have updated their network coding to support IPv6 connections and there is several titles that have been released with IPv6 support off the bat.

For a game like ESO being released at this point to not support it, one has to wonder why it doesn't. I like to think that it is something they will add in the not too distant future and it could very well fix a lot of peoples lag and connection stability issues due to being in areas that have a large strain over IPv4 traffic areas.

Vlas

Again... what does this have to do with the game? IPv6 is Layer 3.

Kalston

There is only one (or maybe 2) ISP in France that TRULY supports IPv6 (not including the ISPs for professionals since the average joe can't afford that), out of like 8 or so. I can't imagine it being much different in other countries, no way lol.

Regardless... what Vlas said. One does not simply move over to IPv6. Not yet, anyway.

RinaldoGandolphi

gain... what does this have to do with the game? IPv6 is Layer 3.

@vlas exactly...IPV6 isn't magically going to make the game faster....IPV6 was designed because IPV4 is running out of addresses. its not some magic pill that is going to fix everything.

Wreaken

Vlas wrote: »

Again... what does this have to do with the game? IPv6 is Layer 3.

IPv6 removes the need for layers because most transport and application-layer protocols need little or no change to operate over IPv6; exceptions are application protocols that embed internet-layer addresses, such as FTP and NTPv3, where the new address format may cause conflicts with existing protocol syntax.

Now on the other hand if you are talking about Network-Layer security, which was originally designed for IPv6 but found it's use in IPv4 first, for obvious reasons, has since become optional in the past 5 years.

So layers, are becoming a phased feature realistically and mean really nothing.

Now, correct me if I am wrong here, as technology will have it at the speed it upgrades in todays age, I will most likely never stop learning, as will anyone who takes a strong interest or does this for a living.

Vlas

IPv6 does not remove the need for layers.

Wreaken

louisrabierb16_ESO wrote: »

There is only one (or maybe 2) ISP in France that TRULY supports IPv6 (not including the ISPs for professionals since the average joe can't afford that), out of like 8 or so. I can't imagine it being much different in other countries, no way lol.

Regardless... what Vlas said. One does not simply move over to IPv6. Not yet, anyway.

Have you called them and confirmed this? I am willing to bet almost all your ISP's are IPv6 ready, however, are people willing to upgrade their hardware to gain the benefit from it? That is up to the user to justify that cost.

Wreaken

Vlas wrote: »

IPv6 does not remove the need for layers.

By all means, feel free to elaborate on that.

Vlas

Layers are an encapsulation methodology.

IPv6 is still an encapsulation, although it does combine Layer 2 and Layer 3.

Wreaken

woodsro wrote: »

gain... what does this have to do with the game? IPv6 is Layer 3.

@vlas exactly...IPV6 isn't magically going to make the game faster....IPV6 was designed because IPV4 is running out of addresses. its not some magic pill that is going to fix everything.

IPv6 never had anything to do with speed, it is about stability and reliability, something that IPv4 is having a hard time doing in todays age.

The most simplest way to explain it is like this. If you are living in a highly populated and dense area that has a high data traffic movement over a IPv4 IP's, you are more likely to be effected by natural congestion, it is just how it is.

With streaming data from cloud technology fast becoming the norm for todays age, it is even worse for IPv4 users.

Some people on these forums have done everything humanly possible to get their games to work. It is possible that it could be the network coding on ZOS's end, it could very well be this issue.

The safest bet is, to just have it as a option for people to test and try or even have it there for people who do have IPv6 connections.

michaelpatrickjonesnub18_ESO

Without getting too technical, this game does not run well at all.

Wreaken

michaelpatrickjonesnub18_ESO wrote: »

Without getting too technical, this game does not run well at all.

I agree 100% with you and it could do with some optimizing and fine tuning, which I am pretty sure everyone can agree on.

Wreaken

Something almost always goes bump in the night.

milaan_muc

Wreaken wrote: »

The most common thing with IPv4 to IPv6 is the amount of traffic over IPv4 connections has reached its limit, hence the reason they started making IPv6 back in the 1990's. Because of the high amount of traffic on IPv4 connections today, it has caused natural congestion and overload, therefore, creating lag. IPv6 connections rectify this, and in time again, the same will repeat for IPv6, but over a longer period of time due to the structural nature of how IPv6 has been designed.

You know that both IPv4 and IPv6 traffic is transported over the same network infrastructure? Just curious...

Wreaken

tobias.braunb16_ESO wrote: »

Wreaken wrote: »

The most common thing with IPv4 to IPv6 is the amount of traffic over IPv4 connections has reached its limit, hence the reason they started making IPv6 back in the 1990's. Because of the high amount of traffic on IPv4 connections today, it has caused natural congestion and overload, therefore, creating lag. IPv6 connections rectify this, and in time again, the same will repeat for IPv6, but over a longer period of time due to the structural nature of how IPv6 has been designed.

You know that both IPv4 and IPv6 traffic is transported over the same network infrastructure? Just curious...

Negative, they aren't. They aren't compatible which is why if you are not on a complete IPv6 backbone, your information needs to be broken back down in to IPv4, which is done at the node where IPv6 stops usually.

It is a lot more technical then this, I am just being very general.

milaan_muc

Wreaken wrote: »

tobias.braunb16_ESO wrote: »

Wreaken wrote: »

The most common thing with IPv4 to IPv6 is the amount of traffic over IPv4 connections has reached its limit, hence the reason they started making IPv6 back in the 1990's. Because of the high amount of traffic on IPv4 connections today, it has caused natural congestion and overload, therefore, creating lag. IPv6 connections rectify this, and in time again, the same will repeat for IPv6, but over a longer period of time due to the structural nature of how IPv6 has been designed.

You know that both IPv4 and IPv6 traffic is transported over the same network infrastructure? Just curious...

Negative, they aren't.

Im sorry, but if you think like this, you are completely wrong. Both v4 and v6 packets are transported over the same copper/optical network infrastructure. So, if a network link is at its limit, this effects both v4 and v6. There may be carriers who seperate v4 and v6 traffic but thats not something you can rely on and there is no benefit for doing such seperation.

Wreaken

Wreaken wrote: »

tobias.braunb16_ESO wrote: »

Wreaken wrote: »

The most common thing with IPv4 to IPv6 is the amount of traffic over IPv4 connections has reached its limit, hence the reason they started making IPv6 back in the 1990's. Because of the high amount of traffic on IPv4 connections today, it has caused natural congestion and overload, therefore, creating lag. IPv6 connections rectify this, and in time again, the same will repeat for IPv6, but over a longer period of time due to the structural nature of how IPv6 has been designed.

You know that both IPv4 and IPv6 traffic is transported over the same network infrastructure? Just curious...

Negative, they aren't.

tobias.braunb16_ESO wrote: »

Wreaken wrote: »

tobias.braunb16_ESO wrote: »

Wreaken wrote: »

The most common thing with IPv4 to IPv6 is the amount of traffic over IPv4 connections has reached its limit, hence the reason they started making IPv6 back in the 1990's. Because of the high amount of traffic on IPv4 connections today, it has caused natural congestion and overload, therefore, creating lag. IPv6 connections rectify this, and in time again, the same will repeat for IPv6, but over a longer period of time due to the structural nature of how IPv6 has been designed.

You know that both IPv4 and IPv6 traffic is transported over the same network infrastructure? Just curious...

Negative, they aren't.

Im sorry, but if you think like this, you are completely wrong. Both v4 and v6 packets are transported over the same copper/optical network infrastructure. So, if a network link is at its limit, this effects both v4 and v6. There may be carriers who seperate v4 and v6 traffic but thats not something you can rely on and there is no benefit for doing such seperation.

I think you might want to do some research on how IPv4 and IPv6 do not talk to each other or are compatible and how traffic over IPv4 is different from traffic over IPv6.

MollocH

IPv6 only makes sense if their server support IPv6 connections ... and why should they ? even if some ISP's support IPv6 on your home line, doesn't mean it's not gonna be translated multiple times to reach the ESO Servers.

There is zero utility added for an MMO by supporting IPv6.
IPv6 brings some nice advantages such as auto-config, no broadcast, ... But all these advantages aren't in any way related to stability or speed of their connections.

MollocH

tobias.braunb16_ESO wrote: »

Wreaken wrote: »

tobias.braunb16_ESO wrote: »

Wreaken wrote: »

The most common thing with IPv4 to IPv6 is the amount of traffic over IPv4 connections has reached its limit, hence the reason they started making IPv6 back in the 1990's. Because of the high amount of traffic on IPv4 connections today, it has caused natural congestion and overload, therefore, creating lag. IPv6 connections rectify this, and in time again, the same will repeat for IPv6, but over a longer period of time due to the structural nature of how IPv6 has been designed.

You know that both IPv4 and IPv6 traffic is transported over the same network infrastructure? Just curious...

Negative, they aren't.

Im sorry, but if you think like this, you are completely wrong. Both v4 and v6 packets are transported over the same copper/optical network infrastructure. So, if a network link is at its limit, this effects both v4 and v6. There may be carriers who seperate v4 and v6 traffic but thats not something you can rely on and there is no benefit for doing such seperation.

Not to mention, that most WAN technologies that carriers use are based on layer 2 (HDLC, PPP, Frame-relay)

milaan_muc

Wreaken wrote: »

I think you might want to do some research on how IPv4 and IPv6 do not talk to each other or are compatible and how traffic over IPv4 is different from traffic over IPv6.

I know that v4 and v6 packets are not compatible but that has nothing to do how they are transported. Do you have two DSL lines at home, one for v4 and one for v6? I guess it's just one ... and the same is happening in the carrier networks, they dont split v4 and v6, why should they?

Wreaken

tobias.braunb16_ESO wrote: »

Wreaken wrote: »

I think you might want to do some research on how IPv4 and IPv6 do not talk to each other or are compatible and how traffic over IPv4 is different from traffic over IPv6.

I know that v4 and v6 packets are not compatible but that has nothing to do how they are transported. Do you have two DSL lines at home, one for v4 and one for v6? I guess it's just one!

I have 3 DSL lines here to the house all with IPv6 enabled. Australia is completely IPv6 enabled and I am willing to bet that majority of USA is as well, it is up to your ISP and your hardware to determine if you are IPv6 ready.

In March 2014, 448 (92.8%) of the 483 top-level domains (TLDs) in the Internet supported IPv6 to access their domain name servers, and 441 (91.3%) zones contained IPv6 glue records, and approximately 5.7 million domains (3.4%) had IPv6 address records in their zones. Of all networks in the global BGP routing table, 17.4% had IPv6 protocol support.

So while almost the entire network infrastructure is IPv6 ready, you are only being held back by an ISP that isn't capable of supplying it too you and on that note in terms on IPv6 routing, if you are with an ISP that supplies you with an IPv6 connection, they would route you through the most logical IPv6 route trying to keep it IPv6 all the way, within reason obviously.

I do see where you are confusing the way the whole system functions though, you seem to be of the understanding that, I need a complete new line to support IPv6. That's not the case due to protocols and layers. Copper wire doesn't = one line = one transmission, you can still send multiple transmissions through copper line and have those layers broke into separate frequencies.


As for transport:

Overlay Networks

To date, before native IPv6 routing and applications were turned on, IPv6 has been in use via overlay networks that were built using tunnels or multiprotocol label switching. Initially, 6BONE and 6NET routed IPv6 through static tunnels. Dynamic approaches have since been developed, though, such as 6to4 (RFC 3056), Teredo (RFC 4380), and ISATAP (RFC 5214).

One solution that has been proposed for broadband access networks involves having the ISP continue to manage an IPv4 network, with IPv6 running as a tunnel overlay between the customer-provided-equipment (CPE) router and an ISP-identified tunnel endpoint. In this model the ISP does not offer native IPv6 service. As a transitional deployment step, the ISP indicates the IPv4 address of a tunnel endpoint to CPE routers when it configures them, and it includes an IPv6 prefix using DHCP-PD. This allows the ISP to traverse the parts of its network that are not yet ready to support native IPv6 forwarding.

The tunnelling of IPv4 through IPv6 is analogous to the tunnelling of IPv6 through IPv4, though only static tunnels are defined at this point.


Translation Technologies

Translation between IPv4 and IPv6 is not generally considered a viable long-term strategy, if only because it begs the question of the size of the address. If IPv6-to-IPv4 translation is sufficient to address the systems to which a user needs access, then one needs only to reallocate the existing IPv4 address space to solve the problem. Translation is, however, generally recognized as a necessity in certain cases to provide connectivity between IPv6-only and IPv4-only systems or networks. The issues that arise relate in part to path- MTU (maximum-transmission-unit) detection, which is often problematic in IPv4 networks but is required in IPv6 networks. Other issues involve supporting applications that are not designed on a client/server architecture or that require a sophisticated firewall traversal mechanism.

The Stateless IP/ICMP (Internet Control Message Protocol) Translation Algorithm (SIIT) (RFC 2765) is implemented in a translating router. The router advertises one or more IPv4 prefixes (perhaps host addresses) in IPv4 routing and a prefix in IPv6 routing. By defined transforms, it translates between IPv4 and IPv6 and between ICMP and ICMPv6.

NAT-PT (RFC 2766) extends the SIIT concept with a DNS application layer gateway. The gateway replicates A records from the IPv4 network as AAAA records carrying SIIT-compliant addresses in the IPv6 domain and advertises A records for the IPv6 hosts with SIIT addresses in the IPv4 domain. Doing this statelessly, however, implies either host routing in the IPv6 network, which has scaling issues, or a small IPv6 domain-nominally a single LAN-attached to a much larger IPv4 domain, because the upper 96 bits of the address in the IPv6 domain are static.

There is one problem with SIIT and NAT-PT: they are designed to enable small IPv6 islands to operate within a general IPv4 network, and they do not scale well in a more general deployment. Hence, the IETF is at this point working on next-generation translation technologies intended to support more general deployment, based on operational experience with SIIT, NAT-PT, and CERNET-CNGI's (China Education and Research Network-China Next-Generation Internet's) IVI prototype. This is expected to help larger networks deploy new services using IPv6-only networks before they become able to get all of their existing users to turn on IPv6. As IPv6 becomes generally deployed, the need for translation disappears and one can expect the technology to disappear, overtaken by events.

As for wether or not the servers can handle IPv6 connections, in this day and age, unless they bought some cheap and nasty servers from 10+ years ago they got cheap on ebay, then almost all server products today have IPv6 compatibility, it is up to the end user to switch it on.

raglau

Wreaken wrote: »

I think you might want to do some research on how IPv4 and IPv6 do not talk to each other or are compatible and how traffic over IPv4 is different from traffic over IPv6.

The above is true at the stack\app level but IPv4 and IPv6 traffic is still carried over the same infrastructure. Right now I have an IPv6 connection to my office running but am also sending IPv4 traffic over the same fibre connection and through the same exchange, as well as through the same switch and router my end.

My company has a datacentre that is moving to IPv6 internally (Windows Servers and clients natively talk) but still carries IPv4 traffic - apps such as Citrix and Lync that will not talk to the Windows IPv6 stack - net result is the same switches, routers and cables carry both sets of traffic. We could prioritise IPv6 if we chose to but that would be an internal archtitecture choice which you cannot guarantee in the outside world.

Everything you said about management is true but not the congestion stuff.

And the management items really only get ROI for enterprises, for most home users with a few bits of kit it's not a big deal as their IPv4 routers will dish out 200 odd addresses for them anyway. It's really mid to large enterprises where they are running out of addresses on various subnets and have to think about split DHCP scope resilience etc.

Yes, the world should move forward and I was very glad when my ISP went to IPv6 but for ZOS they have bigger fish to fry right now. Or at least more urgent fish.

milaan_muc

@Wreaken: Maybe we both miss our points. I totally agree that everyone should enable v6 if possible (and TESO should support it) and i see the benefits of the protocol (i've been to many v6 congresses in europe in the last years) but like i said above, using v6 doesnt mean your packets are transported on other lines than the v4 packets :-)