Round trip time measurements using ICMP and TCP

ping is a great tool for measuring round-trip time delays, but:

1. Sometimes, ICMP is not enabled on the end hosts (increasingly now)
2. ICMP RTTs may not provide the right delay metric for real-world applications.

I searched and found two good "TCP Ping" tools, which basically seem to create a TCP SYN message and check the time delay in getting a SYN-ACK response from the server.

This should be a more realistic measure of RTT for real-world TCP traffic and should be possible to do on any public node.

Here are two that I found to be helpful

• TCP Ping: Download script here and more details here (requires tcptraceroute)
• Scapy TCP Ping (using Python): Doesn't seem to actually do RTT measurements... (requires python and scapy library)
  

UPDATE: scapy can do round-trip measurements itself. You need to scapy.py file and some basic tutorials...

Sending customized TCP packets using jpcap and libpcap

Sorry I haven't blogged for a while; I've moved to Twitter.com/sumanrs for most updates. I'm only using this blog for longer posts now.

So my task this week was to create customized TCP packets for the NetSerV experiment. I would have had to look for a user-level TCP stack ... or use the popular pcap implementation, which can generate packets on the network.

And since this has to run on Java, we have to use jpcap (there is an older version on Sourceforge, which I did not try.)

I was able to successfully create a program that can send TCP packets, both on Windows and Linux. And was able to compile and run SendTCP.java, which can send packets

To get the TCP packets to send properly in a local network and be received at the remote node, you need to know a few things:

1. Make sure to correctly specify source and destination MAC addresses. You can get the source MAC address by doing:
   ether.src_mac = device.mac_address;
   You will have to manually set the receiver's MAC address, or look at ARP.java to figure how to do it over the network.
   
2. Make sure to correctly specify source and destination IP address. Can be done through InetAddress.getByName() as in the example.
3. For unknown TCP ports that don't have any daemons running on them, you may not get a ACK response for a SYN packet, though you will get a TCP RST packet.
   
4. If you send it to a port that has a daemon, you will get a nice ACK packet, which you can handle properly.
   

Windows ran succesfully, but I learnt a few things for the Linux install since I had to run it on a AMD 64-bit processor:

1. There seems to be no version of jpcap download on the jpcap site. So you will have to build it yourself.
2. Download the source from the jpcap site.
3. Follow instructions for source install here.
   
4. You need libpcap and libpcap-dev installed. libpcap is most likely already installed; if you want libpcap-dev, do "sudo apt-get install libpcap-dev"
5. You can install the native library and the JAR by following the instructions in #3.
   

Spring 2009: NetServ + candidacy + TA

As the Spring 2009 semester begins, I am hitting the ground running for my candidacy exam in late Feb. My topic is "Ubiquitous Communication Models for Different Network Scenarios."

While at it, I am also reading up on the following topics for the NetServ project, which I will soon start work on:

• Click Modular Router
• OpenFlow Switch

And, finally, I am TAing the COMS6125 Web Enhanced Information Management again this semester.

The Beginnings of Spring 2009

Back to work for Spring 2009. I am now done with courses - its a wonderful feeling to not have to be aware of when the semester starts and ends. :D Well, except I am TAing Web-Enhanced Information Management again this Spring semester... and am looking forward to it.

The downside is: I do start working on research two weeks before school starts ... but that's OK.

Right now, two items require my fullest attention:

• Preparing my presentation for the IEEE CCNC research conference on the BonAHA framework (this weekend!)
• Finalizing the list of papers for my candidacy exam (which will be in mid-Feb? I hope?)

Parallel computing and communication/network models - the "parallels"

Apologies for the pun, but one of my readings over the last week has been to read up on parallel computing in order to find some parallels between the opportunistic applications I have been working on (such as 7DS) and parallel computing.

Even though the two topics look different, there are actually several points in common.

Below is a list of topics, extracted from the textbook Parallel & Distributed Computing Handbook by Albert H. Zomaya, published by McGraw-Hill.

• PRAM (Parallel RAM) model; Methods for distributing and parallelizing algorithms
• Failures in parallel systems (Byzantine, other)
• Dataflow models
• Checkpointing (for recovery)
• Distributed software systems (this is similar to RMI)
• Data structures for parallel processing
• Shared memory, memory consistency

More details to come soon.

Finished BibTex on IRT publications page

Today I fixed up the BibTeX links on the IRT publications page. I also changed the links so they open in a new, smaller window (like a dialog.)

Papers related to communication/networking middleware: IEEE Network

Am on the trail of papers related to work on communications or networking middleware from a high-level perspective. Been reading IEEE Network publication online all day, and found some interesting issues as well as articles that may be quite relevant:

• (2008) Vol 22, Issue 4: Context aware networks, in mobile scenarios (whole issue)
  
• (2007) Vol 21, Issue 4: GE Network Systems Architecture (whole issue)
• (2006) Vol 20, Issue 4: VON: a scalable peer-to-peer network for virtual environments (this paper has analysis of other P2P-based NVE systems)
• (2006) Vol 20, Issue 3: A survey of transport protocols for wireless sensor networks
• (2004) Vol 18, Issue 1: GE Middleware technologies for future communication networks (whole issue, and is very good)

Among other things:

• Registered and uploading final version of paper for CCNC 2009 conference.
• Testing the new WORKIT box, which may be the final version of the box we will ship