Date: Mon, 22 May 2006 23:49:40 +0800 From: mag@intron.ac To: mallman@icir.org Cc: freebsd-net@freebsd.org, Marcin Jessa <lists@yazzy.org> Subject: Re: How to Quicken TCP Re-transmission? Message-ID: <20060522155113.D01D3F1363@smtp.263.net> In-Reply-To: <20060522141312.5E1D477AF5C@guns.icir.org> References: <20060522141312.5E1D477AF5C@guns.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060522155113.D01D3F1363>