• View
• Edit
• History
• Print

- First question: (interpretation of TIN and TOUT lines)

There are four types of entries:

TIN <size> <seconds portion of timestamp> <usecs portion of timestamp> <src> <dest> <seq #> SIN <size> <seconds portion of timestamp> <usecs portion of timestamp> <src> <dest> <gateway> <seq #> TOUT <size> <seconds portion of timestamp> <usecs portion of timestamp> <src> <dest> <seq #> SOUT <size> <seconds portion of timestamp> <usecs portion of timestamp> <src> <dest> <gateway> <seq #>

I found some src and dst addresses do not agree with the above definition as follows:

(in outdoor-run-20031017/1/APRL/10.0.0.1.APRL.data.parsed) TIN 1077 1066401530 674358 11.0.0.1 11.0.0.39 0 TOUT 1246 1066401607 872217 11.0.0.7 11.0.0.1 25

Why are the current address (10.0.0.1) and src address (11.0.0.1) different in TIN entry? Looks a script bug, but needs to be confirmed.

- Second question: (meaning of 'gateway')

Isn't it the previous node which passed a packet to the current node (for SIN)? Similarly, isn't it the next node to which the current node will pass a packet (for SOUT)?

So for example suppose the following path of a packet with id 100: 1(src)->2->3->4(dst)

Then a log file for node 2 may contain: SIN - - - 1 4 1 100 SOUT - - - 1 4 3 100

(Answer by Jason Liu)

The simplest thing is to take a look at the source code. Actually it's relatively easy to figure things out if you do. Search for DataPacketLogger.h/cc, which is responsible for writing out the data logs and then see who's really calling its methods...

Now back to your questions. First, definitions.

TIN - in from tunnel TOUT - out over tunnel SIN - in from socket SOUT - out over socket

Remember ActComm code uses IP tunneling? Applications (traffic sources and sinks) use virtual addresses, which I assume to be 11.0.0.x. For example, node 1 may say "send a udp packet from me, 11.0.0.1, to to node 11.0.0.3). For real packets that fly between wireless cards, we use physical addresses, which I believe are in 10.0.0.x domain. If I remember right, all ip addresses in the logs are virtual (11.0.0.x).

Now it'll be much easier for me to describe the functions using fig.1 in our SCS'05 paper, which actually explains why the log files are formatted this way. From fig. 1 you can see that both application traffic generator and the routing algorithm (say, APRL) have a (UDP) socket interface. Whenever a packet is received, the virtual source and destination addresses are retrieved. A log entry is created as "SIN size sec usec src_ip dest_ip previous_hop_ip seqno". Virtual ip addresses (11.0.0.x) are used here. The virtual addresses are then converted to physical addresses (changing 11 to 10) and the routing table is then consulted. If the packet is destined for this host, it'll be written out to /dev/tun0 and a new entry is logged "TOUT size sec usec src_ip dest_ip seqno". If the packet is not destined for this host, it'll be send out through the UDP socket. Another entry is created: "SOUT size sec usec src_ip dest_ip next_hop_ip seqno". See, for example, AprlDataPacketHandler.cc for details.

The routing algorithm also read packets from application traffic generator through the tunnel device. If a packet is read from the tunnel device (see for example AprlTunnelHandler.cc), we create a log entry "TIN size sec usec src_ip dest_ip seqno". Again, addresses are converted to physical and routing table is consulted. The packet will be send out through the UDP socket and a new entry SOUT is created.

Now take your example. Say we have three nodes with virtual addresses 11.0.0.1/2/3. If there's a packet to be sent from 1 to 3 through 2. If I get it right, at node 1, you'll see SOUT, TIN, and SOUT (representing a new packet going from trafgen to tunnel to routing algorithm and then out from this node). At node 2, SIN and SOUT (representing the packet is received by routing algorithm and sent out again). At node 3, SIN, TOUT, and SIN (representing the packet received by routing algorithm, though the tunnel, and finally arrived at the sink application).