Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: comp.dcom.modems Subject: PPP spoofing, NetBlazer (was Re: Telebits "PEP" protocol) Message-ID: Date: 18 Dec 90 16:03:56 GMT References: <3592@jaytee.East.Sun.COM> <87673@lll-winken.LLNL.GOV> <36853@cup.portal.com> <87775@lll-winken.LLNL.GOV> Sender: usenet@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Organization: Morning Star Technologies Lines: 52 In article <87673@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: (From what I understand, SLIP spoofing, when it becomes available, will actually be making up for the half duplex nature of DAMQAM.) VJ's header compression (RFC1144) goes a long way toward this with no alterations in the underlying modem. He even mentions the Telebit Trailblazer and USR Courier HST as examples of less-than-full-duplex modems that provided design goals. SLIP or PPP spoofing would be problematic. UUCP spoofing works because uucico's ACKing and retransmission is at the granularity level of a complete file. The "g" protocol level doesn't manage file retransmission or restarts in mid-file. Kermit spoofing is similar. But TCP streams think that, once a packet has been ACKed, it has been delivered to the receiving end. Retransmission and restarts happen at a packet granularity. If part of the circuit between transmitter and receiver were to accept responsibility for delivery of a packet after ACKing it to the transmitter, it would destroy the end-to-end nature of TCP. In article <36853@cup.portal.com> cec@cup.portal.com (Cerafin E Castillo) writes: SLIP spoofing, from what Telebit has told me, will never exist. the Telebit NetBlazer is the current SLIP/CSLIP/PPP solution offered by Telebit. These are two different issues! One decides which bits to put on the wire, the other is the IP circuit handling logic. In article <87775@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: I'm really going to have to look at that product. I'm beginning to think that it might be the right thing to use for tele-commuting... A NetBlazer would indeed be a good thing to have in your office, on the receiving end of all the remote workers' dialins. It would also be a good thing for use between geographically-separated office sites that have occasional traffic, configured for on-demand connections. But even the base model is a little expensive for use with a single host, which is all most folks have at home (if LLNL employees are exceptions, please tell me where to send my resume :-). It's better for that case to implement on-demand dialup IP under that host's native operating system. I'd be surprised if a future KA9Q or NCSA or UNIX PPP implementation didn't contain that logic. ...On the other hand, it would still be slave to the underlaying modem technology... Exactly. The NetBlazer is just a smart router box that still needs to put the bits on the wire, and that's a modem's job. All the performance attributes of PEP or V.32/V.42/V.42bis will still be apparent (is that a nice way to put it? :-). Only the IP circuits will be easier to manage.