[Bloat] short-circuit ACKs maybe
richard
richard at pacdat.net
Wed Feb 9 18:15:54 PST 2011
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 at pacdat.net 604-644-9265
http://digital-rag.com www.pacdat.net
PGP Fingerprint: FCEF 167D 151B 64C4 3333 57F0 4F18 AF98 9F59 DD73
More information about the Bloat
mailing list