Basics

Sharing

Packet switching

• network resources
• per packet

Data is sent as chunks of formatted bits called packets (consist of "header" and "payload") Switches will "forward" the packets based on their header

each packet travels independently

no link resources reserved in advance

Statistical multiplexing allow more demands than the network can handle

• The hope is that not all demands are required at the same time
• Makes it good for bursty traffic (average << peak demand)

Packet switching exploits statistical multiplexing better than circuit switching. This is why on the network layer we use packet switching.

Circuit switching

• network resources reserved a priori at "connection" initiation
• admission control: per connection

Steps:

1. src sends reservation request to dst
2. switches create circuit after admission control
3. src starts sending data
4. src sends teardown request

Performance metrics

! catch up

• delay
  • transmission delay - Due to link properties.
  • propagation delay - Due to link properties.
  • queuing delay - Time packet waits in buffer so that it can be transfered. Due to traffic mix and switch internals.
  • processing delay - time it takes for computer to process the packet. Due to traffic mix and switch internals.
• loss
• throughput - at what rate is the destination receiving the data from the source

A network link

Link bandwidth is the number of bits sent/received per unit test (bits/sec or bps)

propagation delay: time for one bit to move through the link (in seconds)

Packet Delay example

• we send a 100-byte packet
• A sends to B through a 1 Gbps, 1ms link.
• A -- > B | The time to transmit one bit from A is 1/$10^9$ s
• A --> B | time that bit takes to reach B is $1/10^9 + 1/10^3$ s
• But we transfer a 100byte packet so it the time to transmit 800 bits is $800 \times 1/10^9$s
• the last bit reaches B at $(800 \times 1/10^9 s) + 1/10^3 s - 1.008ms$

Maximum Queuing Delay? assume that the packet is the last packet in the queue. There are 10 packets of size 1500 bytes. The link is 10 Gb/s.

The time it takes to process is the transmission delay for one packet 1500 bytes x 8 (bits/byte) / (10 (packets) * 10^9) = 1.2 ms

Queueing delay is 9 x 1.2 = 10.8 ms.

CATCHUP

Throughput

Let transmission rate be R bits/s file of size F bits Packets of size L bits

Transfer time (T) = F/R + propagation delay

CATCHUP

End-to-end throughput

• transmission rate R
• in between is the bottleneck link
• tranmission rate R' > R

The link with the minimum transmission

