DOC PREVIEW
Berkeley COMPSCI 162 - Lecture 15 Reliability, Transport Protocols

This preview shows page 1-2-3-4 out of 12 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Page 1 CS162!Operating Systems and!Systems Programming!Lecture 15!Reliability, Transport Protocols"March 16, 2011!Ion Stoica!http://inst.eecs.berkeley.edu/~cs162!Lec 15.2!3/16! Ion Stoica CS162 ©UCB Spring 2011!Goals for Today"• Finish e2e argument & fate sharing!• Transport: TCP/UDP!– Reliability!– Flow control!Lec 15.3!3/16! Ion Stoica CS162 ©UCB Spring 2011!Placing Network Functionality"• Hugely influential paper: “End-to-End Arguments in System Design” by Saltzer, Reed, and Clark (ʻ84)!• “Sacred Text” of the Internet!– Endless disputes about what it means!– Everyone cites it as supporting their position!Lec 15.4!3/16! Ion Stoica CS162 ©UCB Spring 2011!Basic Observation"• Some types of network functionality can only be correctly implemented end-to-end!– Reliability, security, etc!• Because of this, end hosts:!– Can satisfy the requirement without networkʼs help!– Will/must do so, since canʼt rely on networkʼs help!• Therefore donʼt go out of your way to implement them in the network!Page 2 Lec 15.5!3/16! Ion Stoica CS162 ©UCB Spring 2011!Example: Reliable File Transfer"• Solution 1: make each step reliable, and then concatenate them!• Solution 2: end-to-end check and try again if necessary!OS Appl. OS Appl. Host A Host B OK Lec 15.6!3/16! Ion Stoica CS162 ©UCB Spring 2011!Discussion"• Solution 1 is incomplete!– What happens if memory is corrupted?!– Receiver has to do the check anyway!!• Solution 2 is complete!– Full functionality can be entirely implemented at application layer with no need for reliability from lower layers!• Is there any need to implement reliability at lower layers?!– Well, it could be more efficient!Lec 15.7!3/16! Ion Stoica CS162 ©UCB Spring 2011!Summary of End-to-End Principle"Implementing this functionality in the network:!• Doesnʼt reduce host implementation complexity!• Does increase network complexity!• Probably imposes delay and overhead on all applications, even if they donʼt need functionality!• However, implementing in network can enhance performance in some cases!– E.g., very losy link!Lec 15.8!3/16! Ion Stoica CS162 ©UCB Spring 2011!Conservative Interpretation of E2E"• Donʼt implement a function at the lower levels of the system unless it can be completely implemented at this level!• Unless you can relieve the burden from hosts, donʼt bother!Page 3 Lec 15.9!3/16! Ion Stoica CS162 ©UCB Spring 2011!Moderate Interpretation"• Think twice before implementing functionality in the network!• If hosts can implement functionality correctly, implement it in a lower layer only as a performance enhancement!• But do so only if it does not impose burden on applications that do not require that functionality!Lec 15.10!3/16! Ion Stoica CS162 ©UCB Spring 2011!Related Notion of Fate-Sharing!• Idea: when storing state in a distributed system, keep it co-located with the entities that ultimately rely on the state!• Fate-sharing is a technique for dealing with failure!– Only way that failure can cause loss of the critical state is if the entity that cares about it also fails ...!– … in which case it doesnʼt matter!• Often argues for keeping network state at end hosts rather than inside routers!– In keeping with End-to-End principle!– E.g., packet-switching rather than circuit-switching!– E.g., NFS file handles, HTTP “cookies”!Lec 15.11!3/16! Ion Stoica CS162 ©UCB Spring 2011!Reliable Transfer"• Retransmit missing packets!– Numbering of packets and ACKs!• Do this efficiently!– Keep transmitting whenever possible!– Detect missing ACKs and retransmit quickly!• Two schemes!– Stop & Wait!– Sliding Window (Go-back-n and Selective Repeat)!Lec 15.12!3/16! Ion Stoica CS162 ©UCB Spring 2011!Stop & Wait "ACK DATA Time Sender Receiver RTT • Send; wait for ack!• If timeout, retransmit; else repeat!Inefficient if TRANS << RTT TRANSPage 4 Lec 15.13!3/16! Ion Stoica CS162 ©UCB Spring 2011!Sliding Window"• window = set of adjacent sequence numbers!• The size of the set is the window size!• Assume window size is n!• Let A be the last ackʼd packet of sender without gap; then window of sender = {A+1, A+2, …, A+n}%• Sender can send packets in its window%• Let B be the last received packet without gap by receiver, then window of receiver = {B+1,…, B+n}%• Receiver can accept out of sequence, if in window!Lec 15.14!3/16! Ion Stoica CS162 ©UCB Spring 2011!Go-Back-n (GBN)"• Transmit up to n unacknowledged packets!• If timeout for ACK(k), retransmit k, k+1, …!Lec 15.15!3/16! Ion Stoica CS162 ©UCB Spring 2011!GBN Example w/o Errors"Time!Window size = 3 packets!Sender! Receiver!1!{1}!2!{1, 2}!3!{1, 2, 3}!4!{2, 3, 4}!5!{3, 4, 5}!Sender Window!Receiver Window!{}!6!{4, 5, 6}!.!.!.!.!.!.!{}!{}!Lec 15.16!3/16! Ion Stoica CS162 ©UCB Spring 2011!GBN Example with Errors"Window size = 3 packets!Sender! Receiver!1!2!3!4!5!{}!{}!{}!6!{5}!{5,6}!4 is !missing!Timeout!Packet 4!4!5!6!{}!Page 5 Lec 15.17!3/16! Ion Stoica CS162 ©UCB Spring 2011!Selective Repeat (SR)"• Sender: transmit up to n unacknowledged packets; assume packet k is lost!• Receiver: indicate packet k is missing!• Sender: retransmit packet k !Lec 15.18!3/16! Ion Stoica CS162 ©UCB Spring 2011!SR Example with Errors"Time"Sender" Receiver"1"2"3"4"5"6"4"7"Nack = 4"Window size = 3 packets"{1}"{1, 2}"{1, 2, 3}"{2, 3, 4}"{3, 4, 5}"{4, 5, 6}"{4,5,6}"{7}"Lec 15.19!3/16! Ion Stoica CS162 ©UCB Spring 2011!Observations"• With sliding windows, it is possible to fully utilize a link, provided the window size is large enough. Throughput is ~ (n/RTT)!– Stop & Wait is like n = 1.!• Sender has to buffer all unacknowledged packets, because they may require retransmission!• Receiver may be able to accept out-of-order packets, but only up to its buffer limits!Lec 15.20!3/16! Ion Stoica CS162 ©UCB Spring 2011!Motivation for Transport Protocols"• IP provides a weak, but efficient service model (best-effort)!– Packets can be delayed, dropped, reordered, duplicated!– Packets have limited size (why?)!• IP packets are addressed to a host!– How to decide which application gets which packets?!• How should hosts send packets into the network?!– Too fast


View Full Document

Berkeley COMPSCI 162 - Lecture 15 Reliability, Transport Protocols

Documents in this Course
Lecture 1

Lecture 1

12 pages

Nachos

Nachos

41 pages

Security

Security

39 pages

Load more
Download Lecture 15 Reliability, Transport Protocols
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 15 Reliability, Transport Protocols and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 15 Reliability, Transport Protocols 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?