Cloud Computing

Professor Mangal Sain

 Lecture 3

Distributed Networking
 Lecture 3– Part 1

What’s the Internet?

WHAT’S THE INTERNET: “NUTS AND BOLTS” VIEW
 millions of connected
router
computing devices: hosts workstation
= end systems server
mobile
 running network apps local ISP
 communication links
 fiber, copper, radio, satellite
 transmission rate = regional ISP
bandwidth
 routers: forward packets
(chunks of data)

company
network
WHAT’S THE INTERNET: “NUTS AND BOLTS” VIEW
 protocols control sending,
router
receiving of msgs workstation
 e.g., TCP, IP, HTTP, FTP, PPP server
mobile
 Internet: “network of networks” local ISP
 loosely hierarchical
 public Internet versus private
intranet regional ISP
 Internet standards
 RFC: Request for comments
 IETF: Internet Engineering Task
Force

company
network
WHAT’S THE INTERNET: A SERVICE VIEW
 communication infrastructure
enables distributed applications:
 Web, email, games, e-commerce, file
sharing
 communication services provided
to apps:
 Connectionless unreliable
 connection-oriented reliable
WHAT’S A PROTOCOL?

human protocols: network protocols:

 “what’s the time?”  machines rather than

 “I have a question” humans

 introductions  all communication
activity in Internet
governed by protocols
… specific msgs sent
… specific actions taken protocols define format, ord
when msgs received, er of msgs sent and recei
or other events ved among network entitie
s, and actions taken on ms
g transmission, receipt
WHAT’S A PROTOCOL?
a human protocol and a computer network protocol:

Hi
TCP connection
req
Hi
TCP connection
Got the response
time? Get http://www.awl.com/kurose-ross
2:00
<file>
time

Q: Other human protocols?

A CLOSER LOOK AT NETWORK STRUCTURE:

 network edge: applications

and hosts
 network core:
 routers
 network of networks
 access
networks, physical
media: communication links
THE NETWORK EDGE:

 end systems (hosts):

 run application programs
 e.g. Web, email
 at “edge of network”
 client/server model
 client host requests, receives service
from always-on server
 e.g. Web browser/server; email
client/server
 peer-peer model:
 minimal (or no) use of dedicated
servers
 e.g. Gnutella, KaZaA
NETWORK EDGE: CONNECTION-ORIENTED SERVICE
Goal: data transfer between end TCP service [RFC 793]
systems  reliable, in-order byte-
 handshaking: setup (prepare stream data transfer
for) data transfer ahead of  loss: acknowledgements and
time retransmissions
 Hello, hello back human protocol  flow control:
 set up “state” in two  sender won’t overwhelm
communicating hosts receiver
 TCP - Transmission Control  congestion control:
Protocol  senders “slow down sending
 Internet’s connection-oriented rate” when network
service congested
NETWORK EDGE: CONNECTIONLESS SERVICE

Goal: data transfer between App’s using TCP:

end systems  HTTP (Web), FTP (file
 same as before! transfer), Telnet (remote
 UDP - User Datagram login), SMTP (email)
Protocol [RFC 768]:
 connectionless App’s using UDP:
 unreliable data transfer
 streaming media,
 no flow control
teleconferencing, DNS,
 no congestion control
Internet telephony
THE NETWORK CORE

 mesh of interconnected
routers
 the fundamental question:
how is data transferred
through net?
 circuit switching:
dedicated circuit per call:
telephone net
 packet-switching: data
sent thru net in discrete
“chunks”
NETWORK CORE: CIRCUIT SWITCHING
End-end resources reserved for
“call”
 link bandwidth, switch
capacity
 dedicated resources: no
sharing
 circuit-like (guaranteed)
performance
 call setup required
NETWORK CORE: CIRCUIT SWITCHING

network resources (e.g.,

bandwidth) divided into “pieces”  dividing link bandwidth into
“pieces”
 pieces allocated to calls
 frequency division
 resource piece idle if not used by
 time division
owning call (no sharing)
CIRCUIT SWITCHING: FDM AND TDM
Example:
FDM
4 users

frequency

time

TDM

frequency

time
NUMERICAL EXAMPLE
 How long does it take to send a file of 640,000 bits from host A to
host B over a circuit-switched network?
 All links are 1.536 Mbps
 Each link uses TDM with 24 slots
 500 msec to establish end-to-end circuit

Work it out!
NETWORK CORE: PACKET SWITCHING
resource contention:
each end-end data stream
 aggregate resource demand
divided into packets
can exceed amount available
 user A, B packets share
 congestion: packets queue,
network resources
wait for link use
 each packet uses full link
 store and forward: packets
bandwidth
move one hop at a time
 resources used as needed
 Node receives complete packet
before forwarding

Bandwidth division into “pieces”

Dedicated allocation
Resource reservation
PACKET SWITCHING: STATISTICAL MULTIPLEXING
10 Mb/s
C
A Ethernet statistical multiplexing

1.5 Mb/s
B
queue of packets
waiting for output
link

D E

Sequence of A & B packets does not have fixed

pattern  statistical multiplexing.
In TDM each host gets same slot in revolving TDM
frame.
PACKET SWITCHING VERSUS CIRCUIT SWITCHING
Packet switching allows more users to use network!

 1 Mb/s link
 each user:
 100 kb/s when “active”
 active 10% of time
N users
 circuit-switching: 1 Mbps link
 10 users
 packet switching:
 with 35 users,
probability > 10 active
less than .0004
PACKET SWITCHING VERSUS CIRCUIT SWITCHING
Is packet switching a “slam dunk winner?”

 Great for bursty data

 resource sharing
 simpler, no call setup

 Excessive congestion: packet delay and loss

 protocols needed for reliable data transfer, congestion
control
 Q: How to provide circuit-like behavior?
 bandwidth guarantees needed for audio/video apps
 still an unsolved problem
PACKET-SWITCHING: STORE-AND-FORWARD

L
R R R

 Takes L/R seconds to Example:

transmit (push out)  L = 7.5 Mbits
packet of L bits on to  R = 1.5 Mbps
link or R bps
 delay = 15 sec
 Entire packet must
arrive at router before it
can be transmitted on
next link: store and
forward
 delay = 3L/R
PACKET-SWITCHED NETWORKS: FORWARDING
 Goal: move packets through routers from source to
destination
 we’ll study several path selection (i.e. routing) algorithms
 datagram network:
 destination address in packet determines next hop
 routes may change during session
 analogy: driving, asking directions
 virtual circuit network:
 each packet carries tag (virtual circuit ID), tag determines
next hop
 fixed path determined at call setup time, remains fixed thru
call
 routers maintain per-call state
Lecture 3 – Part 2

Protocol Layers
PROTOCOL “LAYERS”

Networks are complex!

Question:
 many “pieces”:
Is there any hope of
 hosts organizing structure of
 routers network?
 links of various media
 applications Or at least our discussion
 protocols of networks?
 hardware, software
ORGANIZATION OF AIR TRAVEL

ticket (purchase) ticket (complain)

baggage (check) baggage (claim)

gates (load) gates (unload)

runway takeoff runway landing

airplane routing airplane routing

airplane routing

 a series of steps
 LAYERING OF AIRLINE FUNCTIONALITY

ticket (purchase) ticket (complain) ticket

