CS 244 ’15: ASAP, A low-latency transport layer


Team: Dima Brezhnev and Eyuel Tessema

Key Result(s): We compare TCP and ASAP latency of small web-page downloads.

Source(s): W Zhou, Q Li, M Caesar, PB Godfrey. ASAP: A low-latency transport layer. 2011. SIGCOMM.

Contacts: If you have questions, please reach out to dima.[last name]@stanford.edu or to e[Eyuel’s last name]@stanford.edu. We reached out to the authors at email addresses listed in the paper for source code. It’s included in our github repository.

What is ASAP? 

TCP is inefficient in the number of round trips it takes to download a small web-page. One round trip is spent on DNS resolving the domain; another roundtrip is spent on TCP performing a TCP handshake. ASAP is a transport protocol optimized for reducing latency by shortcutting these inefficiencies. For real-world implementation, it requires changes to authority DNS servers, to clients and servers, but does not require changes in global DNS infrastructure.

In ASAP (Figure 1), if the client does not have the server’s IP address, it first constructs a DNS query to the local-DNS server. In the query, it inserts connection establishment information CI. ASAP does not modify the format of or add fields to the DNS query. Instead, it encodes the connection establishment information into the hostname field of the DNS request, concatenated with the hostname being looked up. For example, if the client is looking up http://www.xyz.com, it would generate a DNS request for a.CI.www.xyz.com, where a is an arbitrary character which will not appear in the normal name (e.g., ASCII code 13), used by ASAP to determine if the request is from an ASAP-enabled client or a legacy client.

When a client tries to resolve this domain, it first contact a local DNS. A local DNS will not have this request cached at first and will contact an authority-DNS (which runs ASAP). The ADNS server will strip the CI field and forward the request to the server, spoofing the IP of the client to shortcut the server-client connection. It also returns the A response to the local DNS, which is still waiting on a response from an authority. Communication proceeds between server and client using ASAP.

ASAP_vs_TCP

Figure 1: TCP vs ASAP

As you can imagine with any new protocol, there are many challenges concerning security and scalability. Getting rid of the TCP handshake results in plethora of security concerns: provenance, eavesdropping, replay, DoS attacks on the server, privacy, etc. In addition, there are engineering issues with mobility and error handling. The paper discusses how to deal with these issues in varying levels of detail and we invite you to check it out. We won’t implement any of the suggested security considerations here.

Reported Results: The authors implemented two versions of ASAP. One version was built in the application layer on top of UDT, a UDP-based protocol. Another version was built in the kernel to resemble TCP. Some reported experiments were done on the UDT version, some were on the kernel version. Since compilation and setup was already a headache with the application layer, we did not have time to try out the kernel version, and instead focused on reproducing some of the application layer results.

Figure 2 was the main result of the paper, promising a reduction in latency for small pages. The three graphs correspond to latency measurements in three different topologies. We focus on modeling the topology in (b), in which the DNS server is collocated with the server, and try to reproduce the graph.

Screen Shot 2015-05-30 at 5.22.49 PM

Methods: 

The authors deployed their system to real hardware and measured real-web latency. Even though it’s good to measure how a system performs in the real world, it’s not good for benchmarks, since it is hard to reproduce the exact environment when extending ASAP. So we built a topology in Mininet, with three hosts connected to a central switch. The hosts are client, server and DNS and the switch represents the general internet.

We abstracted away the local DNS to run on the client.

Results:

We were unable to reproduce the results of the paper. Here is a graph of the results we got.

Screen Shot 2015-05-30 at 5.04.56 PM

You can see that our implementation of ASAP was actually slower than UDT. Though, we think this may be a result of implementation issues on our part. We tried to match the implementation described in the paper as closely as possible, but had to use some workarounds for some parts. For example, the main part of the implementation was that the client kind of half-opens a connection and the connection information piggybacks on the DNS request, which the DNS server sends to the server, then the server completes the connection. The best we could do was have the DNS server send the client’s IP to the server, then the server would create a new connection to the client. This means that much of the benefit of piggybacking on the DNS request was lost. This also required having the client to spin up a server to listen for incoming connections, which we believe also slowed things down. If we had figured out a way to actually start the connection on the client’s side, we think our implementation’s speed would have increased significantly.

Another difference is the slanted slope of the author’s CDF. This is due to unpredictability of delivery times in real settings. Mininet is much more deterministic and so is our CDF.  We attempted to simulate unpredictability by using iperf, but the variance did not change by much because iperf fills the links and mininet still stabilizes to a deterministic (yet slower) time.

Takeaways: We learned from this project the importance of writing maintainable code if you want other researchers to use it. We had a hard time understanding what was going on in the code, as it was not commented and was not written very well. A couple important features that were given as part of the implementation in the paper didn’t even seem to be in the code at all, and without documentation, we couldn’t figure out how they were getting around this and had to try to get around it ourselves. With documentation, the process of trying to reproduce their results would have been a lot easier.

Instructions to Replicate This Experiment:

Choose your favorite cloud compute provider: EC2 or DigitalOcean

Create a new instance with Ubuntu 14.04 similar to one used for CS244 projects

Ssh into the virtual machine with -X parameter

Install git

Clone our repository: https://github.com/eyuelt/asap into asap/

Run asap/setup.sh.

Try running “perf” to make sure it installed. (If not, install perf (need for latency checks) by installinglinux-tools-[KERNEL VERSION]-generic. apt-get will suggest the version you need if you run perf)

Run experiments with asap/run.sh

Result will appear in result_img.png

Advertisements

One response to “CS 244 ’15: ASAP, A low-latency transport layer

  1. CS244 peer review eval score for reproducibility: 5/5
    We used the mininet AMI from the course for running the experiment. The setup and run scripts were very convenient, and ran to completion without issues, giving the plot mentioned in the post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s