Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site petrus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!petrus!karn
From: karn@petrus.UUCP (Phil R. Karn)
Newsgroups: net.ham-radio.packet
Subject: Re: Link layer thoughts
Message-ID: <58@petrus.UUCP>
Date: Tue, 18-Mar-86 19:01:15 EST
Article-I.D.: petrus.58
Posted: Tue Mar 18 19:01:15 1986
Date-Received: Wed, 19-Mar-86 05:29:05 EST
References: <1655@decwrl.DEC.COM>
Organization: Bell Communications Research, Inc
Lines: 52

This is in response to Paul Koning's article of 13 March 1986 commenting
on my posting in December on an experimental new link layer protocol.

That posting represented my ideas at a very early stage; WB6RQN and I
wrote a paper for the 5th ARRL Computer Networking Conference that
incorporates a revised version of the protocol as part of a larger paper
on link level performance issues. Some of your questions and/or
objections are answered in the final paper; it's available as
<chepponis>ack-ack.ms (ms macro source) or <chepponis>ack-ack.txt (printable
output) on c.cs.cmu.edu; use anonymous FTP.

You are correct that my assumption of equal loss probability for data
and ACK packets is probably too optimistic. However, I do not agree that
"there is in fact little benefit from the proposal". Most packets are
lost due to collisions, not random thermal noise, so the relationship
between packet size and loss probability is not as clear. Monitoring the
local packet radio frequency reveals a LOT of unnecessary data packet
retransmissions, for whatever reason. ACK-ACK would clearly help in this
case. On the other hand, given a choice I would certainly prefer to have
channels so good that ACK-ACK wasn't needed...

Your alternate proposal (the Reply Requested control packet) is already
in AX.25 Version Two in the form of the Poll/Final recovery procedures.
However, I think that in the very lossy environment for which my
protocol is designed, receiver ACK retransmission is more efficient
because the sender wouldn't have to send anything to elicit the ACK
retransmission.  (Remember that the poll can itself be clobbered). My
goal in all of this has been to minimize the amount of channel time
needed to transfer a given amount of data; since we operate on a shared
channel, I consider the delay as seen by one user to be much less
important than optimizing the efficiency of the channel as a whole.

It ought to be pretty obvious that our protocol was motivated by the
desire for a simpler and more efficient means of relaying IP
datagrams. The host-host (transport level) protocols (e.g., TCP) used
atop IP are designed to reject duplicates created by retransmissions
within the network. However, a little analysis shows that the number of
duplicates would snowball (i.e., increase exponentially) as a packet
propagates across a series of links, and performance would be pretty
bad. Therefore, the published version of the protocol includes an "ID"
field whose purpose is to detect and filter out the majority (but not
necessarily all) duplicates caused by link layer retransmission.

Paul, thanks very much for your thoughtful note. Brian and I would be
very interested in any further comments after you've had a chance to
look over the revised paper, as it contains some further refinements and
simplifications I haven't mentioned here. We'd also be interested in
hearing your comments on AX.25.

73,

Phil Karn, KA9Q