Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!wuarchive!udel!gatech!hubcap!ncrcae!ncr-sd!crash!simpact!jeh
From: jeh@simpact.com
Newsgroups: comp.mail.uucp
Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP)
Message-ID: <688.252e37c2@simpact.com>
Date: 8 Oct 89 00:52:02 GMT
References: <1024@faatcrl.UUCP> <710@lakart.UUCP> <1029@faatcrl.UUCP>
Organization: Simpact Associates, San Diego CA
Lines: 59

In article <1029@faatcrl.UUCP>, jimb@faatcrl.UUCP (Jim Burwell) writes:
[ (many levels of inclusion from previous messages deleted]
> Yes.  I know the short blocks waste a lot of bandwith, but from watching modem
> lights, etc, it sure seems to me like there is some windowing going on.  I'm
> not sure, but it seems that 'g' continues to send blocks before it gets acked.
> Either that, or some uucicos spoof it by sending acks before chcking the block
> or something.  I guess I'll have to dig through some uucico source..
> 
> yes.  increasing the packet size would really help, but it seems like a 
> band-aid fix.  I still want zmodem!  (or some other streaming protocol..but
> why invent a new one ?)
> 
> bidirectional transfers would definitely not gain you much with a PEP
> connection.. I think the back channel is only 300 baud or so.  I'd be happy 
> with Zmodem for now :-).
> 

uucp 'g' definitely "streams" (or, in more conventional parlance, does 
windowing with transmit windowsize > 1; 3 is typical and is more than
sufficient to keep the transmitter transmitting continuously), and, no,
the other end doesn't spoof.  (The Telebit Trailblazer in uucp spoofing
mode *does* spoof, but that's another issue.)  There are a few implementations
(e.g. the gnuucp versino which was the basis for DECUS (VMS) uucp) which
don't do windowing but these are the exception.  

An increased packetsize will produce, at best, a marginal improvement.  
We typically see at least 215 char/sec throughput with 64-byte packets.
Allowing 512-byte packets increases the theoretical max from 219.4 char/sec
to 237.2, a whopping 8% increase.  Not a big deal.  And, as someone else 
said, increasing the packetsize increases the expense of error recovery.  

How would ZMODEM be a big improvement???

One oft-cited deficiency of 'g' is that error correction is go-back-n
rather than selective retransmit; in other words, the receiver windowsize
is 1.  This wouldn't be so bad, except that most uucp's I've watched on
a line analyzer are very shy about sending NAKs (ReJects for you purists);
most of the time they just let the sender time out awaiting an ACK (RR), which
really costs.  

Mind you, it doesn't pay to be too aggressive about sending NAKs either,
as the NAKs are nonspecific and will overlap with the sender's attempts to 
resend the current transmit window, so the sender will resend the whole 
window again, and...  The VMS implementation sends a NAK on 
the first data checksum error for a given packet and on every (transmit 
windowsize) error after that; this has proved robust on some remarkably 
bad lines (some artificially generated, some not), and still allows for
reasonably quick error recovery.  

In practice, I typically see the receipt of an ACK or NAK for packet 'n'
during the transmission of 'n'+1, so it does not seem to me that either
increasing the windowsize or implementing selective retransmit (which, 
by the way, limits your windowsize to 3, given g's 3-bit sequence numbers)
is going to help much.  

	--- Jamie Hanrahan, Simpact Associates, San Diego CA
Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG 
Internet:  jeh@simpact.com, or if that fails, jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!jeh