From owner-freebsd-net@FreeBSD.ORG Mon May 22 15:51:08 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 AFF6816A6F7 for ; Mon, 22 May 2006 15:51:08 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3003B43D45 for ; Mon, 22 May 2006 15:51:07 +0000 (GMT) (envelope-from nitro@263.net) Received: from intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with SMTP id D01D3F1363 for ; Mon, 22 May 2006 23:51:13 +0800 (CST) X-KSVirus-check: 0 References: <20060522141312.5E1D477AF5C@guns.icir.org> In-Reply-To: <20060522141312.5E1D477AF5C@guns.icir.org> From: mag@intron.ac To: mallman@icir.org Date: Mon, 22 May 2006 23:49:40 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <20060522155113.D01D3F1363@smtp.263.net> Cc: freebsd-net@freebsd.org, Marcin Jessa Subject: Re: How to Quicken TCP Re-transmission? 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: Mon, 22 May 2006 15:51:16 -0000 I believe two points: 1. Receiver should tell sender to re-send as soon as possible. (But TCP makes receiver purely passive) 2. Receiver should tell sender what is really necessary to re-send. (Sometimes only a single ACK number of TCP cannot include enough information) ------------------------------------------------------------------------ From Beijing, China Mark Allman wrote: > >> You can take a look at SCPS - http://www.scps.org/ Their protocol is >> used on lossy links with big latency and packet loss (such as >> satellites) and overcomes shortcomings of TCP. It works with divert >> mechanism of FreeBSD and I ported the tap device part as well to both >> NetBSD / FreeBSD (experimental). > > It's not clear to me that this is going to help. Fundamentally, TCP and > SCTP share the same congestion control response. At 30% packet loss > SCTP ought to be as unusable as TCP. Both consider losses to be > indications of network congestion. > > SCTP does have some things built-in that need to be added onto TCP > (e.g., SACK). So, we could expect more consistent behavior from SCTP > across implementations and platforms. But, in the end the performance > of both is proportional to 1/sqrt(p) where p is the loss rate. So, as > the loss rate increases performance decreases. At 30% you're > essentially cooked no matter which you use. > > allman > > >