🚀 go-pugleaf

<SE> Date: 4 Sep 87 13:58:06 GMT
<SE> From: hao!umigw!steve@husc6.harvard.edu  (steve emmerson)
<SE> Subject: Re: not packet-switching, packet-linking; fidonet specs??
<SE> To: protocols@RUTGERS.EDU

(Sorry for tardy reply, I'm way behind in email.)

>In comparing packet-switching and packet-linking in article
> <8709040503.AA13106@RUTGERS.EDU>, REM%IMSSS@SAIL.STANFORD.EDU (Robert
>Elton Maas) writes:
+----
|... (Packet-linking is error-protected blocks of data sent just on a
|single hop, and immediately dis-assembled before incorporation into
|error-protected block for next hop, ...  LOST PACKETS CAUSE RESEND ON
|ONE HOP RATHER THAN ACROSS AN ENTIRE NET [my emphasis -- sre], and are
|therefore much more prompt. ...
+----

<SE> Please excuse my confusion, but wouldn't it still be necessary to have 
<SE> end-to-end resend capabilty?

<SE> If I understand your explanation correctly, wouldn't it still be
<SE> possible for a block to be irretrievably lost due to a node crash?  If
<SE> node A notifies node B of correct reception of a block from node B, and
<SE> then crashes (loosing that block) it couldn't get a retransmission from
<SE> node B if node B reused that particular block buffer (as it should upon
<SE> reciept of the acknowledgment).

Right. There will be need for route re-establishment if a node goes down,
which may involve patching around the down node, or may involve
completely discarding the and making a new route. In that process, the
data counter on the two sides of the patch (or end-to-end) are compared
to see whether any data was lost in the down node, and the source side is
then backed up to re-send that lost data. But this happens much less
often than a simple lost packet, so rarely it can be dismissed as a
serious factor in average thruput. Mere packets getting dropped en route
across a hop don't require any end-to-end or route-control action at all.

Note that a node going down is quite different from mere net overload
which packet-switching suffers from as a matter of course, losing packets
right and left from random links, causing each to require an end-to-end
retransmission, seriously degrading thruput. With packet linking as I've
proposed, per-link flow control automatically slows down activity along
any route passing through a busy node or along a busy link just enough to
prevent lost data, and anyone controlling such a route who doesn't like
the slight slowdown has the option of rerouting through less-busy
links&nodes after passing a control message along the link to inquire
where the slowdown is occurring.

<SE> Am I missing something?

Only that statistically a node going down is insignificant compared to
the constant net-overload lost-packet end-to-end-resend problems that
plague packet switching.

<SE> DDN:   emmerson@miami.miami.edu (192.31.89.4) or
<SE>        emmerson%miami.span@su-star.arpa or 
<SE>        emmerson%miami.span@vlsi.jpl.nasa.gov