From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (syn-045-059-245-186.biz.spectrum.com [45.59.245.186]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EE80E3B2A4; Sat, 28 Sep 2024 21:35:11 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.53]) by mail.lang.hm (Postfix) with ESMTP id DDAB91E107E; Sat, 28 Sep 2024 18:35:10 -0700 (PDT) Date: Sat, 28 Sep 2024 18:35:10 -0700 (PDT) From: David Lang To: "David P. Reed" cc: David Lang , Dave Taht , Cake List , bloat In-Reply-To: <1727557632.49023402@apps.rackspace.com> Message-ID: <793rr84s-q113-npr2-21p0-4ror01s1p376@ynat.uz> References: <1727471439.369527853@apps.rackspace.com> <1727557632.49023402@apps.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Bloat] [Cake] bbr vs all the aqms, cake winning... X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2024 01:35:12 -0000 On Sat, 28 Sep 2024, David P. Reed wrote: > On Friday, September 27, 2024 17:43, "David Lang" said: > >> >> could the community try and produce 'traffic simulators' that implement these >> various protocols with a more realistic traffic pattern? something that can be >> turned up or down with a few presets of the mix that we can make available for >> the academics to use for their testing? > > It's a pretty good idea. > > However, some things I think about...it's important to remember that just recording traffic streams and playing them back filters out almost all of the "control" dynamics. That's why I was saying 'traffic simulator' rather than 'traffic replay'. A good simulator is a much harder problem The simulator needs both ends to send and receive traffid, dealing with delays, failures, and whatever the control system does. This means that the simulator isn't 'play these packets' (for all the reasons you gave) but rather is managing the simulation at layer 7, not at layer 2. It would be things like: 'open these connections and send data' The data can be junk, but it's timing and size match real traffic. There are a lot of different types of traffic, and only ISPs can provide information about the mix of the traffic for types, off the top of my head I know of: one-way streaming such as youtube, two way streaming such as zoom, bulk downloads, dependencies (DNS, http library calls, cache checks), gaming, bulk uploads, etc the control software would have knobs to adjust the mix of traffic types, the number of endpoints (on each end), the volume of data, and report on failures (hard failures where the data doesn't get through, soft failures where there is 'too much' latency for streaming/gaming', user perceived quality (page load times for simulated complex pages), etc and then throw this sort of traffic between the endpoints and see how it changes with different control systems. > However, this suggests a "stress simulator" that might help create realistic > experiments - instead of simulating traffic, simulate instabilities in routers > by injecting packets into queues for mix of flows based on some probabilistic > model that acts like "real Internet". These injected packets might, for > example, have invalid checksums on purpose to avoid harming any endpoint > stacks. So such a tool would be a lot easier to deploy. simulating failures is useful once you have a good case to start with. Based on this discussion, I don't believe that they are starting from a good point, so injecting failures won't get them to where they can tell if they can handle "real world" traffic well. A problem injector is also easier than the type of simulation master I'm talking about. David Lang