From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.dcom.modems
Subject: Re: Interchange cables
Date: 6 Apr 92 15:22:19 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <j2831po@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|  In article <1992Apr2.144444.23220@crd.ge.com>, davidsen@yeti.crd.GE.COM (william E Davidsen) writes:
|  >
|  >   Have you got some figures for this? I haven't found that TCP is all
|  > that great a way to move data over a limited bandwidth line. In fact,
|  > the most cost effective way has seemed to be IHAVE uucp protocol,
|  > minimizing the transmission volume.
|  
|  You must be joking, even if your article ID is not from April 1.
|  
|  I wouldn't presume to defend TCP slowstart et al for moving data lover
|  limited bandwidth lines.  After all these years of something called The
|  Internet, that's rather a dead issue.  Neither can I imagine anyone
|  claiming a start-stop, 1 datum-at-a-time so-called protocol like NNTP might
|  be marginally effective.

  Have you perhaps confused NNTP with UUCP? I certainly never mentioned
NNTP...

  The reason the uucp IHAVE minimizes connect time is that one single
compressed batch of article numbers comes over, and the line disconnects
while the recipient decompresses and examines them. Then the request
(SENDME) message comes back as a compressed list of articles, and the
line disconnects. Then the feeder compresses the articles into large
batches (about 500k is nice over good modems), and the whole batch is
sent as a single transmission.

  I think you are confusing start-stop with multiple connections. Once
the process reaches steady state each connect will carry both batched
articles and IHAVE messages in one direction, and SENDME in the other.

|  I don't know, but bet that most UUNET phone customers (not Internet peers)
|  would say "sendme" for each and every "ihave" from uunet, so that it would
|  most effecient and fastest to have uunet simply rcp batches.

  Unless you have no other feeds whatsoever, that would get you a bunch
of stuff you already have. Any site which takes feeds from multiple
others, as you must to get good distribution and reliability, has a high
level of redundancy when all systems are up and functioning well.

|  If your got significantly better data thru UUCP than thru TCP, then
|  something was wrong.  Possibilities include failing to compress TPC headers
|  ("vj compression"), MTU too small causing excessive headers, machines
|  dropping characters and causing retransmissions, and if-queues too small
|  (window,bandwidth,delay) combination causing drops and retransmissions.

  Same modems, same lines. and if you mean that having some modem magic
diddle the headers, that's nice, but until an affordable modem comes
along which wants to do that, I'm going to measure what I have.

|  Resectioning the bowels of serial I/O, UUCP, and TCP for a brand of
|  workstaion is one of vocations.

  I can't think of a single polite thing to say. Some people spend all
their time improving their tools, and some of us try to pick the best
existing tool for the job and do useful work with it.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment