[Ns-developers] CSMA Tracing Rework

[craigdo@ee.washington.edu]

[ ... ]

> 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.

That's the plan.  I wanted to have a helper method that created a
promiscuous packet sniffer on one net device of the channel and which would
do what you might expect tcpdump to do.  I didn't have a name in mind yet
but I can certainly call it Tcpdump.

>   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.

Yes.


[ ... ]

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

Yes.  I've been going through the devices one at a time and looking at the
differences.

[ ... ]

> the above seem a little fuzzy to me.  MacTx and MaxTxDrop seem 
> synonymous with Queue/Enqueue and Queue/Drop.  

Sometimes.

MacTx, MacRx and MacDrop happen at the boundary of the device irrespective
of what kind of queueing discipline is being used.  In the case of CSMA, for
example, MacTxDrop is used when you drop a packet for reasons other than
queueing -- Queue/Drop means the queue was full.  If the device is down you
will hit the MacTxDrop trace hook and the packet to be sent will never get
to the queue.  This plugged one of the tracing holes in the current scheme
where packets would "disappear."

In the case of MacTx, it probably looks a bit redundant in several of our
devices, but this is the case with several of the trace hooks.  If you look
at the point-to-point link, you will probably think most are a bit redundant
since they happen very close together in the code.  If you look at the CSMA
code, it looks bit less redundant.  It seems much less so in the wifi code.

In the case of the wifi code on the transmission side, you will hit a MacTx
hook on the way in to the device.  A packet then moves deeper into the
device, through the specific mac (e.g, nqsta), through the dca code, and
eventually finds its way to a WifiMacQueue.  This particular kind of queue
does not inherit from Queue and therefore does not provide the Enqueue,
Dequeue and Drop events.  If you look at src/helper/wifi-helper.cc you will
see that the ASCII trace events don't have anything to do with
ns3::Queue-defined events and there is no such thing as a drop there since
there is no such thing as a Queue.

How redundant you see this stuff depends on where you look.

[ ... ]

> > .AddTraceSource ("PhyTxBackoff",
> >                  "Trace source indicating a packet has been 
> delayed by the
> > CSMA backoff process",
> 
> isn't backoff a mac (not phy) function?

Yes.

> > 
> > //
> > // 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.

The trace source really doesn't have anything to do with pcap at this point.
It is simply sniffing packets.  It is the trace sink that takes the packets
and writes them into a file that is formatted according to pcap rules.

I looked at it as having the same relationship to pcap as a NIT, BPF, etc.
Sniffer seemed suitably generic and understandable.