Chapter 2

Application Layer

A note on the use of these ppt slides: Computer

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify, Networking: A
and delete slides (including this one) and slide content to suit your needs.
They obviously represent a lot of work on our part. In return for use, we only Top Down
ask the following:
 If you use these slides (e.g., in a class) that you mention their source Approach
(after all, we’d like people to use our book!)
 If you post any slides on a www site, that you note that they are adapted
6th edition
from (or perhaps identical to) our slides, and note our copyright of this Jim Kurose, Keith Ross
material. Addison-Wesley
Thanks and enjoy! JFK/KWR March 2012
All material copyright 1996-2012
J.F Kurose and K.W. Ross, All Rights Reserved

Application Layer 2-1

Chapter 2: outline
2.1 principles of network 2.6 P2P applications
applications 2.7 socket programming
2.2 Web and HTTP with UDP and TCP
2.3 FTP
2.4 electronic mail
 SMTP, POP3, IMAP
2.5 DNS

Application Layer 2-2

Chapter 2: application layer
our goals:  learn about protocols by
 conceptual, examining popular
implementation aspects application-level
of network application protocols
protocols  HTTP
 transport-layer  FTP
service models  SMTP / POP3 / IMAP
 client-server  DNS
paradigm  creating network
 peer-to-peer applications
paradigm  socket API

Application Layer 2-3

Some network apps
 e-mail  voice over IP (e.g., Skype)
 web  real-time video
 text messaging conferencing
 remote login  social networking
 P2P file sharing  search
 multi-user network games  …
 streaming stored video  …
(YouTube, Hulu, Netflix)

Application Layer 2-4

Creating a network app application
transport
network
data link

write programs that: physical

 run on (different) end systems

 communicate over network
 e.g., web server software
communicates with browser
software

no need to write software for application

network-core devices transport

network
application
data link
 network-core devices do not physical transport
network
run user applications data link
physical

 applications on end systems

allows for rapid app
development, propagation

Application Layer 2-5

Application architectures
possible structure of applications:
 client-server
 peer-to-peer (P2P)

Application Layer 2-6

 Client-server architecture
server:
 always-on host
 permanent IP address
 data centers for scaling

clients:
 communicate with server
client/server  may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate directly
with each other
Application Layer 2-7
P2P architecture
 no always-on server peer-peer
 arbitrary end systems
directly communicate
 peers request service from
other peers, provide service
in return to other peers
 self scalability – new
peers bring new service
capacity, as well as new
service demands
 peers are intermittently
connected and change IP
addresses
 complex management

Application Layer 2-8

Sockets
 process sends/receives messages to/from its socket
 socket analogous to door
 sending process shoves message out door
 sending process relies on transport infrastructure on other
side of door to deliver message to socket at receiving
process

application application
socket controlled by
process process app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

Application Layer 2-9

Addressing processes
 to receive messages, process  identifier includes both IP
must have identifier address and port numbers
 host device has unique 32- associated with process on
bit IP address host.
 Q: does IP address of host  example port numbers:
on which process runs  HTTP server: 80
suffice for identifying the  mail server: 25
process?  to send HTTP message to
 A: no, many processes [Link] web
can be running on same server:
host  IP address: [Link]
 port number: 80
 more shortly…

Application Layer 2-10

App-layer protocol defines
 types of messages open protocols:
exchanged,  defined in RFCs
 e.g., request, response  allows for interoperability
 message syntax:  e.g., HTTP, SMTP
 what fields in messages proprietary protocols:
& how fields are  e.g., Skype
delineated
 message semantics
 meaning of information
in fields
 rules for when and how
processes send & respond
to messages

Application Layer 2-11

What transport service does an app need?
data integrity throughput
 some apps (e.g., file transfer,  some apps (e.g.,
web transactions) require multimedia) require
100% reliable data transfer minimum amount of
 other apps (e.g., audio) can throughput to be “ effective
tolerate some loss ”
 other apps (“ elastic apps” )

timing make use of whatever

throughput they get
 some apps (e.g., Internet
telephony, interactive security
games) require low delay
 encryption, data integrity,
