Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!mathom.cisco.com!BILLW
From: BILLW@mathom.cisco.com (William "Chops" Westfield)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP Spoofing...
Message-ID: <12651077348.18.BILLW@mathom.cisco.com>
Date: 4 Jan 91 00:43:26 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27

"spoofing" usually refers to "faking" an ACK locally, to avoid being
slowed down by long round-trip delays.  In general, this is only useful
in very delay-sensitive protocols (eg those that need an ACK for a packet
before they can send the next packet, like XMODEM, old KERMIT, Novell, etc).
Since TCP already includes sliding windows, it is NOT particularly
delay sensitive, and would not benefit very much from being spoofed.
Spoofing is also difficult since there are things other than the data
transfer that can effect the window/etc...

Header and/or data compression of the packets is a different matter, and
is very useful on slow links (especially when you can compress a 40 byte
TCP header down to 3 bytes or so, ala CSLIP).  For this to be benificial,
you have to do the compression before you go over a slow link (in the PC,
not in the MODEM.)  A modem that compresses TCP headers is not particularly
useful unless the link between the modem is as much faster as the compression
ratio times the comm speed. (90kbps, for CSLIP style compression!)

Even without compression or spoofing, data rates using SLIP are not so
bad.  We WOULD benefit from as little as packet recognition in modems
so that line turn-around type events don't occur until the actual end
of packets.  What SLIP users usually complain about is echo-response
(in telnet), as opposed to ACK-response.  If anyone thinks that a modem
can do an adequate job of spoofing actual data, I'd invite them to
apply their talents to gambling or market research... :-)

BillW
-------