From owner-freebsd-hackers Wed Jan 18 20:17:48 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA11193 for hackers-outgoing; Wed, 18 Jan 1995 20:17:48 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA11187 for ; Wed, 18 Jan 1995 20:17:43 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA14811; Thu, 19 Jan 1995 15:16:15 +1100 Date: Thu, 19 Jan 1995 15:16:15 +1100 From: Bruce Evans Message-Id: <199501190416.PAA14811@godzilla.zeta.org.au> To: davidg@Root.COM, olah@cs.utwente.nl Subject: Re: Netinet internals (Was: Patching a running kernel) Cc: hackers@FreeBSD.org, wollman@halloran-eldar.lcs.mit.edu Sender: hackers-owner@FreeBSD.org Precedence: bulk > Indeed, rfc1122 does say "SHOULD"...which makes this behavior not required. >The problem with acking this often is that on high speed, half-duplex networks >like ethernet, the collision rate caused by acks this frequently can consume a >large amount of the banwidth (measured 10-20%). > In the 4.4-lite TCP code, the acks every 2 packets was indirectly caused by >limiting the window to 4K. This had exceptionally bad side effects on long, >slow, high latency connections that are typical on the internet and usually >resulted in connection thrashing (my terminology) - i.e. the connection becomes >bursty and unable to stream. Perhaps the behaviour should depend more on the type of the interface. Do you remember me old bug report about it not being possible to saturate both directions of a SLIP interface? The two sides take turns in queueing acks behind so many sends that the acks don't get through before the other side stops sending. How is this supposed to work? Bruce