Skip to content

mfouladi/PlanetLabUnitExperiment

Repository files navigation

FUNCTION unitExperimentSender() AT SENDER:
Parameters:
num_of_packets
inter_packet_departure_spacing
probe_packet_length
entropy (low or high)
experiment_run_log_absolute_filename


Sender (S) initiates a TCP connection:
        S sends a packet with the following information to the receiver (R):
                - num_of_packet
                - inter_packet_departure_spacing
                - probe_packet_length
TCP connection terminates upon receipt of ACK from R by S

Note that S, during TCP handshake, estimates RTT by measuring the time
between it initiates the TCP connection until the SYNACK response is
received. This measurement will be used later as a timeout (Timeout)
since this is clearly (>= 2 * real_OTT(one-way transit time)) and can
be used as a safe upperbound. Note that this measurement is obviously
not an accurate estimation of RTT, for it does not have to be. We are
only intested in a fair and easy-to-calculate uppperbound that
prevents the receiver (R) to wait indefinitely for the lost
num_of_packet-th packet.

Sender (S) sends num_of_packets probe packets with "entropy" with
inter_packet_departure_spacing time between each packet. The following
packet format is used to send the packet train:

+------------------------------------------------------------------------------+
| IP header | UDP header | PacketSeqID |    Payload     |
+------------------------------------------------------------------------------+

Low entropy payload is all 0's.
High entropy payload is whatever bytes read from /dev/random once.
(note that reading from /dev/random will happen only once and before
the train starts. The content will be the same for all packets within
the same train.)

Once S sends the num_of_packets-th packet, S will wait exactly Timeout
and then initiates another TCP connection. This TCP connection is just
a way to let R know that the experiment is done and begin processing
the train. We use TCP connection here since we want to make sure R is
definitely notified of the terminated experiment. R upon receipt of
the second TCP connection begins processing the train. At this point R
 sends the receiver all the info in the following format:

packet_sequence_id\tarrival_timestamp\n

arrival_timestamp = -1 if the packet is lost

sender logs in the same format structure in the file
"experiment_run_log_absolute_filename"
and returns.


**** An issues that requires careful consideration:
- Timestamp resolution
This is the part that requires some researching since we are looking
for a very accurate timestamp with the finest granuality we can get.

Here are some excerpts from the following papers that could be useful
in the implementation:

- "Timestamp-resolution Problem of Traffic Analysis on High Speed Networks"
- "Modelling and Analysis of Computer Network Clocks"

"Commonly used network traffic capture programs like tcpdump are based
on libpcap. This library implements functions to get packets dequeued
from the kernel but it handles time information in the microsecond
time domain only. Under Linux, it can use Linux MMAP support (memory
mapping) for doing a more “virtual tapping” by reducing memory block
copies. When this feature is not
available, the SIOCGSTAMP IOCTL call is used to query timestamp
information which is less efficient."

We should not use gettimeofday() because:
"The software clock, which is accessed using the gettimeofday() system
call, is based on a counter of timer interrupts. These are typically
generated by dividing, via a 8254 timer chip, the 1.19318
MHz output signal of a standard quartz oscillator (residing on the
motherboard), and are used by the operating system to schedule
execution of both system and user tasks. The division is typically
to HZ=100Hz, yielding interrupts every δ = 10ms, which sets a coarse
bound on the resolution of the clock. Furthermore, the oscillator has
a skew, in the range of ±50PPM (see below) which is
not measured nor accounted for. This oscillator will be referred to as
the ‘standard oscillator’. Incrementing the counter is one of the
highest priority periodic tasks."

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages