ComputerNetworks

Lecture13JingXu(徐晶)Dept.ofElectronicsandInformationEng.HuazhongUniversityofScienceandTechnologyDec.2011-2-Review:RequirementAnalysisWhatweexpectfromanetwork?Requirement1:connectivityAnestedInterconnectionofnodesandlinksRequirement2:cost-effectiveconnectivitySharingthishardwarebasethroughtheuseofstatisticalmultiplexingThisresultsinapacket-switchednetworkRequirement3:process-to-processcommunicationservices-3-Problem:GettingProcessestoComm.NetworkLayerTransportLayerApplicationLayerLinkLayerConnectivityamongHostsConnectivityatLinklayerleveldirectlinkorswitchednetworksConnectivityatnetworklayerlevel–internetworkinghost-to-hostprotocolsheterogeneityandscalabilityconcernswithinternetworkingIPservicemodelandprotocols?CommonServices?ProbleminChapter5:GettingProcessestoCommunicate-4--5-Lecture13Chapter5End-to-EndProtocolsProblem:GettingProcessestoCommunicate5.1SimpleDemultiplexer(UDP)5.2ReliableByteStream(TCP)5.3RemoteProcedureCall5.4Real-timetransportprotocol(RTP)5.5Performance5.6Summary-6-TransportLayer:AboveNetworkLayerTransportLayerApplicationLayerLinkLayerWhatapplication-levelprocessesaboveexpect?guaranteesmessagedeliverydeliversmessagesinthesameordertheyaresentdeliversatmostonecopyofeachmessagesupportsarbitrarilylargemessagessupportssynchronizationbetweenthesenderandthereceiverallowsthereceivertoapplyflowcontroltothesendersupportsmultipleapplicationprocessesoneachhost-7-TransportLayer:BelowNetworkLayerTransportLayerApplicationLayerLinkLayerWhatthenetworkbelowmayprovideunreliablepacketdeliverylossreorderingduplicatearbitrarilyvariabledelayfinitesizeofpacketWhatapplication-levelprocessesaboveexpect?guaranteesmessagedeliverydeliversmessagesinthesameordertheyaresentdeliversatmostonecopyofeachmessagesupportsarbitrarilylargemessages......-8-TransportLayer:ChallengesNetworkLayerTransportLayerApplicationLayerLinkLayerWhatthenetworkbelowmayprovideunreliablepacketdelivery:loss,reordering,duplicatearbitrarilyvariabledelayfinitesizeofpacketWhatapplication-levelprocessesaboveexpectmultipleapplicationprocessesreliablemessagedeliveryflowcontrolmessagelengthEnd-to-endprotocolsChallengesturndeficientaspectsofunderlyingnetworksintothehigh-levelserviceexpectedbyapplicationprocesses-9-TransportLayerProtocolsThischapterlooksfourrepresentativeservicesasimpleasynchronousdemultiplexingserviceUDP(UserDatagramProtocol)areliablebyte-streamserviceTCP(TransmissionControlProtocol)arequest/replyserviceRemoteProcedureCall(RPC)SunRPCandDCE-RPCareal-timetransmissionserviceRTP-10-Lecture13Chapter5End-to-EndProtocolsProblem:GettingProcessestoCommunicate5.1SimpleDemultiplexer(UDP)5.2ReliableByteStream(TCP)5.3RemoteProcedureCall5.4Real-timetransportprotocol(RTP)5.5Performance5.6SummaryUserDatagramProtocol(UDP)OneoftwotransportlayerprotocolsinTCP/IPprotocolstackUDP:developedin1980FirstTCPin1974,IPv4in1981FeaturesuponIP,justaddsalevelofdemultiplexingmessage-orientedconnectionlessnoguaranteetoreliablemessagedeliverynoflowcontrol-11-TwoBasicTransportFeaturesDemultiplexing:portnumbersErrordetection:checksums12Webserver(port80)ClienthostServerhostEchoserver(port7)Servicerequestto:80OSClientIPpayloaddetectcorruptionRequestfrom:3456Demuxtable(“5tuple”)Socket<*,*,,80,TCP>5<,3456,,80,TCP>6UDPDemultiplexing-14-UDPHeaderFieldsSrcPortandDstPort:identifyapplicationprocessesChecksum:optional,computedonthepayloadandpseudoheader-15-Port:PublicserviceHowaprocesslearnstheporttowhichitwantstosendamessage?Commonapproachisfortheservertoacceptmessagesatawell-knownportDNS,port53SNMP,port25PortMapperTheclientandserverusethewell-knownporttoagreeonsomeotherportthattheywilluseforsubsequentcommunication,leavingthewell-knownportfreeforotherclientsAdvantagesofUDPControloverwhatdataissentandwhenAssoonasanapplicationprocesswritesintothesocket…UDPwillpackagethedataandsendthepacketNodelayforconnectionestablishmentUDPjustsendsmessageswithoutcontactingthehostfirstPaysoffwhenhostisexpectingmessagesanywayStatelessconnectionNoallocationofbuffers,parameters,sequence#s,etc.…makingiteasiertohandlemanyactiveclientsatonce(thinkofservers)SmallpacketheaderoverheadUDPheaderisonlyeight-byteslong16DisadvantagesofUDP“Besteffort”networkingNoguaranteedeliveryofmessagestodestinationhost,noordereddeliveryNocongestioncontrolNoadaptationtothecongestionconditionsofthenetworkSuppressesTCPflowsIncaseofcongestionTCPflowswillbackoffwhileUDPwillstayonthesamerateCanbeusedasanattackmethod(UDPfloodingattack)17ApplicationsUtilizingUDPSimplequeryprotocolslikeDomainNameSystem(DNS)DelayforconnectionestablishmentistoolargeQueriesaresmallandUDPaddsasmalloverhead(header)EasiertohaveapplicationretransmitifneededUsuallymayfitwithinaUDPpacketsonoout-of-orderdangerMultimediaApplicationsRetransmittinglost/corruptedpacketsisnotworthwhileBythetimethepacketisretransmitted,it’stoolateE.g.,telephonecalls,videoconferencing,gamingCertainlossisacceptablesinceVoice,picture,etcarestilldiscernable18-19-Lecture13Chapter5End-to-EndProtocolsProblem:GettingProcessestoCommunicate5.1SimpleDemultiplexer(UDP)5.2ReliableByteStream(TCP)5.3RemoteProcedureCall5.4Real-timetransportprotocol(RTP)5.5Performance5.6Summary-20-TransmissionControlProtocol(TCP)OneoftwotransportlayerprotocolsinTCP/IPprotocolstackEarlyTCPTCP/IPFirstTCPin1974,IPv4in1981MostofapplicationsuseTCPProvidesRELIABLEbytestreamservicestoapplicationprocessesByteStreamingbyTCPTCPdoesnotdistinguishboundariesamongthemessageswrittenbyapplicationprocesses,buttransmitsdataintheformofsegmentApplicationprocessWritebytesTCPSendbufferSegmentSegmentSegmentTransmitsegmentsApplicationprocessReadbytesTCPReceivebuffer■■■TCPServiceModelConnectionorientedendhostsneedtoestablishaconnectionbeforedataexchangefull-duplex:datacanbeexchangedalongbothdirectionsReliabilityguaranteeddatadeliverydataisdeliveredinthecorrectorderFlowcontroltokeepthesenderfromoverloadingthereceiverflowcontrolalsoappearsinlinklayerCongestioncontroltokeepthesenderfromoverloadingthenetworkcongestioncontrolinnetworkandtransportlayer-22-Flowvs.CongestionControlReceiverbufferoverflowRouterbufferoverflowLecture135.2ReliableByteStream(TCP)5.2.1End-to-EndIssues5.2.2SegmentFormat5.2.3ConnectionEstablishmentandTermination5.2.4SlidingWindowRevisited5.2.5TriggeringTransmission5.2.6AdaptiveRetransmission5.2.7RecordBoundaries5.2.8TCPExtensions5.2.9AlternativeDesignChoices-24--25-Reviewofreliablecommunication:

OriginalStop-and-waitAlgorithmTimeouttriggerTimeouttriggerTwofundamentalmethodstoprovidereliablecommunication:(1)ACK(acknowledgement)(2)Timeout-26-Reviewofreliablecommunication:

OriginalSlidingWindowAlgorithmTimeouttriggerTimeouttriggerACKSenderWindowReceiverWindowSeqNum012Morecomponentsrequiredinslidingwindowalgorithm(3)SenderWindow/ReceiverWindow(4)DesignedSeqNumReliabletransmissionservicesBasicsolutionofReliabletransmissionservicesACK(acknowledgement)TimeoutLinklayerARQ,SlidingWindowAlgorithmTransportlayerWhatarethedifferences?DoesTCPDuplicateLowerLayerServices?-27--28-ChallengesofTCPReliabletrans.TimeouttriggerTimeouttriggerACKSenderWindowReceiverWindowSeqNum012Challenge1:HowtosetuptheConnection,Negotiationonstart/endBackgroundbelow:IPprovideconnection-less,un-reliableservices,runningacrossheterogenicnetworks,connectingdiversehosts-29-ChallengesofTCP-1Problem:ConnectionNotrequiredinasinglephysicallinkthatalwaysconnectsthesametwocomputersTCPshouldsupportlogicalconnectionsbetweenprocessesthatarerunningonanytwocomputersintheInternet.MotivationTCPneedsanexplicitconnectionstablishmentphaseTCPalsohasanexplicitconnectionteardownphase-30-ChallengesofTCPReliabletrans.TimeouttriggerTimeouttriggerACKSenderWindowReceiverWindowSeqNum012Backgroundbelow:IPprovideconnection-less,un-reliableservices,runningacrossheterogenicnetworks,connectingdiversehostsChallenge2:Timeoutproblem,Whentoretrans?EstimationonVariableRTT-31-ChallengesofTCP-2Problem:TimeoutasinglephysicallinkthatalwaysconnectsthesametwocomputershasafixedRTTTCPconnectionsarelikelytohavewidelydifferentround-triptimesDifferentdistance:SanFranciscotoBoston,RTT100ms,twohostsinthesameroom,RTT1msVariationsintheRTT:SanFranciscotoBoston,RTT100msat3a.m.,RTT500msat3p.m.Motiviationthetimeoutmechanisminslidingwindowalgorithmthattriggersretransmissionsmustbeadaptive.-32-ChallengesofTCPReliabletrans.TimeouttriggerTimeouttriggerACKSenderWindowReceiverWindowSeqNum012Challenge3:ReorderingPacketslossanddelayBackgroundbelow:IPprovideconnection-less,un-reliableservices,runningacrossheterogenicnetworks,connectingdiversehostsChallengesofTCP-3Problem:ReorderingReorderingisnotpossibleonapoint-to-pointlinkReorderinginrealmultiplehopInternetIPthrowspacketsawayaftertheirTTLexpiresMotivationTCPassumesthateachpackethasamaximumlifetime,maximumsegmentlifetime(MSL),currentrecommendedsettingis120secondsTCPhastobepreparedforveryoldpacketstosuddenlyshowupatthereceiver,potentiallyconfusingtheslidingwindowalgorithm-33--34-ChallengesofTCPReliabletrans.TimeouttriggerTimeouttriggerACKSenderWindowReceiverWindowSeqNum012Backgroundbelow:IPprovideconnection-less,un-reliableservices,runningacrossheterogenicnetworks,connectingdiversehostsChallenge4:FlowcontrolDiversedelay*bandwidth,bufferChallengesofTCP-4Problem:FlowcontrolBufferinslidingwindowcanbedesignedinpoint-to-pointlinkBufferdesignisdifficultintransmissionoverInterentdelay×bandwidthproductisunknownbuffermaybesharedamonghundredsofTCPconnectionsMotivationTCPmustincludeamechanismthateachsideusesto“l(fā)earn”whatresources(e.g.,howmuchbufferspace)theothersideisabletoapplytotheconnection.==>flow-controlissue.-35-ChallengesofTCPReliabletrans.-36-Cancongestionbesolvedlocally?ToomanyTCPconnectionsbringtoomuchtraffictotheintermediaterouterChallengesofTCP-5Problem:CongestioncontrolCongestionisnottheprobleminpoint-to-pointlinkCongestionwilloccurinInterentsendingsideofaTCPconnectionhasnoideawhatlinkswillbetraversedtoreachthedestinationdatabeinggeneratedbymanydifferentsourcesmightbetryingtotraversethissameslowlinkMotivationTCPhastorealisethecongestioncontrolalgorithmforthenetwork-37--38-SummaryofthechallegesChallengesofTCPcomparingwiththeReliabletransmissioninlinklayerConnectionTimeoutReorderingFlowcontrolCongestioncontrolCanwesolveitbyhop-to-hopsolution?Bytheendhost??Bytheintermediaterouter??-39-hop-to-hopvs.end-to-endX.25networksrunningonvirtualcircuitswitchingnetworktheunderlyingnetworkisassumedtobesomehowreliablemessagesaredeliveredreliablyandinorderbetweeneachpairofnodesalongthepathusetheslidingwindowprotocolonahop-by-hopbasisTCPrunningondatagramswitchingnetworktheunderlyingIPnetworkisassumedtobeunreliableandtodelivermessagesoutoforderTCPusestheslidingwindowalgorithmonanend-to-endbasistoprovidereliable/ordereddelivery-40-hop-to-hopvs.end-to-endAsequenceofhop-by-hopguaranteesdoesnotnecessarilyadduptoanend-to-endguaranteeEnd-to-endargumentAfunctionshouldnotbeprovidedinthelowerlevelsofthesystemunlessitcanbecompletelyandcorrectlyimplementedatthatlevelItisstillnecessarytoprovidetrueend-to-endcheckstoguaranteereliable/orderedservice,eventhoughthelowerlevelsofthesystemalsoimplementthatfunctionality.1981Lecture135.2ReliableByteStream(TCP)5.2.1End-to-EndIssues5.2.2SegmentFormat5.2.3ConnectionEstablishmentandTermination5.2.4SlidingWindowRevisited5.2.5TriggeringTransmission5.2.6AdaptiveRetransmission5.2.7RecordBoundaries5.2.8TCPExtensions5.2.9AlternativeDesignChoices-41--42-TCPSegmentsTCPsendsasegmentwhentheamountofdatareachesthemaximumsegmentsize(MSS)triggeredbytheapplication,e.g.pushoperationperiodictimerexpiresChoiceofMSSmakesresultedIPpacketnotbefragmentedMSS=MTU–IPheadersize–TCPheadersize-43-TCPPortsSimilartoUDP,TCPusesportnumberstoidentifytheclientandserverapplicationsWellknownportsareusedtoidentifyserverapplicationsexamples:HTTP(80),FTP(21)wellknownportnumbersarebetween1and1023Clientchoosesadifferentportnumberforeachapplicationprocesstheseportsareknownephemeralports(shortlived)usuallybetween1024and5000EachTCPconnectionisuniquelyidentifiedbya4-tuple<SrcIP,SrcPort,DstPort,DstIP>-44-TCPHeaderusedbysliding-windowbasedflowcontrolFlagsSYN,FIN–establishing/terminatingaTCPconnectionACK–setwhenAcknowledgementfieldisvalidURG–urgentdataPUSH–don’twaittofillsegmentRESET–abortconnectionLecture135.2ReliableByteStream(TCP)5.2.1End-to-EndIssues5.2.2SegmentFormat5.2.3ConnectionEstablishmentandTermination5.2.4SlidingWindowRevisited5.2.5TriggeringTransmission5.2.6AdaptiveRetransmission5.2.7RecordBoundaries5.2.8TCPExtensions5.2.9AlternativeDesignChoices-46-ConnectionEstablishmentDonebeforedatatransferBasedon3-wayhandshaketheexchangeofthreemessagesbetweentwoTCPpeerstoagreeontheinitialsequencenumbersoftwoTCPpeersTheinitialsequencenumberisrandomlygeneratedtheAcknowledgmentisalwaysonelargerthanthepeersent-47--48-3-WayHandshakeActiveparticipant(client)(server)SYN,SequenceNum=xACK,Acknowledgment=y+1Acknowledgment=x+1SYN+ACK,SequenceNum=y,Three-wayhandshaketoestablishconnectionHostAsendsaSYN(open)tothehostBHostBreturnsaSYNacknowledgment(SYNACK)HostAsendsanACKtoacknowledgetheSYNACK-49-ConnectionTerminationTwoindependenthandshakesterminatingunidirectionalhalfoftheconnectionClosingtheconnectionFinish(FIN)tocloseandreceiveremainingbytesAndotherhostsendsaFINACKtoacknowledgeReset(RST)tocloseandnotreceiveremainingbytesTCPStateTransition(State,Event/Action)Lecture135.2ReliableByteStream(TCP)5.2.1End-to-EndIssues5.2.2SegmentFormat5.2.3ConnectionEstablishmentandTermination5.2.4SlidingWindowRevisited5.2.5TriggeringTransmission5.2.6AdaptiveRetransmission5.2.7RecordBoundaries5.2.8TCPExtensions5.2.9AlternativeDesignChoices-51--52-TCPSlidingWindowAlgorithmTCP’svariantofslidingwindowalgorithmcanperformreliabledeliveryofdatain-orderdeliveryofdataflowcontrol(basedonvariedAdvertisedWindowfield)Slidingwindowalgorithmwithvariedreceivingwindowsizethereceiveradvertisesareceivingwindowsizetothesender,whichisvariedovertimeratherthanfixedthereceivingwindowsizeisinformedusingtheAdvertisedWindowfieldintheTCPheader53acknowledgedsenttobesentoutsidewindowSourcePortDest.PortSequenceNumberAcknowledgmentHL/FlagsAdvertisedWinD.ChecksumUrgentPointerOptions..SourcePortDest.PortSequenceNumberAcknowledgmentHL/FlagsAdvertisedWinD.ChecksumUrgentPointerOptions..PacketSentPacketReceivedAppwriteWindowFlowControl:SendSide-54-TCPSlidingWindowAlgorithm1.Reliableandin-orderdeliveryofdataLastByteAcked≤LastByteSentLastByteSent≤LastByteWrittenLastByteRead≤NextByteExpectedNextByteExpected≤LastByteRcvd+1-55-TCPSlidingWindowAlgorithm2.FlowcontrolFlowcontrol:asendersendsdataasmuchaspossiblebutwithoutoverloadingthereceiverAdjustthesender’swindowbyreceiver’srequirementratherthanwaitingfortheACKmsgs.AdvertisedWindowfieldinthereceiver'sview:LastByteReadReceiver’sviewLastByteRcvdNextByteExpectedLastByteRcvd-LastByteRead≤MaxRcvBufferAdvertisedWindow=MaxRcvBuffer–((NextByteExpected-1)-LastByteRead)-56-TCPSlidingWindowAlgorithm2.Flowcontrol(cont.)AdvertisedWindowfieldinthesender'sview:LastByteSent-LastByteAcked≤AdvertisedWindowEffectiveWindow=AdvertiseWindow–(LastByteSent–LastByteAcked)LastByteWrittenLastByteSentLastByteAckedSender’sviewLastByteWritten–LastByteAcked≤MaxSendBuffer-57-TCPSlidingWindowAlgorithm