Week4 lec1-bscs1
- 1. Chapter 3 Transport Layer Computer Networking: A Top Down Approach, 4th edition. Jim Kurose, Keith Ross Addison-Wesley
- 2. Chapter 3: Transport Layer Our goals: Understand principles behind transport layer services: Multiplexing/De-multiplexing Reliable data transfer Congestion control Flow Control Learn about transport layer protocols in the Internet: UDP: connectionless transport TCP: connection-oriented transport TCP Reliability TCP congestion control TCP Flow Control
- 3. Transport Services and Protocols Transport layer protocols provide logical communication between app processes running on different hosts From application’s perspective as if the host running the process are directly connected Transport protocols run in end systems Not in routers Sender side: Breaks app messages into segments, passes to network layer Receiver side: Reassembles segments into messages, passes to application layer More than one transport protocol available to applications Internet: TCP and UDP application transport network data link physical application transport network data link physical
- 4. Transport vs. Network layer Network layer: logical communication between hosts Transport layer: logical communication between processes Household Analogy: 12 kids sending letters to 12 kids processes = kids app messages = letters in envelopes hosts = houses transport protocol = Ann and Bill network-layer protocol = postal service Transport layer relies on Network layer
- 5. Internet Transport Layer Protocols Internet Protocol (IP) Best effort delivery service No guarantees for segment delivery No guarantees for orderly delivery of data IP is unreliable service Extending Host-to-Host delivery to process-to-process delivery. Transport layer Multiplexing and De-multiplexing UDP and TCP also provide integrity checking by including error detection field in their segment headers. UDP services Process to process data delivery Error checking TCP Reliable data Transfer Congestion Control, sequence numbers, acknowledgements and timers
- 6. Multiplexing/De-Multiplexing Every process has a socket which allows Data to pass from the network to the process Data to pass from the process to the network Receiving host directs an incoming transport layer segment to appropriate socket. Uses set of fields in the transport layer segments Delivering data in the transport layer segment to the correct socket is called de-multiplexing. Gathering data chunks at the source host from different sockets ,appending header information and passing to the network layer is called multiplexing Household analogy
- 7. Multiplexing/De-multiplexing Demultiplexing at rcv host: delivering received segments to correct socket = socket = process application P3 P1 P1 application transport transport network network link physical P4 application link physical Multiplexing at send host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) host 1 P2 transport network link physical host 2 host 3
- 8. How De-multiplexing works Sockets have unique identifier Each segment has special field that indicate the socket to which the segment is to be delivered Source port number Destination port number Port is a 16 bit number 0 to 65535 0 to 1023 are well known port numbers and are reserved 32 bits Source Port # Dest Port # Other Header Fields Application Data (message) Transport Layer Segment Format
- 9. Connectionless Transport:UDP Internet transport protocol RFC 768 UDP does just about as little as a transport layer protocol can do Multiplexing/De-multiplexing Error checking “Best Effort” service, UDP segments may be: lost delivered out of order to applications Connectionless: No handshaking between UDP sender, receiver Each UDP segment handled independently of others
- 10. Connectionless Transport:UDP Why is there a UDP? No connection establishment TCP uses a three way handshake UDP has no delay to establish a connection DNS uses UDP No connection state at sender, receiver TCP maintains connection state Congestion control parameters, sequence numbers etc. UDP maintains no connection state Server can support many more active clients with UDP than over TCP Small segment header 20 bytes of header in TCP Only 8 bytes of header in UDP No congestion control UDP can blast away as fast as desired
- 11. UDP: Segment Structure The application data occupies the data field of the UDP segment. UDP header has four fields Each of two bytes Checksum Used by receiving host to check for errors in the segment Length Length of the UDP segment Length, in bytes of UDP segment, including header source port # dest port # length checksum Application data (message) UDP segment format
- 12. Connectionless (UDP) De-multiplexing P2 SP: 6428 SP: 6428 DP: 9157 client IP: A P1 P1 P3 SP: 9157 DP: 6428 DP: 5775 server IP: C SP provides “return address” SP: 5775 DP: 6428 Client IP:B
- 13. UDP Checksum Checksum is used to determine whether bits within the UDP segment have been altered e.g. noise in the link. Sender: Treat segment contents as sequence of 16-bit word Checksum: 1’s complement of the sum of all the 16bit words. Sender puts checksum value into UDP checksum field Receiver: All segments are added and than sum is added with sender's checksum. If no errors are introduced into the packet, then clearly the sum at the receiver will be all 1’s. If receiver side checksum contains any 0 then, error is detected and the packet is discarded.
- 14. Checksum Example (16 bits segment) 0110011001100110 0101010101010101 0000111100001111 The sum of first of these 16-bits integer is: 0110011001100110 0101010101010101 1011101110111011 Adding the third one to the above sum gives 1011101110111011 0000111100001111 1100101011001010 (sum of all segments) The checksum at sender side is : 0011010100110101 (1’s complement). Now at the receiver side, again all segments are added and sum is added with sender's checksum. If no error than check of receiver would be : 1111111111111111
- 15. Checksum Example Note When adding numbers, a carryout from the most significant bit needs to be added to the result Example: Add two 16-bit words 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
- 16. Home Assignment Difference between UDP and UDP Lite?
- 17. Principles of Reliable Data Transfer • Important in application, transport, link layers • Top-10 list of important networking topics!
- 18. Principles of Reliable Data Transfer (rdt) • Important in application, transport, link layers • Top-10 list of important networking topics!
- 19. Principles of Reliable Data Transfer • Important in application, transport, link layers • Top-10 list of important networking topics!
- 20. Reliable Data Transfer: Getting Started rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer send side udt_send(): called by rdt protocol, to transfer packet over unreliable channel to receiver deliver_data(): called by rdt to deliver data to upper layer receive side rdt_rcv(): called when packet arrives on rcv-side of channel
- 21. Reliable Data Transfer: Getting Started We’ll: • Incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) • Consider only unidirectional data transfer – but control info will flow on both directions! • Use Finite State Machines (FSM) to specify sender, receiver event causing state transition actions taken on state transition state: When in this “state” next state uniquely determined by next event state 1 event actions state 2
- 22. Rdt1.0: Reliable Data Transfer over a Perfectly Reliable Channel • Underlying channel perfectly reliable – no bit errors – no loss of packets • Separate FSMs for sender, receiver: – sender sends data into underlying channel – receiver read data from underlying channel • The initial state of the FSM is indicated by the dashed line Wait for call from above rdt_send(data) packet =make_pkt(data) udt_send(packet) Sender Wait for call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) Receiver Note:Perfectly reliable channel no need for feedback
- 23. Rdt2.0: Channel with Bit Errors • More realistic model – Underlying channel may flip bits in packet • How people deal with such a situation – OK (positive acknowledgment) – Please repeat that (negative acknowledgements) – Acknowledgements (ACKs): Receiver explicitly tells sender that pkt received OK – Negative acknowledgements (NAKs): Receiver explicitly tells sender that pkt had errors – Sender retransmits pkt on receipt of NAK • These control messages let the receiver know – What has been received in error and requires repetition • Automatic Repeat reQuest (ARQ) protocols.
- 24. Rdt2.0: Channel with Bit Errors Three capabilities are required in ARQ to handle the presence of bit errors. • Error Detection: – Needed to allow the receiver to detect bit errors – Checksum field in the header • Receiver Feed Back – Receiver provided explicit feedback – ACK – NAK • Retransmission – A packet that is received in error will be retransmitted • New mechanisms in rdt2.0 (beyond rdt1.0): – Error detection – Receiver feedback: Control msgs (ACK,NAK) Rcvr->Sender
- 25. Rdt2.0: FSM Specification rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above Wait for ACK or NAK udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below sender rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
- 26. Rdt2.0: Operation with No Errors rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above Wait for ACK or NAK udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
- 27. Rdt2.0: error scenario rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from above ACK or NAK udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
- 28. Rdt2.0 • rdt2.0 is a stop and wait protocol – Sender sends one packet, then waits for receiver response • rdt2.0 has a fatal flaw • What happens if ACK/NAK get corrupted? – • Add checksum bits to ACK/NAK How the protocol should recover from errors in ACK/NAK? – Retransmission on receipt of a corrupt ACK/NAK – Retransmission causes duplicates – Receiver does not know whether ACK or NAK it sent was received correctly – Receiver does not know a priori whether an arriving packet contains new data or is a retransmission Handling Duplicates: • Sender retransmits current packet if ACK/NAK garbled • Sender adds sequence number to each packet • Receiver discards (doesn’t deliver up) duplicate packet