to be “ effective”
…

Application Layer 2-12

 Transport service requirements: common apps

application data loss throughput 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
text messaging no loss elastic yes and no

Application Layer 2-13

Internet transport protocols services

TCP service: UDP service:

 reliable transport between  unreliable data transfer
sending and receiving between sending and
process receiving process
 flow control: sender won’t  does not provide:
overwhelm receiver
reliability, flow control,
 congestion control: throttle congestion control,
sender when network
overloaded timing, throughput
 does not provide: timing, guarantee, security,
minimum throughput orconnection setup,
guarantee, security
 connection-oriented: setup Q: why bother? Why is
required between client and there a UDP?
server processes
Application Layer 2-14
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 HTTP (e.g., YouTube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) TCP or UDP

Application Layer 2-15

Chapter 2: outline
2.1 principles of network 2.6 P2P applications
applications 2.7 socket programming
 app architectures with UDP and TCP
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3, IMAP
2.5 DNS

Application Layer 2-16

Web and HTTP
First, a review…
 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, e.g.,
[Link]/someDept/[Link]

host name path name

Application Layer 2-17

HTTP overview
HTTP: hypertext transfer
protocol HT
 Web’s application layer TP
req
ues
protocol PC running HT t
Firefox browser TPr
 client/server model esp
ons
 client: browser that e
requests, receives, t
(using HTTP protocol) u es
req server
and “ displays” Web T P n se
HT s po running
objects TP
re Apache Web
T
 server: Web server H server
sends (using HTTP
protocol) objects in iphone running
response to requests Safari browser

Application Layer 2-18

HTTP overview (continued)
uses TCP: HTTP is “stateless”
 client initiates TCP  server maintains no
connection (creates socket) information about
to server, port 80 past client requests
 server accepts TCP
connection from client aside
protocols that maintain
 HTTP messages “ state” are complex!
(application-layer protocol  past history (state) must be
messages) exchanged maintained
between browser (HTTP  if server/client crashes, their
client) and Web server views of “ state” may be
(HTTP server) inconsistent, must be
 TCP connection closed reconciled

Application Layer 2-19

HTTP connections
non-persistent HTTP persistent HTTP
 at most one object sent  multiple objects can
over TCP connection be sent over single
 connection then TCP connection
closed between client, server
 downloading multiple
objects required
multiple connections

Application Layer 2-20

 Non-persistent HTTP
