dplatt@coherent.com (Dave Platt) (11/07/88)
There's another issue w.r.t. V.32 modems vs. Telebit PEP modems that I'm not sure has been mentioned. It may well be true that the V.32 modems may take over the bulk of the synchronous (SDLC/SNA) market and perhaps also the high end of the general-purpose interactive-dialup market. However, I'm not sure that these modems (in their "pure" V.32 form) will be all that useful in the USENET world. The reason is simple: Telebit modems (from the TrailBlazer Plus onwards) support protocol spoofing; none of the V.32 modems I've seen discussed have included this feature. UUCP-protocol spoofing is a _big_ win for those of us who use UUCP as our primary connection to the outside world. The fact that our hosts receive UUCP handshakes from the modem, rather than from the host at the other end of the phone line, has several very large advantages: 1) The sending host receives a packet-acknowledgement immediately, rather than having to wait for the packet to travel to the far-end host and be acknowledged. There's probably a small throughput-gain even over short (local-call) distances; there's an IMMENSE throughput gain when a call is routed over a long-delay link such as a geostationary satellite route. 2) Neither host must retransmit packets due to transmission-line lossages; the modems' PEP error-detection-and-retransmission handles all necessary data retransmission, and does it in a much more time-effective fashion than UUCP (which has an _very_ long packet-timeout value). I'm willing to believe that a standard V.32 modem could equal the UUCP performance of a PEP modem, _IF_ the PEP modem didn't support UUCP protocol spoofing. I have real doubts as to whether a V.32 modem could compete with a UUCP-spoofing PEP modem. I also expect that similar results would obtain when a file-transfer protocol such as XMODEM, YMODEM, or Kermit were being used. Those who favor V.32 as the New Standard can certainly argue that small-window protocols such as UUCP, XMODEM, and Kermit are fundamentally obsolete, and that people "should" use "better" protocols such as SDLC/SNA, TCP/SLIP, ZMODEM, and other large-window protocols. That's a valid route for us to take in the future... but it doesn't do us any good _today_. Let's face it, folks... there are a lot of us out here who must work with the host/micro software that we have today. We here at CTI depend heavily on Sun's rather out-of-date UUCP software to stay in touch with the outside world... we don't have sources, and don't have the luxury of rebuilding our UUCP driver to support a larger window or packet size(as would be necessary if we wanted UUCP to work decently over a V.32 modem at 9600 baud during cross-country calls). We don't have ZMODEM or sliding-windows Kermit, don't have SLIP (nor any place with which to connect), and don't care much about SDLC at the moment. For us, there are precisely two practical choices when it comes to modems: TrailBlazers, and 212/V.22bis modems. We use both... one 'Blazer for UUCP, and a bank of USR Couriers for UUCP and interactive dialin. The TrailBlazer Plus we bought last year has already more than paid for itself in reduced UUNET connect charges. It was the _only_ modem we could buy at the time that we could simply "drop into place" and have work effectively with our primary protocol (UUCP). If we retire it in a couple of years because a still-more-effective solution has arrived, I won't weep... it will have served its purpose, and paid for itself several times over. Very few investments do as well! Perhaps, someday, a V.32 modem manufacturer will release a V.32 modem that supports UUCP protocol spoofing. When that day arrives, I'll consider buying one.
David@cup.portal.com (David Michael McCord) (11/09/88)
The points about uucp protocol spoofing are well made. However, I wouldn't be all that suprised if Telebit was the first on the market with a uucp-spoofing v.32 device. David@cup.portal.com
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield) (11/11/88)
In article <11079@cup.portal.com> David@cup.portal.com (David Michael McCord) writes: >The points about uucp protocol spoofing are well made. >However, I wouldn't be all that suprised if Telebit was the first on the >market with a uucp-spoofing v.32 device. And I wouldn't be supprised if it still talks to their old product line! So then you would likely have the best of both possible worlds and your entire arguement against PEP goes in the bit bucket! You are also assuming that by the time V.32 is a practical reality and equal in cost/benefit tradeoffs to PEP (a year? hmmmm) that PEP will have stood still. Waiting for the new technology to arrive and improve on the present technology is a good phylosophy for getting nothing done. Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
brian@ncrcan.Toronto.NCR.COM (Brian Onn) (11/11/88)
In article <11079@cup.portal.com> David@cup.portal.com (David Michael McCord) writes: >However, I wouldn't be all that suprised if Telebit was the first on the >market with a uucp-spoofing v.32 device. Hey, wouldn't that be great! However, it would be rather useless until someone develops a new protocol that works bi-directionally. g on v.32 would be not utilize the full potential of the device. Brian. -- +-------------------+--------------------------------------------------------+ | Brian Onn | UUCP:..!{uunet!mnetor, watmath!utai}!lsuc!ncrcan!brian | | NCR Canada Ltd. | INTERNET: Brian.Onn@Toronto.NCR.COM | +-------------------+--------------------------------------------------------+
rwhite@nusdhub.UUCP (Robert C. White Jr.) (11/11/88)
in article <11079@cup.portal.com>, David@cup.portal.com (David Michael McCord) says: > However, I wouldn't be all that suprised if Telebit was the first on the > market with a uucp-spoofing v.32 device. Why bother? There would be no particular gain to spoofing using V.32 since the connection will not be impared by passing the protocol directly. There is no dynamic or adaptave turnaround to slow the connection durring the acknowlegement phases, and the ack phases slide through an open window wide enough to allow streaming (e.g. ack is not required before next packet is sent.) What would the spoofing buy me? Would that purchase be enough to justify getting back into a dependance relationship with a modem producer/programmer? How would I upgrade to some new uupc deritive (like larger windows and simultaneous bidirectional file transfer) without tripping all over the spoofing mode on some modems? Sticking strictly to V.32, how would my modem know when to spoof? Rob.
chris@mimsy.UUCP (Chris Torek) (11/13/88)
>In article <11079@cup.portal.com> David@cup.portal.com (David Michael McCord) >suggests: >>... I wouldn't be all that suprised if Telebit was the first on the >>market with a uucp-spoofing v.32 device. In article <1247@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >Why bother? There would be no particular gain to spoofing using V.32 >since the connection will not be impared by passing the protocol >directly. There is no dynamic or adaptave turnaround to slow the >connection durring the acknowlegement phases, and the ack phases slide >through an open window wide enough to allow streaming (e.g. ack is not >required before next packet is sent.) There would still be a minor gain if the computer<->modem connection is run at >9600 bps, or if the modem's error correction protocol reduces actual modem<->modem bit rate to <9600 bps. UUCP's `g' packets are a bit too small for efficient high speed communication. If the modem is strictly 9600 bps, you would gain nothing (since any modem-to-modem transmission of acks suppressed by spoofing would have to occur on one end of the modem-to-computer links anyway). If you use ACSnet-like software, *and* your data flow is approximately balanced, a true 9600 bps full duplex connection would outperform the average Telebit TB+ modem in terms of time required to transmit data, because the aggregate throughput approximates 19200 bps, not ~14000 as in the (unidirectional flow) TB+. If you use UUCP-like software, *or* if your data flow is predominately unidirectional, an adaptive half duplex protocol that provides more than 9600 bps in the primary direction will win over a full duplex protocol that provides only 9600 bps in the primary direction. It is worth noting that netnews flow is predominately unidirectional for leaf USENET nodes. Using a better transport mechanism than UUCP would still provide no incentive to switch to full duplex modems for such nodes, assuming that netnews makes up the bulk of your UUCP traffic. (At approximately 4 MB/day, it almost certainly does. This seems to be what Mr. McCord has missed: USENET leaf nodes are pushing multiple megabytes of junk each day in a single direction over any given dialup connection; we *need* most of the available bandwidth to be allocated unidirectionally. The data volume is high enough---and growing fast enough---to indicate that this unidirectionality is not likely to reverse for some time yet, despite the growing prevalence of things like SLIP. Netnews data flow remains unidirectional even if sent over IP or X.25. It will take a either a qualitative change in usage, which seems unlikely for the near future, or an enormous quantitative shift, which also seems unlikely, to change this. The exact compromise provided by the TB+ may not be appropriate a year from now, but one like it probably will.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jgp@moscom.UUCP (Jim Prescott) (11/23/88)
In article <1247@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >in article <11079@cup.portal.com>, David@cup.portal.com (David Michael McCord) says: >> However, I wouldn't be all that suprised if Telebit was the first on the >> market with a uucp-spoofing v.32 device. >Why bother? There would be no particular gain to spoofing using V.32 >since the connection will not be impared by passing the protocol directly. There would still be a gain since the modem can ack faster than the remote site can. A packet can take up to 70ms to go cross country and back. At 9600 even a 7 window g protocol stalls when the delay is over ~40ms. A better reason to say "why bother" is that it would only be useful when connecting to v.32 modems that have uucp-spoofing but do not have PEP. Are there really going to be that many vendors who care enough about unix and pc transfers to add the spoofing code and not add PEP (especially since they will almost certainly have at least one competitor with both)? If you have PEP there isn't any reason to do uucp transfers with v.32 since PEP will be faster. I would expect v.32 telebits to be able to make the connection using v.32 and then switch over to PEP at the same time they negotiate protocol spoofing. -- Jim Prescott moscom!jgp@cs.rochester.edu {rutgers,ames,harvard}!rochester!moscom!jgp
jgp@moscom.UUCP (Jim Prescott) (11/26/88)
In article <1304@moscom.UUCP> jgp@moscom.UUCP (Jim Prescott) writes: >At 9600 even a 7 window g protocol stalls when the delay is over ~40ms. Thanks to james@bigtex.cactus.org for pointing out that the 40ms is way off. At 9600 baud a round trip delay of ~430ms is needed to stall a 7 window g protocol. About 140ms for 3 window. So a modem with spoofing will still be able to provide acks quicker but it might not make much difference for most calls (although calling via satellite is sure to slow down the 3 window version). -- Jim Prescott moscom!jgp@cs.rochester.edu {rutgers,ames,harvard}!rochester!moscom!jgp