[Ns-developers] CSMA Tracing Rework

[Tom Henderson]

craigdo at ee.washington.edu wrote:
> We have a couple of P1 bugs for ns-3.4 that I am currently working on
> resolving
> 
> 1) http://www.nsnam.org/bugzilla/show_bug.cgi?id=438 (csma helper hooks the
> transmit queue enqueue operation for pcap tracing)
> 
> 2) http://www.nsnam.org/bugzilla/show_bug.cgi?id=443 (Net device pcap traces
> arent consistent with what tcpdump would display)
> 
> I've put together a repo that begins to address these issues (for CSMA at
> least).  You can find it at http://code.nsnam.org/craigdo/ns-3-traces if you
> want to take a look.
> 
> The basic idea is to fill out the number of trace sources to provide enough
> hooks to make it clear where and when things are happening.  I added hooks
> to events that happen at the "top" of the device as things come in or go out
> to and from L3 along with drop events that happen at that level.  I added
> another group of trace sources at the "bottom" of the device that fire as
> things go out to or in from the channel along with drop events that happen
> at that level.  
> 
> There is a new trace hook called "Sniffer" that provides packets for a
> non-promiscuous packet sniffer -- the same thing that you would get if you
> ran a tcpdump packet sniffer on the interface.  This trace source is hooked
> into the same logical places as tcpdump would (with its PF_PACKET ETH_P_ALL
> sockets) but on the device side.  Note that this is a non-promiscuous
> sniffer so it won't capture PACKET_OTHERHOST packets.  It may be useful to
> make a promiscuous sniffer (Attribute "PromiscSniffer") that would work just
> like tcpdump (i.e., capture all packets on the channel in one place).

At the helper API level, I think it would be nice to have a method named 
Tcpdump() of some sort that was a promiscuous sniffer for the interface. 
  I am OK with having a non-promiscuous tracepoint by default since it 
will cut down on trace files when "EnableAll()" is called, but we need 
to clearly document this.

> 
> I think this makes it a lot more clear what exactly you are tracing when you
> connect to these sources.  The existing device queue is still there with its
> associated trace sources, so AsciiTrace is unchanged.  The ambiguous trace
> hooks are removed (e.g., "Drop").  
> 
> I would like to do a similar treatment on all of the real net devices in
> /src/devices.  Comments?
> 
> This will, of course, mean regenerating most of the regression traces.

Please check that the regenerated traces are still sane.  We have had a 
problem in this regard with some recent checkins.

> 
> I have reproduced the new trace sources below.  More detailed descriptions
> may be found in the doxygen in csma-net-device.h
> 
> -- Craig
> 
> ---------- Begin Source ----------
> 
> //
> // Trace sources at the "top" of the net device, where packets transition
> // to/from higher layers.
> //
> .AddTraceSource ("MacTx",
>                  "Trace source indicating a packet is being queued for
> transmission by this device",
> 
> .AddTraceSource ("MacTxDrop",
>                  "Trace source indicating a packet has been dropped by the
> device before transmission",
> 
> .AddTraceSource ("MacRx",
>                  "Trace source indicating a packet has been received by this
> device and is being forwarded up the stack",

the above seem a little fuzzy to me.  MacTx and MaxTxDrop seem 
synonymous with Queue/Enqueue and Queue/Drop.  However, I might think of 
Mac-named as being associated with a mac event, not a queue event.


> 
> //
> // Trace souces at the "bottom" of the net device, where packets transition
> // to/from the channel.
> //
> .AddTraceSource ("PhyTx",
>                  "Trace source indicating a packet has been completely
> transmitted over the channel medium",
> 
> .AddTraceSource ("PhyTxDrop",
>                  "Trace source indicating a packet has been dropped by the
> device during transmission",
> 
> .AddTraceSource ("PhyRx",
>                  "Trace source indicating a packet has been completely
> received from the channel medium by the device",
> 
> .AddTraceSource ("PhyRxDrop",
>                  "Trace source indicating a packet has been dropped by the
> device during reception",
> 
> .AddTraceSource ("PhyTxBackoff",
>                  "Trace source indicating a packet has been delayed by the
> CSMA backoff process",

isn't backoff a mac (not phy) function?


> 
> //
> // Trace source designed to simulate a packet sniffer facility 
> //
>     .AddTraceSource ("Sniffer",
>                      "Trace source simulating a non-promiscuous packet
> sniffer attached to the device",
>

I would also be fine with the name "pcap" for this trace point.

Tom