From owner-freebsd-net@FreeBSD.ORG Sun Apr 9 22:32:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67D9E16A400 for ; Sun, 9 Apr 2006 22:32:49 +0000 (UTC) (envelope-from andrea@webcom.it) Received: from www.webcom.it (gen053.n002.c03.escapebox.net [213.73.82.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EAA143D49 for ; Sun, 9 Apr 2006 22:32:48 +0000 (GMT) (envelope-from andrea@webcom.it) Received: from andrea by webcom.it with local (Exim 3.36 #1) id 1FSiSc-0009h6-00 for freebsd-net@freebsd.org; Sun, 09 Apr 2006 22:32:46 +0000 Date: Sun, 9 Apr 2006 22:32:46 +0000 From: Andrea Campi To: freebsd-net@freebsd.org Message-ID: <20060409223246.GA1747@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Sender: Andrea Campi Subject: TCP Daytona in userland X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2006 22:32:49 -0000 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