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

[Gustavo Carneiro]

2008/7/14 <craigdo at 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).


The above plan sounds perfectly fine assuming you mean that
NetDevice::SetPromiscuousCallback means a callback that is called for the
case of PACKET_OTHERHOST _only_, i.e. it is not called for PACKET_HOST,
PACKET_BROADCAST, or PACKET_MULTICAST.  If that is so, it sounds perfectly
reasonable and I'll just go ahead with the implementation.

And best of all it looks like API compatibility is preserved :-)

Thanks,

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