This document provides an overview of application layer requirements and transport layer services. It discusses how different applications have varying requirements for data loss tolerance, timing guarantees, and throughput needs. It then describes the transport services provided by TCP and UDP, noting that TCP provides reliable data transfer and flow control while UDP does not. The document outlines common Internet applications and the protocols and transport layers typically used. It also provides details on the Domain Name System (DNS), including its distributed hierarchical database design and role of root servers, top-level domain servers and authoritative servers.
2. What Transport Service does an
Application need?
Data Loss
Loss Tolerant Applications
Some apps (e.g., audio, VoIP)
can tolerate some loss
2% tolerable for VoIP
Other apps (e.g., file transfer,
email) require 100% reliable
data transfer
Timing
Application may require
timing guarantee
Tight timing constraints
multiplayer games, VoIP,
teleconferencing.
In Non-real time lower delays
are preferred but no tight
constraint on end-to-end
delays.
Throughput
Bandwidth sensitive
applications (e.g., multimedia)
require minimum amount of
throughput
Other apps (“elastic apps”)
make use of whatever
throughput they get
e.g .Email, file transfer
Security
Encryption and decryption
3. Transport Service Requirements of Common
Applications
Data loss
Throughput
Time Sensitive
file transfer
e-mail
Web documents
real-time audio/video
no loss
no loss
no loss
loss-tolerant
no
no
no
yes, 100’s msec
stored audio/video
interactive games
loss-tolerant
loss-tolerant
elastic
elastic
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps -10kbps
Application
yes, few secs
yes, 100’s msec
4. Internet transport protocols services
TCP service:
connection-oriented: setup
required between client and
server processes
reliable transport between
sending and receiving process
flow control: sender won’t
overwhelm receiver
congestion control: throttle
sender when network
overloaded
does not provide: timing,
minimum throughput
guarantees, security
UDP service:
unreliable data transfer
between sending and
receiving process
does not provide:
connection setup,
reliability, flow control,
security
Throughput and timing
guarantee not provided
5. Internet Applications: application, transport
protocols
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
Application
layer protocol
Underlying
transport protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
RTP [RFC 1889]
TCP
TCP
TCP
TCP
UDP
SIP, Skype
UDP
6. DNS: Domain Name System
People: many identifiers:
SSN, name, passport #
Internet hosts:
IP address (32 bit)
“name”, e.g.,
ww.yahoo.com - used by
humans
Q: map between IP
addresses and name ?
Domain Name System:
Distributed Database
implemented in hierarchy of
many DNS servers
An application-layer protocol
that allows hosts to query the
distributed database
DNS uses UDP over port
number 53.
RFC 1034 and RFC 1035
7. DNS
Simple design would have one DNS server
that contains all the mappings
Why not centralize DNS?
Single point of failure
Traffic volume
Distant centralized database
Maintenance
A centralized database in a single DNS
server doesn’t scale!
8. Distributed, Hierarchical Database
Root DNS Servers
com DNS servers
yahoo.com
amazon.com
DNS servers DNS servers
org DNS servers
pbs.org
DNS servers
edu DNS servers
poly.edu
umass.edu
DNS servers
DNS servers
Client wants IP for www.amazon.com:
Client first queries a root server
The root server returns the IP addresses for TLD servers for
the top level domain com
The client then contacts one of the TLD servers which returns
the IP address of an authoritative server for amazon.com
The authoritative server then returns the IP address for the
host name www.amazon.com
9. DNS: Root Name Servers
13 root DNS servers world wide
Each server is a cluster of replicated servers
security and reliability purposes.
For more information see www.root-servers.org
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD
g US DoD Vienna, VA
h ARL Aberdeen, MD
j Verisign, ( 21 locations)
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA (and 36 other locations)
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
k RIPE London (also 16 other locations)
i Autonomica, Stockholm (plus
28 other locations)
m WIDE Tokyo (also Seoul,
Paris, SF)
10. TLD and Authoritative Servers
Top-level Domain (TLD) Servers:
Responsible for com, org, net, edu, etc, and all
top-level country domains uk, fr, jp.
Network Solutions maintains servers for com TLD
Educause for edu TLD
ICANN: Internet Corporation for Assigned Names
and Numbers
Authoritative DNS Servers:
Every organization with publicly accessible hosts
provide accessible DNS records.
That maps the names of those hosts to IP addresses
Authoritative DNS servers houses these DNS records
11. Local Name Server
Does not strictly belong to hierarchy
Each company, university has one.
Also called “default name server”
When host makes DNS query, query is sent
to its local DNS server
acts as proxy, forwards query into hierarchy
12. DNS name
resolution example
root DNS server
2
Host at cis.poly.edu
3
wants IP address for
gaia.cs.umass.edu
Iterated query:
Contacted server
replies with name of
server to contact.
“I don’t know this
name, but ask this
server”.
TLD DNS server
4
5
local DNS server
dns.poly.edu
1
8
requesting host
7
6
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu
13. DNS name
resolution example
Recursive Query:
2
Puts burden of name
resolution on other
server.
DNS Caching
Extensively used
Cache entries timeout
(disappear) after some
time
TLD servers typically
cached in local name
servers
Thus root name
servers not often
visited
root DNS server
3
7
6
TLD DNS server
local DNS server
dns.poly.edu
1
5
4
8
requesting host
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu