info-kermit@ucbvax.ARPA (07/27/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Fri, 26 Jul 1985 Volume 3 : Number 9
Departments:
ANNOUNCEMENTS -
Kermit for the PDP-8
PROPOSAL FEEDBACK -
Lurching Windows?
About the New Proposals
Kermit Windowing Questions and Answers...Continued
MISCELLANY -
Tranferring a MacPaint or MacDraw Document
MS-Kermit and the Hercules Monochrome Graphics Card
----------------------------------------------------------------------
Date: Fri 26 Jul 85 17:07:42-EDT
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Kermit for the PDP-8
This is to announce Kermit-8 for the DEC PDP-8 with OS8 or RTS8, written in
the PAL-8 assember by Jerry Sands and Randy Hippe of the Bureau of
Engraving, Inc., Minneapolis, MN. It works in local mode only, includes
CONNECT, BYE, EXIT, SEND, GET, and RECEIVE commands, and can do wildcard
sends. There is no documentation to speak of. The program is in
K2:K08MIT.PAL (and .HLP) on CU20B, available via anonymous FTP.
This means that Kermit is now available for every single existing DEC
machine operating system, with the exception of IAS-11 (soon to be
contributed, I hope). (I hope there aren't any PDP-1's, -4's, -6's, -7's,
9's, -12's, or 15's left out there... If you have one, why haven't you
written Kermit for it?) And if you count WPS-8 as an operating system,
maybe someone who knows something about it could convert this program for
the benefit all the poor DECmate users who need to transfer their WPS
"documents" to systems that don't have DX.
------------------------------
Date: Thu, 25 Jul 85 12:49:49 pdt
From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa
Subject: Lurching Windows?
I didn't see any discussion of how to extend this to half-duplex lines
("lurching windows"). Is any forthcoming?
Ken Poulton
[Ed. - See below.]
------------------------------
Date: 24 Jul 1985 1257-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: About the New Proposals
Yes, I have seen the stuff only "fly by" on the screen - so my comments will
be "fast and [maybe] not fully founded". [By the way, I like both proposals
and believe, they both will work together.]
I would like to introduce the "bulk" ACK from the Receiver [didn't see that
mentioned - or "lost it on the screen"], i.e. the Receiver has the freedom
to "ACK" every X packets, where X can be between 1 and the agreed upon
maximum window-size.
Receipt of the "BULK" ACK forces a "sliding" of the SENDER's window, so that
it "starts" after receipt with the next packet.
The Receiver will discard packets with packet-nr's LESS than current "BULK"
ACK and "BULK" ACK minus MAX Window-size. I will regard receipt of packets
with even smaller numbers a "serious errror" - i.e. stop receiving.
[To be "discussed more" : It might be also a good rule to FORCE an ACK on the
last two PACKETS BEFORE crossing the 64-magic to make sure, that the SENDER's
window slides nicely..]
I believe, that the above rules "get rid" of the receivers duty to keep a
"table" plus a relatively large buffer - it also leaves it open for the
receiver to "write to the 'disk' whenever he feels necessary"
It doesn't complicate SENDER behaviour - but the hightest overall "gain" is
anyhow at the 90% of down-loads from distribution-points, which typically
are slightly larger than "micro's" - and can afford the "extra" coding.
It also [as a side effect] eases handling of "larger packets" on the micro
[I just hate to debug the logic of a "floating table" depending on memory-
limits {relatively easy} plus "agreed upon" package size {slightly more
muggy} aggravated by [either] unexpected RE-Sends because I was too long
occupied didling the floppy or expected - i.e. I saw a bad packet , sent
a NAK but was not allowed to "throw away the rest".
Which leads to an "addendum" for the SENDER - all in the view of keeping
the coding EASY for all the micro-versions...
On receipt of a NAK - all PACKETS INCLUDING the NAKed one and [maybe already
sent other ones] will be re-sent.
If we are clever - remember the "bulk" number for the ACK didn't have to be
established - we can "train" the receiver to "trim down" the "bulk" number
depending on the amount of NAKs per X packets - thereby allowing a "macro"
adjustment to line-quality.
I will not go into "calculations" - but as a rule of thumb:
On SLOW channels [300 Baud] - there typically will be only ONE MORE packet
sent after the receiver sees the NAK - and its NOW the msg "Lets redo it
after the last good one" - so thats tolerable.
On "faster" channels [4800 Baud and UP] - there "might be" another packet
"sneaking in" - but "channel quality" typically tends to be better anyhow,
so "better quality" and "higher speed" make the overhead of above
simplification tolerable again.
... and last not least - one probably can even under CP/M with ist 64K
limitation handle both LARGER PACKETS and "floating ACKs"
Rgds,
Bernie.
--------------------------------------
Date: Fri 26 Jul 85 16:50:48-EDT
From: Leslie Spira <OC.SOURCE@CU20B.ARPA>
Subject: KERMIT Windowing Questions and Answers...continued.
FORWARD:
The two proposed extensions to KERMIT, Windowing and Extended Packet
Length, are both useful. They seem to me to be complementary, and each
solves certain problems that the other cannot.
The purpose for the development of the windowing protocol was to solve the
problem of how to increase throughput over circuits with long delays that
also had a potentially noisy section of the circuit.
The discussion of the Windowing protocol, and of Extended Packet Lengths,
should keep in mind the environments in which each would be useful. In
some cases, a combination would provide optimum performance.
The extensions will only be implemented for situations that make sense.
In all cases, KERMIT Classic will still be available, with all its utility
of being able to handle varied enviroments.
While reading the following questions and answers, keep in mind that this
windowing definiton was developed to handle a common situation of long
circuit delays with possible moderate error rates. KERMIT does not need
this type of extension for clean lines with insignificant delays - KERMIT
could be left alone, or use Extended Packet Lengths, in such environments.
Long delays with significant error rates will occur under two obvious and
common conditions:
A. Local phone line (of uncertain quality) to Public Data Networks
(such as Telenet).
B. Satellite phone links. These often occur with the lower-priced
phone services, which often also have noisier lines. In
addition, satellite links will increase as more people need to
transfer data overseas.
The above conditions will become more common, as well increased baud
rates, which make the delays more significant.
As an aside, note that the benefit of Extended Packet Lengths over the
Public Data Networks is limited by the number of outstanding bytes the PDN
allows. (Internally, the PDNs require end-to-end acknowledgement. They
use their own windowing system within the network.) I don't currently
know the exact impact of this.
Now on to the questions...
Q. Can sliding windows be done on half-duplex channels? Are any
modifications to the proposal required?
A. An underlying assumption in the development of windowing was that
there was a full-duplex channel. (See section 5.4, "Low Level
Protocol Requirements")
The intent of windowing is to try to keep the sender continuously
sending data. Obviously, this is not possible on a half-duplex
channel. A better solution for half-duplex channels would be to use
an extended packet length.
An attempt to use windowing on half-duplex really is just a way of
doing extended packet lengths. The sender would send out a group of
packets, then wait and get a group of ACKS. It would be better to
simply send out a large packet, which would have less overhead.
Q. Is the cost in complexity for sliding windows worth the increase in
performance?
A. Under the conditions described above (long delays and possibly
significant error rates) windowing can increase performance by a
factor of 2, 3, or more, especially at higher baud rates. This
increase is necessary to make KERMIT viable under some conditions.
With classic KERMIT over the Public Data Networks, I have had
througput as low as 250 baud over a 1200 baud circuit (with a
negligible error rate). Windowing should allow throughput close to
the maximum baud rate.
Windowing is most helpful when the delay is significant in relation to
data sending time. Any delay becomes more significant as users move
to higher baud rates (2400 baud and beyond).
The complexity of implementing windowing has yet to be fully
evaluated. The first implementation (for the IBM PC using C-KERMIT)
proved to be fairly manageable. It appears that the windowing logic
can be implemented so that KERMIT Classic uses the same code, but with
a window size of 1, which should avoid having to keep separate
sections of code.
The windowing definiton was developed with the idea of keeping changes
to KERMIT to a minimum. No new packet types were developed, ACKs and
NAKS were kept the same, and windowing is in effect only during actual
data transfer (D packets). We tried to define the protocol so that a
window size of 1 was the same as the current classic KERMIT.
These factors should help reduce the complexity of implementing
windowing. We currently have a working implementation of KERMIT for
the IBM PC going through testing.
It's fun to see the modem "Send" light stay on constantly!
Q. Why doesn't the Windowing proposal use a "bulk ACK"?
A. There are a couple of possibilities for ways to use some sort of
"bulk" or combined ACK. We looked at them when developing the
Windowing definition. We did not see any advantages that outweighed
the disadvantages.
Here are two possible ways of changing how ACKs would work:
1. An ACK for any packet would also ACK all previous packets.
2. A new "Bulk ACK" (BAK?) packet could be developed.
1. The concept that an ACK would also ACK all previous packets seems
attractive at first, since it would appear to reduce overhead.
However, it has a major drawback in that you then must re-synch when
you get errors. This is because, once you have an error, you have to
send a NAK, then stop and wait for a re-transmission of the NAKed
packet, before you send out any more ACKs. (If you sent out an ACK
for a later packet, it would imply that you had received the NAKed
packet. Not until you safely get the re-transmission can you go ahead.)
This would negate one of the nicest parts of windowing as it is
defined now, which is that the sender can transmit continuously,
including during error recovery, as long as the window does not become
blocked.
It does not appear to us that the reduction in the number of ACKs sent
is worth this penalty.
In addition, this is a departure from the way ACKs in KERMIT work
now. It seemed best to make as few changes to KERMIT as possible. If
this facility turns out to be useful, it would be better to introduce
a new packet type (or other means of distinguishing regular ACKs from
"Bulk ACKS").
2. A new "Bulk ACK" packet type could be developed. This did not seem to
us to be a good idea, since it required defining a new packet type.
We were trying to fit windowing in with as few changes to KERMIT as
possible.
A "Bulk ACK", in which one packet could contain a whole string of ACKs
and NAKs, also seems like a good idea at first. The penalty here is a
little more subtle. First, if you lose a "Bulk ACK" packet, you lose
more information and it takes longer to get things flowing smoothly
again.
Second, and probably more importantly, efficient windowing depends on
the window never becoming "blocked" (i.e., the sender can always keep
sending). A "Bulk ACK" interferes with this to some extent, because
if you have a long delay, the "Bulk ACK" with its multiple individual
ACKs may not get back to the sender in time to prevent the window from
becoming blocked.
With the current definition of windowing, returning an ACK for each
packet gets the ACKs (or NAKs) to the sender as soon as possible.
This provides the best chance for keeping the window open so that the
sender can transmit continually.
Once again, remember the conditions under which windowing is most
useful: long delays with significant error rates. Under these
conditions, individual ACKs have advantages.
If these conditions don't apply, it may not be necessary to use
windowing, or it may be better to use extended packet lengths.
------------------------------
Date: Thu, 25 Jul 85 16:41:22 PDT
From: ucsfcca.ucsf!jd9014@ucsf-cgl.ARPA (Joe DeBattista)
Subject: Tranferring a MacPaint or MacDraw Document
I have a question about whether it is possible to upload and/or download a
MacPaint or MacDraw document. When I use macput or macget with Versaterm or
MacTerminal this works ok, as it seems to grab the data and resource files
together. When I try to upload to our VAX 750, I can only specify the data
or resource from the settings menu. When I try to download a macpaint
document, I tried sending the data file first and then the resource, but
that didn't work. I've checked the MacKermit documentation for hints, and
have asked people around here if they have a solution. I am currently
running version 08(32). Thanks.
Joe DeBattista
BITNET: jd9014@ucsfcca
UUCP: ucbvax!ucsfcgl!ucsfcca.ucsf!jd9014
[Ed. - It says somewhere in the Mac Kermit documentation that you can only
send one fork of a file at a time. I think what you need to do is send each
fork separately, giving each a different name (like FOO.DATA and FOO.RSRC).
When bringing them back to the Mac, get the two files separately, each into
the appropriate fork of the same file. I realize this is less than
satisfactory, but Kermit was not designed to anticipate that a file could
actually have more than one part; the other programs you mentioned are
Mac-specific and designed to know about this. In general, I think the
safest way to treat arbitrary Mac files is to run them through Binhex before
transmitting to a foreign system, and unBinhex them upon return.]
------------------------------
Date: Tue, 23 Jul 85 19:17:35 BST
From: Ljwu@ucl-cs.arpa
Subject: MS-Kermit and the Hercules Monochrome Graphics Card
In response to query on MS-KERMIT with the Hercules card (vol 3
#5), I must say that I have encountered no problems, at least with
version 2.27. Our configuration is an XT, DOS 2.10, and a fully
populated QuadRam expansion card. We dedicate 360K to a RAM disk
using AST support though. Good luck!
Les Wu
------------------------------
End of Info-Kermit Digest
*************************
-------