suppose user enters URL: (contains text,
[Link]/someDepartment/[Link] references to 10
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server
(process) at 1b. HTTP server at host
[Link] on port 80 [Link] waiting
for TCP connection at port 80.
“ accepts” connection, notifying
2. HTTP client sends HTTP request message client
(containing URL) into TCP connection
socket. Message indicates that client wants
object someDepartment/[Link] 3. HTTP server receives request
message, forms response
message containing requested
object, and sends message into
its socket
time
Application Layer 2-21
 Non-persistent HTTP (cont.)
4. HTTP server closes TCP
connection.
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 of 10
jpeg objects

Application Layer 2-22

Non-persistent HTTP: response time
RTT (definition): time for a
small packet to travel from
client to server and back
HTTP response time: initiate TCP
 one RTT to initiate TCP connection
connection RTT
 one RTT for HTTP request request
file
and first few bytes of HTTP time to
response to return RTT transmit
file
 file transmission time
file
 non-persistent HTTP received
response time =
2RTT+ file transmission time time
time

Application Layer 2-23

Persistent HTTP

non-persistent HTTP persistent HTTP:

issues:  server leaves connection
 requires 2 RTTs per object open after sending
 OS overhead for each TCP response
connection  subsequent HTTP
 browsers often open messages between same
parallel TCP connections to client/server sent over
fetch referenced objects open connection
 client sends requests as
soon as it encounters a
referenced object
 as little as one RTT for all
the referenced objects

Application Layer 2-24

 HTTP request message
 two types of HTTP messages: request, response
 HTTP request message:
 ASCII (human-readable format)
carriage return character
line-feed character
request line
(GET, POST, GET /[Link] HTTP/1.1\r\n
HEAD commands) Host: [Link]\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
headerAccept-Language: en-us,en;q=0.5\r\n
linesAccept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
carriage return, Keep-Alive: 115\r\n
line feed at start Connection: keep-alive\r\n
\r\n
of line indicates
end of header lines
Application Layer 2-25
Uploading form input
POST method:
 web page often includes
form input
 input is uploaded to server
in entity body

URL method:
 uses GET method
 input is uploaded in URL
field of request line:
[Link]/animalsearch?monkeys&banana

Application Layer 2-26

 HTTP 1.x Key Characteristics:
1. Text-Based: HTTP 1.x is text-based, with both requests and responses
being human-readable. This simplicity made it easy for developers to
debug, but it also resulted in larger message sizes and higher
bandwidth consumption.
2. Stateless: Each HTTP request-response cycle is independent, and the
server doesn't maintain any knowledge of previous interactions. This
statelessness simplifies server design but can lead to inefficiencies
when multiple requests are needed to load a web page.
3. Blocking: HTTP 1.x is blocking in nature, meaning that the client
must wait for a response to a request before making the next request,
even if there are other resources it could be fetching concurrently. This
blocking behavior can cause latency and slower page loading times.
4. Connection Overhead: A new TCP connection is typically
established for each request-response cycle. This results in connection
overhead and can slow down web page loading, especially when many
resources need to be fetched.

Application Layer 2-27

HOL Problem in HTTP 1.x:
HTTP 1.x, the first generation of the HTTP protocol, uses a simple and
straightforward request-response model, where each client request is processed
sequentially. While this model is easy to understand, it leads to the Head-of-Line
(HOL) problem.
1. Serial Processing: In HTTP 1.x, the client sends a request for a resource, and the
server processes it one at a time. The server can't start processing another request
until it has completed the current one. This sequential processing of requests and
responses creates a bottleneck.
2. Blocked Resources: If a web page includes multiple resources (e.g., HTML, CSS,
JavaScript, images, and more), and any of these resources takes a while to load, it
blocks subsequent resources from being requested and loaded. For example, if an
image resource is slow to load, it can delay the loading of critical resources like CSS or
JavaScript files.
3. Impact on Page Load Time: The HOL problem directly impacts the page load time.
Since resources are loaded serially, the total time to load a web page can be
significantly longer, especially if there are latency issues or slow-loading resources.
Users may experience slower page rendering and interactivity.
4. Latency Issues: High network latency further exacerbates the HOL problem. For each
resource request, there's a delay due to the round-trip time between the client and
server. This latency adds up when multiple resources need to be fetched.

Application Layer 2-28

HOL Problem in HTTP 1.x:
Example: Imagine a scenario where a web page consists of several resources:
• HTML document
• CSS stylesheet
• JavaScript files
• Multiple images
In an HTTP 1.x scenario, if the HTML document is slow to load due to a large size or
network latency, the subsequent resources, such as CSS, JavaScript, and images, will be
delayed. The browser has to wait for the HTML document to finish loading before it can
parse it and discover other resources that need to be fetched. This results in a situation
where even fast-loading resources are held back by slower resources.
This delay has a cascading effect, leading to slower web page rendering and reduced user
experience. The HOL problem makes it difficult to fully utilize available network
bandwidth and parallelize resource retrieval effectively.
HTTP/2.0, with its multiplexing and concurrent processing capabilities, addresses the
HOL problem by allowing multiple resources to be requested and delivered in parallel
over a single connection, significantly improving web page loading times and user
experience.

Application Layer 2-29

 HTTP /2.0 Key Features:
1. Binary Framing: HTTP/2.0 uses a binary protocol for its messages. Data is divided
into smaller frames, which are more efficiently processed by both the client and server.
Binary framing allows for better multiplexing and prioritization of requests and
responses.
2. Multiplexing: Multiplexing is one of the most significant improvements in HTTP/2.0.
It allows multiple requests and responses to be sent concurrently over a single
connection. This reduces latency, as clients no longer have to wait for one resource to
download before requesting another.
3. Header Compression: HTTP/2.0 uses header compression techniques to reduce
redundancy in header data. This reduces the overhead of sending headers with each
request and response, making data transfer more efficient.
4. Server Push: With HTTP/2.0, servers can proactively push resources to the client.
For
example, if a web page requires multiple resources, the server can push some of these
resources to the client before the client requests them. This feature improves the
efficiency of loading complex web pages.

Application Layer 2-30

 HTTP /2.0 Key Features:
Binary Frame Structure: Binary frames in HTTP/2.0 are the fundamental units used to
structure and transmit data efficiently over the network. These frames are essential for
multiplexing, flow control, and prioritization. Let's dive into the binary frame structure and its
components with an example:
A binary frame in HTTP/2.0 consists of three parts:

[Link] Header: This is a fixed-size section of the frame that contains essential
information such as the frame length, type, flags, stream identifier, and, in some cases, a
priority field.
[Link] Payload: This is the variable-sized portion of the frame that carries the actual
data. The structure of the payload depends on the frame type.
[Link]: Padding can be added to a frame if necessary, but it's optional. Padding is
used to increase the size of the frame, for example, to obfuscate the actual payload size.

Example: A DATA Frame

Let's take a look at the structure of a DATA frame in HTTP/2.0 as an example:
• Frame Type: DATA (0x0)
• Flags: DATA frames have three flags: END_STREAM (0x1), END_HEADERS
(0x4), and PADDED (0x8). These flags indicate, respectively, whether this is the last
frame for the associated stream, the end of the header block, and if padding is included.
Application Layer 2-31
 HTTP /2.0 Key Features:
• Stream Identifier: A 31-bit identifier indicating which stream this frame belongs to.
• Payload: The actual binary data that the frame carries. This is typically the content of
an HTTP message or a part of it.
• Padding: If the PADDED flag is set, there may be padding included, and the length of
the padding is determined by the length of a padding field. The padding field can be up
to 255 bytes long.
Here's how a DATA frame might look in binary for
+-----------------------------------------------+
|Frame Type (8 bits) | Flags (8 bits) | Stream Identifier (31 bits) |
+-----------------------------------------------+
| Data (binary content) |
+-----------------------------------------------+
| Padding (optional) |
+-----------------------------------------------+

Application Layer 2-32

 HTTP /2.0 Key Features:
Example: Sending a DATA Frame
Let's say you're the client, and you're sending an HTTP request for an image resource to
the server:
1. You initiate a new stream with the server and send a DATA frame with the following
structure:
o Frame Type: DATA
o Flags: END_STREAM (indicating that this is the last frame for the stream)
o Stream Identifier: 1 (assuming this is the first stream you've created)
o Payload: The binary content of the HTTP request, which includes the resource
URL, headers, and other request data.
o Padding: None in this case (PADDED flag is not set).
2. The server receives the DATA frame, processes the request, and responds with a
DATA frame of its own, containing the binary content of the image you requested.

The binary frame structure and multiplexing capabilities of HTTP/2.0 allow multiple
streams to be managed concurrently, optimizing data transmission and improving the
overall performance of web applications.
Application Layer 2-33
HTTPS (HTTP Secure)
SSL (Secure Sockets Layer):
1. Encryption: SSL was the original protocol designed for securing data transmission between
a client and a server. It uses encryption algorithms to ensure that data exchanged over the
network is encrypted, making it unreadable to any third parties intercepting the traffic.
2. Authentication: SSL also provides a level of authentication. It verifies that the server is
indeed the one it claims to be, helping to prevent man-in-the-middle attacks.
TLS (Transport Layer Security):
1. Encryption Standards: TLS builds upon SSL but uses more modern and secure encryption
standards. It has evolved to address vulnerabilities found in SSL.
2. Security: TLS is generally considered more secure and robust than SSL. It's the protocol
that is used to secure most HTTPS connections today.
3. Versions: SSL has multiple versions, including SSL 2.0 and SSL 3.0, which have known
security issues. TLS, on the other hand, has versions like TLS 1.0, TLS 1.1, TLS 1.2, and TLS
1.3, with each newer version improving security and performance. TLS 1.3, in particular,
focuses on minimizing latency.
In summary, HTTP/2.0 brings significant improvements over HTTP 1.x, including binary
framing, multiplexing, header compression, and server push. HTTPS, secured by SSL or TLS,
is vital for protecting data in transit, with TLS being the more secure and modern option
compared to SSL, due to its stronger encryption standards and better security practices.
Application Layer 2-34
HTTPS (HTTP Secure)
Exchange of Messages between Host and Server in HTTPs:
Client (Host): Your web browser, for example, Google Chrome.
Server: The web server hosting a website, such as an online shopping site like
"[Link]."
Message Exchange Steps in HTTPS:
[Link] Hello (TLS Handshake):
o Client: The client initiates the connection by sending a "Client Hello" message to
the server.
o Server: The server receives the "Client Hello" message and processes it.
2. Server Hello (TLS Handshake):
o Client: The client receives the "Server Hello" message and checks the server’s
certificate for authenticity. The certificate might be issued by a trusted Certificate
Authority (CA). If it's trusted, the client proceeds.
o Server: The server responds with a "Server Hello" message, which includes
information like the selected encryption protocol, a random number, and the
server's digital certificate.

Application Layer 2-35

HTTPS (HTTP Secure)
3. Key Exchange (TLS Handshake):
o Client: The client generates a random "pre-master secret" and encrypts it with
the server's public key (extracted from the server's certificate).
o Client: The client sends this encrypted "pre-master secret" to the server.
o Server: The server decrypts the "pre-master secret" using its private key.
4. Session Key Derivation (TLS Handshake):
o Both the client and server use the "pre-master secret" to independently derive a
shared "session key." This key is used for encrypting and decrypting the actual
data exchanged during the session.
5. Finished Messages (TLS Handshake):
o Both the client and server send "Finished" messages to confirm that they have
successfully established a secure connection.
o The "Finished" messages are encrypted using the shared session key, ensuring
that further communication will be secure.

Application Layer 2-36

HTTPS (HTTP Secure)
6. Data Exchange (HTTP Messages):
o With the secure TLS connection established, the client and server can exchange
data, such as HTTP requests and responses.
o Client: The client sends an HTTP request, such as requesting the homepage of
"[Link]."
o Server: The server receives the request, processes it, and sends back the
requested web page, along with an encrypted HTTP response.

7. Secure Data Exchange (TLS Encyption):

o All data exchanged between the client and server, including the web page content,
is encrypted using the shared session key.
o This encryption ensures that any data intercepted during transmission remains
unreadable to eavesdroppers.
8. End of Session:
o When the client has received the data it needs, it may choose to terminate the
session. The client and server exchange "goodbye" messages and close the
connection.

Application Layer 2-37

HTTPS (HTTP Secure)
Example Scenario:
Imagine you're shopping online on "[Link]." Your web browser establishes a
secure HTTPS connection with the server hosting the website. During the TLS
handshake, encryption keys are exchanged, ensuring that your sensitive information, such
as your payment details, remains confidential. When you make a purchase, your payment
details are encrypted and securely transmitted to the server, providing you with a safe and
private shopping experience.

Application Layer 2-38

Web caches (proxy server)
goal: satisfy client request without involving origin server
 user sets browser: Web
accesses via cache
 browser sends all HTTP proxy
HT
requests to cache TP
req server u est
HT ues P req
 object in cache: cache client TP
res
t H TT po n se
origin
pon res
returns object se HT
T P server
t
 else cache requests ues
req e
object from origin TT P o ns
p
H res
server, then returns HT TP
object to client
client origin
server

Application Layer 2-39

More about Web caching
 cache acts as both why Web caching?
client and server  reduce response time for
 server for original client request
requesting client
 client to origin server  reduce traffic on an
 typically cache is institution’s access link
installed by ISP  Internet dense with
(university, company, caches: enables “ poor”
residential ISP) content providers to
effectively deliver
content (so too does P2P
file sharing)

Application Layer 2-40

FTP: the file transfer protocol
file transfer
FTP FTP FTP
user client server
interface
user
at host remote file
local file system
system

 transfer file to/from remote host

 client/server model
 client: side that initiates transfer (either to/from remote)
 server: remote host
 ftp: RFC 959
 ftp server: port 21
Application Layer 2-41
FTP: separate control, data connections
TCP control connection,
 FTP client contacts FTP server server port 21
at port 21, using TCP
 client authorized over control TCP data connection,
connection FTP server port 20 FTP
client server
 client browses remote
directory, sends commands
over control connection  server opens another TCP
data connection to transfer
 when server receives file another file
transfer command, server
opens 2nd TCP data connection  control connection: “out of
(for file) to client band”
 after transferring one file,  FTP server maintains “ state
server closes data connection ” : current directory, earlier
authentication

Application Layer 2-42

Electronic mail outgoing
message queue
user mailbox
Three major components: user
agent
 user agents
 mail servers mail user
server agent
 simple mail transfer
protocol: SMTP SMTP mail user
server agent
User Agent SMTP
 a.k.a. “ mail reader” SMTP user
agent
 composing, editing, reading mail
mail messages server
user
 e.g., Outlook, Thunderbird, agent
iPhone mail client user
 outgoing, incoming agent
messages stored on server
Application Layer 2-43
Electronic mail: mail servers
mail servers: user
agent
 mailbox contains incoming
messages for user mail user
server agent
 message queue of outgoing
(to be sent) mail messages SMTP mail user
 SMTP protocol between server agent
mail servers to send email SMTP
messages user
 client: sending mail SMTP agent
mail
server server
user
 “ server” : receiving mail agent
server
user
agent

Application Layer 2-44

Scenario: Alice sends message to Bob
1) Alice uses UA to compose 4) SMTP client sends Alice’s
message “ to” message over the TCP
bob@[Link] connection
2) Alice’s UA sends message to 5) Bob’s mail server places the
her mail server; message message in Bob’s mailbox
placed in message queue 6) Bob invokes his user agent to
3) client side of SMTP opens read message
TCP connection with Bob’s
mail server

1 user mail user

mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
Application Layer 2-45
Mail access protocols
user
mail user
SMTP SMTP access
agent agent
protocol
(e.g., POP,
IMAP)

sender’s mail receiver’s mail

server server

 SMTP: delivery/storage to receiver’s server

 mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]: authorization,
download
 IMAP: Internet Mail Access Protocol [RFC 1730]: more
features, including manipulation of stored msgs on server
 HTTP: gmail, Hotmail, Yahoo! Mail, etc.

Application Layer 2-46

DNS: domain name system
people: many identifiers: Domain Name System:
 SSN, name, passport #  distributed database
Internet hosts, routers: implemented in hierarchy of
 IP address (32 bit) - many name servers
used for addressing  application-layer protocol:
datagrams hosts, name servers
 “ name” , e.g., communicate to resolve
[Link] - names (address/name
used by humans translation)
 note: core Internet function,
Q: how to map between IP
implemented as application-
address and name, and
layer protocol
vice versa ?
 complexity at network’s
“ edge”
Application Layer 2-47
DNS: a distributed, hierarchical database
Root DNS Servers

… …

com DNS servers org DNS servers edu DNS servers

[Link] [Link] [Link]

[Link] [Link]
DNS servers DNS serversDNS servers
DNS servers DNS servers

