Date: Sun, 9 Apr 2006 22:32:46 +0000 From: Andrea Campi <andrea+freebsd_net@webcom.it> To: freebsd-net@freebsd.org Subject: TCP Daytona in userland Message-ID: <20060409223246.GA1747@webcom.it>
next in thread | raw e-mail | index | archive | help
Hi all, I have started working on a "TCP Daytona" implementation [1]. I'm quite familiar with TCP/IP in theory, and sort of familiar with the BSD implementation ideas, but looking into tcp_input and tcp_output is always a mistic experience ;-) I tried to understand how I could generate multiple (either duplicate or better partial ACKs), but I guess tcp_output is really not meant to do such a thing. Does anyone have an idea of how hard would it be to generate more than one ACK for an input packet, and could you give me some suggestion? So to get my feet wet, I've decided to start from a simple userland implementation using BPF. Currently I'm using a test program that does an HTTP transfer and, from a parallel thread, I monitor the conversation and send additional ACKs for each genuine ACK I see. This doesn't seem to have any (positive or negative) effect if I send 1 or 2 duplicate ACKs, but slows the connection down if I send 3 or more additional ACKs. I didn't have much time to investigate this yet. Sadly, this wouldn't work if I wanted to send partial ACKs instead. What would be nice is to be able to stop the genuine ACK from being sent and inject partial ACKs instead. Do we have any mechanism that would allow me to do this? Maybe I should be using divert(4) instead? Lastly, if anybody already worked on this: do you have any additional suggestion? In particular regarding the testing methodology: since a few years have passed, I'm not quite sure whether different OSs have implemented any countermeasure. I'm mainly testing against a FreeBSD box I control, and I don't think we have any defence against this yet. Bye, Andrea 1. as per the Savage et al. paper: http://www-cse.ucsd.edu/~savage/papers/CCR99.pdf
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060409223246.GA1747>