Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!SAIL.STANFORD.EDU!REM%IMSSS From: REM%IMSSS@SAIL.STANFORD.EDU (Robert Elton Maas) Newsgroups: comp.protocols.misc Subject: down node rare, net overload common; packet-linking wins Message-ID: <8709182206.AA21628@RUTGERS.EDU> Date: Fri, 18-Sep-87 14:33:19 EDT Article-I.D.: RUTGERS.8709182206.AA21628 Posted: Fri Sep 18 14:33:19 1987 Date-Received: Sun, 20-Sep-87 05:02:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 58 Date: 4 Sep 87 13:58:06 GMT From: hao!umigw!steve@husc6.harvard.edu (steve emmerson) Subject: Re: not packet-switching, packet-linking; fidonet specs?? 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. ... +---- Please excuse my confusion, but wouldn't it still be necessary to have end-to-end resend capabilty? If I understand your explanation correctly, wouldn't it still be possible for a block to be irretrievably lost due to a node crash? If node A notifies node B of correct reception of a block from node B, and then crashes (loosing that block) it couldn't get a retransmission from node B if node B reused that particular block buffer (as it should upon 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. 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. DDN: emmerson@miami.miami.edu (192.31.89.4) or emmerson%miami.span@su-star.arpa or emmerson%miami.span@vlsi.jpl.nasa.gov