Slide 1AnnouncementsMidtermProject 1Feedback (positive)Feedback (negative)OutlineTransport ProtocolsFunctionality SplitTransport ProtocolsUDP: User Datagram Protocol [RFC 768]UDP, cont.UDP ChecksumHigh-Level TCP CharacteristicsTCP HeaderEvolution of TCPTCP Through the 1990sOutlineSlide 19Recovering from ErrorProblems with Stop and WaitHow to Recognize Resends?How to Keep the Pipe Full?Sliding WindowSender/Receiver StateSequence NumbersWindow Sliding – Common CaseLoss RecoveryGo-Back-N in ActionSelective RepeatSelective Repeat: Sender, Receiver WindowsImportant LessonsNext LecturePonder This…15-441 Computer NetworkingLecture 15 – Transport ProtocolsCopyright ©, 2007-10 Carnegie Mellon University2Announcements•Ignore SIO posted midsemester grades – they are wrong in both directions!!•Sorry •Feel free to stop by OHs or make appointment•New mid-semester grades•Should have received them by email•Based on project1 + midterm + HW1 + HW2 •NOTE: GRADES DO NOT REFLECT LATE PENALTIES!•37.5% of class•If you got a D+,D, D- or F must meet with Seth or me•62.5% of class grade remains!Midterm•Avg: 59.5•Med: 59•STD: 10.4•Max: 78•Min: 28326-3031-3536-4041-4546-5051-5556-6061-6566-7071-7576-8002468101214Project 1•Avg: 87•Med: 98•STD: 27.3•Max: 100•Min: 040-511-1521-2531-3541-4551-5561-6571-7581-8591-95051015202530354045Feedback (positive)Likes•20: project•17: lectures (or some aspect of lectures)•6: recitations/bboard/TAs•4: HW•2: textbook•2: video•“Extra” slides•CheckpointsMore•10: Project: updated/more complex/lower level/more interesting/harder checkpoints•4: Topics: MORE (future Internet/research, security, routing), LESS(PHY)•4: More/smaller exams and more/smaller HW•Late days•More OH•Updated video•Remove failing component rule5Feedback (negative)Project/HW•10: Specification (RFC vagueness, writeup bugs/changes, updates)•7: Feedback/Grading (quicker, more, access)•3: Starter code (need more)•Test scripts•Allow non-C coding•Checkpoint feedbackLectures•7: lecture slides (more details/3: more examples/ too dense/ post earlier/ better)•Not helpfulOther•3: lecture/proj/HW/book disconnected•2: Switch bboard to forum •bboard response time67Outline•Transport introduction•Error recovery & flow control8Transport Protocols•Lowest level end-to-end protocol.•Header generated by sender is interpreted only by the destination•Routers view transport header as part of the payload776655776655TransportTransportIPIPDatalinkDatalinkPhysicalPhysicalTransportTransportIPIPDatalinkDatalinkPhysicalPhysicalIPIProuter222211119Functionality Split•Network provides best-effort delivery•End-systems implement many functions•Reliability•In-order delivery•Demultiplexing•Message boundaries•Connection abstraction•Congestion control•…10Transport Protocols•UDP provides just integrity and demux•TCP adds…•Connection-oriented•Reliable•Ordered•Point-to-point•Byte-stream•Full duplex•Flow and congestion controlled11UDP: User Datagram Protocol [RFC 768]•“No frills,” “bare bones” Internet transport protocol•“Best effort” service, UDP segments may be:•Lost•Delivered out of order to app•Connectionless:•No handshaking between UDP sender, receiver•Each UDP segment handled independently of othersWhy is there a UDP?•No connection establishment (which can add delay)•Simple: no connection state at sender, receiver•Small header•No congestion control: UDP can blast away as fast as desired12UDP, cont.•Often used for streaming multimedia apps•Loss tolerant•Rate sensitive•Other UDP uses (why?):•DNS, SNMP•Reliable transfer over UDP•Must be at application layer•Application-specific error recoverySource port # Dest port #32 bitsApplicationdata (message)UDP segment formatLengthChecksumLength, inbytes of UDPsegment,includingheader13UDP ChecksumSender:•Treat segment contents as sequence of 16-bit integers•Checksum: addition (1’s complement sum) of segment contents•Sender puts checksum value into UDP checksum fieldReceiver:•Compute checksum of received segment•Check if computed checksum equals checksum field value:•NO - error detected•YES - no error detectedBut maybe errors nonethless? Goal: detect “errors” (e.g., flipped bits) in transmitted segment – optional use!14High-Level TCP Characteristics•Protocol implemented entirely at the ends•Fate sharing•Protocol has evolved over time and will continue to do so•Nearly impossible to change the header•Use options to add information to the header•These do change sometimes•Change processing at endpoints•Backward compatibility is what makes it TCP15TCP HeaderSource port Destination portSequence numberAcknowledgementAdvertised windowHdrLenFlags0Checksum Urgent pointerOptions (variable)DataFlags:SYNFINRESETPUSHURGACK16Evolution of TCP1975 1980198519901982TCP & IPRFC 793 & 7911974TCP described byVint Cerf and Bob KahnIn IEEE Trans Comm1983BSD Unix 4.2supports TCP/IP1984Nagel’s algorithmto reduce overheadof small packets;predicts congestion collapse1987Karn’s algorithmto better estimate round-trip time1986Congestion collapseobserved1988Van Jacobson’s algorithmscongestion avoidance and congestion control(most implemented in 4.3BSD Tahoe)19904.3BSD Renofast retransmitdelayed ACK’s1975Three-way handshakeRaymond TomlinsonIn SIGCOMM 7517TCP Through the 1990s1993199419961994ECN(Floyd)Explicit CongestionNotification1993TCP Vegas (Brakmo et al)delay-based congestion avoidance1994T/TCP(Braden)TransactionTCP1996SACK TCP(Floyd et al)Selective Acknowledgement1996HoeNewReno startup and loss recovery1996FACK TCP(Mathis et al)extension to SACK18Outline•Transport introduction•Error recovery & flow control19Stop and WaitTimePacketACKTimeout•ARQ•Receiver sends acknowledgement (ACK) when it receives packet•Sender waits for ACK and timeouts if it does not arrive within some time period•Simplest ARQ protocol•Send a packet, stop and wait until ACK arrives Sender Receiver20Recovering from ErrorPacketTimeoutPacketACKTimeoutPacketTimeoutPacketACKTimeoutTimePacketTimeoutPacketACKTimeoutACK lost Packet lostEarly timeoutDUPLICATEPACKETS!!!21•How to recognize a duplicate•Performance•Can only send one packet per round tripProblems with Stop and Wait22How to Recognize Resends?•Use sequence numbers•both packets and acks•Sequence # in packet is finite How big should it
View Full Document