[Ns-developers] Requesting help for csma promiscuous mode

[Gustavo Carneiro]

2008/7/7 <craigdo at ee.washington.edu>:

>
> >   4- I really think it makes no sense in NS-3 to have a
> > "promiscuous mode"
> > if we have a single receive callback in netdevices.  Might as
> > well _always_
> > receive in promiscuous mode because a) simplifies API, and b)
> > allows subtle
> > bugs of a protocol handler not being prepared for promiscuous
> > mode, due to a
> > bug, and suddenly another handler activates the promiscuous mode and
> > triggers a bug in the first handler, until then undiscovered.
> >  "Modes" in
> > general are usually evil because of the way they attract bugs
> > when multiple
> > independent code modules are brought together into the same system.
>
> I think having the net devices always be in promiscuous mode is very
> strange.
>
> From the perspective of a system that tries to reflect real hardware and
> real software, having devices that do something like this would be contrary
> to this spirit, IMO.  In every ethernet-like device I've ever worked with,
> there has been a special bit that defaults to off which you have to turn on
> to get into promiscuous mode.  The root of the thing is a bit in a register
> on an ethernet controller chip.  It's the way the world works.  I think
> it's
> what people will expect.  It's what I would expect.
>
> What kind of pcap traces would devices that always operate in promiscuous
> mode generate?  Would these be terribly useful?  Wouldn't it be the case
> that very often people would want to turn this promiscuous mode off to get
> behaviors that reflect the real world?  Would turning on promiscuous
> operation just lead to an a request for an opposite "mode" where we have a
> non-promiscuous bit for people who want to model more real-world devices?


Please just lets take a step back and re-consider the focus of this
project.  Are we building a _network_ simulator or a _hardware_ simulator?

>From a _hadware_ simulator POV what you say makes sense.

>From a network POV it hardly matters IMHO.  Before deciding to blindly copy
the promiscuous mode into NS-3, let us consider why it exists in the first
place.  The problem is that NICs communicate with the CPU via a PCI bus, in
a PC (or a South Bridge for NICs built into the motherboard).  So there is a
barrier with limited bandwidth.  Moreover, interrupting the CPU via a IRQ
causes a context switch to attend the interrupt, which decreases system
performance.  For that reason, NICs are built to only communicate to the CPU
only when frames of interest arrive, which normally include only unicast
frames directed to the NIC or broadcast.  Promiscuous mode is enabled on a
as needed basis due to performance considerations.

In NS-3 we obviously have no such performance penalty.  Filtering frames at
the Node level is just as efficient as filterering at the NetDevice level.


>
>
> While I agree that mode switches can cause problems, there are many of them
> in the real world we're trying to simulate.  If we're going to have a
> simulator that reflects the real world we're going to need to have mode
> switches that real systems do -- right?
>
> I think a user would expect to set a PROMISC bit in a socket ioctl.  How
> this is implemented at a low level and what it means across device types is
> another question.
>
> I think that linux has a number of bits that you can set to enable various
> promiscuity levels:  RxStation, RxMulticast, RxBroadcast, RxProm.
>
> What I would "expect" to see would be an attribute having something like
> these levels and which defaults to RxStation | RxMulticast | RxBroadcast.
>
> We could also provide a promiscuous callback that passes up all packets by
> default.  Code specially written to handle promiscuous packets could just
> hook this code -- including bridges and packet filters.


I am _all_ for a separate promiscuous mode callback.  Please, you and Tom
decide if that is what you definitely want and I'll code it.

I am OK with:

  1- Separate promiscuous receive callback, with or without "promiscuous
mode" (though I don't see the point of it);

  2- Single receive callback, but always in promiscuous mode and PacketType
to make filtering easy;

I strongly advise against:

  3- Single receive callback _and_ promiscuous mode on/off switch.

In either case, a quick final decision about this would be greatly
appreciated.  If deciding for 1, please also advise on whether full backward
API compatibility is desired or not.

Thanks in advance.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert