1 / 44

ECE 5650 TL: Reliable Data Transfer

ECE 5650 TL: Reliable Data Transfer. IP service model Host-to-host best-effort delivery service, datagram Unreliable serivce UDP: unreliable, unordered delivery Proc to proc segment delivery: no-frills extension of “best-effort” IP (Multiplexing /demultiplexing) Error checking TCP:

cira
Télécharger la présentation

ECE 5650 TL: Reliable Data Transfer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ECE 5650 TL: Reliable Data Transfer Transport Layer

  2. IP service model Host-to-host best-effort delivery service, datagram Unreliable serivce UDP: unreliable, unordered delivery Proc to proc segment delivery: no-frills extension of “best-effort” IP (Multiplexing /demultiplexing) Error checking TCP: reliable, in-order delivery: flow control, sequence number, ack, timer, etc congestion control to prevent TCP connection from swamping the links and switches services not available in either TCP or UDP: delay guarantees bandwidth guarantees application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport Recap: transport-layer protocols Transport Layer

  3. application application application transport transport transport P4 P2 P3 P1 P1 network network network link link link physical physical physical Multiplexing at send host: Demultiplexing at rcv host: host 3 host 2 host 1 Recap: Multiplexing/demultiplexing (encode/decode) The job of delivering received transport-layer segments to correct socket. Each socket has a unique identifier (a set of fields in each segment) The job of gathering data from different sockets, enveloping data with header (later used for demultiplexing) and passing the data to the network layer. = socket = process Transport Layer

  4. P3 P2 P1 P1 SP: 9157 client IP: A DP: 6428 Client IP:B server IP: C SP: 5775 SP: 6428 SP: 6428 DP: 6428 DP: 5775 DP: 9157 Recap: Connectionless demux DatagramSocket serverSocket = new DatagramSocket(6428); One Server Socket port 9157 port 6428 port 5775 SP = Source Port, DP = Destination Port Source Packet provides “return address” that destination host can use to reply Transport Layer

  5. SP: 5775 SP: 9157 P1 P1 P2 P4 P3 P6 P5 client IP: A DP: 80 DP: 80 Recap: Conn-oriented demux Three Server Sockets S-IP: B D-IP:C SP: 9157 DP: 80 Client IP:B server IP: C S-IP: A S-IP: B D-IP:C D-IP:C SP = Source Port, DP = Destination Port, S-IP = Source IP, D-IP = Destination IP Transport Layer

  6. UDP segment has an 8 byte header. Length of UDP segment, in bytes, including header. Minimum length is 8 and maximum is 64k. Recap: UDP Segment Structure 32 bits source port # dest port # checksum (16-bit) length (16-bit) Application data (message) UDP segment format Transport Layer

  7. Recap: Internet Checksum: Sender Example • Note • When adding numbers, a carryout from the most significant bit needs to be added to the result • Segment has two 16-bit integers and the checksum • Add the two 16-bit integers • compute the checksum by taking the 1’s complement of the sum. 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 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 wraparound: add carry to LSB sum checksum Transport Layer

  8. 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control TL outline Transport Layer

  9. Reliable transfer: no data corrupted or loss, and in-order delivery important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Principles of Reliable data transfer Transport Layer

  10. rdt_send():called from above, (e.g., by app.). Passed data to deliver to receiver upper layer deliver_data():called by rdt to deliver data to upper udt_send():called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv():called when packet arrives on rcv-side of channel Reliable data transfer: getting started send side receive side Transport Layer

  11. 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 state 1 state 2 actions Reliable data transfer: getting started event causing state transition (when..happens) actions taken on state transition (then this happens) state: when in this “state” next state uniquely determined by next event Symbol L above or below the line denote the lack of an action or event Transport Layer

  12. Finite State Machine • FSM is a model of behavior composed of states, transitions and events • State stores info about the past, reflecting the system start to the present moment • Transition indicates a state change, triggered by an event • Events: activity to be performed at a given moment: entry, exit, input • FSM often represented using a state diagram Transport Layer

  13. 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 Rdt1.0: reliable transfer over a reliable channel rdt_send(data) rdt_rcv(packet) Wait for call from below Wait for call from above extract (packet,data) deliver_data(data) packet = make_pkt(data) udt_send(packet) sender receiver Transport Layer

  14. underlying channel may flip bits in packet Solution: checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells sender that pkt received “OK” negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors “please repeat that”. sender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection receiver feedback: control msgs (ACK,NAK) rcvr->sender Rdt2.0: channel with bit errors but does not lose packets Transport Layer

  15. Automatic Repeat reQuest protocols (ARQ) • Protocols based on ACKs and NAKs. • ARQ Protocols have 3 capabilities: • Error detection of bit errors which requires additional bits added to the transmitted packet. • Receiver feedback: ACK and NAK bit (1=ACK, 0=NAK) to be added to the transmitted packet. • Retransmission: a packet with errors will be retrasmitted. Transport Layer

  16. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt2.0: FSM specification rdt_send(data) receiver sndpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) L sender rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) Sender can not send another packet until receiver sends back ACK/NAK. (send-and-wait protocols) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transport Layer

  17. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) 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 udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transport Layer

  18. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) rdt2.0: error scenario rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transport Layer

  19. What happens if ACK/NAK corrupted? sender doesn’t know what happened at receiver! can’t just retransmit: possible duplicate Handling duplicates: sender retransmits current packet if ACK/NAK garbled/corrupt sender adds sequence number to each packet, 1-bit that changes if a new packet is sent receiver discards (doesn’t deliver up) duplicate pkt ACK/NAK packets do not need the sequence number of the packet acknowledged since sender knows it is for the last packet (we assume no packet loss) rdt2.0 has a fatal flaw! Transport Layer

  20. Wait for ACK or NAK 0 Wait for call 1 from above Wait for ACK or NAK 1 rdt2.1: sender, handles garbled ACK/NAKs rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) Wait for call 0 from above udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) L L rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) udt_send(sndpkt) Transport Layer

  21. Wait for 0 from below Wait for 1 from below rdt2.1: receiver, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Transport Layer

  22. Sender: seq # added to pkt two seq. #’s (0,1) will suffice. Why? must check if received ACK/NAK corrupted twice as many states state must “remember” whether “current” pkt has 0 or 1 seq. # Receiver: must check if received packet is duplicate state indicates whether 0 or 1 is expected pkt seq # note: receiver can not know if its last ACK/NAK received OK at sender rdt2.1: discussion Transport Layer

  23. same functionality as rdt2.1, using ACKs only instead of NAK, receiver sends ACK for last pkt received OK receiver must explicitly include seq # of pkt being ACKed duplicate ACK at sender results in same action as NAK: retransmit current pkt rdt2.2: a NAK-free protocol Transport Layer

  24. Wait for ACK 0 Wait for call 0 from above Wait for 0 from below rdt2.2: sender, receiver fragments rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) udt_send(sndpkt) sender FSM fragment rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) L receiver FSM fragment udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) Transport Layer

  25. New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions will be of help, but not enough Approach: sender waits “reasonable” amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but use of seq. #’s already handles this receiver must specify seq # of pkt being ACKed requires countdown timer rdt3.0: channels with errors and loss timeout is worst-case time (taking all types of delays into account) for packet to reach receiver and for an ACK to be received Transport Layer

  26. Wait for ACK0 Wait for ACK1 Wait for call 1 from above Wait for call 0from above rdt3.0 sender rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer L rdt_rcv(rcvpkt) L timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer L Transport Layer

  27. rdt3.0 in action Alternating-bit protocol because packet sequence numbers alternate between 0 and 1 Transport Layer

  28. rdt3.0 in action Transport Layer

  29. rdt3.0 works, but performance stinks example: 1 Gbps link, 15 ms e-e propagation delay, 1KByte packet: Performance of rdt3.0 L (packet length in bits) 8kb/pkt T = = = 8 microsec transmit R (transmission rate, bps) 10^9 b/sec last bit arrives at receiver at 15 ms + 8 microsec = 15.008 ms ACK comes back at sender at 15.008 ms + 15 ms = 30.008 ms (assuming ACK size is small) • U sender: utilization – fraction of time sender busy sending • 1 KByte packet every 30 msec -> 267 kbps throughput over 1 Gbps link • network protocol limits use of physical resources! Transport Layer

  30. rdt3.0: stop-and-wait operation sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Transport Layer

  31. Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: go-Back-N, selective repeat Pipelined protocols Transport Layer

  32. Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3! Transport Layer

  33. Sender: There is a k-bit sequence # in packet header “window” of up to N, consecutive unacknowledged sent/can-be-sent packets allowed window moves by 1 packet at a time when its 1st sent pkt is acknowledged (standard behavior) Go-Back-N (Sliding Window) window cannot contain acknowledged pkts Sender must respond to three types of events: • 1- Invocation from above: application layers tries to send a packet, if window is full then packet is returned otherwise the packet is accepted and sent. • 2- Receipt of an ACK: One ACK(n) received indicates that all pkts up to, including seq # n have been received - “cumulative ACK” • may receive duplicate ACKs (when receiver receives out-of-order packets) • 3- A timeout event (only cause of retransmission): • timer for each in-flight pkt. • if timeout occurs: retransmit packets that have not been acknowledged. Transport Layer

  34. Wait GBN: sender extended FSM rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) L base=1 nextseqnum=1 timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && corrupt(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer Transport Layer

  35. ACK-only: always send ACK for correctly-received pkt with highest in-order seq # need only remember expectedseqnum When out-of-order pkt is received: discard (don’t buffer) -> no receiver buffering! Re-ACK pkt with highest in-order sequence # GBN: receiver extended FSM default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) L Wait extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) Transport Layer

  36. GBN inaction Window-size = 4 Transport Layer

  37. Receiver discards out-of-order packets and does not even buffer them for future use: Receiver must deliver data in order to application layer If out-of-order packets are buffered and in-order packets are lost then a retransmission will re-send the out-of-order packets. Simplicity of receiver buffering due to discarding One disadvantage of not buffering is that a retransmission could be also lost which would require additional retransmissions. A single packet error can cause GBN sender to retransmit larger #pkts as the window size increases. Notes on GBN: Transport Layer

  38. receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer sender only resends pkts for which ACK not received sender timer for each unACKed pkt sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts Selective Repeat Transport Layer

  39. Selective repeat: sender, receiver windows Window may contain acknowledged pkts (unlike GBN) Transport Layer

  40. data from above : if next available seq # in window, send pkt timeout(n): resend pkt n, restart timer ACK(n) in window: mark pkt n as received if n smallest unACKed pkt, advance window base to next unACKed seq # receiver events sender events Selective repeat pkt n in window • send ACK(n) • out-of-order: buffer • in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt pkt n previously acknowledged • ACK(n), necessary to move sender’s window otherwise: • ignore Transport Layer

  41. Selective repeat in action Transport Layer

  42. Example: seq #’s: 0, 1, 2, 3 window size=3 receiver sees no difference in two scenarios! incorrectly passes duplicate data as new in (a) To avoid this condition:the sequence number space (k) must be at least twice as large as the window size (w) or k >= 2w Selective repeat: too large window dilemma Transport Layer

  43. Checksum: used to detect bit errors in transmitted pkt. Timer: used to retransmit a packet when the packet or its ACK was lost. Duplicate copies of pkt could be received due to premature timeouts when the packet or its ACK are delayed. Sequence number: used for sequential numbering of packets sent. Gaps in seq #s indicate lost/delayed packts while duplicate seq #s indicate duplicate pkts. Acknowledgement (ACK): used by receiver to tell sender a packet (individual ACK) or packets (cumulative) have been received. Negative Acknowledgement (NAK): used by receiver to tell sender a packet has not been received correctly. Pipelining: used to allow sending packets even if prior ones were not acknowledged and hence increasing the utilization of the sender. Window: used to restrict sender to send packets with seq #s within a range (window size) without waiting for an acknowledgement. Reliable Data Transfer Mechanisms Transport Layer

  44. Automatic Repeat reQuest protocols (ARQ) Send-and-wait protocols The use of Sequences numbers in reliable data transfers Low Utilization of the Send-and-wait protocols 2 approaches to Pipelined error recovery: Go-Back-N (GBN)/sliding-window protocol Selective Repeat (SR) Summary Transport Layer

More Related