Date: Wed, 04 Apr 2012 08:08:56 +1000 From: Darren Reed <darrenr@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size Message-ID: <4F7B74F8.9080600@freebsd.org> In-Reply-To: <4F7B3098.3090901@freebsd.org> References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> <4F7B3098.3090901@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/04/2012 3:17 AM, Andre Oppermann wrote: > On 03.04.2012 17:38, Darren Reed wrote: >> On 3/04/2012 11:45 PM, Andre Oppermann wrote: >>> It's the other way around. remote.ssh is sending old data >>> which freebsd82.62922 has already ack'ed. The sessions seems >>> to be de-synchronized, perhaps some middle box mucking with >>> the segments trying to modulate something? >> >> I suspect that the ISP is dropping packets and/or applying >> some other means of throttling the connection. So, yes. > > That doesn't explain it. The other side is retransmitting data > we have already received and acknowledged! There is not > nothing we can do on our side. That behavior is totally > non-compliant. > > The zero-window is not involved in this as it would affect > FreeBSD sending data, not the other end sending data. > > Can you try to find out what kind of middle-box is mucking > TCP here on your side and the other side? It must be some > device that actively touches the TCP session transiting > through it. A router with active queue management (like WFQ > or RED) is not enough to cause this behavior. > > What is the OS of your remote.ssh? NetBSD. So its TCP behaviour is going to be a lot like FreeBSD's. Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F7B74F8.9080600>