client wants IP for [Link]; 1st approx:

 client queries root server to find com DNS server
 client queries .com DNS server to get [Link] DNS server
 client queries [Link] DNS server to get IP address for
[Link]

Application Layer 2-48

 DNS: root name servers
 contacted by local name server that can not resolve name
 root name server:
 contacts authoritative name server if name mapping not known
 gets mapping
 returns mapping to local name server

c. Cogent, Herndon, VA (5 other sites)

d. U Maryland College Park, MD k. RIPE London (17 other sites)
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)

m. WIDE Tokyo
e. NASA Mt View, CA (5 other sites)
f. Internet Software C.
Palo Alto, CA (and 48 other sites)

a. Verisign, Los Angeles CA 13 root name

(5 other sites)
b. USC-ISI Marina del Rey, CA
“servers” worldwide
l. ICANN Los Angeles, CA
(41 other sites)
g. US DoD Columbus,
OH (5 other sites)

Application Layer 2-49

TLD, authoritative servers
top-level domain (TLD) servers:
 responsible for com, org, net, edu, aero, jobs, museums,
and all top-level country domains, e.g.: uk, fr, ca, jp
 Network Solutions maintains servers for .com TLD
 Educause for .edu TLD
authoritative DNS servers:
 organization’s own DNS server(s), providing authoritative
