[Ns-developers] Tracing Rework

[craigdo@ee.washington.edu]

> am I correct that these trace sources are supposed to provide 
> a common interface for all net devices? And this common 
> interface is then used to create different types of tcpdump files.

I think we just decided that there should be a set of standard trace source
names across net devices.  It is up to the net device author which of these
trace sources he or she wants to implement.  Two of these trace sources are
used for pcap tracing:  Sniffer and PromiscSniffer.  "Sniffer" has some
problems, so "PromiscSniffer" is the "standard" and corresponds to what
kinds of packets would be displayed in a tcpdump.  Helpers turn the sniffed
packets into pcap files as they currently do.

> I noticed that you added a phyRxDropTrace to YansWifiPhy. I 
> did the same in my testing code, but obviously I was more 
> interested in the reason why the packet was dropped. The 
> reason is indicated to the callback via an enum parameter. 
> Beyond the drop reason there is a lot of interesting 
> information that should also be passed to the trace callback.

This touches on one of the issues I've been wrestling with:  what it is that
actually comes over the callback.  There are conflicting goals.  On one
hand, the whole point of the tracing system is to allow you to trace
whatever it is you feel is appropriate, and pass whatever information in
whatever form you need in the callback.  The other is usability.

In many of our devices, we've been trying to make the common trace hooks
behave similarly.  The tricky part is to get the balance between usability
and usefulness right :-)

The previous incarnation of the tracing hooks clearly didn't provide enough
information.  There were hooks called, "Drop" that were sometimes called in
the tx path, sometimes called in the rx path and sometimes not called at
all.  There clearly was a need to do more.

So the 64,000 euro question is:  how far can we take this today.  I've come
to the conclusion that a statement of basic policy and the definition and
implementation of a reasonable set of the trace hooks is about as much as I
can do in the next couple of days.

> So how does this match up with your work on a common trace 
> interface? Does that mean there are two subsequent trace 
> sources calls:
> m_phyRxDropTrace(packet);
> m_phyRxDropTraceDetailed(packet, reason, rxPower, snr, ...);
> ?

This lines up with what I was thinking.  The name "PhyRxDrop" is a standard
name indicating rough enough semantics that a user of a net device might
suspect this trace source is implemented and of interest to her.  Since, as
I mentioned in another email, the contents of the packet passed back may be
in various states of assembly and disassembly, you cannot just blindly use
this trace source.  You have got to figure out what passed to you in the
callback.  This could just as easily mean, "what list of parameters with
what contents" as it could mean, "packets with llc/snap header and no
Ethernet header."  For example, I think it would be okay to see
(pseudocode):

  CsmaNetDevice::m_phyRxDropTrace (packet); // with some implied reason for
dropping a packet

and

  YansWifiPhy::m_phyRxDropTrace (packet, SOME_WIFI_REASON, rxPower, ...);

It's just that I really don't have the time to think through each trace
source in the system and figure out what the useful set of parameters should
be.

> I for my part believe that there should be a common set of 
> (optional) relative trace paths / names: MacTxStart, 
> MacRxEnd, PhyRxDrop, PhyRxEnd.

Sounds good.

> However the parameters must be adaptable to whatever 
> interesting information the device has to export.
> These parameters must then be reconciled (i.e. dropped) in 
> the helper module implementing the tcpdump output callback.

I think this is in the spirit of the ns-3 tracing system.

Regards,

-- Craig