Gaming Consoles and IPv4

Mon Sep 28 19:55:49 UTC 2020

>
> Delay, or “lag” in gamer parlance is everything. Have too much lag and you
> are dead without realizing you are dead. Lag frustrates gamers enormously
> and is probably one of the main drivers of NOC calls.
>

Lag is frequently abused by gamers as a crutch excuse for why they aren't
as successful as their favorite Twitch streamer or their friends. Often
times that extra 15ms of extra latency that their kid is screaming about
because they got fragged means nothing when their monitor is only
refreshing frames at 100ms. It has however given rise to generally useless
products like the old Killer NICs, which only provided benefits to network
performance if you were running a potato of a machine that was being run
over by the game, in which case any other core component upgrade was a
better choice. But they made a lot of money eventually being bought, so
good for them.

Peer to peer games absolutely do suffer from latency issues, often either
artificially induced on one side to abuse poor netcode, or essentially
DoSing a target such that they cannot properly play. A quick example that
comes to mind is the Destiny series that has suffered from this problem
since day 1, but still made Bungie a lot of money while doing so.

On Mon, Sep 28, 2020 at 3:30 PM Carlos M. Martinez <carlosm3011 at gmail.com>
wrote:

> Delay, or “lag” in gamer parlance is everything. Have too much lag and you
> are dead without realizing you are dead. Lag frustrates gamers enormously
> and is probably one of the main drivers of NOC calls.
>
> It seems to me that a purely client/server model will inherently have more
> lag issues than a peer-to-peer game.
>
> Not to mention cost… if you are the game publisher suddenly you’re faced
> with maintaining a global footprint of servers with all that implies.
>
> /Carlos
>
> On 28 Sep 2020, at 11:21, Tom Beecher wrote:
>
> Why stray away from how PC games were 20 years ago where there was a
>> dedicated server and clients just spoke to servers?
>
>
> Much cheaper to just let all the game clients talk peer to peer than it is
> to maintain regional dedicated server infrastructure.
>
> On Mon, Sep 28, 2020 at 8:35 AM Mike Hammett <nanog at ics-il.net> wrote:
>
>> Why stray away from how PC games were 20 years ago where there was a
>> dedicated server and clients just spoke to servers?
>>
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions <http://www.ics-il.com/>
>> <https://www.facebook.com/ICSIL>
>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
>> <https://www.linkedin.com/company/intelligent-computing-solutions>
>> <https://twitter.com/ICSIL>
>> Midwest Internet Exchange <http://www.midwest-ix.com/>
>> <https://www.facebook.com/mdwestix>
>> <https://www.linkedin.com/company/midwest-internet-exchange>
>> <https://twitter.com/mdwestix>
>> The Brothers WISP <http://www.thebrotherswisp.com/>
>> <https://www.facebook.com/thebrotherswisp>
>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>> ------------------------------
>> *From: *"Justin Wilson (Lists)" <lists at mtin.net>
>> *To: *"North American Network Operators' Group" <nanog at nanog.org>
>> *Sent: *Monday, September 28, 2020 7:22:28 AM
>> *Subject: *Re: Gaming Consoles and IPv4
>>
>> There are many things going on with gaming that makes natted IPv4 an
>> issue when it comes to consoles and gaming in general.   When you break it
>> down it makes sense.
>>
>> -You have voice chat
>> -You are receiving data from servers about other people in the game
>> -You are sending data to servers about yourself
>> -If you are using certain features where you are “the host” then you are
>> serving content from your gaming console.  This is not much different than
>> a customer running a web server.  You can’t have more than one customer
>> running a port 80 web-server behind nat.
>> -Streaming to services like Twitch or YouTube
>>
>> All of these take up standard, agreed upon ports. It’s really only
>> prevalent on gaming consoles because they are doing many functions.  Look
>> at it another way.  You have a customer doing the following.
>>
>> -Making a VOIP call
>> -Streaming a movie
>> -Running a web server
>> -Running bittorrent on a single port
>> -Having a camera folks need to access from the outside world
>>
>> This is why platforms like Xbox developed things like Teredo.
>>
>> Justin Wilson
>> j2sw at mtin.net
>>
>> —
>> https://j2sw.com - All things jsw (AS209109)
>> https://blog.j2sw.com - Podcast and Blog
>>
>> On Sep 27, 2020, at 9:33 PM, Daniel Sterling <sterling.daniel at gmail.com>
>> wrote:
>>
>> Matt Hoppes raises an interesting question,
>>
>> At the risk of this being off-topic, in the latest call of duty games
>> I've played, their UDP-NAT-breaking algorithm seems to work rather well and
>> should function fine even behind CGNAT. Ironically turning on upnp makes
>> this *worse*, because when their algorithm probes to see what ports to use,
>> upnp sends all traffic from the "magical xbox port" to one box instead of
>> letting NAT control the ports. This does cause problems when multiple
>> xboxes are behind one NAT doing upnp. If upnp is on and both xboxes are
>> fully powered off and then turned on one at a time, things do work. But
>> when upnp is off everything works w/o having to do that.
>>
>> There are many other games and many CPE NAT boxes that may do horrible
>> things, but CGNAT by itself shouldn't cause problems for any recent device
>> / gaming system.
>>
>> It is true that I've yet to see any FPS game use ipv6. I assume that's
>> cuz they can't count on users having v6, so they have to support v4, and it
>> wouldn't be worth their while to have their gaming host support dual-stack.
>> just a guess there
>>
>> -- Dan
>>
>>
>>
>> On Sun, Sep 27, 2020 at 7:29 PM Mike Hammett <nanog at ics-il.net> wrote:
>>
>>> Actually, uPNP is the only way to get two devices to work behind one
>>> public IP, at least with XBox 360s. I haven't kept up in that realm.
>>>
>>>
>>>
>>> -----
>>> Mike Hammett
>>> Intelligent Computing Solutions <http://www.ics-il.com/>
>>> <https://www.facebook.com/ICSIL>
>>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
>>> <https://www.linkedin.com/company/intelligent-computing-solutions>
>>> <https://twitter.com/ICSIL>
>>> Midwest Internet Exchange <http://www.midwest-ix.com/>
>>> <https://www.facebook.com/mdwestix>
>>> <https://www.linkedin.com/company/midwest-internet-exchange>
>>> <https://twitter.com/mdwestix>
>>> The Brothers WISP <http://www.thebrotherswisp.com/>
>>> <https://www.facebook.com/thebrotherswisp>
>>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>>> ------------------------------
>>> *From: *"Matt Hoppes" <mattlists at rivervalleyinternet.net>
>>> *To: *"Darin Steffl" <darin.steffl at mnwifi.com>
>>> *Cc: *"North American Network Operators' Group" <nanog at nanog.org>
>>> *Sent: *Sunday, September 27, 2020 1:22:51 PM
>>> *Subject: *Re: Gaming Consoles and IPv4
>>>
>>> I understand that. But there’s a host of reasons why that night not work
>>> - two devices trying to use UPNP behind the same PAT device, an apartment
>>> complex or hotel WiFi system, etc.
>>>
>>> On Sep 27, 2020, at 2:17 PM, Darin Steffl <darin.steffl at mnwifi.com>
>>> wrote:
>>>
>>> 
>>> This isn't rocket science.
>>>
>>> Give each customer their own ipv4 IP address and turn on upnp, then they
>>> will have open NAT to play their game and host.
>>>
>>> On Sun, Sep 27, 2020, 12:50 PM Matt Hoppes <
>>> mattlists at rivervalleyinternet.net> wrote:
>>>
>>>> I know the solution is always “IPv6”, but I’m curious if anyone here
>>>> knows why gaming consoles are so stupid when it comes to IPv4?
>>>>
>>>> We have VoIP and video systems that work fine through multiple layers
>>>> of PAT and NAT. Why do we still have gaming consoles, in 2020, that can’t
>>>> find their way through a PAT system with STUN or other methods?
>>>>
>>>> It seems like this should be a simple solution, why are we still
>>>> opening ports or having systems that don’t work?
>>>
>>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200928/6ebe61d2/attachment.html>