baggage (check) baggage (claim baggage

gates (load) gates (unload) gate

runway (takeoff) runway (land) takeoff/landing

airplane routing airplane routing airplane routing airplane routing airplane routing

departure intermediate air-traffic arrival

airport control centers airport

Layers: each layer implements a service

 via its own internal-layer actions
 relying on services provided by layer below
WHY LAYERING?
Dealing with complex systems:
 explicit structure allows identification, relationship
of complex system’s pieces
 layered reference model for discussion
 modularization eases maintenance, updating of
system
 change of implementation of layer’s service transparent
to rest of system
 e.g., change in gate procedure doesn’t affect rest of
system
 layering considered harmful?
INTERNET PROTOCOL STACK

 application: supporting network

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

physical
 source
message
segment Ht
M application ENCAPSULATION
M transport
datagram Hn Ht M network
frame Hl Hn Ht M link
physical
Hl Hn Ht M link Hl Hn Ht M
physical

switch

destination Hn Ht M network Hn Ht M
M application Hl Hn Ht M link Hl Hn Ht M
Ht M transport physical
Hn Ht M network
Hl Hn Ht M link router
physical
APPLICATION ARCHITECTURES
 Client-server
 Peer-to-peer (P2P)

 Hybrid of client-server and P2P

CLIENT-SERVER ARCHITECTURE

server:
 always-on host
 permanent IP address
 server farms for scaling
clients:
 communicate with server
 may be intermittently
client/server connected
 may have dynamic IP
addresses
 do not communicate directly
with each other
PURE P2P ARCHITECTURE

 no always-on server
 arbitrary end systems
directly communicate peer-peer
 peers are intermittently
connected and change IP
addresses
 example: Gnutella

Highly scalable but

difficult to manage
HYBRID OF CLIENT-SERVER AND P2P
Skype
 voice-over-IP P2P application
 centralized server: finding address of remote party:
 client-client connection: direct (not through server)
Instant messaging
 chatting between two users is P2P
 centralized service: client presence detection/location
 user registers its IP address with central
server when it comes online
 user contacts central server to find IP
addresses of buddies
PROCESSES COMMUNICATING

Process: program running Client process: process

within a host. that initiates
 within same host, two communication
processes communicate Server process: process
using inter-process that waits to be
communication (defined contacted
by OS).
 processes in different
hosts communicate by  Note: applications with
exchanging messages P2P architectures have
client processes &
server processes
SOCKETS
host or host or
 process sends/receives server server
messages to/from its
socket controlled by
app developer
 socket analogous to door
process process

 sending process shoves socket socket

message out door TCP with TCP with

buffers, Internet buffers,
 sending process relies on variables variables
transport infrastructure on
other side of door which
controlled
brings message to socket at by OS
receiving proc.

 API: (1) choice of transport protocol; (2) ability to fix

a few parameters (lots more on this later)
ADDRESSING PROCESSES
 to receive messages, process must
have identifier
 host device has unique 32-bit IP
address
 Q: does IP address of host on which
process runs suffice for identifying
the process?
 ADDRESSING PROCESSES

 to receive messages, process must  identifier includes both IP address

have identifier and port numbers associated with
 host device has unique 32-bit IP process on host.
address  Example port numbers:

 Q: does IP address of host on  HTTP server: 80

which process runs suffice for  Mail server: 25
identifying the process?  to send HTTP message to
 A: No, many processes can be gaia.cs.umass.edu web server:
running on same host  IP address: 128.119.245.12
 Port number: 80
 more shortly…
APP-LAYER PROTOCOL DEFINES

 Types of messages
exchanged, Public-domain protocols:
 e.g., request, response  defined in RFCs
 Message syntax:  allows for
 what fields in messages & interoperability
how fields are delineated
 e.g., HTTP, SMTP
 Message semantics
Proprietary protocols:
 meaning of information in
fields  e.g., Skype

 Rules for when and how

processes send &
respond to messages
WHAT TRANSPORT SERVICE DOES AN APP NEED?
Data loss
Bandwidth
 some apps (e.g., audio) can
tolerate some loss  some apps (e.g.,
multimedia) require
 other apps (e.g., file
transfer, telnet) require minimum amount of
100% reliable data transfer bandwidth to be
“effective”
Timing  other apps (“elastic
 some apps (e.g., apps”) make use of
Internet telephony, whatever bandwidth
interactive games) they get
require low delay to be
“effective”
TRANSPORT SERVICE REQUIREMENTS OF COMMON APPS

Application Data loss Bandwidth Time Sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
instant messaging no loss elastic yes and no
INTERNET TRANSPORT PROTOCOLS SERVICES
TCP service: UDP service:
 connection-oriented: setup  unreliable data transfer
required between client and between sending and
server processes
receiving process
 reliable transport between
sending and receiving process  does not provide:
connection setup,
 flow control: sender won’t
reliability, flow control,
overwhelm receiver
congestion control, timing,
 congestion control: throttle
or bandwidth guarantee
sender when network
overloaded
 does not provide: timing, Q: why bother? Why is there
minimum bandwidth a UDP?
guarantees
INTERNET APPS: APPLICATION, TRANSPORT PROTOCOLS

Application Underlying
Application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia proprietary TCP or UDP
(e.g. RealNetworks)
Internet telephony proprietary
(e.g., Vonage,Dialpad) typically UDP
 Lecture 3 – Part 3

The Web and HTTP

WEB AND HTTP
First some jargon
 Web page consists of objects

 Object can be HTML file, JPEG image, Java applet, audio file,…

 Web page consists of base HTML-file which includes several

referenced objects
 Each object is addressable by a URL

 Example URL:

www.someschool.edu/someDept/pic.gif

host name path name

HTTP OVERVIEW
HTTP: hypertext transfer
protocol
 Web’s application layer protocol PC running
 client/server model Explorer

 client: browser that requests,

receives, “displays” Web objects
 server: Web server sends objects Server
in response to requests running
Apache Web
 HTTP 1.0: RFC 1945 server
 HTTP 1.1: RFC 2068
Mac running
Safari
HTTP OVERVIEW (CONTINUED)

Uses TCP: HTTP is “stateless”

 client initiates TCP  server maintains no
connection (creates socket) to information about past
server, port 80 client requests
server accepts TCP
aside

connection from client Protocols that maintain “state
 HTTP messages (application- ” are complex!
layer protocol messages)  past history (state) must b
exchanged between browser e maintained
(HTTP client) and Web  if server/client crashes, t
server (HTTP server) heir views of “state” may b
 TCP connection closed e inconsistent, must be rec
onciled
HTTP CONNECTIONS
Nonpersistent HTTP Persistent HTTP
 At most one object is sent over  Multiple objects can be sent
a TCP connection. over single TCP connection
 HTTP/1.0 uses nonpersistent between client and server.
HTTP  HTTP/1.1 uses persistent
connections in default mode
NONPERSISTENT HTTP
Suppose user enters URL www.someSchool.edu/someDepartment/home.index (contains text,
references to 10
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server
1b. HTTP server at host www.so
(process) at
meSchool.edu waiting for TCP
www.someSchool.edu on port 80
connection at port 80. “accep
ts” connection, notifying client

2. HTTP client sends HTTP requ

est message (containing URL) i
nto TCP connection socket. Me 3. HTTP server receives request
ssage indicates that client wan message, forms response mess
ts object someDepartment/ho age containing requested obje
me.index ct, and sends message into its
socket

time
NONPERSISTENT HTTP (CONT.)

4. HTTP server closes TCP conne

ction.
5. HTTP client receives response
message containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
objects
time 6. Steps 1-5 repeated for each o
f 10 jpeg objects
NON-PERSISTENT HTTP: RESPONSE TIME

Definition of RTT: time to

send a small packet to
travel from client to server
and back. initiate TCP
connection
Response time:
RTT
 one RTT to initiate TCP
request
connection file
time to
 one RTT for HTTP request RTT
transmit
and first few bytes of HTTP file
file
response to return received
 file transmission time

total = 2RTT+transmit time time time

PERSISTENT HTTP

Nonpersistent HTTP issues: Persistent without pipelining:

 requires 2 RTTs per object  client issues new request

 OS overhead for each TCP

only when previous
connection response has been received
 one RTT for each referenced
 browsers often open parallel
TCP connections to fetch object
referenced objects Persistent with pipelining:
Persistent HTTP  default in HTTP/1.1

 server leaves connection  client sends requests as

open after sending response soon as it encounters a
 subsequent HTTP messages
referenced object
between same client/server  as little as one RTT for all
sent over open connection the referenced objects
HTTP REQUEST MESSAGE

 two types of HTTP messages: request, response

 HTTP request message:
 ASCII (human-readable format)

request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr

Carriage return,
line feed (extra carriage return, line feed)
indicates end
of message
HTTP REQUEST MESSAGE: GENERAL FORMAT
UPLOADING FORM INPUT
Post method:
 Web page often includes form
input URL method:
 Input is uploaded to server in  Uses GET method
entity body  Input is uploaded in
URL field of request
line:

www.somesite.com/animalsearch?monkeys&banana
METHOD TYPES

HTTP/1.0 HTTP/1.1
 GET  GET, POST, HEAD

 POST  PUT

 HEAD  uploads file in entity body to path

specified in URL field
 asks server to leave requested
object out of response  DELETE
 deletes file specified in the URL
field
HTTP RESPONSE MESSAGE

status line
(protocol
status code HTTP/1.1 200 OK
status phrase) Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
header
Last-Modified: Mon, 22 Jun 1998 …...
lines
Content-Length: 6821
Content-Type: text/html

data, e.g., data data data data data ...

requested
HTML file
HTTP RESPONSE STATUS CODES
In first line in server->client response message.
A few sample codes:

200 OK
 request succeeded, requested object later in this message
301 Moved Permanently
 requested object moved, new location specified later in this
message (Location:)
400 Bad Request
 request message not understood by server
404 Not Found
 requested document not found on this server
505 HTTP Version Not Supported
USER-SERVER STATE: COOKIES
Example:
Many major Web sites use cookies  Susan always access Internet
Four components: always from PC
1) cookie header line of HTTP  visits specific e-commerce site
response message for first time
2) cookie header line in HTTP
 when initial HTTP requests
