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

"Bless, Roland (TM)" <roland.bless@kit.edu> Fri, 03 February 2023 13:37 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3FBC16B5D6 for <tsvwg@ietfa.amsl.com>; Fri, 3 Feb 2023 05:37:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLuceSOWATxa for <tsvwg@ietfa.amsl.com>; Fri, 3 Feb 2023 05:37:39 -0800 (PST)
Received: from iramx1.ira.uni-karlsruhe.de (iramx1.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7917C14CE44 for <tsvwg@ietf.org>; Fri, 3 Feb 2023 05:37:38 -0800 (PST)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx1.ira.uni-karlsruhe.de with esmtpsa port 25 iface 141.3.10.8 id 1pNwFx-0002uV-FB; Fri, 03 Feb 2023 14:37:33 +0100
Received: from [IPV6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 58533D00153; Fri, 3 Feb 2023 14:37:33 +0100 (CET)
Message-ID: <29e42735-1179-bda4-851e-891727ad388e@kit.edu>
Date: Fri, 03 Feb 2023 14:37:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.4.2
Content-Language: de-DE, en-US
To: Sebastian Moeller <moeller0@gmx.de>, Ruediger.Geib@telekom.de
Cc: tsvwg@ietf.org
References: <167348364734.15098.9183646444272144529@ietfa.amsl.com> <FR2P281MB1527D9C44F4208923484CEF19CD79@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM> <DFFC6091-65DF-4572-BDAC-F8F2D649987E@gmx.de>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
In-Reply-To: <DFFC6091-65DF-4572-BDAC-F8F2D649987E@gmx.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx1.ira.uni-karlsruhe.de)
X-ATIS-Checksum: v3zoCAcc32ckk
X-ATIS-Timestamp: iramx1.ira.uni-karlsruhe.de esmtpsa 1675431453.507336347
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/njyedPr1jB1sVq8M-ycjvb3ifjU>
Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb-15.txt - Definition of gaming/game traffic
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2023 13:37:43 -0000

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

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

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.

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, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> 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 <tsvwg-bounces@ietf.org> Im Auftrag von internet-drafts@ietf.org
>> Gesendet: Donnerstag, 12. Januar 2023 01:34
>> An: i-d-announce@ietf.org
>> Cc: tsvwg@ietf.org
>> 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
>>
>>
>