TOC: Transport ProtocolsWhy?OverviewUDPTCPSummaryTOC–TransportWhy?IP provides a weak, but efficient service model (best-effort)Packets can be delayed, dropped, reordered, duplicatedPackets have limited size (why?)IP packets are addressed to a hostHow to decide which application gets which packets?How should hosts send into the network?Too fast is bad; too slow is not efficientTOC–Transport –Why?OverviewBasic FeaturesIllustrationPortsUDPTCPHeadersTOC–Transport –OverviewBasic FeaturesCan provide more reliability, in order delivery, at most once deliverySupports messages of arbitrary lengthProvide a way to decide which packets go to which applications (multiplexing/demultiplexing)Govern when hosts should send dataTOC–Transport –Overview –Basic FeaturesIllustrationIPTransportABC[A | B | p1 | p2 | …]p1 p2 p1 p2 p3 p1 p2portsApplicationHTTPDNSRAUDP: Not reliableTCP: Ordered, reliable, well-pacedTOC–Transport –Overview –IllustrationPortsNeed to decide which application gets which packetsSolution: map each socket to a portClient must know server’s portSeparate 16-bit port address space for UDP and TCP(src IP, src port, dst IP, dst port) uniquely identifies TCP connectionWell known ports (0-1023): everyone agrees which services run on these portse.g., ssh:22, http:80on UNIX, must be root to gain access to these ports (why?)ephemeral ports(most 1024-65535): given to clientse.g. chatclient gets one of theseTOC–Transport –Overview –PortsUDPUser Datagram Protocolminimalist transport protocolsame best-effort service model as IPmessages of up to 64KBprovides multiplexing/demultiplexing to IPdoes not provide congestion controladvantage over TCP: does not increase end-to-end delay over IPapplication example: video/audio streaming TOC–Transport –Overview –UDPTCPTransmission Control Protocolreliable, in-order, and at most once deliverymessages can be of arbitrary lengthprovides multiplexing/demultiplexing to IPprovides congestion control and avoidanceincreases end-to-end delay over IPe.g., file transfer, chatTOC–Transport –Overview –TCPHeadersIP header used for IP routing, fragmentation, error detection… (we study that when we explore IP)UDP header used for multiplexing/demultiplexing, error detectionTCP header used for multiplexing/demultiplexing, flow and congestion control IPTCP UDPdataTCP/UDPdataTCP/UDPIPApplicationSenderdataIPTCP UDPApplicationReceiverdataTCP/UDPdataTCP/UDPIPdataTOC–Transport –Overview –HeadersUDPService:Send datagram from (IPa, Port 1) to (IPb, Port 2)Service is unreliable, but error detection possibleHeader:Source portDestination port016 31UDP length UDP checksumPayload (variable)•UDP length is UDP packet length (including UDP header and payload, but not IP header)•Optional UDP checksum is over UDP packetWhy have UDP checksum in addition to IP checksum?Why not have just the UDP checksum?Why is the UDP checksum optional?TOC–Transport –UDPTCPServiceSteps3-Way HandshakeState Diagram: 1State Diagram: 2HeaderSliding Window ProtocolTOC–Transport –TCPServiceStart a connectionReliable byte stream deliveryfrom (IPa, TCP Port 1) to (IPb, TCP Port 2)Indication if connection fails: ResetTerminate connectionTOC–Transport –TCP –ServiceSYN kSYN n; ACK k+1DATA k+1; ACK n+1ACK k+n+1data exchangeFINFIN ACK½ closeFINFIN ACK½ closeSteps3-way handshakeTOC–Transport –TCP –Steps3WHDescriptionRationaleTOC–Transport –TCP –3WHDescriptionGoal: agree on a set of parameters: the start sequence number for each sideStarting sequence numbers are random.Client (initiator)ServerSYN, SeqNum= xSYN and ACK, SeqNum= y and Ack= x + 1ACK, Ack= y + 1ActiveOpenPassiveOpenconnect() listen()accept()allocatebuffer spaceTOC–Transport –TCP –3WH -DescriptionRationaleThree-way handshake adds 1 RTT delay Why?congestion control: SYN (40 byte) acts as cheap probeProtects against delayed packets from other connection (would confuse receiver)TOC–Transport –TCP –3WH -RationaleState Diagram 1ABSYNSYN + ACKData + ACKACK…FINFIN.ackFINFIN.ackListenSYN receivedEstablishedClose WaitLast AckClosedClosedSYN sentEstablishedFIN Wait-1FIN Wait-2Timed WaitClosed(1)(1): A waits in case B retransmits FIN and A must ack againTOC–Transport –TCP –State Diagram 1State Diagram 2TOC–Transport –TCP –State Diagram 2HeaderSequence number, acknowledgement, and advertised window – used by sliding-window based flow controlFlags:SYN, FIN – establishing/terminating a TCP connectionACK – set when Acknowledgement field is validURG – urgent data; Urgent Pointer says where non-urgent data startsPUSH – don’t wait to fill segmentRESET – abort connectionSource portDestination portOptions (variable)Sequence numberAcknowledgementAdvertised windowChecksum Urgent pointerFlagsHdrLen0 4 10 16 31Payload (variable)TOC–Transport –TCP –HeaderSliding Window ProtocolObjectivesStop & WaitGo-Back-nTOC–Transport –TCP –SWPObjectivesRetransmit missing packetsNumbering of packets and ACKsDo this efficientlyKeep transmitting whenever possibleDetect missing ACKs and retransmit quicklyTOC–Transport –TCP –SWP –ObjectivesStop & Wait ACKDATATimeSenderReceiverRTTSend; wait for ackIf timeout, retransmit; else repeatInefficient ifTRANS << RTTInefficient ifTRANS << RTTTRANSTOC–Transport –TCP –SWP –S&WGo-Back-n (GBN)DefinitionIllustration without errorsIllustration with errorsSliding window rulesSliding window exampleObservationsRound-Trip TimingThe question of ACKsTOC–Transport –TCP –SWP –GBNDefinitionTransmit up to n unacknowledged packetsIf timeout for ACK(k), retransmit k, k+1, …TOC–Transport –TCP –SWP –GBN –DefinitionExample without errorsTimen = 9 packets in one RTT instead of 1 Fully efficientTOC–Transport –TCP –SWP –GBN –No ErrorsExample with errorsTimeWindow size = 3 packetsWindow size = 3 packetsSender Receiver1234567TimeoutPacket 5567TOC–Transport –TCP –SWP –GBN –ErrorsSliding Window Ruleswindow = collection of adjacent sequence numbersthe size of the collection is the window sizeLet A be the last ack’d packet of sender without gap; then window of sender = {A+1,
View Full Document