From: richard <richard@pacdat.net>
To: bloat@lists.bufferbloat.net
Subject: [Bloat] short-circuit ACKs maybe
Date: Wed, 09 Feb 2011 18:15:54 -0800 [thread overview]
Message-ID: <1297304154.21612.21.camel@amd.pacdat.net> (raw)
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
reply other threads:[~2011-02-10 2:16 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1297304154.21612.21.camel@amd.pacdat.net \
--to=richard@pacdat.net \
--cc=bloat@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox