Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 24 Mar 2020 10:53:44 -0400
From:   Bob Copeland <me@bobcopeland.com>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org,
        Masashi Honma <masashi.honma@gmail.com>
Subject: Re: wmediumd MAC implementation/simulation
Message-ID: <20200324145344.GA17278@bobcopeland.com>
References: <30484acdee4cd19078673f4f4229dfae49b17804.camel@sipsolutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <30484acdee4cd19078673f4f4229dfae49b17804.camel@sipsolutions.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 23, 2020 at 02:56:46PM +0100, Johannes Berg wrote:
> I wonder if this should be split, implementing a "real" MAC for hwsim,
> and then sending also the ACKs "properly", perhaps implementing RTS/CTS
> behaviour in the MAC, etc.?

The reason I did it this way was to go more for rough approximation rather
than fidelity to get whatever simplifications that allows.  For example,
loop really only considers a single frame at a time (and all of its rateset)
rather than all the possible stations that could be sending at a given time
step.  That is good enough for comparing rate controllers, and doing some
mesh testing with a few one-off hacks bolted on top, but nowhere near
complete.

That said, splitting them apart and having more realistic mac layer sounds
reasonable -- how do you anticipate it looking?

> Or perhaps then that's too much complexity and I should just teach ns3
> the hwsim virtio interface?

Up to you :)

-- 
Bob Copeland %% https://bobcopeland.com/