Update assignment 1

1 files changed, 173 insertions, 440 deletions

diff --git a/assignments/1/README.md b/assignments/1/README.md
index 9969312..8c94511 100644
--- a/assignments/1/README.md
+++ b/assignments/1/README.md
@@ -30,15 +30,15 @@ Traceroute was run from my computer to google.com at three different
 times with the following results:
 
 | Measurement | Time     | # of Hops | End-to-End RTT (ms) |
-| ----------- | ----     | --------- | ------------------ |
-| 1           | 14:34    | 13        | 61.43              |
-| 2           | 14:39    | 8         | 20.85              |
-| 3           | 15:08    | 8         | 21.51              |
+| ----------- | ----     | --------- | ------------------- |
+| 1           | 14:34    | 13        | 61.43               |
+| 2           | 14:39    | 8         | 20.85               |
+| 3           | 15:08    | 8         | 21.51               |
 
-RTT Statistics:
+RTT Statistics (over the three measurements):
 
 - Average RTT: 34.60 ms
-- Standard Deviation: 23.24 ms
+- Standard Deviation (sample): 23.24 ms
 
 ### Trace 1
 
@@ -109,45 +109,22 @@ traceroute to google.com (142.251.215.238), 64 hops max, 40 byte packets
     172.253.79.231 (172.253.79.231) 76 bytes to 192.168.0.139  22.211 ms  21.499 ms
 ```
 
-### Trace 4
-
-```bash
-traceroute -v google.com
-Using interface: en0
-traceroute to google.com (142.251.215.238), 64 hops max, 40 byte packets
- 1  192.168.0.1 (192.168.0.1) 48 bytes to 192.168.0.53  5.041 ms  2.739 ms  2.033 ms
- 2  10.139.230.1 (10.139.230.1) 48 bytes to 192.168.0.53  3.232 ms  3.904 ms  4.116 ms
- 3  * * *
- 4  * * *
- 5  * * *
- 6  * * *
- 7  192.178.105.146 (192.178.105.146) 36 bytes to 192.168.0.53  29.061 ms
-    142.251.249.236 (142.251.249.236) 36 bytes to 192.168.0.53  22.413 ms
-    108.170.255.196 (108.170.255.196) 36 bytes to 192.168.0.53  23.130 ms
- 8  172.253.79.231 (172.253.79.231) 76 bytes to 192.168.0.53  23.171 ms
-    sea09s35-in-f14.1e100.net (142.251.215.238) 36 bytes to 192.168.0.53  22.844 ms  22.020 ms
-```
-
 ### Analysis
 
-The traceroute runs show different destination IPs due to Google's
-load balancing. Trace 1 took longer (61ms, 13 hops) while Traces
-2-3 were faster (21ms, 8 hops), indicating route optimization. The
-`* * *` entries show routers filtering ICMP traffic, which is normal
-behavior.
+- The traceroute runs show different destination IPs due to Google's load balancing and anycast.
+- Trace 1 took longer (~61 ms RTT, 13 hops) while Traces 2-3 were faster (~21 ms RTT, 8 hops), indicating route changes/optimization and likely regional Google front-end selection.
+- `* * *` entries indicate ICMP responses are rate-limited or filtered by intermediate routers.
 
 ## 1.2 Internet Protocol Stack Layers (5%)
 
 > What are the five layers in the Internet protocol stack? Develop a table to summarise what each layer does.
 
-The Internet protocol stack has five layers, each with specific responsibilities (Kurose & Ross, 2021, Section 1.5):
-
 | Layer | Name        | Description                                                        |
 | ----- | ----------- | ------------------------------------------------------------------ |
 | 5     | Application | Provides services for applications (e.g., HTTP, SMTP, FTP, DNS)    |
 | 4     | Transport   | Reliable or unreliable data delivery between processes (TCP, UDP)  |
 | 3     | Network     | Routes packets between hosts using logical addressing (IP, ICMP)   |
-| 2     | Link        | Transfers data between adjacent nodes (Ethernet, WiFi)             |
+| 2     | Link        | Transfers data between adjacent nodes (Ethernet, Wi-Fi)            |
 | 1     | Physical    | Sends raw bits as signals over the physical medium (cables, radio) |
 
 ## 1.3 Packet-Switched vs Circuit-Switched Networks (5%)
@@ -163,18 +140,18 @@ The Internet protocol stack has five layers, each with specific responsibilities
 | Path Determination  | Per packet, can vary                | Fixed for entire session                |
 | Bandwidth Usage     | Efficient, statistical multiplexing | Less efficient, reserved even when idle |
 | Setup Required      | None                                | Required before communication           |
-| Transmission Mode   | Store-and-forward                   | Direct circuit path                     |
-| Reliability         | Best effort delivery                | Guaranteed once connected               |
+| Transmission Mode   | Store-and-forward                   | Dedicated end-to-end circuit            |
+| Reliability         | Best-effort delivery                | Guaranteed once connected               |
 | Cost                | Lower, pay per usage                | Higher, pay for reserved capacity       |
-| Scalability         | High                                | Limited by circuits                     |
-| Fault Tolerance     | Robust, automatic rerouting         | Vulnerable, failure breaks connection   |
-| Performance         | Variable delays, jitter possible    | Predictable, consistent                 |
+| Scalability         | High                                | Limited by number of circuits           |
+| Fault Tolerance     | Robust, automatic rerouting         | Vulnerable; circuit failure breaks call |
+| Performance         | Variable delay and jitter possible  | Predictable, consistent latency         |
 | Typical Examples    | Internet, Ethernet, web, email      | PSTN, T1/T3 leased lines                |
 
 Key Points:
 
-* Packet-switched: Efficient, flexible, cost-effective, but can have variable delays and packet loss.
-* Circuit-switched: Predictable, guaranteed bandwidth, good for real-time traffic, but inefficient and less scalable.
+- Packet-switched: Efficient, flexible, cost-effective, but can have variable delays and packet loss.
+- Circuit-switched: Predictable, guaranteed bandwidth, good for real-time traffic, but inefficient and less scalable.
 
 ## 1.4 Network Delays and Traffic Intensity (5%)
 
@@ -188,42 +165,26 @@ Key Points:
 In packet-switched networks, four main delays can occur (Kurose & Ross, 2021):
 
 1. Processing Delay (`d_proc`)
-   * What: Time to examine packet header and determine where to forward it
-   * Where: At routers and switches
-   * Typical duration: Microseconds
+   - What: Time to examine packet header and determine where to forward it
+   - Where: At routers and switches
+   - Typical duration: Microseconds
 2. Queuing Delay (`d_queue`)
-   * What: Time a packet waits in a queue before being transmitted
-   * Where: In router output queues
-   * Depends on: Network congestion and traffic load
+   - What: Time a packet waits in a queue before being transmitted
+   - Where: In router/switch output queues
+   - Depends on: Network congestion and traffic load
 3. Transmission Delay (`d_trans`)
-   * What: Time to push all bits of the packet onto the link
-   * Where: At the sender's interface
-   * Formula: `d_trans = L / R`
-     * `L` = packet length (bits)
-     * `R` = link rate (bps)
+   - What: Time to push all bits of the packet onto the link
+   - Where: At the sending interface of each link
+   - Formula: `d_trans = L / R (L bits, R bps)`
 4. Propagation Delay (`d_prop`)
-   * What: Time for the signal to travel across the link
-   * Where: Along the transmission medium (e.g. fiber, cable)
-   * Formula: `d_prop = d / s`
-     * `d` = physical distance
-     * `s` = propagation speed
+   - What: Time for the signal to travel across the link
+   - Where: Along the transmission medium (e.g., fiber, copper)
+   - Formula: `d_prop = d / s (distance d, propagation speed s)`
 
 ### Traffic Intensity
 
-* Definition: `ρ = La / R`
-  * `L` = avg. packet length (bits)
-  * `a` = avg. packet arrival rate (packets/sec)
-  * `R` = link bandwidth (bps)
-* Why `ρ` should be <= 1:
-  * If `ρ < 1`: Network can handle the traffic -> delays stay manageable
-  * If `ρ = 1`: Link is fully utilized -> delays increase sharply
-  * If `ρ > 1`: Traffic exceeds capacity -> queues grow indefinitely -> packet loss
-* Design Rule:
-  Keep `ρ < 1` (ideally <= 0.7–0.8) for:
-  * Stability
-  * Low delays
-  * Room for bursts
-  * Preventing congestion collapse
+- Definition: rho = La / R (avg. packet length L, average arrival rate a, link rate R)
+- Why rho <= 1: If rho >= 1, packets arrive as fast as or faster than service capacity, so queues grow without bound. Good design targets rho well below 1 (e.g., <= 0.7-0.8) to keep delays low and allow for bursts.
 
 ## 1.5 Web Caching (5%)
 
@@ -231,31 +192,27 @@ In packet-switched networks, four main delays can occur (Kurose & Ross, 2021):
 > university? What problem does the conditional GET in HTTP aim to
 > solve?
 
-Web caching stores frequently requested web content (pages, images,
-videos) closer to users so it can be served locally instead of from
-the origin server. This reduces response time and network traffic.
+Web caching stores frequently requested web content (pages, images, videos) closer to users so it can be served locally instead of from the origin server. This reduces response time and network traffic.
 
-* Cache hit: Requested content is found in the cache
-* Cache miss: Content is not in the cache and must be fetched from the server
+- Cache hit: Requested content is found in the cache
+- Cache miss: Content is not in the cache and must be fetched from the server
 
 Usefulness in universities:
 
-* Shared content: Many students access the same resources, increasing cache hits
-* Bandwidth optimization: Reduces external traffic, preserving limited bandwidth
-* Cost reduction: Cuts repeated downloads from the internet
-* Performance: Faster access to educational content, especially during peak usage
+- Shared content: Many students access the same resources, increasing cache hits
+- Bandwidth optimization: Reduces external traffic, preserving limited bandwidth
+- Cost reduction: Cuts repeated downloads from the Internet
+- Performance: Faster access to educational content, especially during peak usage
 
-Conditional GET in HTTP ensures cached content is up-to-date without
-downloading unchanged objects:
+Conditional GET in HTTP ensures cached content is up to date without downloading unchanged objects:
 
-1. Cache stores object with `Last-Modified` date or `ETag`
-2. On subsequent requests, cache sends a conditional GET with `If-Modified-Since` or `If-None-Match`
+1. Cache stores object with Last-Modified or ETag metadata
+2. On subsequent requests, cache sends a conditional GET with If-Modified-Since or If-None-Match
 3. Server responds:
-   * 304 Not Modified: Content unchanged -> no download
-   * 200 OK: Content changed -> new object sent
+   - 304 Not Modified: Content unchanged -> no download
+   - 200 OK: Content changed -> new object sent
 
-Benefits: Maintains cache freshness, reduces bandwidth use, lowers
-server load, and validates cache efficiently
+Benefits: Maintains cache freshness, reduces bandwidth use, lowers server load, and validates cache efficiently.
 
 ## 1.6 Email Protocol Analysis (5%)
 
@@ -272,69 +229,21 @@ server load, and validates cache efficiently
 
 Scenario: Web-based email (Gmail) sent to Alice who accesses email via IMAP on smartphone over Wi-Fi (Kurose & Ross, 2021, Section 2.3).
 
-### Network Protocols Involved
-
-#### Sender Side (Web-based Gmail)
-
-- HTTP/HTTPS: Communication between browser and Gmail web server
-- SMTP: Gmail server sending email to Alice's mail server
-- DNS: Domain name resolution for Alice's mail server
-- TCP: Reliable transport for HTTP and SMTP
-- IP: Network layer routing
-- Wi-Fi (802.11): Wireless LAN protocol
-- Ethernet: If Wi-Fi access point connects via wired network
-
-#### Receiver Side (Alice's IMAP access)
-
-- IMAP: Alice's smartphone retrieving email from her mail server
-- TCP: Reliable transport for IMAP
-- IP: Network layer routing
-- Wi-Fi (802.11): Wireless connection to home network
-- DNS: Resolving mail server address
+Protocols involved:
 
-### Detailed Message Flow Through Protocol Layers:
+- Application: HTTPS (browser <-> Gmail), SMTP (Gmail <-> Alice's mail server), IMAP (Alice's phone <-> Alice's mail server), DNS (name resolution)
+- Transport: TCP for HTTPS/SMTP/IMAP
+- Network: IP (routing), ICMP (diagnostics)
+- Link: IEEE 802.11 Wi-Fi; possibly Ethernet on the home LAN/backhaul
+- Physical: 2.4/5 GHz radio, copper/fiber on ISP link
 
-#### Phase 1: Sending Email (Your Smartphone -> Gmail Server)
+Layered traversal summary:
 
-1. Application Layer: You compose email in Gmail web interface
-2. HTTP/HTTPS: Browser sends POST request with email data to Gmail server
-3. Transport Layer: TCP segments the HTTP request, adds port numbers (443 for HTTPS)
-4. Network Layer: IP adds source/destination IP addresses (your phone -> Gmail server)
-5. Link Layer: Wi-Fi frames the IP packets with MAC addresses (phone -> router)
-6. Physical Layer: Radio waves transmit frames to Wi-Fi access point
+- Sending (your phone -> Gmail): App composes email -> HTTPS POST over TCP/443 -> IP addressing -> Wi-Fi frames to home router -> ISP uplink
+- Server processing: Gmail extracts message, uses DNS to locate Alice's MX, sends via SMTP over TCP (server-side routing through ISPs)
+- Receiving (Alice's phone): Her mail app uses IMAP over TCP/993 via Wi-Fi to her home router/ISP -> mail server responds with message data -> app displays it
 
-#### Phase 2: Gmail Processing and SMTP Delivery
-
-1. Gmail Server Processing: Receives HTTP request, extracts email, prepares for SMTP delivery
-2. DNS Resolution: Gmail server queries DNS to find Alice's mail server IP address
-3. SMTP Connection: Gmail establishes TCP connection to Alice's mail server (port 25/587)
-4. Application Layer: SMTP protocol transfers email from Gmail to Alice's mail server
-5. Transport Layer: TCP ensures reliable delivery of SMTP commands and email content
-6. Network Layer: IP routes packets through internet infrastructure
-7. Link Layer: Various link technologies (Ethernet, fiber, etc.) carry packets
-
-#### Phase 3: Alice Retrieving Email (Alice's Mail Server -> Smartphone)
-
-1. IMAP Request: Alice's email app sends IMAP commands to check for new messages
-2. Transport Layer: TCP establishes connection (port 143/993), segments IMAP requests
-3. Network Layer: IP routes packets from Alice's phone to her mail server
-4. Link Layer: Wi-Fi frames carry IP packets (phone -> Wi-Fi router -> ISP)
-5. Physical Layer: Radio waves and various physical media transmit signals
-
-#### Phase 4: Email Delivery to Alice's Phone
-
-1. IMAP Response: Mail server responds with email content via IMAP protocol
-2. Transport Layer: TCP reliably delivers email data to Alice's phone
-3. Network Layer: IP routes response packets back to Alice's phone
-4. Link Layer: Wi-Fi receives and processes frames at Alice's phone
-5. Physical Layer: Radio signals converted back to digital data
-6. Application Layer: Email app displays the received message
-
-Key Protocol Stack Traversals:
-
-- Downward: Each device processes from Application -> Physical when sending
-- Upward: Each device processes from Physical -> Application when receiving
-- Multiple Hops: Email traverses multiple network devices (routers, switches) between sender and receiver, each processing up to Network layer and back down
+Key stack behavior: Each sender encapsulates data top-down (Application to Physical); each receiver decapsulates bottom-up (Physical to Application). Routers along the path process up to the network layer.
 
 # Part 2: Long Answer Questions (70%)
 
@@ -351,73 +260,66 @@ Key Protocol Stack Traversals:
 
 Given:
 
-- File size: 10 MB = 10 × 10^6 bytes = 80 × 10^6 bits
+- File size: 10 MB = 10 x 10^6 bytes = 80 x 10^6 bits
 - Packet size: 10,000 bits (including 100 bits header)
 - Payload per packet: 9,900 bits
 
 ### a) Number of packets
 
-Number of packets = Total file bits ÷ Payload bits per packet
-= 80 × 10^6 bits ÷ 9,900 bits/packet
-= 8,080.81 packets
-= 8,081 packets (rounded up)
+```
+Number of packets = ceil(total file bits / payload bits per packet)
+= ceil(80 x 10^6 / 9,900)
+= ceil(8,080.808...)
+= 8,081 packets
+```
 
 ### b) Links identified using traceroute
 
-Based on traceroute to google.com (representing university server path):
+I did not have traceroute access to the actual university server, so I use the measured path to google.com as a representative Internet path within Canada. The longest of the three traces above shows 13 hops, of which the first few are:
+
+1. 192.168.0.1 (home router)
+2. 10.139.230.1 (ISP gateway)
+3. [no reply]
+4. 209.85.174.62 (Google edge)
+5-12. Google backbone routers
+13. 142.251.32.78 (Google front end)
+
+Assumption for calculations below: 13 hops end-to-end (home -> destination).
+
+### c) Link speed estimates and method
 
-1. Home router -> ISP gateway (192.168.1.254 -> 192.168.0.1)
-2. ISP local -> ISP regional (192.168.0.1 -> 10.139.230.1)
-3. ISP -> Internet backbone (10.139.230.1 -> 209.85.174.62)
-4. Multiple backbone links through Google's network
-5. Final delivery to destination server
+Exact per-link speeds are not directly inferable from traceroute RTTs. Using link types and a typical residential plan:
 
-Total identified links: 14 hops
+- Home Wi-Fi: ~300 Mbps (PHY), effective uplink much lower; not the bottleneck here
+- Access uplink (home router -> ISP): ~20 Mbps upload (typical cable/FTTN plan)
+- ISP regional/backbone links: >= 1-10 Gbps
 
-### c) Link speed calculations
+Thus, the first upstream access link (~20 Mbps) is the bottleneck for uploading.
 
-Based on traceroute RTT measurements:
+### d) Time for last packet to enter the first link
 
-| Link  | From -> To      | RTT (ms)   | Estimated Speed                    |
-| ----- | --------------- | ---------- | ---------------------------------- |
-| 1     | Home -> Router  | 16         | ~100 Mbps (Local Ethernet/Wi-Fi)   |
-| 2     | Router -> ISP   | 16         | ~960 Mbps (Residential broadband)  |
-| 3     | ISP Local       | 18         | ~1 Gbps (ISP infrastructure)       |
-| 4-14  | Backbone        | 38-79      | ~10+ Gbps (Internet backbone)      |
+Total bits to send (including headers) across the first link:
 
-First link speed estimation: ~960 Mbps (residential upload speed)
+- `N_packets x packet_size = 8,081 x 10,000 bits = 80,810,000 bits`
 
-### d) Time for last packet to enter first link
+At R1 = 20 Mbps upstream:
 
-Transmission time per packet = Packet size ÷ Link speed
-= 10,000 bits ÷ (960 × 10^6 bps)
-= 0.0104 ms per packet
+- Time to push all bits = 80,810,000 / 20,000,000 ~ 4.041 s
 
-Time for all packets to enter first link:
-= 8,081 packets × 0.0104 ms/packet
-= 84.04 ms = 0.084 seconds
+Answer: The last packet is pushed into the first link at t0 + 4.04 s (approx.).
 
-At t₀ + 0.084 seconds, the last packet will be pushed into the first link.
+### e) Time for last packet to arrive at the university server
 
-### e) Time for last packet to arrive at university server
+Once the last packet leaves the first (bottleneck) link, faster core links transmit it with negligible additional transmission delay relative to the 20 Mbps access bottleneck. The remaining components are propagation plus small processing/queuing.
 
-Total end-to-end delay consists of:
-- Transmission delays: Each link transmits the packet
-- Propagation delays: Signal travel time (estimated ~79 ms from traceroute)
-- Processing delays: Router processing (estimated ~1 ms per hop)
-- Queuing delays: Variable, estimated ~5 ms average per hop
+- One-way propagation on a national path: ~10-30 ms (consistent with the ~20-60 ms RTTs observed)
+- Processing/queuing in the core: a few milliseconds total under light load
 
-Calculation:
-- Time for last packet to enter first link: 0.084 s
-- Transmission time through all links: ~0.0104 ms × 14 = 0.146 ms  
-- Propagation delay: ~79 ms
-- Processing delays: 1 ms × 14 = 14 ms
-- Queuing delays: 5 ms × 14 = 70 ms
+Approximate arrival time for the last packet:
 
-Total time = 0.084 s + 0.000146 s + 0.079 s + 0.014 s + 0.070 s
-= 0.247 seconds
+- `t_last_arrival ~ t0 + 4.04 s + 0.05-0.06 s ~ t0 + 4.09-4.10 s`
 
-The last packet will arrive at the university server at t₀ + 0.25 seconds.
+Conservative answer: t0 + 4.10 s (+/- 0.05 s).
 
 ## 2.2 Propagation Delay and Bandwidth-Delay Product (20%)
 
@@ -425,311 +327,142 @@ The last packet will arrive at the university server at t₀ + 0.25 seconds.
 > computer to the university server, and you have worked out a list
 > of network links between your computer and the university server.
 
-Based on the network path from question 2.1 with links to university server.
+Based on a typical regional path.
 
 ### a) Total distance calculation
 
-Distance estimation using geographic locations:
+Estimate of cumulative fiber distance (home -> ISP local -> regional hub -> intercity backbone -> campus): ~1,800 km.
 
-From traceroute analysis and typical routing:
-
-1. Local network: Home -> ISP (≈ 5 km)
-2. Regional: ISP local -> regional (≈ 50 km)
-3. Long-haul: Regional -> major city hub (≈ 200 km)
-4. Backbone: Inter-city backbone links (≈ 1,500 km total)
-5. University: Final delivery to campus (≈ 20 km)
-
-Estimated total distance = 5 + 50 + 200 + 1,500 + 20 = 1,775 km
-
-Total distance ~ 1,775,000 meters
+Total distance ~ 1,800,000 m.
 
 ### b) Propagation delay calculation
 
-Given:
-
-- Propagation speed: 2 × 10^8 m/s
-- Total distance: 1,775,000 m
-
-```
-Propagation delay (T_prop):
-T_prop = distance / speed
-= 1,775,000 m ÷ (2 × 10^8 m/s)
-= 0.008875 seconds
-= 8.875 ms
-```
-
-### c) Bandwidth-delay
+Given propagation speed s ~ 2 x 10^8 m/s:
 
-Assuming all links have the same speed `R` bps:
+`T_prop = distance / speed = 1.8 x 10^6 / (2 x 10^8) = 9 x 10^-3 s = 9 ms (one way)`
 
-From our analysis, the bottleneck is likely the residential connection at 960 Mbps.
+### c) Bandwidth-delay product
 
-```
-Bandwidth-delay product:
+Assume the bottleneck link rate R is the upstream access link used for uploads, e.g., R = 20 Mbps:
 
