Your SlideShare is downloading. ×
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
CNWeek4 lec2-bscs1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CNWeek4 lec2-bscs1

209

Published on

Computer Networks Sir Zawar

Computer Networks Sir Zawar

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
209
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Chapter 3 Transport Layer Computer Networking: A Top Down Approach, 4th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2007.
  • 2. Principles of Reliable Data Transfer • Important in application, transport, link layers • Top-10 list of important networking topics!
  • 3. Principles of Reliable Data Transfer (rdt) • Important in application, transport, link layers • Top-10 list of important networking topics!
  • 4. Principles of Reliable Data Transfer • Important in application, transport, link layers • Top-10 list of important networking topics!
  • 5. 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
  • 6. 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
  • 7. 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 reads 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
  • 8. 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 sender know – What has been received in error and requires repetition • Automatic Repeat reQuest (ARQ) protocols.
  • 9. 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
  • 10. 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)
  • 11. 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)
  • 12. 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)
  • 13. 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
  • 14. Rdt2.1: Sender, handles garbled ACK/NAKs rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) Wait for call 0 from above Wait for ACK or NAK 0 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Wait for ACK or NAK 1 Wait for call 1 from above rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)
  • 15. Rdt2.1: Receiver, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)
  • 16. Rdt2.2: a NAK-free protocol • Same functionality as rdt2.1, using ACKs only • Instead of NAK, receiver sends ACK for last packet received OK – Receiver must explicitly include seq # of the packet being ACKed • Duplicate ACK at sender results in same action as NAK: retransmit current packet
  • 17. Rdt2.2: Sender, Receiver Fragments rdt_send(data) sndpkt = make_pkt(0, data, checksum) rdt_rcv(rcvpkt) && udt_send(sndpkt) ( corrupt(rcvpkt) || Wait for Wait for isACK(rcvpkt,1) ) ACK call 0 from above 0 Sender FSM Fragment rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt) Wait for 0 from below udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) Receiver FSM Fragment rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK,1, chksum) udt_send(sndpkt)
  • 18. Rdt3.0: Channels with Errors and Loss New Assumption: Underlying channel can also lose packets (data or ACKs)  What to do when packet loss occurs?  Retransmissions  How to detect loss?  Sender waits “reasonable” amount of time for ACK  Must wait at least as long as RTT plus processing delay.  Retransmits if no ACK received in this time  If packet (or ACK) just delayed (not lost):  Retransmission will be duplicate, but use of sequence numbers can handles this.
  • 19. Rdt3.0: Channels with Errors and Loss Implement a Retransmission mechanism using a  count down timer  Interrupts the sender after certain amount of time The sender will need to be able to: Start the timer each time a packet is sent Respond to a timer interrupt Stop the timer
  • 20. 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 rdt_rcv(rcvpkt) Wait for call 0 from above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer stop_timer timeout udt_send(sndpkt) start_timer Wait for ACK 0 Wait for ACK1 Wait for call 1 from above rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer Rdt3.0 Receiver? rdt_rcv(rcvpkt)
  • 21. Pipelined Reliable Data Transfer Protocols  Rdt3.0 works, but performance is poor  Poor Performance is due to the fact that it is a stop and wait protocol  Poor utilization of the resource  Solution Sender is allowed to send multiple packets without waiting for ACKs.  Pipelining  Since many sender to receiver packets can be visualized as filling a pipeline Increase utilization
  • 22. Pipelined Reliable Data Transfer Protocols  Pipelining has the following consequences for reliable data transfer  Range of sequence numbers must be increased  Sender and receiver sides may have to buffer more than one packet.  Two basic approaches towards pipeline error recovery: Go-Back-N, Selective Repeat
  • 23. Go-Back-N (GBN) Sender:  Sender is allowed to transmit multiple packets without waiting for an acknowledgement  Constrained to a certain maximum number N.  Base or send_base  Sequence number of oldest unacknowledged packet  Nextseqnum  Sequence number of next packet to be sent  The range of sequence numbers for transmitted but not acknowledged packets can be viewed as a window of size N.  This window slides forward as the protocol operates
  • 24. Go-Back-N GBN sender must respond to three types of events  Invocation from above (rdt_send() is called):  If window is full, returns data to upper layer  Maintain synchronization mechanism  Receipt of an ACK:  ACK for packet with seq # n is taken as“Cumulative ACK”  More shortly in receiver  Time out event:  Sender has timer for oldest unacknowledged packet • If timer expires, retransmit all unacknowledged packets
  • 25. Go-Back-N Receiver:  If a packet with seq # n is received correctly and is in order  ACK is sent and data is delivered to upper layers  For all other cases  Receiver discards the packet and resends ACK for most recently received in order packet  Packets are delivered one at a time to upper layers  If a packet k has been received and delivered, then all packets with seq # lower than k have also been delivered.  Receiver discards out of order packets  No receiver buffering  Need only remember expectedseqnum
  • 26. GBN in action http://www.eecis.udel.edu/~amer/450/TransportApplets/GBN/GBNindex.html

×