request message
arrives at site, site creates:
3) cookie file kept on user’s host,
 unique ID
managed by user’s browser
 entry in backend database for
4) back-end database at Web
ID
site
 COOKIES: KEEPING “STATE” (CONT.)
client server
ebay 8734
usual http request msg
Amazon server
cookie file usual http response creates ID
Set-cookie: 1678 1678 for user create
ebay 8734 entry
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
one week later: usual http response msg action backend
database
access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
spectific
usual http response msg action
COOKIES (CONTINUED)
aside
What cookies can bring: Cookies and privacy:
 cookies permit sites to
 authorization
learn a lot about you
 shopping carts
 you may supply name
 recommendations and e-mail to sites
 user session state (Web
e-mail)
How to keep “state”:
 protocol endpoints: maintain state
at sender/receiver over multiple
transactions
 cookies: http messages carry state
WEB CACHES (PROXY SERVER)
Goal: satisfy client request without involving origin server

 user sets browser: Web origin

server
accesses via cache
 browser sends all Proxy
HTTP requests to server
cache client
 object in cache: cache
returns object
 else cache requests
object from origin server,
then returns object to
client client
origin
server
MORE ABOUT WEB CACHING
 cache acts as both client and Why Web caching?
server  reduce response time for client
 typically cache is installed by request
