CSS 432
FAQ on Program 3: TCP Analysis

Q1: In how much detail should I draw a timing chart for hw3?

A: As much as possible.

The tcpdump shows all ip packets exchanged between the local host and a given remote host. For each packet, indicate all the information including timestamps, message sequence numbers, ip addresses, port numbers and appropriate notations.

Q2: Can I reuse the code from HW1?

A: Yes

Q3: I don't know how to use shutdown( ).

A: Type "man 2 shutdown".

Actuall all you need is shutdown( serverSd, SHUT_WR ); where serverSd is a socket descriptor obtained from the server's accept( ) call.

Q5: When does an IP packet have a P notation. When does an IP packet have a "." notation.

A: An IP packet that carries the last data of a given write( ) call has a P(Push) option.

If you try to send data whose size is more than MSS, it is segmented into several packets. All those packets except the very last one has a "." notation, but the last one has a "p" notation indicating that this is the last data of a given write( ) call.

Q6: Parameters passed to ttcp

I have a question about ttcp. You stated that the format for the arguments for ttcp is as follows: 
       -l#     length of bufs read from or written to network (default 8192)
       -b#     set the socket buffer size if supported (default is 16384)
       -p#     specify another service port (default is 5001)
Should we have a space between the argument character and the number?

A: No, the number should follow the option without a space.

Q7: For Analysis 1 and 3, we are to make a graph or table in terms of Mbps. Should we look at the client or server Mbps? I know the two do not greatly differ.

A: Focus on the client Mbps.

Q8: Does the nagle-off option slow down the network?

I've got an issue with strace and I'm not sure if it's suppose to be like this or not. When I'm running strace -c -e trace=write ./ttcp -l 64 -n 1048576, and tcpdump at the same time(test#4), the finish times are really slow. I'm getting mbps from 6.78407(nagle off) to 10.3316(nagle on). It takes 18 microseconds per write for nagle on and 51 mircoseconds per write for nagle off. Should it be that slow(almost 1 minute to finish with nagle off)? If I don't run strace, it's faster(~90 mbps for nagle on, ~15 mbps for nagle off). So are the results truly accurate when I'm running strace?

A: With the nagle off, the performance should be degraded as you saw in your correct results.

This is because OS need a certain time to transmit data to NIC, and the nagle-off situation requires more frequent writes which cumulates such OS overhead.

Q9: With using strace, the times are considerably slower if I don't use strace

A: Since strance traces every single OS system call and prints it out to the display, it causes more frequent interrputs and thus slows down.

Q10: There are two independent sequences of packet IDs.

I expected there would be packets of data being sent to my server besides, but since I'm only listening on port 5001 I'm confused as to why I'm seeing the packet IDs change as if there were two sockets on the same port: 
1273986401.734004 IP (tos 0x0, ttl  64, id 9891, offset 0, flags [DF], proto: TCP (6), length: 52) uw1-320-10.uwb.edu.35853 > uw1-320-11.uwb.edu.commplex-link: ., cksum 0x63d0 (correct), ack 1 win 46 < nop,nop,timestamp 98161313 99209533>
1273986401.734020 IP (tos 0x0, ttl  64, id 9892, offset 0, flags [DF], proto: TCP (6), length: 56) uw1-320-10.uwb.edu.35853 > uw1-320-11.uwb.edu.commplex-link: P, cksum 0x6344 (correct), 1:5(4) ack 1 win 46 < nop,nop,timestamp 98161313 99209533>
1273986401.734028 IP (tos 0x0, ttl  64, id 11268, offset 0, flags [DF], proto: TCP (6), length: 52) uw1-320-11.uwb.edu.commplex-link > uw1-320-10.uwb.edu.35853: ., cksum 0x63cc (correct), ack 5 win 46 < nop,nop,timestamp 99209533 98161313>
1273986401.734272 IP (tos 0x0, ttl  64, id 9893, offset 0, flags [DF], proto: TCP (6), length: 1500) uw1-320-10.uwb.edu.35853 > uw1-320-11.uwb.edu.commplex-link: . 5:1453(1448) ack 1 win 46 < nop,nop,timestamp 98161313 99209533>
1273986401.734302 IP (tos 0x0, ttl  64, id 11269, offset 0, flags [DF], proto: TCP (6), length: 52) uw1-320-11.uwb.edu.commplex-link > uw1-320-10.uwb.edu.35853: ., cksum 0x5e0e (correct), ack 1453 win 68 < nop,nop,timestamp 99209533 98161313>

A. Both a client and the corresponding server have their own packet IDs.

Q11: hw3 bad checksum question

I notice that at a certain point one packet always returns with a bad checksum, its always the same packet in he same place. Are we supposed to hard code a bad checksum in our program? That seems like a weird thing to do so I wanted to make sure.

A: Just ignore this problem. :-)

This checksum error occured due to a packet returned from the server to the client. Note that tcpdump is checking only the data correctness of packets from the client to the server. So, ignore this problem.

Q12: For the output from the "strace -ttT ttcp" call, I forgot how we are supposed to interpret the data

Here's some sample output:
------------------------------------------------------------------------------------------------------------------------------
 ...
19:16:29.574171 write(3, "\4\0\0\0\3245\212\0\270\305\266\277i>\204\0\3\0\0\0\1\0\0\0\4\0\0\0\0\0\0\0"..., 64) = 64 < 0.000018>
19:16:29.574265 write(3, "\4\0\0\0\3245\212\0\270\305\266\277i>\204\0\3\0\0\0\1\0\0\0\4\0\0\0\0\0\0\0"..., 64) = 64 < 0.000015>
19:16:29.574343 write(3, "\4\0\0\0\3245\212\0\270\305\266\277i>\204\0\3\0\0\0\1\0\0\0\4\0\0\0\0\0\0\0"..., 64) = 64 < 0.000014>
 ...
------------------------------------------------------------------------------------------------------------------------------

I remember hearing something about the timestamp in the beginning (i.e. 19:16:29.574171),
and something about the stuff at the end of the line (i.e. < 0.000018>)?

A: Each lap time is time elapsed to handle this write system call.

the timestamp in the beginning is the time at which the system call was called, the time at the right is a lap timestamp that shows the total time for the system call to complete. For example, the first write call: 
start time: 19.16.29.574171
+lap time:         0.000018
end time:   19.16.29.574189
Notice the end time of the first system call is a bit behind the start time of the next system call. Additional .000076 is the kernel doing other jobs (such as process scheduling).