Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!spool2.mu.edu!news.cs.indiana.edu!maytag!xenitec!zswamp!root From: root@zswamp.fidonet.org (Geoffrey Welsh) Newsgroups: comp.dcom.modems Subject: Re: PPP spoofing Message-ID: <6578.277D7512@zswamp.fidonet.org> Date: 29 Dec 90 19:41:43 GMT Organization: Izot's Swamp BBS - Kitchener, Ontario Lines: 70 Bob Sutterfield (bob@MorningStar.Com ) wrote: GW > Not if it could guarantee accurate delivery of the data GW >to a device which would retransmit it to the final destination if it GW >were to be NAKed... that is the way spoofing works. >If such a guarantee were possible, then your conclusion >would be correct. But a modem cannot guarantee packet delivery. If >a modem has ACKed a packet to the sender and continues to hold it in >its on-board memory buffer while it attempts to re-establish a >connection, the packet is vulnerable to a multitude of problems such as >power loss. Jeez... first I thought were were talking about recovery from line noise bursts... then we got into IP rerouting around breaking links... now you're throwing in a charge of Grand Failure Powerline! As you point out, end to end ACKing is the only robust procedure... but spoofing implies ACKing in a non end-to-end manner, so you seem to imply that there is no way to enhance Internet protocol performance by using spoofing? It's logical... but it's sad if true. >I'm having trouble imagining at what level of the stack >in-modem protocol spoofing might be useful for IP or ISO >internetworks, above the data link layer. It took me a while to figure out that this is what you were saying. It looks like we're stuck with the following situation: we can use intermediate queues and spoofing to increase the performance of the actual data transfer, but we must still depend on end-to-end acknowledgement at the file level. This leaves us vulnerable in that the situation may require retransmission of packets ACKed locally... but let's look closely at what we gain/lose: First of all, my machine and my modem run off the same power. If I am the originating site, it doesn't matter whether I've sent all of the data to the modem and am waiting for the whole file ACK from the remote site, or I'm still sending data blocks to the remote site and being ACKed end-to-end; the transfer will be interrupted either way. In both cases, I know that the file has not been received at the other end... but the enhanced throughput of the spoofed connection might allow me to complete the transfer before the power fails! I may really be sticking my foot in my mouth when I say this, because I am not familiar with the mechanics of Internet protocols, BUT... we need to develop protocols such that the receiving end can determine if a transfer has been previously attempted, and provide information to the sender such that it may be resumed. ZMODEM already does this: the receiver, if it detects that the file name, datestamp are identical to an existing file, informs the sender of how many bytes it has of the file and what the CRC of the bytes are. If the sender finds that the first n bytes of the file it's sending matches the CRC, the transmission jumps to the uncompleted portion. If we can all agree that this is a sensible way to go, we can take advantage of the enhanced throughput of spoofing while neither losing the robust nature of end to end ACKing nor necessitating massive redundant retransmissions whenever an in-progress transfer has been interrupted. Am I completely off the wall on this? If so, pardon my ignorance... I should lock myself into a (padded) room with some books on TCP/IP... -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Molson 'C' compiler... it specializes in 'case' statements!