Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jul 2002 15:06:43 -0700
From:      Luigi Rizzo <rizzo@icir.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        Garrett Wollman <wollman@lcs.mit.edu>, Jonathan Lemon <jlemon@flugsvamp.com>, net@FreeBSD.ORG
Subject:   Re: Retransmit times (was something else)
Message-ID:  <20020718150643.A26307@iguana.icir.org>
In-Reply-To: <Pine.BSF.4.21.0207181436170.84569-100000@InterJet.elischer.org>; from julian@elischer.org on Thu, Jul 18, 2002 at 02:39:26PM -0700
References:  <200207182133.g6ILXHNl007758@khavrinen.lcs.mit.edu> <Pine.BSF.4.21.0207181436170.84569-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 18, 2002 at 02:39:26PM -0700, Julian Elischer wrote:
> and now that we are on -net.......
> TADA!!!
> SACK is now supported by default on 90% of internet hosts except for
> "guess who?"

supported does not mean used though, and I am not even sure how much
traffic is successfully delivered using SACK. I am Bcc-ing someone
who might know some data...

> SACK is the way that most internet traffic is now handling packet loss.
> Isn't it about time that one of the (3?) SACK implementations got
> integrated?

well, mine (dating back to 1996) is totally outdated and not terribly
well tested (in other words, "sacks"...), and the other one which
was announced last summer broke the regular behaviour in the non-sack
case, so...  I'd rather stay away from them unless someone wants
to put substantial amount of time in looking at them (which is not
fun at all).

	cheers
	luigi

> On Thu, 18 Jul 2002, Garrett Wollman wrote:
> 
> > [Trying desparately to move this discussion to the correct list....]
> > 
> > 
> > - He notes that Microsoft's TCP had a serious problem wherein it would
> > slow-retransmit too aggressively, which resulted in almost any network
> > transient triggering sufficient dupacks to cause fast retransmit to
> > engage.  (The result was that every data packet would be sent twice.)
> > He suggests that, to avoid this, it may be necessary to lengthen the
> > slow-retransmit timeout after a fast retransmit is triggered.
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020718150643.A26307>