Principles - Computer Networks - Lecture Slides, Slides of Computer Networks

Download Principles - Computer Networks - Lecture Slides and more Slides Computer Networks in PDF only on Docsity!

3: Transport Layer 3a-

8: Principles of Reliable Data

Transfer

3: Transport Layer 3a-

Roadmap

 UDP is a very thin layer over IP

 multiplexing /demultiplexing

 error detection

 TCP does these things also and then adds

some other significant features

 TCP is quite a bit more complicated and

subtle

 We are not going to jump right into TCP

 Start gently thinking about principles of

reliable message transfer in general

3: Transport Layer 3a-

Intuition: Faxing a document

With Flaky Machine

 Can’t talk to person on the other side any other way

 Number the pages – so sender can put back together

 Let receiver send you a fax back saying what pages they have and what they still need (include your fax number on the document!)

 What if the receiver sends their responses with a flaky fax machine too?

 What if it is a really big document? No point in overwhelming the receiver. Receiver might like to be able to tell you send first 10 pages then 10 more…

 How does receiver know when they have it all? Special last page? Cover sheet that said how many to expect?

3: Transport Layer 3a-

Principles of Reliable data transfer

 Solving this problem is one on top-10 list of most

important networking topics!

 important in application, transport, link layers

 Characteristics of unreliable channel will determine

complexity of reliable data transfer protocol– what

is worst underlying channel can do?

 Drop packets/pages?

 Corrupt packet/pages (even special ones like the

cover sheet or the receiver’s answer?)

 Reorder packets/pages?

3: Transport Layer 3a-

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

state 1

state 2

event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event

event actions

3: Transport Layer 3a-

Rdt1.0: reliable transfer over a reliable channel

 underlying channel perfectly reliable (so this should

be easy )

 no bit errors  no loss of packets

 separate FSMs for sender, receiver:

 sender sends data into underlying channel  receiver read data from underlying channel

3: Transport Layer 3a-

Rdt2.0: channel with bit errors

 underlying channel may flip bits in packet (can’t drop or reorder packets)  recall: UDP checksum to detect bit errors

 Once can have problems, the receiver must give the sender

feedback (either that or the sender would just have to keep

sending copy after copy forever to be sure)

 After receiving a packet, the receiver could say one of two

things:

 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  human scenarios using ACKs, NAKs?

3: Transport Layer 3a-

Rdt2.0: channel with bit errors

 new mechanisms in rdt2.0 (beyond rdt1.0 ):

 receiver feedback: control msgs (ACK,NAK) rcvr->sender (let receiver fax you back info?)  Possible retransmission – detection of duplicates (number fax pages?)  error detection (checksums? Cover sheet summary?)

3: Transport Layer 3a-

rdt2.0: in action (no errors)

sender FSM receiver FSM

3: Transport Layer 3a-

rdt2.0: in action (error scenario)

sender FSM receiver FSM

3: Transport Layer 3a-

rdt2.1: sender, handles garbled ACK/NAKs

New:

compute_chksum

corrupt()

3: Transport Layer 3a-

rdt2.1: receiver, handles garbled ACK/NAKs

If not corrupt, always

send ACK, but only

Deliver_data first time

3: Transport Layer 3a-

rdt2.2: a NAK-free protocol

 Less intuitive but getting us closer to TCP

 same functionality as rdt2.1, using NAKs only

 instead of NAK, receiver sends ACK for last pkt received OK (or for other number on the first receive)  receiver mustexplicitly include seq # of pkt being ACKed

 duplicate (or unexpected) ACK at sender results in same

action as NAK: retransmit current pkt

 TCP really ACKS the next thing it wants

rdt2.2: sender, receiver fragments