From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-21-ewr.dyndns.com (mxout-137-ewr.mailhop.org [216.146.33.137]) by lists.bufferbloat.net (Postfix) with ESMTP id 4C0872E04BF for ; Wed, 9 Feb 2011 18:16:02 -0800 (PST) Received: from scan-22-ewr.mailhop.org (scan-22-ewr.local [10.0.141.244]) by mail-21-ewr.dyndns.com (Postfix) with ESMTP id 9D2C8A1B for ; Thu, 10 Feb 2011 02:16:00 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 64.59.134.9 Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mail-21-ewr.dyndns.com (Postfix) with ESMTP id A39FC60DF for ; Thu, 10 Feb 2011 02:15:56 +0000 (UTC) Received: from pd7ml1no-ssvc.prod.shaw.ca ([10.0.153.161]) by pd6mo1no-svcs.prod.shaw.ca with ESMTP; 09 Feb 2011 19:15:55 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=AcJjKCdO+C1gfaz5PU+ZhOHJ3th58JHw7dR6QJZP96w= c=1 sm=1 a=BLceEmwcHowA:10 a=wPDyFdB5xvgA:10 a=xqWC_Br6kY4A:10 a=EvaGpPYFoCfc2jwbaD6Azw==:17 a=Jif4L5mEAAAA:8 a=3dZX8JWgAAAA:8 a=b7SLfKwVAAAA:8 a=jG4kwFC5EDJUeJDdCYcA:9 a=Ru90-iGzGOJ7Um4KDzMA:7 a=oqX4w3lxasFhTwm3aeu-jmjeAJYA:4 a=Fw8iwiUKpeAA:10 a=TphoKWqS9HQA:10 a=wJoommXVOcDLOBYS:21 a=sPQs1Acfr2lZIHue:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO amd.pacdat.net) ([96.48.77.169]) by pd7ml1no-dmz.prod.shaw.ca with ESMTP; 09 Feb 2011 19:15:55 -0700 Received: from localhost ([::1]) by amd.pacdat.net with esmtp (Exim 4.69) (envelope-from ) id 1PnM4Y-0001lG-Kp for bloat@lists.bufferbloat.net; Wed, 09 Feb 2011 18:15:55 -0800 From: richard To: bloat@lists.bufferbloat.net Content-Type: text/plain Date: Wed, 09 Feb 2011 18:15:54 -0800 Message-Id: <1297304154.21612.21.camel@amd.pacdat.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- Subject: [Bloat] short-circuit ACKs maybe X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 02:16:02 -0000 Back in the "middle" days of phone modems (after 9600 baud and before 54000 bps) there was the Telebit Trailblazer - 18,000 bps "ping-pong" (only transmit full speed in one direction at a time with a slow-speed back channel at 1200 bps) with built in compression and an interesting facility directly related to use with UUCP; it assumed the local serial connection was 100% reliable and KNEW it's own protocol guaranteed link integrity, so IT transmitted a UUCP ACK as soon as it saw the data coming into the sending modem from the sending application, and absorbed the ones coming back on the serial port of the receiving modem from the UUCP application, thus short-circuiting the application's and the link's delay and thus speeding up the throughput dramatically. Having just read http://www.stuartcheshire.org/papers/NagleDelayedAck/ paper detailing a potential/real problem with TCP's Delayed ACK facility, I started wondering if there was some method of dealing with this at the edge-router (consumer router) - a concept that likely has little or no application closer to the core but might have one at the edge. At minimum it might be reasonable to forestall the delayed ACKs. just a thought. The more I research this area the confusder I get :( And I thought nailing jello to a tree was hard. Kathie's pointers were very interesting - thanks. richard -- Richard C. Pitt Pacific Data Capture rcpitt@pacdat.net 604-644-9265 http://digital-rag.com www.pacdat.net PGP Fingerprint: FCEF 167D 151B 64C4 3333 57F0 4F18 AF98 9F59 DD73