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 WINTER 2018

WEEK 2 -OVERVIEW CONT’D Brian Harrington

University of Toronto Scarborough

January 16, 2018

Store & Forward Delay & Loss Break Standards Architecture

STORE & FORWARD

• 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

STORE & FORWARD

• 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

DELAY

• 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
• ther factors

Store & Forward Delay & Loss Break Standards Architecture

QUEUEING DELAY

• 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

PACKET LOSS

• 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

WHY 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 )(ai ∗(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

BREAK

Store & Forward Delay & Loss Break Standards Architecture

INTERNET STANDARDS

• 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

THE INTERNET VS SOFTWARE ENGINEERING

• 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

THE INTERNET VS SOFTWARE ENGINEERING

• 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

THE INTERNET VS SOFTWARE ENGINEERING

• The Internet is a SE nightmare!
• But somehow it still works
• And we’re going to find out how.