operateadequatelyevenifsomevideoframesarenotreceived.Itwould,however,needtoensurethatthose
messagesthataredeliveredarriveinthesameorderinwhichtheyweresent,toavoiddisplayingframesoutof
sequence.Liketherequest/replychannel,themessagestreamchannelmightwanttoensuretheprivacyandintegrity
ofthevideodata.Finally,themessagestreamchannelmightneedtosupportmulticast,sothatmultiplepartiescan
participateintheteleconferenceorviewthevideo.
Whileitiscommonforanetworkdesignertostriveforthesmallestnumberofabstractchanneltypesthatcanserve
thelargestnumberofapplications,thereisadangerintryingtogetawaywithtoofewchannelabstractions.Simply
stated,ifyouhaveahammer,theneverythinglookslikeanail.Forexample,ifallyouhavearemessagestreamand
request/replychannels,thenitistemptingtousethemforthenextapplicationthatcomesalong,evenifneithertype
providesexactlythesemanticsneededbytheapplication.Thus,networkdesignerswillprobablybeinventingnew
typesofchannels—andaddingoptionstoexistingchannels—foraslongasapplicationprogrammersareinventing
newapplications.
Alsonotethatindependentofexactlywhatfunctionalityagivenchannelprovides,thereisthequestionofwherethat
functionalityisimplemented.Inmanycases,itiseasiesttoviewthehost-to-hostconnectivityoftheunderlying
networkassimplyprovidingabitpipe,withanyhigh-levelcommunicationsemanticsprovidedattheendhosts.The
advantageofthisapproachisthatitkeepstheswitchesinthemiddleofthenetworkassimpleaspossible—they
simplyforwardpackets—butitrequirestheendhoststotakeonmuchoftheburdenofsupportingsemanticallyrich
process-to-processchannels.Thealternativeistopushadditionalfunctionalityontotheswitches,therebyallowingthe
endhoststobe"dumb"devices(e.g.,telephonehandsets).Wewillseethisquestionofhowvariousnetworkservices
arepartitionedbetweenthepacketswitchesandtheendhosts(devices)asarecurringissueinnetworkdesign.
Reliability
Assuggestedbytheexamplesjustconsidered,reliablemessagedeliveryisoneofthemostimportantfunctionsthata
networkcanprovide.Itisdifficulttodeterminehowtoprovidethisreliability,however,withoutfirstunderstandinghow
networkscanfail.Thefirstthingtorecognizeisthatcomputernetworksdonotexistinaperfectworld.Machines
crashandlaterarerebooted,fibersarecut,electricalinterferencecorruptsbitsinthedatabeingtransmitted,switches
runoutofbufferspace,and,asifthesesortsofphysicalproblemsaren'tenoughtoworryabout,thesoftwarethat
managesthehardwaremaycontainbugsandsometimesforwardspacketsintooblivion.Thus,amajorrequirementof
anetworkistorecoverfromcertainkindsoffailures,sothatapplicationprogramsdon'thavetodealwiththemoreven
beawareofthem.
Therearethreegeneralclassesoffailurethatnetworkdesignershavetoworryabout.First,asapacketistransmitted
overaphysicallink,biterrorsmaybeintroducedintothedata;thatis,a1isturnedintoa0orviceversa.Sometimes
singlebitsarecorrupted,butmoreoftenthannotabursterroroccurs—severalconsecutivebitsarecorrupted.Bit
errorstypicallyoccurbecauseoutsideforces,suchaslightningstrikes,powersurges,andmicrowaveovens,interfere
withthetransmissionofdata.Thegoodnewsisthatsuchbiterrorsarefairlyrare,affectingonaverageonlyoneoutof
every10 to10 bitsonatypicalcopper-basedcableandoneoutofevery10 to10 bitsonatypicalopticalfiber.
Aswewillsee,therearetechniquesthatdetectthesebiterrorswithhighprobability.Oncedetected,itissometimes
possibletocorrectforsucherrors—ifweknowwhichbitorbitsarecorrupted,wecansimplyflipthem—whileinother
casesthedamageissobadthatitisnecessarytodiscardtheentirepacket.Insuchacase,thesendermaybe
expectedtoretransmitthepacket.
Thesecondclassoffailureisatthepacket,ratherthanthebit,level;thatis,acompletepacketislostbythenetwork.
Onereasonthiscanhappenisthatthepacketcontainsanuncorrectablebiterrorandthereforehastobediscarded.
Amorelikelyreason,however,isthatoneofthenodesthathastohandlethepacket—forexample,aswitchthatis
forwardingitfromonelinktoanother—issooverloadedthatithasnoplacetostorethepacketandthereforeisforced
todropit.Thisistheproblemofcongestionjustdiscussed.Lesscommonly,thesoftwarerunningononeofthenodes
thathandlesthepacketmakesamistake.Forexample,itmightincorrectlyforwardapacketoutonthewronglink,so