-R × T_prop = 960 × 10^6 bps × 8.875 × 10^-3 s
-= 8,520,000 bits
-= 8.52 Mbits
-```
+`R x T_prop = 20 x 10^6 bps x 9 x 10^-3 s = 180,000 bits ~ 0.18 Mbits`
 
 ### d) Maximum bits in links (continuous transmission)
 
-When sending a file continuously as one big stream, the maximum
-number of bits in the network links at any given time equals the
-bandwidth-delay product.
-
-Maximum bits in links = `R × T_prop` = 8,520,000 bits
+If sending a very long continuous stream, the maximum number of bits "in flight" at any instant equals the bandwidth-delay product:
 
-This represents the "capacity" of the network pipe, the total number
-of bits that can be "in flight" between sender and receiver at any
-moment.
+Max bits in links ~ 180,000 bits.
 
 ### e) Bandwidth-delay product implications
 
-The bandwidth-delay product represents the network pipe capacity and has several important implications (Kurose & Ross, 2021, Section 1.4.3):
-
-1. Buffer Requirements:
-  - Minimum buffer size needed for optimal performance
-  - TCP window size should be at least `R × T_prop` for maximum throughput
-2. Network Utilization:
-  - To fully utilize the available bandwidth, the sender must keep at least `R × T_prop` bits in the network
-  - Smaller send windows result in underutilized links
-3. Protocol Design:
-  - Determines minimum window size for sliding window protocols
-  - Critical for TCP congestion control and flow control mechanisms
-4. Performance Impact:
-  - High bandwidth-delay product networks (like satellite links) require larger buffers and windows
-  - Affects protocol efficiency and responsiveness
-5. Storage vs. Transmission Trade-off:
-  - Shows the relationship between link capacity and propagation delay
-  - Higher bandwidth or longer delays both increase the "storage" capacity of the network itself
+- It is the amount of unacknowledged data the sender should keep in flight to fully utilize the path
+- Sets a lower bound on TCP window size and buffering needed along the path
+- Large bandwidth-delay products (e.g., satellite or 10G WANs) require proportionally larger windows/buffers to avoid underutilization
 
 ## 2.3 Web Cache Implementation and Performance (20%)
 
 > You have learned that a Web cache can be useful in some cases. In this problem, you will investigate how useful a Web cache can be at a home. First, you need to download Apache server and install and run it as a proxy server on a computer on your home network. Then, write a brief report on what you did to make it work and how you are using it on all your devices on your home network.
 > Assume your family has six members. Each member likes to download short videos from the Internet to watch on their personal devices. All these devices are connected to the Internet through Wi-Fi. Further assume the average object size of each short video is 100 MB and the average request rate from all devices to servers on the Internet is three requests per minute. Five seconds is the average amount of time it takes for the router on the ISP side of your Internet link to forward an HTTP request to a server on the Internet and receive a response.
 >
-> * What is the average time α for your home router to receive a video object from your ISP router?
-> * What is the traffic intensity µ on the Internet link to your home router if none of the requested videos is cached on the proxy server?
-> * If average access delay β is defined as α/(μ−1), what is the average access delay your family members will experience when watching the short videos?
-> * If the total average response time is defined as 5+β, and the miss rate of your proxy server is 0.5, what will be the total average response time?
+> - What is the average time alpha for your home router to receive a video object from your ISP router?
+> - What is the traffic intensity mu on the Internet link to your home router if none of the requested videos is cached on the proxy server?
+> - If average access delay beta is defined as alpha/(mu-1), what is the average access delay your family members will experience when watching the short videos?
+> - If the total average response time is defined as 5+beta, and the miss rate of your proxy server is 0.5, what will be the total average response time?
 
 ### Apache Proxy Server Implementation
 
-I implemented an Apache HTTP proxy server with disk caching capabilities on the home network:
+I implemented an Apache HTTP forward proxy with disk caching capabilities on my home network (config included in this submission):
 
-- Installation: `brew bundle` to install Apache HTTP Server
-- Configuration: Forward proxy with disk caching (see `etc/apache/apache.conf`)
-- Management: Server startup/shutdown scripts in `bin/server` and `bin/client`
-- Network Setup: Server runs on port 8081, family devices configured to use proxy at `192.168.x.x:8081`
-
-The proxy server enables all family video requests to flow through the cache, providing the foundation for the performance analysis below.
+- Installation: Brewfile includes httpd; start via bin/server (httpd -f etc/apache/apache.conf)
+- Configuration: Forward proxy with disk cache (`mod_proxy`, `mod_cache_disk`). Cache root: var/cache/apache2 (see etc/apache/apache.conf)
+- Usage: Devices configured to use proxy at http://<proxy-host>:8081; test with bin/client (curl -x localhost:8081 ...)
 
 ### Performance Analysis
 
 Given parameters:
 
-- 6 family members downloading videos
-- Average object size: 100 MB = 800 Mb per video
-- Average request rate: 3 requests/minute = 0.05 requests/second
-- ISP response time: 5 seconds average
-- Home internet connection: 960 Mbps
-
-### a) Average time (α) for home router to receive video object
-
-Transmission time calculation:
-
-- Video size: 100 MB = 800 Mb
-- Link speed: 960 Mbps (download)
-- Transmission time = 800 Mb ÷ 960 Mbps = 0.833 seconds
-
-```
-Total time (α):
-
-α = ISP processing time + transmission time
-α = 5 seconds + 0.833 seconds = 5.833 seconds
-```
-
-### b) Traffic intensity (μ) without caching
+- Average object size: F = 100 MB = 800 Mb
+- Aggregate request rate across all devices: lambda = 3 requests/min = 0.05 requests/s
+- ISP router request/response overhead (uncached path): 5 s (added later to the access delay)
+- Assumed downlink capacity to home router: R = 100 Mbps (typical plan; used for numeric example)
 
-Traffic calculation:
+Definitions (Kurose & Ross, 2021):
 
-- Request rate (λ): 6 members × 0.05 req/sec = 0.3 requests/second
-- Service time per request: 5.833 seconds (from part a)
-- Service rate (μ): 1/5.833 = 0.171 requests/second
+- alpha: Average time to receive an object over an otherwise idle access link -> alpha = F/R
+- mu (traffic intensity): Fraction of link busy time due to arrivals -> mu = lambda x alpha = lambda F / R (must be < 1 for stability)
+- beta (average access delay on the link): beta = alpha / (1 - mu)
 
-```
-Traffic intensity (ρ):
+a) alpha = F/R = 800 Mb / 100 Mbps = 8 s
+b) mu = lambda x alpha = 0.05 x 8 = 0.40 (stable; mu < 1)
+c) beta = alpha/(1 - mu) = 8 / (1 - 0.40) = 8 / 0.60 = 13.33 s
+d) Total average response time without caching is defined as 5 + beta = 5 + 13.33 = 18.33 s. With miss rate m = 0.5 and assuming cache hits are served locally with negligible delay, the total average response time is:
 
