CPSC 441 Test 2 Review DNS Name Resolution

- Iterative Query: Contacted server replies with another

2.4 DNS: Domain Name System server for the asker to ask
- Internet Hosts contain a 32-bit IP address and a name - Recursive Query: Puts the burden of name resolution
for humans. on the contacted name server, heavy load at upper
- Distributed database is implemented in a hierarchy of levels of hierarchy
many name-servers Iterative Recursive
- Application Layer Protocol: Hosts and name servers
communicate to resolve names
o Core internet function, implemented as app
layer protocol
o Handles complexity at networks edge
- Services include:
o Hostname to IP translation
o Host aliasing (canonical vs alias names)
o Load distribution via replicated web servers.
Many IPs correspond to one name
Why not centralize DNS
- Single point of failure DNS Records
- Large traffic volume - Distributed database that stores resource records (RR)
- Distant centralized database - RR Format = (name, value, type, ttl)
- Costly and difficult to maintain o ttl = time to leave
- Used globally, does not scale if centralized - Type A
Root Name Servers o Name is hostname
- Contacted by local name servers that cannot resolve o Value is IP address
name - Type NS
- Either knows the name mapping or knows the server o Name is domain
that knows the mapping o Value is hostname of authoritative name server
- 13 root name servers worldwide, 1368 instances for this domain
operated globally - Type CNAME
o Name is alias for some canonical (real) name
o Value is canonical name
- Type MX
o Value is name of mail server associated with
name
Inserting Records into DNS
TLD, Authoritative Servers - Register name (stuff.com) at DNS registrar
- Top Level Domains, responsible for com, org, edu, etc o Provide names, IP addresses of authoritative
- Authoritative DNS Servers: For large organizations, name server
provides authoritative hostname to IP mappings for an o Registrar inserts two RRs into .com TLD
organization’s named hosts
server
Local DNS Name Server
- Create authoritative server type A record for
- Each ISP has one (default name server)
www.stuff.com, type MX record for stuff.com
- When host makes DNS query, query is sent to local
DNS
- Stores a local cache of recent name-address translation
pairs
- Acts as a proxy, forwards query into hierarchy
2.5 P2P Applications
- No always on servers, arbitrary end systems directly
communicate with a dynamic IP
File Distribution: BitTorrent
- Files divided into 256 kB chunks
- Peers in system send/receive chunks, can receive the
chunks to 1 file from multiple peers
- Distributes load and speeds up downloads
- Trackers: Keep track of torrents
- Torrents: Group of peers exchanging chunks of a file
- In order to download a file, first need to find a tracker
who will direct you to the torrent for the file you need
- Whenever a peer joins a server, starts with no chunks
but begins to accumulate chunks over time
2.6 Video Streaming and Content Distribution Networks
- Video Traffic: Major consumer of internet bandwidth
(~80%)
- Challenge of scale, how to reach ~2B users globally, a
single server won’t work
- Challenge of Heterogeneity, users have different
capabilities
- Solution: A distributed, app-level infrastructure
Multimedia: Video
- Video: Sequence of images displayed at constant rate
- Image: 2d array of pixels, each pixel represented by
bits
- Coding: Use redundancy between and within images to
decrease the number of bits used to encode an image
o Spatial: Within image
o Temporal: Between images
- CBR: Constant Bit Rate: Video encoding rate fixed
- VBR: Variable Bit Rate: Video encoding rate changes
as coding changes
- Need to stream stored videos from server, across
internet, to client
DASH: Dynamic Adaptive Streaming over HTTP
- Server divides video into multiple chunks
- Each chunk is stored and encoded at different rates and
resolutions, with manifest file to organize them
- Client periodically measures server-client bandwidth
o Consults manifest, requests one chunk at a
time with GET requests
o Chooses max coding rate sustainable with
current bandwidth
o Can choose different coding rates at different
points in time
Content Distribution Networks
- Scalability addressed with many geographically
distributed sites (CDN)
- CDNs are third party major servers by location
- Clients access content at closest CDN
- Subscriber requests content from host, directed to
nearest CDN via manifest
3.1 Transport Layer Services - Processes need an IP address and port number of the
- Provides a logical communication channel between the destination process to establish a connection to send
same layer of two hosts (and must be the same layer of segments
each host, can’t be two different layers) - Each process has its own unique socket
- Provides logical communication between app - Multiplexing organizes the src/dest ports and the
processes in different hosts src/dest IP of a process segment at the sending side.
- Transport protocols run in end systems Combines multiple segments into one stream
o Sending Side: Break application messages into - Demultiplexing separates each individual segment
segments and passes it to the network layer from a single stream and sends them where they need
o Receiving Side: Reassembles segments into to go
messages, passes to application layer o Uses only a destination IP and port to identify
- More than one transport protocol available to apps segments
Levels of Encapsulation Specific Packet Names
Application Message
Transport Segment
Network Datagram
Link Frame
Physical
Transport vs Network Layer
- Network: Establishes logical communication between
Hosts
Consider a single server process communicating with
- Transport: Establishes logical communication between
many client processes
Processes
- Multiplexing remains the same
o Relies on and enhances network services
- Demultiplexing matters if UDP or TCP
Internet Transport Layer Protocols
- UDP: Open a datagram socket, all receiving segments
- Reliable, in-order delivery of app messages (TCP)
have to go to the same socket. All data can be mixed
o Congestion Control, Flow Control, Connection
together
Setup
o Demultiplexing only considers dest IP/Port
- Unreliable, unordered delivery (UDP)
- TCP: Provides a connection oriented process.
o No frills extension of best-effort IP
Incoming requests open a new socket. Can have
- Services not available: Delay guarantees, Bandwidth
multiple sockets all with the same port number
guarantees
o The server opens a new socket for each client
process
o Keeps them from getting mixed up but needs
more info than UDP Demultiplexing
 Has to look at all 4 pieces of
