1 / 57

Chapter 3

Chapter 3. Transport Layer Section 3.4. 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

skyler-yates
Download Presentation

Chapter 3

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. Chapter 3 Transport Layer Section 3.4

  2. 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 Chapter 3 Outline

  3. Principles of Reliable Transport • TCP is a reliable data transfer protocol that sits at the Transport layer • IP is an unreliable end-to-end data transfer protocol sitting at the Network layer • TCP uses IP as its underlying transport • Therefore, it’s up to TCP to provide the reliable transport services

  4. Principles of Reliable Transport RDT = Reliable Data Transfer UDT = Unreliable Data Transfer • With a reliable channel • No transferred bits are corrupted (flipped) or lost • Delivered in the order in which they were sent The service model offered by TCP to Internet apps

  5. 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 send side receive side 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

  6. Reliable Data Transfer:Getting Started • In this discussion, we will • Incrementally develop sender, receiver sides of reliable data transfer protocol (RDT) • Consider data transfer in a single direction only (unidirectional) • But control info will flow on both directions! • Use finite state machines (FSM) to specify the sender and receiver

  7. Finite State Machine (FSM) • In general, a state machine is any device that • Stores the status of something at a given time • Can operate on input to change the status and/or cause an action or output to take place for any given change • A computer is basically a state machine • Each machine instruction is input that changes one or more states and may cause other actions to take place

  8. Finite State Machine (FSM) • To summarize it, a state machine can be described as • An initial state or record of something stored someplace • A set of possible input events • A set of new states that may result from the input • A set of possible actions or output events that result from a new state

  9. Finite State Machine (FSM) • A finite state machine (FSM) is one that has a limited or finite number of possible states • It can be used as • A development tool for approaching and solving problems • A formal way of describing the solution for later developers and system maintainers

  10. event causing state transition actions taken on state transition State: when in this “state,” the next state is uniquely determined by the next event event state 1 state 2 actions Finite State Machine (FSM) • This diagram illustrates the concept of a FSM • The FSM begins in state 1 • An event occurs that prompts some action • This event also causes the FSM to enter state 2

  11. The Reliable Data Transport (RDT) Protocol • Step by step we’ll build a reliable protocol for “the real world” • RDT 1.0: Reliable data transfer over a perfectly reliable channel • RDT 2.0: Reliable data transfer over a channel with bit errors • RDT 3.0: Reliable data transfer over a lossy channel with bit errors

  12. The underlying channel is perfectly reliable No bit errors No loss of packets Separate FSMs for sender and receiver Sender sends data into underlying channel Receiver read data from the underlying 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 RDT 1.0: Reliable Transfer over a Reliable Channel

  13. RDT 1.0 Assumptions • There is no difference between a unit of data and a packet • Packets are received in order • Sender and receiver don’t communicate • Because the channel is perfectly reliable, there’s no need for feedback between sender and receiver (acknowledgement) • We also assume that the receiver can accept data as fast as the sender can transmit it, so there’s no need to tell the sender to slow down (flow control)

  14. RDT 2.0: Reliable Transfer over a Channel with Bit Errors • Our underlying channel is no longer perfect, and bits may become corrupted • Packet transmission • Propagation over the network • Buffering • Packets continue to arrive in order

  15. RDT 2.0: Reliable Transfer over a Channel with Bit Errors • Because our channel is no longer perfect, sender and receiver must communicate • Positive acknowledgements (ACKs): receiver explicitly tells sender that packet was received OK • Negative acknowledgements (NAKs): receiver explicitly tells sender that the packet had errors • Sender retransmits packet on receipt of NAK

  16. RDT 2.0: Reliable Transfer over a Channel with Bit Errors • Automatic Repeat reQuest (ARQ) • Protocol for error control in data transmission • When the receiver detects an error in a packet, it automatically requests the transmitter to resend the packet • This process is repeated until the packet is error free or the error continues beyond a predetermined number of transmissions

  17. RDT 2.0: Reliable Transfer over a Channel with Bit Errors • Additional ARQ capabilities • Error detection • Receiver feedback • ACK: positive acknowledgement (1) • NAK: negative acknowledgement (0) • Retransmission

  18. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below RDT 2.0: FSM Specification rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) Receiver rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) L Sender • Sender has two states • Waiting for data • Waiting for reply • “Stop-and-wait” rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

  19. A packet is sent and arrives intact. The receiver sends a positive acknowledgement (ACK) to let the sender know it arrived okay. rdt_send(data) Wait for call from below snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for ACK or NAK Wait for call from above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(NAK) L Sender Receiver RDT 2.0: Operation with No Errors

  20. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) RDT 2.0: Error Scenario A packet is sent and arrives with errors. The receiver sends a negative acknowledgement (NAK) to let the sender know a problem occurred and request retransmission. Receiver rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) Wait for call from below rdt_rcv(rcvpkt) && isACK(rcvpkt) L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) Sender extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

  21. RDT 2.0: A Fatal Flaw • What happens if ACK/NAK is corrupted? • The sender doesn’t know what happened at receiver, and vice versa • The sender can’t just retransmit because of possible duplicates • Assigning a sequence number to each packet will help this problem

  22. Sequence Numbers • We now number the packets being sent • Receiver need only check the sequence number to determine whether or not the received packet is a retransmission

  23. Sequence Numbers • Handling duplicates • Sender adds sequence number to each packet • Sender retransmits current packet if ACK/NAK is garbled • Receiver discards (doesn’t deliver up) duplicate packet

  24. 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 Wait for ACK or NAK 0 udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) L L Wait for call 1 from above rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_send(data) Wait for ACK or NAK 1 sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) udt_send(sndpkt) RDT 2.1:Sender Handles Garbled ACK/NAKs RDT 2.1 Sender: 4 distinct states

  25. RDT 2.1 Sender • Sequence number is added to packet • Two sequence #’s (0,1) will suffice. Why? • Must check if received ACK/NAK is corrupted • Twice as many states • State must “remember” whether “current” packet has 0 or 1 sequence number

  26. rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Wait for 0 from below 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_seq0(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) Wait for 1 from below extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) RDT 2.1:Receiver Handles Garbled ACK/NAKs RDT 2.1 Receiver: 2 distinct states

  27. RDT 2.1 Receiver • Must check if received packet is duplicate • State indicates whether 0 or 1 is expected packet sequence number • NOTE: The receiver still cannot know if its last ACK/NAK was received OK at the sender

  28. RDT 2.2: A NAK-free Protocol • Same functionality as RDT 2.1 using ACKs only • Instead of NAK, receiver sends ACK for last packet received OK • Receiver must now explicitly include the sequence number of the packet being ACKed • A duplicate ACK at the sender is equivalent to a NAK: retransmit the current packet

  29. RDT 2.2: A NAK-free Protocol

  30. 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) Wait for call 0 from above Wait for ACK 0 rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) L receiver FSM fragment udt_send(sndpkt) Wait for 0 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) RDT 2.2: Sender/Receiver Error Handling Logic

  31. RDT 3.0: Channels with Errors and Packet Loss • New assumption: the underlying channel can also lose packets • Both data and ACKs • Checksums, sequence numbers, ACKs, and retransmissions will be of help, but not enough

  32. RDT 3.0: Channels with Errors and Packet Loss • The solution • Sender waits “reasonable” amount of time for ACK • Retransmits if no ACK received in this time • If the packet (or ACK) is delayed (not lost) • Retransmission will be duplicate, but use of sequence numbers already handles this • Therefore, receiver must specify sequence number of packet being ACKed

  33. RDT 3.0: Channels with Errors and Packet Loss • This solution requires a countdown timer • Start the timer each time a packet is sent • Respond to a timer interrupt and take appropriate action • Stop the timer

  34. 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) Wait for ACK0 Wait for ACK1 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) ) Wait for call 0from above Wait for call 1 from above sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer L RDT 3.0 Sender Logic

  35. RDT 3.0 in Action

  36. RDT 3.0 in Action

  37. RDT 3.0 Summary • We have now assembled the key elements of a reliable data transfer protocol • Checksums • Sequence numbers • Timers • Positive and negative acknowledgement packets

  38. sender receiver first packet bit transmitted, t = 0 first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R RDT 3.0:Stop-and-Wait Operation last packet bit transmitted, t = L / R

  39. RDT 3.0:Stop-and-Wait Operation • Stop-and-wait is very inefficient • Pages 214-215 • Utilization is low because there are long idle periods between transmission of data and the receipt of acknowledgements (ACKs) • Pipelining addresses this issue

  40. Pipelined Reliable Data Transfer Protocols • Send multiple in-transit packets without waiting for an ACK • Consequences • Range of sequence numbers must be increased • Multiple packets must be buffered on both sides

  41. Pipelined Reliable Data Transfer Protocols

  42. sender receiver 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! Pipelining:Increased Utilization first packet bit transmitted, t = 0

  43. Pipelined Reliable Data Transfer Protocols • Two basic approaches • Go-Back-N • Selective repeat

  44. Go-Back-N (GBN) • Sender is allowed to transmit multiple packets without waiting for an ACK • A.k.a. sliding window protocol • A window of up to “N” consecutive unACK’ed packets is allowed • In other words, N=window size • As the protocol operates, this window slides forward over the seq # space

  45. Sliding Window

  46. Sliding Window vs.Stop-and-Wait

  47. Go-Back-N (GBN):Sender Operation • Data from above • If window is full, data may be buffered • If not full, packet is created and sent • Receipt of ACK • Cumulative ACK acknowledging all packets (and sequence numbers) within the current window

  48. Go-Back-N (GBN):Sender Operation • A timeout event • As in stop-and-wait, a timer is used to recover from lost data or ACKs • If a timeout occurs, the sender resends all packets that have been previously sent but have not yet been acknowledged

  49. Go-Back-N (GBN):Receiver Operation • Receipt of a packet • If packet with sequence # n is received correctly and in-order, send an ACK for packet n • In all other cases • Discard the packet • Resend an ACK for the most recent packet that was received correctly and in-order

  50. GBN InAction

More Related