[Ns-developers] Requesting help for csma promiscuous mode (resend)

[craigdo@ee.washington.edu]

Well, Outlook Excess certainly screwed up the attributions in that last
message.  Let me try to sort this out manually for those of us not using
html or rich text.  There's no additional content here than in my last
message ...

Gustavo wrote:
>>> Now one more question.  So we will have two callbacks from
>>> NetDevice to
>>> Node.  How do you want to handle Node::AddProtocolHandler and
>>> promiscuous
>>> mode:
>>>
>>>    1- Node::AddProtocolHandler (callback1) and
>>> Node::AddPromiscuousProtocolHandler (callback2), each with different
>>> callback signatures;
>>>
>>>    2- Single Node::AddProtocolHandler (promiscuousMode=false,
>>> callback),
>>> with changes in callback signature;

Craig wrote:
>> I'm not sure what the purpose of these alternatives actually 
>> is.  I know
>> about a method that sets the callback in the device to point to a Node
>> method:
>> 
>> uint32_t
>> Node::AddDevice (Ptr<NetDevice> device)
>> 
>> and a method in the node to receive packets from the device,
>> 
>> bool
>> Node::ReceiveFromDevice (Ptr<NetDevice> device, Ptr<Packet> packet,
>>                         uint16_t protocol, const Address &from)
>> 
>> and a method to register handlers to process packets 
>> forwarded up from the
>> device,
>> 
>> void
>> Node::RegisterProtocolHandler (ProtocolHandler handler,
>>                               uint16_t protocolType,
>>                               Ptr<NetDevice> device)
>> 
>> You obviously need some way to use the new promiscuous 
>> callback.  Can you be
>> more specific regarding how you want this to work?  Are you 
>> suggesting new
>> node methods called something like AddProtocolHandler that 
>> would hook into
>> the promiscuous callback instead of the normal callback?

Gustavo wrote:
> Yes, I am suggesting that.
>  
> The problem with NetDevice callbacks is that they only allow 
> one callback to
> be registered at any time, which is very  limiting.  A long 
> long time ago I
> suggested the use of a Signal class, to work the Set*Callback 
> limitation,
> but the idea did not find traction.  The only alternative 
> left to me is to
> add promiscuous mode protocol handlers to the Node class. 

Craig wrote:

I don't want to dictate a solution from some western US "ivory tower" --
there are a lot of possible policy choices here; so I want to get some of
them out in the open before just making a call ...
 
There are two extreme alternatives as you have suggested:
 
1) Completely separate public promiscuous code paths:
  - Four new methods RegisterPromiscuousProtocolHandler,
UnregisterPromiscuousProtocolHandler, SetPromiscuousDeviceCallback,
ReceivePromiscuousFromDevice with a separate handler list and possibly even
separate handler type.
 
2) Single code path:
  - Have AddDevice call two methods, SetReceiveCallback,
SetPromiscuousReceiveCallback both calling back to a single handler
(equivalent to a single always-on promiscuous mode).
 
I don't think we should duplicate a bunch of code for 1) and nobody likes
the effect of 2) so we're clearly somewhere in the middle.
 
My tendency would be to try and minimize the number of public API, so I
would lean toward a RegisterProtocolHandler with a promiscuous flag.  I
wouldn't want to duplicate a lot of extremely similar code, so I would
probably add the promiscuous flag to the ProtocolHandlerEntry.  When the
promiscuous callback is called, you would loop through the handlers looking
for the ones that are prepared to accept promiscuous callbacks.  Do you also
envision a need for a "wildcard" protocol?  A packet sniffer would need one
...
 
There's the question of how to "turn on" the promiscuous callback.  There
should probably be a test for promiscuity in the net device
(HasPromiscuous?) since some devices won't have a meaningful concept of
promiscuous mode nor the callback.  There seem to be two further extreme
alternatives here.  If the test returns true, always enable the promiscuous
callback at initialization and loop through the handlers every time a packet
is received to see if a promiscuous handler is present.  At the other
extreme is a kind of on-demand promiscuous mode where the act of registering
a protocol handler with the promiscuous bit turned on enables promiscuous
callbacks if available.  You could disable callbacks (or not worry about it)
when all promiscuous handlers are unregistered.  There are performance
implications regarding your choice, of course.  I don't know if anyone would
ever want to turn promiscuous mode off once enabled, so maybe a "once set,
always set" semantic is fine.
 
The last issue I can think of is that, as designed, packets may be forwarded
up by a device twice if promiscuous mode is set.  The promiscuous callback
could be called before any filtering is done, and then (possibly) the normal
callback will be called.  That seems like a policy decision at the device
level that could have large impact on higher layers.  
 
This leads to the next question.  Would it be better to admit the
possibility that a promiscuous protocol handler can consume packets that
will come up a non-promiscuous path later?  This seems to me to introduce
lots of complexity.  Intuitively, I would think it would be easier to have
some packets forwarded up twice (once to something that wants them all) than
to have to deal with the possibility of handling packets twice in two
places.  So we need a clear policy statement regarding what is expected to
come up both possible paths and what a promiscuous handler is permitted to
do with respect to "consuming" packets -- i.e., it can't.
 
I don't know if you've thought any deeper about this than I have, but my
first take would be to have the system do something like,
 
1) Add a HasPromiscous method to the net device that defaults to returning
false;
2) Refine this method in CSMA at least to return true;
3) Add a SetPromiscuousCallback method to the net device to parallel
SetCallback;
4) Add a flag to the node's ProtocolHandlerEntry that says a handler is
prepared to accept promiscuous packets;
5) Add a flag to RegisterProtocolHandler to provide the flag to the entry;
6) Use "once set, always set" semantics to call SetPromiscuousCallback when
the promiscuous flag is set in the Register method;
7) Have the net device forward all packets up the promiscuous callback and
not try to play any fancy filtering games;
8) UnregisterProtocolHandler just removes handlers and doesn't try to figure
out when it can turn off promiscuous callbacks;
9) Have a single Node::HandlePacketFromDevice that includes a promiscuous
flag;
10) Have a Node::ReceiveFromDevice (non-promiscuous) packet reception and
that calls (9) with flag false;
11) Have a Node::ReceivePromiscuousFromDevice (promiscuous) packet reception
and calls (9) with flag true;
12) Teach (9) to only forward packets to handlers with matching flags
(non-promiscuous flag goes to non-promiscuous handler).
 
The end result would be that operation doesn't change if there's no use of
the promiscuous feature.  If RegisterProtocolHandler is called with a
promiscuous flag, promiscuous callbacks start coming in from the specified
device to the node.  Protocol handlers registered as non promiscuous don't
see promiscuous callbacks so they are not affected.  Protocol handlers
registered as promiscuous must act as if all packets are not addressed to
the current host.  This gives the same behavior as in Linux where any
sk_buff not directed to the host is discarded without any processing.
Promiscuous protocol handlers are allowed to do other things (like implement
a learning bridge).
 
Comments?
 
-- Craig