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

[Sebastian Moeller <[e-mail]>]

Hi Ruerdiger,

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
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.

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
> 
>