information, rather than just 2

3.2 Multiplexing and Demultiplexing

3.3 Connectionless Transport: UDP
- UDP segments may be lost or delivered out of order
- Connectionless means no handshake between UDP
sender and receiver
o Each UDP segment is handled independently
of others
- UDP Use
o Streaming multimedia apps (are loss tolerant
and rate sensitive)
o DNS and SNMP
- Reliable transfer over UDP
o Adds reliability at application layer
o Application specific error recovery
- Analogous to physical mail, put address on letter and
send it out, multiple letters can take different routes
and arrive in different orders
UDP Segment Header
- Length: In bytes of the UDP segment, including header
- All of these small rectangles are 2 bytes wide, 4 bytes
tall
Why is there a UDP
- No connection establishment (Faster)
- Simple: No connection state at sender/receiver
- Small header size
- No congestion control: UDP can send as fast as desired
- Logical structure (Big Endian, not really important)
UDP Checksum
- Detect errors (flipped bits) in transmitted segment
- Sender:
o Treats segment contents (including header) as
a sequence of 16 bit integers
o Checksum: Addition (ones complement) of
segment contents
o Sender puts checksum value into UDP
Checksum field
- Receiver:
o Compute checksum of received segment
o Checks if computed checksum equals the
checksum field value. If so, there are no
detected errors, otherwise there is a detected
error
Checksum Calculation Example
- First add all the bits, carry the leftmost bit to the right
and add it, then flip all the bits
- Not a very powerful error detection system
3.4 Principles of Reliable Data Transfer (RDT)
Reliable Data Transfer: Getting Started
- Incrementally develop sender and receiver sides of
RDT protocol
- Consider only unidirectional data transfer (control info
flows in both directions)
- Use finite state machines (FSM) to specify senders and
receivers (a quick sketch of the system)
rdt1.0: Reliable transfer over a reliable channel
- Underlying channel is perfectly reliable
o No bit errors or loss of packets
- Separate FSMs for sender and receiver
o Sender reads data into underlying channel
o Receiver reads data from underlying channel
rdt2.0: Reliable channel with bit errors
- Underlying channel may flip bits in a packet
- Question: How to recover from errors:
- Error detection via checksum, assume the checksum is
perfect (despite it being pretty bad in practice)
- Feedback:
o ACK (packet received, no errors)
o NAK (packet received with errors)
o Together known as ARQ (Automatic Repeat
reQuest protocols)
- Retransmissions: The sender keeps transmitting the
same packet whenever the receiver reports NAK
FSM Specifications for rdt2.0
- There are a few problems with this design:
- Consider an error in the packet but also an error in the
returning NAK (could be interpreted as ACK)
- So we need error checking at the sender and a
checksum on ACK/NAK messages
- The problem with this is that the sender can send
duplicate messages if a successful message returns a
corrupted ACK message.
- Reliable: No loss, no errors, no out-of-order, no
duplicates
- To fix duplicates, use a sequence number for each
message. The receiver ignores a message with the
same sequence number as the previous message. Only
need a single bit and flips between 0 and 1
Stop and Wait Protocol
- Sender sends one packet, then waits for response.
- Practical use and used in Wi-Fi.
Sender FSM for rdt2.1: Handles garbled ACK/NAKS
Receiver FSM for rdt2.1:
rdt2.1 overview:
Sender:
- Sequence number added to packets.
- Two sequence numbers (0,1) will suffice.
- Must check if received ACK/NAK is corrupted
Receiver:
- Must check if a received packet is a duplicate
o State indicates whether a 0 or 1 is the expected
packet sequence number.
rdt2.2: a NAK free protocol
- Same functionality as rdt2.1, using ACKs only.
- Instead of NAK, receiver sends ACK for the last
packet received okay.
o Receiver must explicitly include the sequence
number of the packet being acknowledged.
- Duplicate ACK at sender results in same action as
NAK (retransmission)
rdt3.0: Channel with errors and losses
- New assumption: Underlying channel can also lose
entire packets (data or acknowledgements)
o Checksum, sequence #s, ACKs, may help but
aren’t enough on their own
- Approach: Sender waits a “reasonable” amount of time
for ACK
o Retransmits if no ACK is received.
o If the packet is delayed (not lost) the
retransmission will be a duplicate (handled by
sequence #)
o Requires a countdown timer.
o Only risk is a waste of bandwidth by sending
unnecessary duplicates.
Performance of rdt3.0
- Performance is awful but does everything correctly.
- Example: 1 Gbps link, 15 ms prop delay, 8000 bit
packet
- Utilization: Percentage of time spent sending
- Stop and Wait has horrible, horrible utilization.
Throughput calculations from lecture
o RTT = 2 x (prop delay)
o L = size of message in bits
o R = transmission rate (bps)
- A good way to increase throughput and utilization is to
send more packets per round.
Pipelining Protocols
- Sender allows multiple “in-flight” and yet to be
acknowledged packets
o Range of sequence numbers must be increased
o Buffering at sender and/or receiver
- Two generic forms of pipelined protocols: Go-Back-N
and Selective Repeat

- Duration of each round = L/R + RTT

- Want to get throughput to be equal to R for max
efficiency and utilization
- So throughput = (N*L)/(RTT + L/R) = R
o N = R (RTT + L/R)/L
- Since L/R ~ 0, then throughput = N * (L/RTT) where
N is the number of packets