1 / 19

Week 2 Lecture 2 – Network Layers Transport Layer – Example: TCP/UDP

Week 2 Lecture 2 – Network Layers Transport Layer – Example: TCP/UDP. application: supporting network applications FTP, SMTP, STTP transport: host-host data transfer TCP, UDP network: routing of datagrams from source to destination IP, routing protocols

kane-dale
Download Presentation

Week 2 Lecture 2 – Network Layers Transport Layer – Example: TCP/UDP

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. Week 2 Lecture 2 – Network LayersTransport Layer – Example: TCP/UDP

  2. application: supporting network applications FTP, SMTP, STTP transport: host-host data transfer TCP, UDP network: routing of datagrams from source to destination IP, routing protocols link: data transfer between neighboring network elements PPP, Ethernet physical: bits “on the wire” application transport network link physical Transport layer location

  3. TCP/UDP Analogy IP Layer (routing) Data link layer 5 brothers 5 Sisters City P.O. Mum City P.O. NY Post Office CA Post Office Dad -- Mum, please make sure our sisters receive our Christmas cards… (Application Layer) -- No problem, darling. (TCP) -- I’ll try my best, but … (UDP) -- Dad, please make sure our brothers receive our Christmas cards… (Application Layer) -- No problem, darling. (TCP) -- I’ll try my best, but … (UDP) Router

  4. 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 Likewise, in Internet … Router 1A Host B: Christmas Picture Host A: Christmas Picture Host 1 Router 1 Host 2 Router 2 B IP Add B socket # Identify a frame; Remove FH; do sth. based on FH; Remove IP header; Analyze IP header and do sth like figuring out best route; Install new IP header; Install new frame header; deliver it to next host (Route 2). Anyway, Host 1 and Route 1 do not look at TCP header and message (Picture); Only end hosts (Host A & B look at TCP header and do sth. So we say TCP is end-to-end protocol. Host 1 Add Identify a frame from stream; Remove Frame Header(FH); Analyze FH and do sth like error correction; It founds out that frame is not to itself, it will install new FH and deliver it to Router 1. F I T Pic 0101010101111000 … Note: each node finally needs to form new frame !

  5. TCP is core Internet protocol • TCP shows the real network tricks ! • Software-controlled • Lots of ideas • Lots of Algorithms • Lots of Protocols • Attract 30% networking research • Thousands of PhD students

  6. provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to network layer receive side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP 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 Transport services and protocols

  7. reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP services not available: 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 Internet transport-layer protocols

  8. “no frills,” “bare bones” Internet transport protocol “best effort” service, UDP segments may be: lost delivered out of order to app connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others (no pipe) Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired UDP: User Datagram Protocol : Unreliable Transport!

  9. TCP – Reliable Transfer

  10. 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 Needed in Project #2

  11. 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

  12. 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 actions taken on state transition state: when in this “state” next state uniquely determined by next event

  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

  14. underlying channel may flip bits in packet recall: UDP 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 -- 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 no loss)

  15. 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 snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from App udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) L sender rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

  16. 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) 1 rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L 3 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 2

  17. 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) 1 2 rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) 3 rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L 5 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 4

  18. New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions will be of help, but not enough Q:how to deal with loss? sender waits until certain data or ACK lost, then retransmits yuck: drawbacks? 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”

  19. Wait for ACK0 Wait for ACK1 Wait for call 1 from above Wait for call 0 from 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

More Related