Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Definition of gaming/game traffic

[Sebastian Moeller <[e-mail]>]

Hi Roland,


> On Feb 3, 2023, at 14:37, Bless, Roland (TM) <[e-mail]> wrote:
> 
> Hi Sebastian,
> 
> On 03.02.23 at 10:13 Sebastian Moeller wrote:
>> thanks for bringing this up again. I have a suspicion, that the "games and gaming" examples were not deeply researched before being added to the description.
>> a) with game streaming services likenvidia's gforce now, microsoft cloud gaming and more some games will have a considerable download traffic
> 
> Yes, streaming screen output is a completely different thing than just to transmit control traffic (game sync).

	We all a agree, and I am sure that NQB was never intended to be used for streaming traffic, however such packets are genuine "gaming" packets that users of such services consider important. "Game sync" seems not correct either, because games really do not try (hard) to actually synchronize and generate a common causality for all players, they really want to distribute updates of veridical world state to the clients that have been running predictive simulations of that world state since the last update and that then will try to bring their local state into compliance with the servers authoritative idea about world state.


> 
>> b) some on-line FPS games with sufficient players show bursty traffic on the oder of 10Mbps (averaged over longer periods) which is both to high sustained rate and especially too high burst rate to fit NQB criteria.
> 
> Do you have a source for this?

	In a discussion in the OpenWrt forum a user of Valorant reported 10-19Mbps sustained traffic during game play, that ceased once the games was exited. Not a gamer myself I have no data to support that, but I also have no reason to doubt that number. With a 128 Hz tick and ~10 players that boils down to:

(10 Mbps * 1000^2/ (8 bit/byte)) / (128 Hz) = 9765.625 bBytes per tick. This will require more than one packet per tick hence "bursts" (world updates need to be distributed ASAP, so pacing is not an attractive option).

	Now, I would prefer to just get a packet capture of the game in question, but I am a linux/macos only shop and Valorant is windows only... not sure I am prepared to buy a windows machine capable enough for 128Hz gaming just to support my point that the authors of the NGB draft (and of the L4S RFCs) should actually make sure that their definition of gaming traffic matches what is used in the field today. ;)



> 10Mbit/s seems to me quite high even for modern FPS games or do you mean aggregated data rate instead of an individual flow? In the past, FPS games had a very low data rate (few kbit/s) and around 20–40 packets per second for their "game sync" traffic, see also
> https://ieeexplore.ieee.org/document/5445069,
> https://link.springer.com/chapter/10.1007/11600930_106
> or even
> https://www.ietf.org/proceedings/87/slides/slides-87-tsvarea-1.pdf

	Valorant operates on as 128 Hz tickrate, so even if the world state fits into a single packet, we already exceed that old estimate by a factor of 3-4... but it seems that there are more packets per update (I would not be amazed if these would be per player/entity in the current players "cone of game causality").


> 
> Not sure about the nomenclature, usually it's player's actions and
> movements from the client toward the server and game state back to the client, so game sync captures both somehow.

	Yes, given enough annotations "game sync" works, however unless there is estalished nomenclature already can we find a terminology requiring less/no additional explanation?

Regards
	Sebastian

> 
> Regards,
> Roland
> 
>> I would appreciate if any list-members associated with game studios could comment upon the current and expected trends in "gaming traffic" per session. My hunch is that NQB targets the on-line games of the past and not the games of today, let alone of tomorrow.
>> Regards
>> 	Sebastian
>> P.S.: How about asking game developers how they call such packets? Maybe no need to invent a new nomenclature that differs from the nomenclature used in the field already? And if we invent something "game sync" seems worse that "world state update", no?
>>> On Feb 3, 2023, at 09:07, <[e-mail]> <[e-mail]> wrote:
>>> 
>>> Hi Greg,
>>> 
>>> Please provide a definition of "games and gaming, respectively" and clarify to the reader, that you define this term in a technical sense for draft NQB, before you start using it. I've found:
>>> - low-data-rate online gaming
>>> - Current examples include many online games,..
>>> - draft-ietf-tsvwg-aqm-dualq-coupled: Both Classic and L4S services can cope with a proportion of
>>>      unresponsive ..traffic....(e.g. DNS, VoIP, game sync datagrams, etc.)
>>> - https://www.rfc-editor.org/rfc/rfc9331.html: this document discusses the conditions for mixing other "'Safe' Unresponsive Traffic" (e.g., DNS, LDAP, NTP, voice, and game sync packets). 1 of 5 times, always "game sync packets"
>>> - https://www.rfc-editor.org/rfc/rfc9332.html: unresponsive traffic.... (e.g., DNS, Voice over IP (VoIP), game sync datagrams, etc.).
>>> 
>>> I don't understand, why the definition of game related traffic differs between RFC's 9331, 9332 (where game related terminology is applied stringent as "game sync packets") and standards track draft NQB. In the latter, game/gaming appears twice, diverges for some untold reason from L4S terminology and isn't defined stringently within the doc. Please use "game sync packets" through draft NQB, as this is compliant with text of RFCs 9331 and 9332.
>>> 
>>> Regards,
>>> 
>>> Ruediger
>>> 
>>> 
>>> 
>>> -----Ursprüngliche Nachricht-----
>>> Von: tsvwg <[e-mail]> Im Auftrag von [e-mail]
>>> Gesendet: Donnerstag, 12. Januar 2023 01:34
>>> An: [e-mail]
>>> Cc: [e-mail]
>>> Betreff: [tsvwg] I-D Action: draft-ietf-tsvwg-nqb-15.txt
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Transport Area Working Group WG of the IETF.
>>> 
>>>        Title           : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
>>>        Authors         : Greg White
>>>                          Thomas Fossati
>>>  Filename        : draft-ietf-tsvwg-nqb-15.txt
>>>  Pages           : 25
>>>  Date            : 2023-01-11
>>> 
>>> Abstract:
>>>   This document specifies properties and characteristics of a Non-
>>>   Queue-Building Per-Hop Behavior (NQB PHB).  The purpose of this NQB
>>>   PHB is to provide a separate queue that enables smooth, low-data-
>>>   rate, application-limited traffic flows, which would ordinarily share
>>>   a queue with bursty and capacity-seeking traffic, to avoid the
>>>   latency, latency variation and loss caused by such traffic.  This PHB
>>>   is implemented without prioritization and can be implemented without
>>>   rate policing, making it suitable for environments where the use of
>>>   these features is restricted.  The NQB PHB has been developed
>>>   primarily for use by access network segments, where queuing delays
>>>   and queuing loss caused by Queue-Building protocols are manifested,
>>>   but its use is not limited to such segments.  In particular,
>>>   applications to cable broadband links, Wi-Fi links, and mobile
>>>   network radio and core segments are discussed.  This document
>>>   recommends a specific Differentiated Services Code Point (DSCP) to
>>>   identify Non-Queue-Building flows.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/
>>> 
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-15.html
>>> 
>>> A diff from the previous version is available at:
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-nqb-15
>>> 
>>> 
>>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>> 
>>> 
>