CSCD58 W INTER 2018 W EEK 2 -O VERVIEW C ONT D Brian Harrington - PowerPoint PPT Presentation

Store & Forward Delay & Loss Break Standards Architecture CSCD58 W INTER 2018 W EEK 2 -O VERVIEW C ONT ’ D Brian Harrington University of Toronto Scarborough January 16, 2018

Store & Forward Delay & Loss Break Standards Architecture S TORE & F ORWARD • Last week: Packet Switching • Break up data into packets • Each packet makes its own way to destination • Only worry about one “hop” at a time • Let’s look at what happens at each “hop” • Store and forward • Example: L bits over R bps channel, with H hops • H L R seconds • Question: Why do we need store & forward?

Store & Forward Delay & Loss Break Standards Architecture S TORE & F ORWARD • L = 7.5 Mbits R = 1.5 Mbps • 15 second delay for 3 hops, 50 seconds for 10 • Remember, that’s assuming no other delay (we’ll get to that later) • Would be 5 seconds with direct connection, • Can we do better? • Message Segmentation • Break item into 5000 smaller packets • Each packet 1500 bits • 1 msec / packet /link • 15 sec → 5.002 sec • Pipelining

Store & Forward Delay & Loss Break Standards Architecture D ELAY • processing: waiting for router to read packet and know where to send it next • negligible time • transmission: waiting for previous packets to be sent • store-and-forward delay L R • propagation: waiting for message to move along medium • Depends on distance • We’ll see later how this can be dealt with • queueing: waiting for the router to send other packets that got there before you • Depends on network traffic • Can be negligible, or orders of magnitude worse than the other factors

Store & Forward Delay & Loss Break Standards Architecture Q UEUEING D ELAY • R = bandwidth (b/sec) • L = packet size (b) • a = average packet arrival rate (packets/sec) La R = traffic intensity • •

Store & Forward Delay & Loss Break Standards Architecture P ACKET L OSS • Routers have finite capacity • Queue is full, don’t accept any new packets • Dropped packet • Remember: Best effort transmission • Have to re-send from the start • Assuming we even know how to find out what’s missing

Store & Forward Delay & Loss Break Standards Architecture W HY BOTHER ? • With all these problems, why bother with packet switching at all? • Let’s look at a scenario: • 1 Mb/s link, users take 100kb/s when active, active 10% of the time • Circuit switching: 10 users at a time • Packet Switching: n users, probability i active at any one time? (binomial distribution) • p ( i ) = ( n i )( a i ∗ ( 1 − a ) n − i ) • n = num users i = num active users at a given time a = percentage of time users are active • n = 35, i = 10, a = 0.1 • p ( 10 ) = 0 . 0013 • p ( i > 10 ) = 0 . 0004

Store & Forward Delay & Loss Break Standards Architecture B REAK

Store & Forward Delay & Loss Break Standards Architecture I NTERNET S TANDARDS • Open standards are an essential part of the Internet • Why open? • Advantages/disadvantages? • Metcalfe’s Law: • Value of a network proportional to square of number of users • Benefits/Drawbacks of open standards: • Users: • Avoid vendor lock in • Sluggish adaptation of technologies? • Developers • Standard API • May be harder to push through “cool” new technologies • Manufacturers • Large market • No vendor lock in

Store & Forward Delay & Loss Break Standards Architecture IETF • So who keeps track of all of these open standards? • IETF: Internet Engineering Task Force • Open membership (meritocracy) • ~2000-3000 “core” members • Most work done via mailing lists ( www.ietf.org ) • Working groups for new technologies • Emphasis on interoperability and deployment: “working code is the ultimate arbiter” • RFCs (Request For Comments): Standards documents

Store & Forward Delay & Loss Break Standards Architecture T HE I NTERNET VS S OFTWARE E NGINEERING • Internet is a SE nightmare • Predates a lot of SE methodologies • Reliability: • No guarantees that messages will make it through • This is a design decision • Efficiency: • How do we know the best path? • Queueing issues • Fairness: • See recent Net Neutrality debate • Control: • Billions of users/nodes communicating/working with no central control • Try to arrange dinner with ~10 friends this way

Store & Forward Delay & Loss Break Standards Architecture T HE I NTERNET VS S OFTWARE E NGINEERING • Robustness: • Taking down any part of the network shouldn’t bring down the whole thing • Autonomous self healing • Scalability: • Most of the design was done when there were a few dozen hosts • Systems have vastly different speeds/bandwidths/traffic volume • Security: • Early protocols just never thought about this • People suck! • Media Networking: • Internet was designed for (mostly) asynchronous transfer • But how will the world see my livestream of me reacting to videos of cats watching my previous livestreams (where I was mostly watching videos of other cats)?

Store & Forward Delay & Loss Break Standards Architecture T HE I NTERNET VS S OFTWARE E NGINEERING • The Internet is a SE nightmare! • But somehow it still works • And we’re going to find out how.