From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 01:53:27 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 960F416A41C; Fri, 17 Jun 2005 01:53:27 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F9743D1F; Fri, 17 Jun 2005 01:53:23 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j5H1qqwp039274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2005 08:52:53 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j5H1qpBl035396; Fri, 17 Jun 2005 08:52:51 +0700 (ICT) Date: Fri, 17 Jun 2005 08:52:51 +0700 (ICT) Message-Id: <200506170152.j5H1qpBl035396@banyan.cs.ait.ac.th> From: Olivier Nicole To: lists@yazzy.org In-reply-to: <20050616144707.18bfa000.lists@yazzy.org> (message from Marcin Jessa on Thu, 16 Jun 2005 14:47:07 +0200) References: <20050615114556.6df96e8c.lists@yazzy.org> <1118925438.91936.2.camel@realtime.exit.com> <20050616144707.18bfa000.lists@yazzy.org> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) X-Mailman-Approved-At: Fri, 17 Jun 2005 11:59:27 +0000 Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: Looking for networking solution. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 01:53:27 -0000 > I want to just dump all the packets between two satelite links > without checking for ack back and forth which creates latency and > long ping times. The latency is created by the satellite transmission delay, not by the ack. ACK suffer from the latency, but do not create it. > Correct. That's why I asked about this problem here. > I was in doubt something like that existed for FreeBSD. > We are willing to pay someone to develop such a solution for FreeBSD. > I'd love to get in touch with someone willing to pick up that challenge. I doubt that anyone will be interested in developping a protocol that do not care about the reliability of transmission. Just saying "drop the ack" is not the way to go. If you are talking about a protocole that does dialogue (like email), suppressing the ack will not help: one end must wait until it receives one question before it can answer, and then the ack is transmitted in the same paket as the answer. If you are talking about a more "one way" protocol (like http for ex. request one file and then wait for the file to flow), a better a pproach would be to allow a bigger chunk of data to get through before the first ack is due (to fill the pipe). That can be done by increading the window size of TCP, without damaging the retransmission capabilities. As the window size change would need to b done in every client and server, we were once considering to put two reverse NAT at each end of the satellite link. The NAT being in charge of changing the window size (I don't remember the full details, but it looked feasible). Olivier