Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!decwrl!ucbvax!telecom From: telecom@ucbvax.UUCP Newsgroups: mod.telecom Subject: Re: MNP Proposed as Industry Standard Message-ID: Date: Thu, 2-Jan-86 17:07:26 EST Article-I.D.: SIMTEL20.KPETERSEN.12173201925.BABYL Posted: Thu Jan 2 17:07:26 1986 Date-Received: Wed, 8-Jan-86 03:24:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Keywords: Can you say "Layered Protocols"? Yes, but I don't like to. Approved: telecom@mit-xx.arpa > And while I agree that error correction (and recovery) really must be > done at the application level, error recovery at lower levels can reduce > the overal data-flow overhead, as the higher up the problems must be > RECOVERED from, the more the overhead to perform the recovery... Note the key word "can", not "will". Upper levels sometimes need do *less* work to perform recovery, because they know more about what's going on. An extreme case is packet voice, where it is usually better *not* to attempt recovery at all, because the delay involved in recovery is much more audible than just forgetting the bad packet altogether and faking it until the next good one arrives. (How to "fake it"? Repeat the last packet. Or hold the sound output constant at the last value of the last packet. Or do any of several more complicated things. All less audible than a gap.) Also don't forget that layered protocols can exact a terrible price in performance, because of multiple layers of overhead. If your lines are noisy and your performance needs are both moderate and orthodox, low-level recovery is probably a win even though one does need end-to-end checks as well. If you care a lot about performance and your transmission medium is pretty good (e.g. Ethernet), the situation looks very different. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry