REM%IMSSS@SAIL.STANFORD.EDU (Robert Elton Maas) (09/18/87)
<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