info-kermit@ucbvax.ARPA (07/16/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Mon, 15 Jul 1985 Volume 3 : Number 4
Kermit Protocol Extension Proposals
Proposal for Extended Packet Lengths
----------------------------------------------------------------------
Date: Mon 15 Jul 85 16:12:15-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Protocol Extension Proposals
To: Info-Kermit@CU20B.ARPA
This week, two new extensions to the Kermit file transfer protocol will be
proposed. Both address one of Kermit's weakest areas: performance. Both
extensions are designed to allow extended Kermits to work transparently with
older Kermit programs that are ignorant of the extension; this has always
been the rule for extensions added to the protocol.
The two extensions are:
1. Longer packets.
2. Continuous transmission of packets in a "sliding window".
As originally designed, Kermit is a "stop and wait" protocol; each packet has
to be acknowledged before the next one is sent. A Kermit packet includes a
single-byte length field expressed as a printable ASCII character, limiting
the packet length to 94. The original design has been quite effective for
several reasons:
a. Kermit programs are simple to write.
b. The restriction on packet length guaranteed that Kermit would work on
practically every system, including the many whose terminal input buffers
cannot tolerate long bursts of input.
c. The stop-and-wait strategy gives the operating system time to consolidate
its input buffers.
As Kermit grows in popularity, it has found use in situations where its basic
design results in poor performance. Two examples:
a. Connections with built-in delays, like public networks or satellite
links. Unlike direct or dialup connections, these connections do not
have a dedicated channel; response varies with the current load on the
medium, and also with the "diameter" of the network. Delays can slow
down the performance or stop it all together if they exceed Kermit's
timeout parameters.
b. Direct, clean connections, to systems with big input buffers. When
the error rate is very low, throughput is unreasonably impeded by
stop-and-wait for short packets.
At first glance, it would seem that a single solution could address both
situations. First, note that any performance extension must require the
receiver of a file to have big input buffers (and since many many systems
don't, any extensions will have to be negotiable). The question is whether to
send one long packet or a bunch of short packets end-to-end (or both).
Assuming that each packet must be acknowledged, the advantage would seem to
go to long packets, since fewer acks would be required per unit data. But
when errors occur the amount of data to be retransmitted is less with short
packets, so a sliding window with short packets would be better in a
potentially noisy environment. But sliding windows work best on a full
duplex communication channel, which certain key systems do not provide.
It is still possible to do packet windowing on half-duplex connections, but
in this case the windows lurch rather than slide -- a batch of packets can be
sent, responded to by a batch of ACKs and NAKs.
Some random observations:
Longer packets are simpler to specify and program.
Windowing is harder to specify and program, and for true full duplex operation
also requires either multiprocessing (e.g. separate input and output forks) or
else interrupt-driven i/o.
Long packets need a rigorous error-detection mechanism like the 16-bit CRC.
The normal 6-bit checksum just won't do. Windowing with short packets, on the
other hand, should work well even with short block checks.
Currently during initial connection, two present-day Kermits tell each other
the longest packet they are prepared to accept, up to the maximum of 94.
Each computer bases this number on some knowledge about its input buffers.
But there are also external factors which may be unknown to the computers;
for instance, the connection has been made through a public packet-switched
network or a local area network whose interface devices might have smaller
buffers than the computers themselves. These factors have rarely interfered
with original ("classic"?) Kermit, because even its biggest packets are
acceptable to most of these devices. But if Kermit is extended to allow
transmission of much longer bursts of continuous data, all bets are off. The
burden will shift to the (often naive) user to understand the communications
environment enough to elect the best parameters and options.
The biq question is: Are the benefits in performance worth the cost in
complexity for specification, programming, and "user education"? Especially
in view of the likelihood that even if adopted, the extensions will
probably not be made to more than a few of the existing Kermit programs.
Assuming extension is desirable, which extension should be made: long packets,
sliding windows, or both?
The first proposal follows. The next one will appear in a forthcoming
Info-Kermit (most likely the next one). By the way, it should be noted that
long packets and windowing should probably be mutually exclusive, since the
proposal for windowing (in its present form) expresses window sizes in numbers
of packets, assuming the current maximum length.
------------------------------
Date: Mon 15 Jul 85 16:12:44-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Proposal for Extended Packet Lengths
To: Info-Kermit@CU20B.ARPA
A method is proposed to allow the formation of long Kermit packets.
Questions as to the desirability or appropriateness of this extension to the
Kermit protocol are not addressed. All numbers are in decimal (base 10)
notation, all arithmetic is integer arithmetic.
In order for long packets to be exchanged, the sender must set the LONGP bit
in the CAPAS field of the Send-Init (S or I) packet, and also furnish the
MAXLX1 and MAXLX2 (extended length 1 and 2) fields, as follows (the value for
the LONGP bit and the position of the MAXLX1,MAXLX2 fields have not yet been
settled):
---+-------+- -+--------+--------+
| CAPAS | ... | MAXLX1 | MAXLX2 |
---+-------+- -+--------+--------+
where MAXLX1 and MAXLX2 are each a printable ASCII character in the range SP
(space, ASCII 32) to ~ (tilde, ASCII 126), formed as follows:
MAXL1 = char(m / 95)
MAXL2 = char(m MOD 95)
(where m is the intended maximum length),
to indicate the longest extended-length packet it will accept as input. The
receiver responds with an ACK packet having the same bit also set in the CAPAS
field, and with the MAXLX1 and MAXLX2 fields set to indicate the maximum length
packet it will accept.
The maximum length expressible by this construct is 95 x 94 + 94, or 9024.
Since the sender can not know in advance whether the receiver is capable of
extended headers, the Send-Init MAXL field must also be set in the normal
manner for compatibility.
If the receiver responds favorably to an extended-length packet bid (that is,
if its ACK has the LONGP bit set in the CAPAS field), then the combined value
of its MAXLX1,MAXLX2 fields is used. If the the LONGP bit is set but
MAXL1,MAXL2 is missing, then the value 500 will be used by default.
If it responds unfavorably (the LONGP bit is not set in the CAPAS field),
then extended headers will not be used and the MAXL field will supply the
maximum packet length.
After the Send-Init has been sent and acknowledged with agreement to allow
extended headers, all packets up to and including the B or E packet which
terminates the transaction (and its acknowledgement) are allowed -- but not
required -- to have extended headers; extended and normal packets may be freely
mixed by both Kermits.
The normal Kermit packet length field (LEN) specifies the number of bytes
to follow, up to and including the block check. Since at least 3 bytes must
follow (SEQ, TYPE, and CHECK), a value of 0, 1, or 2 is never encountered
in the LEN field of a valid unextended Kermit packet. When extended packets
have been negotiated, the LEN field is treated as follows for the duration of
the transaction:
If unchar(LEN) > 2 then the packet is a normal, unextended packet.
If unchar(LEN) = 0 then the packet has a "Type 0" extended header.
If unchar(LEN) = 1 or 2, the packet is invalid and should evoke an Error.
"Lengths" of 1 and 2 are reserved for future use in Type 1 and 2 extended
headers, yet to be specified.
A Type 0 extended packet has the following layout:
+------+-----+-----+------+-------+-------+--------+---- ----+-------+
| MARK | | SEQ | TYPE | LENX1 | LENX2 | HCHECK | DATA .... | CHECK |
+------+-----+-----+------+-------+-------+--------+---- ----+-------+
| Extended Header |
The blank length field (SP = char(0)) indicates that the first 3 bytes of
what is normally the data field is now an extended header of Type 0, in which
the number of bytes remaining in the packet, up to and including the block
check, is
extended-length = (95 x unchar(LENX2)) + unchar(LENX2)
and HCHECK is a header checksum, formed exactly like a Type-1 Kermit block
check, but from the sum of the ASCII values of the SEQ, TYPE, LENX1, and
LENX2 fields:
s = SEQ + TYPE + LENX1 + LENX2
HCHECK = char((s + ((s AND 192)/64)) and 63)
Since the value of the extended length field must be known accurately in
order to locate the end of the packet and the packet block check, it is
vital that this information not be corrupted before it is used. The header
checksum prevents this.
The extended header, like the normal header itself, is NOT prefix-encoded.
This implies that the entity responsible for building packets must leave 3
spaces at the beginning of the data field, form the rest of the packet
(encode the data), and then go back and fill in LENX1, LENX2, and HCHECK
based upon the data actually entered into the packet, after encoding.
Similarly, the packet receiver must allow the extended header to be treated
as prefix-encoded data.
The packet block check is formed in the usual manner, based on all packet bytes
beginning with LEN and ending with the last character in the data field. The
block check may be Type 1, 2, or 3, depending upon what was negotiated, but
longer packets are more likely to be corrupted than shorter ones and should
therefore have higher-order block checks if possible. This proposal does not
change the way block check type is negotiated, and does not require that Type
2 or 3 block check be implemented.
------------------------------
End of Info-Kermit Digest
*************************
-------