ISP (university, company,  reduce traffic on an
residential ISP) institution’s access link.
 Internet dense with caches:
enables “poor” content
providers to effectively deliver
content (but so does P2P file
sharing)
CACHING EXAMPLE
origin
Assumptions servers
 average object size = 100,000
bits public
Internet
 avg. request rate from
institution’s browsers to origin
servers = 15/sec
 delay from institutional router 1.5 Mbps
to any origin server and back access link
to router = 2 sec institutional
Consequences network
10 Mbps LAN
 utilization on LAN = 15%
 utilization on access link = 100%
 total delay = Internet delay +
institutional
access delay + LAN delay
cache
CACHING EXAMPLE (CONT)
origin
possible solution servers
 increase bandwidth of access public
link to, say, 10 Mbps Internet
consequence
 utilization on LAN = 15%
 utilization on access link = 15% 10 Mbps
access link
 Total delay = Internet delay +
access delay + LAN delay institutional
network
 often a costly upgrade 10 Mbps LAN

institutional
cache
CACHING EXAMPLE (CONT)
origin
possible solution: install servers
cache public
 suppose hit rate is 0.4 Internet
consequence
 40% requests will be satisfied
almost immediately
1.5 Mbps
 60% requests satisfied by access link
origin server
institutional
 utilization of access link network
reduced to 60%, resulting in 10 Mbps LAN
negligible delays (say 10
msec)
 total avg delay = Internet
delay + access delay + LAN institutional
delay = .6*(2.01) secs + cache
.4*milliseconds < 1.4 secs
 CONDITIONAL GET
 Goal: don’t send object if cache cache
server
has up-to-date cached version HTTP request msg
 cache: specify date of cached If-modified-since: <
object
date>
copy in HTTP request not
If-modified-since: <date>
HTTP response modified
 server: response contains no HTTP/1.0
object if cached copy is up-to- 304 Not Modified
date:
HTTP/1.0 304 Not Modified HTTP request msg
If-modified-since: <
date> object
modified
HTTP response
HTTP/1.0 200 OK
<data>