-
Notifications
You must be signed in to change notification settings - Fork 0
mfouladi/PlanetLabUnitExperiment
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
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 0
No packages published