The average throughput is min{R, R'} = R

LAYERS

Lower 3 layers implemented everywhere top two layers are implemented only at host

end systems : application, transport, network datalink

routers: network, datalink

As we go lower in layers, new headers are added.

IP is the narrow waste of the the layering hourglass. It's the common protocol implemented in the network layer. (compare this to other layers where there are many different types in different layers)

Application layer

HTTP

hyper text transfer protocol

client-server architecutre

• server is "always on" (always listening to one specific port number) rand "well known" (the clients know the address to that server)
• clients initiate the contact to server

Synchronous request/reply protocol

• runs over tcp, port 80 stateless

Steps in the HTTP request/response C(Clients) S(server)

Establish connection

• C->S TCP syn
• S->C syn+ack

Client request

• C->S ack + http get

Response request...

Object request response time RTT (round-trip time) is the time for a small packet to travel from client to server and back. (like time between send and receive ACK)

send after ack response time:

• 1 RTT for TCP setup
• 1 RTT for HTTP request and first few bytes
• transmission time
• total = 2RTT + Transmission time

This is not efficient, so a strategy to improve HTTP performance:

Optimizing HTTP

(CATCH UP) Optimize connection

1. using 3 "P"s
   1. persistent connection
   2. parallel/concurrent connections
   3. pipelined transfers over the same connection: send n requests at a time
2. Caching 5. forward proxy (close to client) 6. reverse proxy (close to the server)
3. Replication (exact copy of the data stored elsewhere, while caching is temporary)

CDN

CDN

• caching and replication as a service
• combination of these two
  • pull: direct result of the client's requests (caching)
  • push: expectation of high access rate (replication)

DNS

how do we know the addressees of the servers that we want to send? we use DNS

Hierarchies in DNS:

• have three intertwined hierarchies
  • hierarchical namespace: as opposed to original flat namespace.
  • hierarchical administered: as opposed to centralized. this means there are 13 global root servers instead of 1. Different servers are attributed to each of the high domain name (.gov, .edu, etc.)
  • (distributed) hierarchy of servers: as opposed to centralized storage

name resolution takes place first in the root, then moves to .edu, then princeton.edu servers.

From client outwards:

• The DNS client (me.cs.jhu.edu) will ask for princeton.edu from your local dns server (mydns.jhu.edu) which will go to the root server.

Recursive: the servers take care of everything, they will send back the result to the upper hand server which will figure it out and send it to you

Iterative: the root server will give you all the edu servers, which then you use this information to find princeton.edu (keeps going back and forth between you and each level)

DNS Caching

Performing all these queries takes time- up to 1 second latency before starting download

caching greatly reduces overhead:

• top level servers rarely change.
• popular sites are visited often. heavily requested. it'll be cached so that the next request will be quickly answered without going to the root server
• local dns server often has the information cached.

How DNS caching works:

• dns servers cache responses to queries
• responses have TTL field
• server deletes cached entry after TTL expires.

Transport Layer

The transport layer is responsible for:

1. comm between app processes
   1. mux and demux from/to application processes
   2. implemented using ports
2. provide common e2e service for app layer
   1. reliable, in order data delivery
   2. well-paced data delivery

UDP vs TCP:

• both have mux/demux via port

UDP:

• data abstraction: packets (datagrams) you can see each packet individually.
• service: best-effort, like IP

TCP:

• data abstraction: stream of bytes of arbitrary length (needs to make sure its in order)
• service: reliable, in order delivery, congestion + flow control.

Reliable transport

• checksum (for error detection)
• timers (for loss detection)
• ack (feedback from receiver)
  • cumulative: 'received everything up to X' (up to 6)
  • selectiveL 'received x' (packet 6)
• seq no. (detects dups, accounting).
• sliding window (improves efficiency)

Make sure you know

• what these concepts are
• why they exist
• how tcp uses them

stop and wait (works packet by packet, of size DATA): is correct but inefficient (throughput of DATA/RTT) because you have to wait for ack after sending each data

sliding window (use pipelinig to increase throughput):

• send n packets at a time, which results in higher throughput
• $min(n \times data/RTT, \text{link bandwidth})$

Three aspects: reliable, in-order, byte stream

• reliable: tcp resends long packets recursively. CATCHUP

Know the functionality and why it is needed of the following concepts:

• how tcp achieves reliability
• RTT estimation
• connection establsihment/teardown
• flow control
• congestion control

reliabiltiy: know the following concepts:

• checkssum timer
• fast retansmit
• cumulative acks
• sliding window
• buffer at sender
• buffer at receiver (reorder )

RTT estimation:

• we have a timer so that we can retransmit if the destination has not acknolwedged.
• So what value should the timer be?
  • too small, we don't give time for the network to transfer
  • too big, delay resending the packet and the transmit is slower
• RTT varies (significantly) for different reasons on different timescale due to a few factors: temp congestion, long-lived congestion, due to a change in routing paths
• The solution is to estimated
• An incorrect RTT estimate might introduce spurious retransmissions or overly long delays
• proposed solutions use EWMA, incorporate deviations.

establish a TCP connection with a threeway handshake

• A sends B a SYN
• B returns SYN ACK
• A sends ACK for the SYN ACK

fin then data can be sent

flow control:

• we don't want to overflow the buffers in the receiver.
• any receiver must buffer a packet until all packets before it (in byte-order)have arrived and the receiving application has consumed available bytes.
• the application layer is taking one by one packets from the buffer
• hence, the receiver advances window when the receiving application consumes data
• sender advances window when new data ACKd'
• risk of sender over-running the rceiver's buffer

How? advertised window filed in TCP header.

CONGESTION CONTROL:

• whyL because the network itself can be the bottle neck.
• make efficient use of avaialbel network capacity
  • while sharing available capacity fairly wiht other flows
  • and adapt to changes in avail capacity.

CATCHUP

TCP Overivew;

• flow control to restrict window to RWND to make sure that receiver is not overwhelmed
• congestion contorl restrcits window to CWND to make sure network is not overwhelmed
• CATCHUP

Congestion control:

• states at sender: CWND (initailized to small constant)
• ssthresh ( initailized to large constant)
• dupACKcount and timer.

events:

• ack (new data)

  • (slow start, exponential increase) if CWND < ssthresh: increase CWND by one, else CWND = CWND+ 1/CWND (congestion avoidance phase, linear +1 increase)

• dupACK (duplicate ACK For old data)

  • increase dupACKcount ++ , if dupACKcount = 3 (fast retransmit)

• timeout

  • if timeout, then ssthesh.... CATCH UP

CATCHUP

NETWORK LAYER

forwarding and routing

locally done.

forwarding : "data plane"

• direct one data packet
• each router uses local routing state

routing "control plane":

• compute the forwarding table that guides packet
• jointly computed by routers using a distributed algorithm.

both have very different timescales.

designing the IP header

• ip header is an interface
  • between source and destinatino end system.between source and networks (
  • catch up

parse packet:

• version number, packet length

carry packet to destination

• ip address

deal with problems on the way

• loops: ttl
• corruption: checksum
• packet too large: fragmentation fields.