hostname to IP mappings for organization’s named hosts
 can be maintained by organization or service provider

Application Layer 2-50

Local DNS name server
 does not strictly belong to hierarchy
 each ISP (residential ISP, company, university)
has one
 also called “ default name server”
 when host makes DNS query, query is sent to its
local DNS server
 has local cache of recent name-to-address translation
pairs (but may be out of date!)
 acts as proxy, forwards query into hierarchy

Application Layer 2-51

Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicate
 peers are intermittently
connected and change IP
addresses

examples:
 file distribution
(BitTorrent)
 Streaming (KanKan)
 VoIP (Skype)

Application Layer 2-52

File distribution: client-server vs P2P
Question: how much time to distribute file (size F) from one server to N
peers?
 peer upload/download capacity is limited resource

us: server upload

capacity

u1 di: peer i download

file, size F us d1 u2 capacity
d2
server
di
uN network (with abundant
bandwidth) ui
dN
ui: peer i upload
capacity

Application Layer 2-53

File distribution time: client-server
 server transmission: must
sequentially send (upload) N F
us
file copies:
di
 time to send one copy: F/us
network
 time to send N copies: NF/us ui

 client: each client must

download file copy
 dmin = min client download rate
 min client download time: F/dmin

time to distribute F
to N clients using
Dc-s > max{NF/us,,F/dmin}
client-server approach

increases linearly in N
Application Layer 2-54
File distribution time: P2P
 server transmission: must
upload at least one copy F
us
 time to send one copy: F/us
di
 client: each client must network
download file copy ui
 min client download time: F/dmin
 clients: as aggregate must download NF bits
 max upload rate (limting max download rate) is us + ui

time to distribute F
DP2P
to N clients using > max{F/us,,F/dmin,,NF/(us + ui)}
P2P approach

increases linearly in N …
… but so does this, as each peer brings service capacity
Application Layer 2-55
 Client-server vs. P2P: example
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us

3.5
P2P
Minimum Distribution Time

3
Client-Server
2.5

1.5

0.5

0
0 5 10 15 20 25 30 35

N
Application Layer 2-56
P2P file distribution: BitTorrent
 file divided into 256Kb chunks
 peers in torrent send/receive file chunks

tracker: tracks peers torrent: group of peers

participating in torrent exchanging chunks of a
file

Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

Application Layer 2-57

P2P file distribution: BitTorrent
 peer joining torrent:
 has no chunks, but will
accumulate them over time
from other peers
 registers with tracker to get
list of peers, connects to
subset of peers (“ neighbors” )

 while downloading, peer uploads chunks to other peers

 peer may change peers with whom it exchanges chunks
 churn: peers may come and go
 once peer has entire file, it may (selfishly) leave or
(altruistically) remain in torrent

Application Layer 2-58

BitTorrent: requesting, sending file chunks

requesting chunks: sending chunks: tit-for-tat

 at any given time, different  Alice sends chunks to those four
peers have different subsets peers currently sending her
of file chunks chunks at highest rate
 periodically, Alice asks  other peers are choked by Alice
each peer for list of chunks (do not receive chunks from her)
that they have  re-evaluate top 4 every10 secs
 Alice requests missing  every 30 secs: randomly select
chunks from peers, rarest another peer, starts sending
first chunks
 “ optimistically unchoke” this peer
 newly chosen peer may join top 4

Application Layer 2-59

BitTorrent: tit-for-tat
(1) Alice “ optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers higher upload rate:
find better trading
partners, get file
faster !

Application Layer 2-60