-ρ = λ/μ = 0.3 ÷ 0.171 = 1.75
+- E[T] ~ m x (5 + beta) + (1 - m) x 0 ~ 0.5 x 18.33 = 9.17 s
 
-Note: ρ > 1 indicates system overload - requests arrive faster than they can be served.
-```
+(If we account for a small local cache hit time, say 0.2 s, then E[T] ~ 0.5 x 18.33 + 0.5 x 0.2 ~ 9.27 s.)
 
-### c) Average access delay (β)
+Summary answers:
 
-```
-Given formula: β = α/(μ-λ)
-
-Since μ = 0.171 and λ = 0.3:
-μ - λ = 0.171 - 0.3 = -0.129
-
-System is unstable (ρ > 1), so the traditional queuing formula doesn't apply directly.
-
-For stable analysis, let's assume the system can buffer requests:
-β = 5.833/(0.171 - 0.3) = 5.833/(-0.129) = -45.2 seconds
-
-Since the result is negative, this indicates queue buildup and system instability.
-
-Corrected interpretation: With ρ = 1.75, average delay approaches infinity due to queue buildup.
-```
-
-### d) Total average response time with proxy caching
-
-Given:
-
-- Miss rate: 0.5 (50% cache misses)
-- Hit rate: 0.5 (50% cache hits)
-
-Cache hit scenario:
-
-- Local cache access time: ~0.1 seconds (local disk access)
-- Response time for cache hit: 0.1 seconds
-
-Cache miss scenario:
-
-- Same as no caching: 5.833 seconds
-
-```
-Average response time:
-
-Total response time = (Hit rate × Hit time) + (Miss rate × Miss time)
-= (0.5 × 0.1) + (0.5 × 5.833)
-= 0.05 + 2.917
-= 2.967 seconds
-```
-
-With proxy caching, total average response time = 2.97 seconds
-
-### Summary of Results
-
-**Assignment Question Answers:**
-
-- **a) Average time (α)**: 5.833 seconds for home router to receive video object
-- **b) Traffic intensity (ρ)**: 1.75 (system overload - requests arrive faster than service)
-- **c) Access delay (β)**: System unstable with infinite delays due to ρ > 1
-- **d) Total response time with caching**: 2.97 seconds (50% cache hit rate)
-
-**Web Cache Performance Benefits:**
-
-The analysis demonstrates the critical importance of web caching in home networks:
-
-1. **System Stability**: Without caching, the traffic intensity of 1.75 creates an unstable system where requests queue indefinitely
-2. **Performance Transformation**: A 50% cache hit rate reduces average response time from infinite to 2.97 seconds
-3. **Bandwidth Efficiency**: Caching reduces external bandwidth usage by 50%, alleviating the bottleneck
-4. **User Experience**: Family members experience predictable, reasonable response times instead of system overload
-5. **Modern Internet Reality**: Even with gigabit internet (960 Mbps), the system is still overloaded due to ISP processing delays and request patterns
-
-**Key Insight**: Web caching remains essential even with high-speed internet connections. The bottleneck shifts from pure bandwidth to service capacity and ISP processing time, demonstrating that caching benefits extend beyond just bandwidth limitations.
+- a) alpha = 8.0 s
+- b) mu = 0.40
+- c) beta = 13.33 s
+- d) Total average response time with 50% miss rate ~ 9.17-9.27 s (depending on whether local hit time is considered)
 
 ## 2.4 File Distribution Comparison (10%)
 
-> You have learned that a file can be distributed to peers in either client–server mode or peer-to-peer (P2P) mode (Kurose & Ross, 2021, Section 2.5). Consider distributing a large file of F = 21 GB to N peers. The server has an upload rate of Us = 1 Gbps, and each peer has a download rate of Di = 20 Mbps and an upload rate of U. For N = 10, 100, and 1,000 and U = 300 Kbps, 7000 Kbps, and 2 Mbps, develop a table giving the minimum distribution time for each of the combination of N and U for both client–server distribution and P2P distribution. Comment on the features of client–server distribution and P2P distribution and the differences between the two.
-
-Given parameters:
-
-- File size: F = 21 GB = 21 × 10^9 bytes = 168 × 10^9 bits
-- Server upload rate: U_s = 1 Gbps = 10^9 bps
-- Each peer download rate: D_i = 20 Mbps = 20 × 10^6 bps
-- Each peer upload rate: U = varies (300 Kbps, 7000 Kbps, 2 Mbps)
-
-### Distribution Time Calculations
-
-```
-Client-Server Distribution Time:
-
-  T_cs = max(NF/U_s, F/D_min)
-
-Where D_min = min(D_i) = 20 Mbps for all peers
-
-P2P Distribution Time:
-
-  T_p2p = max(F/U_s, F/D_min, NF/(U_s + ΣU_i))
-```
-
-### Results Table
-
-| N        | U (Kbps) | Client-Server (seconds)    | P2P (seconds)                 |
-| --       | --       | --                         | --                            |
-| N = 10   |          |                            |                               |
-|          | 300      | max(1680, 8400) = 8400     | max(168, 8400, 1512) = 8400   |
-|          | 7000     | max(1680, 8400) = 8400     | max(168, 8400, 151.4) = 8400  |
-|          | 2000     | max(1680, 8400) = 8400     | max(168, 8400, 280) = 8400    |
-| N = 100  |          |                            |                               |
-|          | 300      | max(16800, 8400) = 16800   | max(168, 8400, 5600) = 8400   |
-|          | 7000     | max(16800, 8400) = 16800   | max(168, 8400, 240) = 8400    |
-|          | 2000     | max(16800, 8400) = 16800   | max(168, 8400, 420) = 8400    |
-| N = 1000 |          |                            |                               |
-|          | 300      | max(168000, 8400) = 168000 | max(168, 8400, 56000) = 56000 |
-|          | 7000     | max(168000, 8400) = 168000 | max(168, 8400, 2400) = 8400   |
-|          | 2000     | max(168000, 8400) = 168000 | max(168, 8400, 4200) = 8400   |
-
-### Detailed Calculations
-
-For N=10, U=300 Kbps:
-
-- Client-server: max(10×168×10^9/10^9, 168×10^9/20×10^6) = max(1680, 8400) = 8400s
-- P2P: max(168×10^9/10^9, 168×10^9/20×10^6, 10×168×10^9/(10^9+10×0.3×10^6)) = max(168, 8400, 1512) = 8400s
-
-For N=1000, U=7000 Kbps:
-
-- Client-server: max(1000×168×10^9/10^9, 168×10^9/20×10^6) = max(168000, 8400) = 168000s
-- P2P: max(168, 8400, 1000×168×10^9/(10^9+1000×7×10^6)) = max(168, 8400, 2400) = 8400s
-
-### Client-Server Distribution Features:
-
-Advantages:
-
-- Simple implementation and management
-- Predictable performance
-- Server has complete control over distribution
-- No coordination overhead between peers
+> You have learned that a file can be distributed to peers in either client-server mode or peer-to-peer (P2P) mode (Kurose & Ross, 2021, Section 2.5). Consider distributing a large file of F = 21 GB to N peers. The server has an upload rate of Us = 1 Gbps, and each peer has a download rate of Di = 20 Mbps and an upload rate of U. For N = 10, 100, and 1,000 and U = 300 Kbps, 7000 Kbps, and 2 Mbps, develop a table giving the minimum distribution time for each of the combination of N and U for both client-server distribution and P2P distribution. Comment on the features of client-server distribution and P2P distribution and the differences between the two.
 
-Disadvantages:
+Parameters:
 
-- Server becomes bottleneck as N increases
-- Distribution time grows linearly with number of peers
-- Inefficient use of peer upload capacity
-- Single point of failure
+- File size: F = 21 GB = 168 x 10^9 bits
+- Server upload: `U_s = 1 x 10^9 bps`
+- Each peer download: `D_i = 20 x 10^6 bps`
+- Each peer upload U in {300 Kbps, 7000 Kbps, 2 Mbps} = {0.3, 7, 2} x 10^6 bps
 
-Scaling characteristics: T_cs grows linearly with N when NF/U_s dominates
+Formulas (minimum time, idealized):
 
-### P2P Distribution Features:
+- Client-Server: T_cs = max(NF/U_s, F/D_min), with D_min = 20 Mbps
+- P2P: T_p2p = max(F/U_s, F/D_min, NF/(U_s + Sigma U_i)) with Sigma U_i = N x U
 
-Advantages:
+Compute common terms:
 
-- Utilizes aggregate peer upload capacity
-- More scalable than client-server for large N
-- Distributes load across all participants
-- Self-scaling with more peers
+- F/U_s = 168 s
+- F/D_min = 168 x 10^9 / 20 x 10^6 = 8,400 s
 
-Disadvantages:
+Results:
 
-- Complex protocol implementation
-- Coordination overhead
-- Dependent on peer participation and upload capacity
-- Less predictable performance
+- N = 10
+  - Sigma U_i = 10U; NF = 1.68 x 10^12 bits
+  - NF/(U_s + Sigma U_i):
+    - U = 0.3 Mbps -> denom = 1.003 x 10^9; time ~ 1,676 s
+    - U = 7 Mbps   -> denom = 1.07 x 10^9; time ~ 1,570 s
+    - U = 2 Mbps   -> denom = 1.02 x 10^9; time ~ 1,647 s
+  - T_cs = max(1,680, 8,400) = 8,400 s
+  - T_p2p = max(168, 8,400, 1,570-1,676) = 8,400 s
 
-Scaling characteristics: Better scalability as collective upload capacity grows with N
+- N = 100
+  - Sigma U_i = 100U; NF = 1.68 x 10^13 bits
+  - NF/(U_s + Sigma U_i):
+    - U = 0.3 Mbps -> denom = 1.03 x 10^9; time ~ 16,311 s
+    - U = 7 Mbps   -> denom = 1.7 x 10^9; time ~ 9,882 s
+    - U = 2 Mbps   -> denom = 1.2 x 10^9; time ~ 14,000 s
+  - T_cs = max(16,800, 8,400) = 16,800 s
+  - T_p2p = max(168, 8,400, 9,882-16,311) = {16,311 s, 9,882 s, 14,000 s}
 
-### Key Differences:
+- N = 1,000
+  - Sigma U_i = 1000U; NF = 1.68 x 10^14 bits
+  - NF/(U_s + Sigma U_i):
+    - U = 0.3 Mbps -> denom = 1.3 x 10^9; time ~ 129,231 s
+    - U = 7 Mbps   -> denom = 8.0 x 10^9; time ~ 21,000 s
+    - U = 2 Mbps   -> denom = 3.0 x 10^9; time ~ 56,000 s
+  - T_cs = max(168,000, 8,400) = 168,000 s
+  - T_p2p = max(168, 8,400, 21,000-129,231) = {129,231 s, 21,000 s, 56,000 s}
 
-1. Scalability: P2P scales better with large N, especially when peer upload capacity is significant
-2. Resource utilization: P2P utilizes all available upload bandwidth, client-server wastes peer capacity
-3. Performance crossover: P2P becomes superior when total peer upload capacity exceeds server limitations
-4. Minimum distribution time: P2P bounded by max(F/U_s, F/D_min), client-server bounded by max(NF/U_s, F/D_min)
+Observations and comparison:
 
-Critical insight: P2P effectiveness depends heavily on peer upload rates. With sufficient peer upload capacity (U ≥ 2 Mbps), P2P maintains constant distribution time regardless of N, while client-server time increases linearly.
+- Client-server time grows linearly with N when NF/U_s dominates; the server is the bottleneck and a single point of failure.
+- P2P scales with aggregate peer upload capacity. When N is large and U is substantial (e.g., 7 Mbps), T_p2p can be far smaller than client-server and is bounded by peers' download limit (8,400 s) or the aggregate upload term.
+- For small N (e.g., 10), both approaches are bounded by each peer’s 20 Mbps download (8,400 s). For large N, P2P substantially outperforms client-server if total peer upload (N x U) is large.
 
 # References