SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 3 Are these needed by all applications? Guarantee message delivery Guarantee ordered delivery No duplicates Arbitrary size messages How about things like Encryption, Synchronization,... Recall the end-to-end principle; we are getting closer to the ends What are common end-to-end services of interest? Ideally: transport protocol worries about the endto-end service provided to the application; it does not care about the communication path Application Service Models End-to-End (Transport) Protocols IP and the network layer provide host-to-host connectivity across a scalable heterogeneous network IP provides only best-effort connectivity; it can: Drop Messages Reorder messages Duplicate messages Delay messages a long time Limit size of messages How do these features compare with the requirements of applications? SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 1 Flow Control and Congestion Control End-to-end protocols Transport Protocols are often also the place where we provide 1. Flow control prevent a sender from overflowing its receiver 2. Congestion control prevent senders collectively from overflowing network is this an end-to-end service? 3. Fairness and QoS Next layer up from the network layer Its services (in order of increasing difficulty!): 1. Provides process to process connectivity (not just host to host) 2. Provides better service models to applications 3. Sometimes, we use this layer to manage congestion 4....or even attempt to provide fairness and Quality of Service SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 4 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 2
Discussion Why is end-to-end operation different from link-level communication? At the link layer (layer 2) ends on the link communicate with each other End-to-end, 2 ends of the connection communicate with each other Direct connection vs. a path over a switched network; we will revisit this relationship a couple of more times SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 5 Transport Protocols User Datagram Protocol (UDP) Basic transport: only provides process to process access to IP Many other protocols built on top of it Transmission Control Protocol () Reliable bytestream; many bells and whistles Others, including: Realtime Transmission Protocol (RTP/R) Remote Procedure Call (RPC) Stream Control Transmission Protocol (SCTP) Mutlicast Transport Protocols MFTP, PGM, etc.. Point UDP and are not the only transport protocols SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 6 UDP User Datagram Protocol Demultiplexing Application Application Application process process process Ports The simplest end-to-end protocol is to extend IP to recognize multiple processes per host UDP provides a simple demultiplexing key to differentiate between processes no other functionality is supported e.g., when a message arrives, if queues are full it is dropped Why is this interesting? What should be used as a demultiplex key How about process id? Queues Packets demultiplexed UDP Packets arrive Port Numbers are used as a demultiplex key A Port is a logical mailbox which is associated with a process How does a process know the key for a process it wants to communicate with? Well known port numbers for most servers (e.g., http server at port 80; defined in RFC 1700) Otherwise, by out-of-band agreement Try to tie this in with socket programming SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 7 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 8
IP Revisited 0 4 8 16 19 31 Version HLen TOS Length Ident Flags Offset TTL Protocol Checksum SourceAddr DestinationAddr Pad (variable) Options (variable) Data How does the packet get to UDP in the first place?? Protocol numbers also defined in RFC 1700 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 9 SrcPort UDP 0 16 31 Checksum Data DstPort Length UDP checksum is optional; when used, it checksums the whole message body (including UDP header) Psuedoheader from IP 0 7 8 15 16 23 24 31 source address destination address zero protocol UDP length Recall that IP checksum was on the IP header only Idea: protection against misrouted datagrams SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 10 Transmission Control Protocol () A reliable connection-oriented service model Reliable: everything gets there exactly one time connection-oriented: in-order delivery of a stream of bytes Full duplex Most widely used and most carefully tuned transport protocol on the internet Like UDP supports multiple processes per host (also using port numbers) implements both flow-control and congestion control (will discuss in detail later) SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 11 Overview of Operation Application process Send buffer Write bytes Segment Segment Segment Transmit segments Application process Connection establishment is needed Receive buffer Read bytes Sending process writes some bytes (any number) breaks into segments and sends via IP Receiving process reads some bytes (any number) How big is the segment? When does send the segments? How to implement Reliability and in-order delivery? SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 12
Overview (cont d) 0 4 10 16 31 SrcPort DstPort SequenceNum Common choice for Maximum Segment Size (MSS): maximum size that will not cause IP to fragment locally What is this equal to? When to send a segment? 1. When there is enough data to send an MSS 2. If the application demands an immediate send 3. Set a timer when you send a segment; send again when it fires Why three different ways? Packet boundaries are not visible to a process Reliability? Need some form of ARQ (isnt it supported at link layer?) In-order delivery? Dont allow a receive until all preceeding data has arrived HdrLen 0 Flags Checksum Acknowledgment Options (variable) Data AdvertisedWindow UrgPtr Source port and Destination port identify processes With source and destination IPs, they provide a unique connection identifier runs a sliding window algorithm Acknowledgements used to ack received segments Sequence number is the number of the first byte in the segment Advertised window is the size of the window at the receiver (flow control) Checksum is identical to UDP SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 13 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 14 Connection Establishment Passive participant (server) Active participant (client) SYN, SequenceNum = x Acknowledgment = x + 1 SYN +, SequenceNum = y,, Acknowledgment = y + 1 The sequence number is the number of the byte received last + 1 Initially randomly picked Note Duplex operation SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 15 SYN_RCVD Close/FIN FIN_WAIT_1 FIN_WAIT_2 State Diagram Passive open CLOSED LISTEN ESTABLISHED CLOSING TIME_WAIT Close SYN/SYN + Send/SYN SYN/SYN + Close/FIN FIN/ + FIN/ FIN/ SYN + / FIN/ Close Timeout after two segment lifetimes Active open/syn SYN_SENT CLOSE_WAIT LAST_ Close/FIN CLOSED Normal operation occurs within the established state Why timewait state? Track connection establishment and teardown SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 16
Established Operation Data (SequenceNum) Receiver Sender Acknowledgment + AdvertisedWindow Strategy Sliding window ARQ Use s and Sequence numbers sets a flag bit to say that the field is valid Flow control using advertised window (more soon) Congestion control (more later) SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 17 Sliding Window Operation in LastByteAcked Sending application LastByteWritten (a) LastByteSent Receiving application LastByteRead NextByteExpected (b) LastByteRcvd s sliding window is a hybrid of Selective repeat and Go-Back-N (accepts out of order segments, but cumulative ) Sender window size obtained by explicit feedback; used for flow control Advertised window is: (MaxRcvBuffer - (LastByteRcvd - LastByteRead)) Effective Send Window = Advertised Window - (Last Byte Sent - Last Byte d) SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 18 Problems/Performance Tuning Aside: Gigabit Networks and Wraparound Problems Zero window advertisement Sender probes with 1-byte packet Silly Window Syndrome Small openings in advertised window cause tiny packets to be sent inefficient Solution Sender side: Nagle s algorithm, wait before you send under some conditions Solution Receiver side: delay acks to give window chance to open can have bad side effects Problem: Gigabit networks and field wraparound Problem: 32-bit sequence number can wraparound fast on Gigabit networks assumes a packet cannot live more than Maximum Segment Life (MSL = 120s) Problem: valid packets with same sequence number alive at the same time Not a big problem currently; tend to be constrained by flow control first Problem: 16-bit advertised window field only enough to express 64-Kb window Delay bandwidth product (pipe volume) of Megabytes or even gigabytes possible Cannot fill the pipe without exceeding the advertised window Forced to operate at a low throughput SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 19 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 20
Solution: Long Fat Pipe Extension Uses options in header Add a timestamp to the packet; destination copies back onto helps identify different incarnations of the same sequence number Negotiate a scaling factor for the advertised window size Helps with the 16-bit advertised window limitation how? Is there a drawback? Details in RFC 1122 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #21 21