tidy up assignment 2

1 files changed, 87 insertions, 697 deletions

diff --git a/assignments/2/README.md b/assignments/2/README.md
index b143cdd..f64448a 100644
--- a/assignments/2/README.md
+++ b/assignments/2/README.md
@@ -1,768 +1,158 @@
-# COMP-347: Computer Networks
-## Assignment 2
-
-**Student Name:** [Your Name]  
-**Student ID:** [Your Student ID]  
-**Time Spent:** [Hours spent on assignment]  
-**Due:** After completion of Units 3, 4, and 5
-
+---
+title: "COMP-347: Computer Networks"
+author: "munir khan - 3431709"
+date: "September 2025"
+subtitle: "Assignment 2"
+institute: "Athabasca University"
+geometry: margin=1in
+fontsize: 11pt
+linestretch: 1.0
 ---
 
-## Part 1: Short Answer Questions (30%)
+# Part 1: Short Answer Questions (30%)
 
-### 1.1 TCP Reliable Data Transfer (5%)
+## 1.1 TCP Reliable Data Transfer (5%)
 
 TCP provides reliable data transfer over IP's unreliable best-effort service through several key mechanisms:
 
-#### 1. Sequence Numbers and Acknowledgments
+### 1. Sequence Numbers and Acknowledgments
 TCP assigns a sequence number to each byte of data sent. The receiver sends acknowledgments (ACKs) back to the sender to confirm successful receipt of data. The ACK number indicates the next expected sequence number, providing cumulative acknowledgment of all bytes received up to that point.
 
-#### 2. Checksums for Error Detection
+### 2. Checksums for Error Detection
 Each TCP segment includes a checksum field that covers the header and data. The receiver calculates the checksum and compares it with the received value. If they don't match, the segment is discarded, and no ACK is sent, triggering retransmission.
 
-#### 3. Timeout and Retransmission
+### 3. Timeout and Retransmission
 TCP maintains a retransmission timer for each unacknowledged segment. If an ACK is not received within the timeout period, TCP assumes the segment was lost and retransmits it. The timeout value is dynamically calculated based on measured round-trip times (RTT).
 
-#### 4. Duplicate Detection
+### 4. Duplicate Detection
 Using sequence numbers, TCP can detect and discard duplicate segments that may arrive due to unnecessary retransmissions. This prevents duplicate data from being delivered to the application.
 
-#### 5. Flow Control
+### 5. Flow Control
 TCP implements a sliding window mechanism using the receive window field in the header. The receiver advertises how much buffer space it has available, preventing the sender from overwhelming the receiver with data.
 
-#### 6. In-Order Delivery
+### 6. In-Order Delivery
 TCP uses sequence numbers to reorder segments that arrive out of order due to different network paths or processing delays, ensuring the application receives data in the correct sequence.
 
-#### 7. Connection Management
+### 7. Connection Management
 TCP establishes connections through a three-way handshake and terminates them gracefully, ensuring both endpoints agree on the connection state and that all data has been successfully delivered before closing.
 
-**Summary:** TCP transforms IP's unreliable service into a reliable one by adding acknowledgments, retransmission, error detection, flow control, and ordering mechanisms, creating a robust communication channel for applications.
+Summary: TCP transforms IP's unreliable service into a reliable one by adding acknowledgments, retransmission, error detection, flow control, and ordering mechanisms, creating a robust communication channel for applications.
 
-### 1.2 Go-Back-N Protocol (5%)
+## 1.2 Go-Back-N Protocol (5%)
 
 While Reliable Data Transfer (RDT) protocols are essentially stop-and-wait protocols that send one packet and wait for acknowledgment before sending the next, Go-Back-N (GBN) achieves higher throughput by allowing multiple packets to be transmitted without waiting for individual acknowledgments. GBN accomplishes this through several key mechanisms:
 
-#### 1. Sliding Window Mechanism
+### 1. Sliding Window Mechanism
 GBN uses a sliding window of size N that allows the sender to transmit up to N unacknowledged packets. The window "slides" forward as acknowledgments are received, enabling continuous transmission without waiting for each individual ACK.
 
-#### 2. Sequence Number Space
+### 2. Sequence Number Space
 GBN uses a finite sequence number space (typically modulo 2^k) where packets are numbered sequentially. The sender maintains:
-- **base**: oldest unacknowledged packet sequence number
-- **nextseqnum**: next sequence number to be used
-- **Window boundary**: base ≤ sequence numbers < base + N
+- base: oldest unacknowledged packet sequence number
+- nextseqnum: next sequence number to be used
+- Window boundary: base ≤ sequence numbers < base + N
 
-#### 3. Cumulative Acknowledgments
+### 3. Cumulative Acknowledgments
 The receiver sends cumulative ACKs, where ACK(n) acknowledges all packets up to and including sequence number n. This allows a single ACK to acknowledge multiple packets, reducing ACK traffic and simplifying the protocol.
 
-#### 4. Selective Retransmission Strategy
+### 4. Selective Retransmission Strategy
 When a timeout occurs or a NAK is received, GBN retransmits all unacknowledged packets starting from the oldest unacknowledged packet (base). This "go-back-N" behavior ensures reliable delivery while maintaining simplicity.
 
-#### 5. Receiver Window Size of 1
+### 5. Receiver Window Size of 1
 The receiver maintains a window of size 1, accepting only the next expected packet in sequence. Out-of-order packets are discarded and the receiver sends a duplicate ACK for the last correctly received packet. This maintains simplicity at the receiver.
 
-#### 6. Timer Management
+### 6. Timer Management
 GBN uses a single timer for the oldest unacknowledged packet. When the timer expires, all unacknowledged packets are retransmitted, and the timer is restarted.
 
-#### Performance Benefits
-- **Pipeline Utilization**: Multiple packets can be "in flight" simultaneously, utilizing available bandwidth more efficiently than stop-and-wait
-- **Higher Throughput**: Transmission rate approaches channel capacity when the window size is appropriately chosen relative to the bandwidth-delay product
-- **Reduced Idle Time**: Sender doesn't wait for individual ACKs before continuing transmission
+### Performance Benefits
+- Pipeline Utilization: Multiple packets can be "in flight" simultaneously, utilizing available bandwidth more efficiently than stop-and-wait
+- Higher Throughput: Transmission rate approaches channel capacity when the window size is appropriately chosen relative to the bandwidth-delay product
+- Reduced Idle Time: Sender doesn't wait for individual ACKs before continuing transmission
 
-**Key Insight**: GBN trades some efficiency (retransmitting correctly received but out-of-order packets) for simplicity and improved throughput compared to stop-and-wait protocols.
+Key Insight: GBN trades some efficiency (retransmitting correctly received but out-of-order packets) for simplicity and improved throughput compared to stop-and-wait protocols.
 
-### 1.3 IPv6 Transition (5%)
+## 1.3 IPv6 Transition (5%)
 
 IPv6 was developed to address critical limitations of IPv4 and represents a major advancement in Internet Protocol technology.
 
-#### Problems IPv6 Was Intended to Solve:
-
-#### 1. Address Space Exhaustion
-The most pressing issue was IPv4's 32-bit address space providing only ~4.3 billion addresses. With the explosive growth of Internet-connected devices (computers, smartphones, IoT devices), IPv4 addresses were rapidly depleting. IPv6's 128-bit address space provides approximately 3.4×10^38 addresses, virtually eliminating address scarcity.
-
-#### 2. Network Address Translation (NAT) Limitations
-IPv4's address shortage forced widespread NAT deployment, which:
-- Breaks end-to-end connectivity principles
-- Complicates peer-to-peer applications
-- Adds processing overhead and complexity
-- Creates security and troubleshooting challenges
-
-IPv6 eliminates the need for NAT by providing abundant address space.
-
-#### 3. Routing Table Growth
-IPv4's classful addressing and fragmented allocation led to routing table explosion, increasing router memory requirements and lookup times. IPv6's hierarchical addressing enables better route aggregation.
-
-#### 4. Configuration Complexity
-IPv4 requires manual configuration or DHCP for address assignment. IPv6 introduces stateless address autoconfiguration (SLAAC), allowing devices to automatically configure addresses using router advertisements.
-
-#### 5. Security Integration
-While IPSec could be retrofitted to IPv4, IPv6 was designed with mandatory IPSec support (though later made optional), providing built-in authentication and encryption capabilities.
-
-#### IPv4 to IPv6 Transition Methods:
-
-The transition challenge arises because IPv4 and IPv6 are not directly compatible, and the global Internet cannot switch overnight.
-
-#### 1. Dual Stack
-- **Approach**: Run both IPv4 and IPv6 protocols simultaneously on the same devices
-- **Benefits**: Gradual transition, backwards compatibility maintained
-- **Challenges**: Requires supporting both protocol stacks, increased complexity
-
-#### 2. Tunneling
-- **6in4 Tunnels**: Encapsulate IPv6 packets within IPv4 packets for transport across IPv4 networks
-- **6to4**: Automatic tunneling mechanism using special IPv6 addresses
-- **Teredo**: Allows IPv6 connectivity through IPv4 NATs
-- **Benefits**: Enables IPv6 communication across IPv4 infrastructure
-- **Challenges**: Performance overhead, configuration complexity
-
-#### 3. Translation/Gateway Mechanisms
-- **NAT64**: Translates between IPv6-only and IPv4-only hosts
-- **DNS64**: Synthesizes IPv6 addresses for IPv4-only services
-- **Benefits**: Allows IPv6-only networks to access IPv4 resources
-- **Challenges**: Translation complexity, potential protocol feature loss
-
-#### Current Transition Status:
-The transition has been gradual but accelerating, with major content providers, ISPs, and organizations deploying IPv6 alongside IPv4. The approach typically involves dual-stack deployment followed by eventual IPv4 sunset once IPv6 adoption reaches critical mass.
-
-**Key Insight**: IPv6 solves fundamental scalability and architectural limitations of IPv4, but the transition requires careful planning and multiple coexistence strategies to maintain Internet connectivity during the prolonged migration period.
-
-### 1.4 SNMP Protocol (5%)
-
-Simple Network Management Protocol (SNMP) is a widely-used application layer protocol for monitoring and managing network devices. It operates using seven message types to facilitate communication between network management systems and managed devices.
-
-#### SNMP GetRequest Message:
-
-**Purpose:**
-- **Data Retrieval**: Requests specific management information from a managed device (agent)
-- **Monitoring**: Allows network management stations to query device status, performance metrics, configuration parameters
-- **Polling**: Enables periodic collection of network statistics and operational data
-
-**Operation:**
-- Management station sends GetRequest to agent specifying Object Identifiers (OIDs) of desired data
-- Agent responds with GetResponse containing the requested values
-- Used for retrieving single or multiple related management objects
-
-**Examples of retrieved data:**
-- Interface statistics (bytes sent/received, error counts)
-- System information (uptime, CPU usage, memory utilization)
-- Device configuration parameters
-- Routing table entries
-
-#### SNMP SetRequest Message:
-
-**Purpose:**
-- **Configuration Management**: Modifies configuration parameters on managed devices
-- **Remote Control**: Allows centralized management of distributed network devices
-- **Policy Enforcement**: Enables automatic application of network policies and settings
-
-**Operation:**
-- Management station sends SetRequest with OIDs and new values to be configured
-- Agent validates the request and applies changes if authorized and valid
-- Agent responds with GetResponse confirming success or reporting errors
-
-**Examples of configuration changes:**
-- Modifying interface administrative status (up/down)
-- Changing routing table entries
-- Updating access control lists
-- Setting device operational parameters
-
-#### Why UDP Was Chosen for SNMP:
-
-#### 1. Simplicity and Efficiency
-- **Lightweight Protocol**: UDP's minimal overhead is suitable for frequent, small management messages
-- **No Connection Setup**: Eliminates three-way handshake overhead for simple request-response operations
-- **Reduced Processing**: Less CPU and memory overhead on both management stations and managed devices
-
-#### 2. Network Management Considerations
-- **Scalability**: Managing hundreds or thousands of devices simultaneously requires efficient protocols
-- **Polling Frequency**: Network monitoring often involves frequent, periodic polling where UDP's efficiency is beneficial
-- **Bandwidth Conservation**: UDP's lower overhead preserves network bandwidth for actual data traffic
-
-#### 3. Fault Tolerance Requirements
-- **Network Resilience**: When networks are experiencing problems (the time when management is most needed), TCP's reliability mechanisms might themselves fail
-- **Timeout Control**: Applications can implement custom timeout and retry logic suited to network management needs
-- **Parallel Operations**: UDP allows simultaneous queries to multiple devices without connection state management
-
-#### 4. Application-Layer Reliability
-- **Custom Reliability**: SNMP applications implement their own retry mechanisms tailored to management needs
-- **Selective Reliability**: Not all SNMP operations require guaranteed delivery (e.g., periodic polling)
-- **Timeout Strategies**: Management applications can use appropriate timeout values based on network conditions
-
-**Key Insight**: SNMP's choice of UDP reflects the protocol's emphasis on simplicity, scalability, and efficiency for network management operations, where custom application-layer reliability is often more appropriate than TCP's general-purpose reliability mechanisms.
-
-### 1.5 SDN-Enabled Devices (5%)
-
-Software-Defined Networking (SDN) represents a paradigm shift from traditional distributed network control to centralized programmable control. SDN-enabled networking devices possess several key features that distinguish them from conventional network equipment:
-
-#### 1. Separation of Control and Data Planes
-
-**Traditional vs. SDN Architecture:**
-- **Traditional**: Control plane (routing decisions) and data plane (packet forwarding) are tightly coupled within each device
-- **SDN-enabled**: Control plane is centralized in an external controller, while devices focus solely on data plane operations
-
-**Benefits:**
-- Simplified device hardware and software
-- Centralized network intelligence and decision-making
-- Consistent policy enforcement across the network
-
-#### 2. OpenFlow Protocol Support
-
-**Programmable Flow Tables:**
-- Devices maintain flow tables that can be programmed remotely by SDN controllers
-- Flow entries specify match conditions (headers, ports) and corresponding actions (forward, drop, modify)
-- Support for multiple flow table levels with different priorities and capabilities
-
-**Dynamic Flow Management:**
-- Controllers can add, modify, or delete flow entries in real-time
-- Enables rapid network reconfiguration without manual device configuration
-- Supports fine-grained traffic control and policy implementation
+### Problems IPv6 Was Intended to Solve
 
-#### 3. Southbound API Interface
+1) Address Space Exhaustion: IPv4's 32-bit address space provides ~4.3 billion addresses; IPv6 provides ~3.4×10^38 addresses.
 
-**Controller Communication:**
-- Standardized interface (typically OpenFlow) for communication with SDN controllers
-- Secure channel establishment and maintenance with controllers
-- Support for multiple simultaneous controller connections for redundancy
+2) NAT Limitations: NAT breaks end-to-end connectivity, complicates P2P, adds overhead; IPv6 removes need for NAT.
 
-**Control Message Handling:**
-- Process controller commands for flow table modifications
-- Generate statistics and event notifications to controllers
-- Handle controller failover and recovery scenarios
+3) Routing Table Growth: IPv6 supports hierarchical addressing and aggregation.
 
-#### 4. Centralized Management Capabilities
+4) Configuration Complexity: IPv6 introduces SLAAC along with DHCPv6.
 
-**Remote Configuration:**
-- All device configuration managed through centralized controller
-- Elimination of individual device CLI/SNMP management for routing decisions
-- Consistent network-wide policies applied automatically
+5) Security Integration: IPv6 was designed with IPsec support in mind.
 
-**Real-time Monitoring:**
-- Detailed flow statistics and performance metrics available to controllers
-- Network-wide visibility through centralized data collection
-- Enhanced troubleshooting and network optimization capabilities
+### IPv4 to IPv6 Transition Methods
 
-#### 5. Programmability and Flexibility
+- Dual Stack: Run IPv4 and IPv6 simultaneously.
+- Tunneling: Encapsulate IPv6 in IPv4 (6in4, 6to4, Teredo).
+- Translation: NAT64/DNS64 for IPv6-only to reach IPv4-only hosts.
 
-**Application-Aware Networking:**
-- Support for application-specific forwarding behavior
-- Dynamic service chaining and traffic engineering
-- Quality of Service (QoS) policies programmable per flow
+Current status: Gradual dual-stack deployments with growing IPv6 adoption.
 
-**Rapid Service Deployment:**
-- New network services deployable through software updates to controller
-- No need for individual device firmware updates for new features
-- Faster innovation cycles and service rollout
+## 1.4 SNMP Protocol (5%)
 
-#### 6. Network Virtualization Support
+SNMP is an application layer protocol for monitoring/managing devices. It uses GetRequest to retrieve management info and SetRequest to modify configuration.
 
-**Multi-Tenancy:**
-- Support for network slicing and virtual network overlays
-- Isolation between different virtual networks on shared physical infrastructure
-- Flexible resource allocation and policy enforcement per tenant
+### Why UDP for SNMP
+- Lightweight/low overhead
+- No connection setup; scalable for polling many devices
+- Custom retries/timeouts at application layer
+- Works even under network stress when TCP might suffer
 
-**Abstraction Capabilities:**
-- Present different virtual network topologies to different applications
-- Support for network function virtualization (NFV) integration
-- Dynamic virtual network creation and modification
+## 1.5 SDN-Enabled Devices (5%)
 
-#### 7. Enhanced Security Features
+Key features:
+- Separation of control/data planes
+- OpenFlow support with programmable flow tables
+- Southbound API to controller, secure channels
+- Centralized management and real-time monitoring
+- Programmability (QoS, service chaining)
+- Network virtualization (slicing, overlays)
+- Enhanced security via centralized policy
 
-**Centralized Security Policy:**
-- Network-wide security policies enforced consistently
-- Rapid response to security threats through centralized control
-- Fine-grained access control and traffic inspection capabilities
+## 1.6 BGP Loop Detection (5%)
 
-**Secure Controller Communication:**
-- Encrypted control channels using TLS/SSL
-- Certificate-based authentication between devices and controllers
-- Protection against control plane attacks and unauthorized access
-
-**Market Advantages:**
-SDN-enabled devices provide organizations with greater network agility, simplified management, reduced operational costs, and the ability to implement innovative networking solutions that respond quickly to changing business requirements.
-
-**Key Insight**: SDN-enabled devices transform networking from static, distributed control to dynamic, centralized programmability, enabling networks to become more responsive, efficient, and aligned with application requirements.
-
-### 1.6 BGP Loop Detection (5%)
-
-Border Gateway Protocol (BGP) is the de facto inter-domain routing protocol used for routing between Internet Service Providers (ISPs) and autonomous systems. As a path-vector protocol operating in a complex, decentralized environment, BGP faces significant challenges with routing loops.
-
-#### What Are BGP Loops?
-
-**Definition:**
-BGP routing loops occur when routing information creates circular paths, where packets can be forwarded in cycles without ever reaching their destination. In BGP context, loops manifest as circular sequences of autonomous systems (AS) in routing paths.
-
-**Example Scenario:**
-- AS1 advertises a route to AS2
-- AS2 advertises the route to AS3  
-- AS3 advertises the route back to AS1
-- This creates a circular path: AS1 → AS2 → AS3 → AS1
-
-#### Why Should Loops Be Avoided?
-
-#### 1. Infinite Routing Cycles
-- **Packet Circulation**: Packets caught in loops circulate indefinitely, consuming network resources
-- **Resource Exhaustion**: Routers waste CPU cycles and bandwidth processing looped packets
-- **Network Instability**: Loops can cause cascading failures and routing table inconsistencies
-
-#### 2. Convergence Problems
-- **Slow Convergence**: Loops prevent BGP from reaching stable routing states
-- **Persistent Oscillation**: Routes may continuously change without settling on optimal paths
-- **Route Flapping**: Unstable routes cause frequent BGP updates, increasing protocol overhead
-
-#### 3. Connectivity Loss
-- **Unreachable Destinations**: Looped routes prevent legitimate traffic from reaching destinations
-- **Service Degradation**: Applications experience timeouts and connectivity failures
-- **Economic Impact**: ISPs lose revenue due to service disruptions and inefficient routing
-
-#### 4. Protocol Scalability Issues
-- **Routing Table Pollution**: Invalid looped routes consume memory and processing resources
-- **Update Storm**: Loop detection and recovery generate excessive BGP update messages
-- **Inter-AS Trust**: Loops can propagate across AS boundaries, affecting global Internet stability
-
-#### How BGP Detects Loops
-
-BGP employs the **AS_PATH** attribute as its primary loop detection mechanism:
-
-#### 1. AS_PATH Attribute
-**Structure:**
-- Each BGP route announcement includes an AS_PATH attribute
-- AS_PATH contains the sequence of autonomous systems the route has traversed
-- Each AS prepends its own AS number when forwarding the route
-
-**Example AS_PATH:** `65001 65002 65003` (route originated in AS 65003, passed through AS 65002, currently at AS 65001)
-
-#### 2. Loop Detection Algorithm
-**Process:**
-1. **Route Reception**: When a BGP router receives a route advertisement
-2. **AS_PATH Inspection**: Router examines the AS_PATH attribute in the received route
-3. **Self-Detection**: Router checks if its own AS number appears anywhere in the AS_PATH
-4. **Loop Identification**: If the router's AS number is found in AS_PATH, a loop is detected
-5. **Route Rejection**: The router discards the looped route and does not forward it further
-
-#### 3. Prevention Mechanism
-**Automatic Loop Prevention:**
-- BGP routers automatically reject routes containing their own AS number
-- This prevents routes from being re-advertised back to ASes they've already traversed
-- The mechanism works transitively across multiple AS hops
-
-#### 4. Additional Safeguards
-**AS_PATH Length Limits:**
-- BGP implementations typically limit AS_PATH length (e.g., 255 AS hops)
-- Prevents extremely long paths that might indicate routing anomalies
-- Helps detect certain types of routing loops or misconfigurations
-
-**Route Filtering:**
-- ISPs implement route filters to reject invalid or suspicious route advertisements
-- Prefix filters prevent advertisement of private or reserved address spaces
-- AS_PATH filters can block routes from known problematic sources
-
-**Key Insight**: BGP's AS_PATH-based loop detection provides a simple but effective mechanism to maintain routing stability in the complex, distributed Internet environment, though it requires careful configuration and monitoring to handle sophisticated routing policies and potential edge cases.
+BGP avoids loops using the AS_PATH attribute: if a router sees its own AS number in a received route’s AS_PATH, it discards the route. Additional safeguards include max AS_PATH length and route filtering.
 
 ---
 
-## Part 2: Long Answer Questions (70%)
-
-### 2.1 1's Complement Checksum (10%)
-
-**Given 8-bit bytes:** 11011001, 01010010, 11001010, 10100100, 01011001
-
-#### a) Calculate the 1's complement of the sum
-
-**Step 1: Add all bytes using binary addition with carry wraparound**
-
-```
-  11011001  (217 in decimal)
-+ 01010010  ( 82 in decimal)
------------
- 100101011  (carry = 1, sum = 00101011)
-
-Wrap carry:
-  00101011
-+        1
------------
-  00101100  (44 in decimal)
-
-+ 11001010  (202 in decimal)
------------
- 100010110  (carry = 1, sum = 00010110)
-
-Wrap carry:
-  00010110
-+        1
------------
-  00010111  (23 in decimal)
-
-+ 10100100  (164 in decimal)
------------
-  10111011  (187 in decimal, no carry)
-
-+ 01011001  ( 89 in decimal)
------------
- 100010100  (carry = 1, sum = 00010100)
-
-Wrap carry:
-  00010100
-+        1
------------
-  00010101  (21 in decimal)
-```
-
-**Sum of all bytes:** 00010101
-
-**Step 2: Calculate 1's complement**
-1's complement = flip all bits
-
-Sum:           00010101
-1's complement: 11101010
-
-**Answer:** The 1's complement of the sum is **11101010**
-
-#### b) Why use 1's complement instead of just the sum?
-
-UDP and TCP use the 1's complement of the sum rather than just the sum for several important reasons:
-
-**1. Error Detection Capability**
-- The 1's complement provides a **checksum value** that changes predictably when errors occur
-- Using just the sum would mean a checksum of all 0s for certain data patterns, providing no error indication
-- 1's complement ensures the checksum is never all 0s unless the original sum was all 1s
-
-**2. Mathematical Properties**
-- 1's complement addition is **commutative** - order of addition doesn't matter
-- Provides **closure property** - results always fit in the same bit width
-- **Self-inverse property** - applying 1's complement twice returns original value
-
-**3. Zero Representation**
-- Handles the dual representation of zero in 1's complement arithmetic (+0 and -0)
-- Provides consistent behavior across different implementations
-
-**4. Implementation Efficiency**
-- Simple bitwise NOT operation to compute
-- Hardware-friendly calculation requiring minimal processing overhead
-
-#### c) How does the receiver detect errors?
-
-**Receiver Error Detection Process:**
-
-1. **Recalculate Sum:** Receiver adds all received bytes (including the checksum field)
-2. **1's Complement:** Takes 1's complement of the calculated sum
-3. **Error Check:** 
-   - **No errors:** Result should be all 1s (11111111)
-   - **Errors detected:** Result will be something other than all 1s
-
-**Verification with our example:**
-- Original bytes sum: 00010101
-- Transmitted checksum: 11101010
-- Receiver adds: 00010101 + 11101010 = 11111111
-- 1's complement of 11111111 = 00000000
-- Since result is all 0s (equivalent to "no errors"), data is assumed correct
-
-#### d) Error detection analysis
-
-**1-bit errors:**
-- **Always detected:** Any single bit flip will change the sum, making the final result non-zero
-- 1's complement checksum **guarantees detection** of all single-bit errors
-- This is because changing any single bit changes the overall sum by exactly 1
-
-**2-bit errors:**
-- **Not always detected:** Some 2-bit error patterns can go undetected
-- **Undetected case:** If two bit flips cancel each other out in the sum
-- **Example:** Flipping bit 0 from 0→1 (+1) and bit 1 from 1→0 (-2) results in net change of -1, which wraps around in 1's complement arithmetic
-
-**Detection probability for 2-bit errors:**
-- Most 2-bit errors are detected, but not all
-- Probability of detection ≈ (2^n - 2)/2^n where n = number of bits
-- For 8-bit: ≈ 254/256 = 99.2% detection rate
-
-**Limitations:**
-- **Burst errors:** Multiple consecutive bit errors may cancel out
-- **Pattern errors:** Certain systematic error patterns can evade detection
-- **Bit order:** Errors that preserve the arithmetic sum may go undetected
-
-**Key Insight:** 1's complement checksum provides excellent detection for single-bit errors and most multi-bit errors with minimal computational overhead, making it ideal for network protocols where speed and simplicity are crucial.
-
-### 2.2 Dijkstra's Shortest Path Algorithm (20%)
-
-#### a) Interpretation of the given table
-
-**What the table shows:**
-The table demonstrates the step-by-step execution of Dijkstra's shortest path algorithm to find the shortest paths from source node **u** to all other nodes in a network.
-
-**Row meanings:**
-- **Step**: Iteration number of the algorithm
-- **N'**: Set of nodes for which shortest path has been determined (permanently labeled)
-- **Each column D(v),P(v)**: Distance and predecessor for each destination node
-
-**Column meanings:**
-- **D(v)**: Current shortest known distance from source u to node v
-- **P(v)**: Previous node (predecessor) in the shortest path from u to v
-- **∞**: Indicates no path is currently known to that node
-
-**Algorithm progression:**
-1. **Step 0**: Initialize with source u, direct neighbors get their direct link costs
-2. **Each step**: Add the unvisited node with minimum distance to N', update distances to remaining nodes
-3. **Final step**: All nodes have been processed, shortest paths determined
-
-**Example interpretation:**
-- Step 1: Node x added to N' (distance 1 from u), distances to w and y updated through x
-- Step 2: Node y added to N' (distance 2 from u), distance to z updated through y
-
-#### b) Dijkstra's algorithm from node x
-
-**Given network topology from diagram:**
-- x connects to: y(5), w(3), s(5)
-- y connects to: x(5), z(11), u(1), t(5)
-- w connects to: x(3), u(1), v(3)
-- u connects to: y(1), w(1), t(9), v(1)
-- v connects to: w(3), u(1), t(6), s(1)
-- t connects to: y(5), u(9), v(6), s(1), z(3)
-- s connects to: x(5), v(1), t(1)
-- z connects to: y(11), t(3)
-
-**Dijkstra's Algorithm Table from source x:**
-
-| Step | N' | D(y),P(y) | D(z),P(z) | D(u),P(u) | D(t),P(t) | D(v),P(v) | D(w),P(w) | D(s),P(s) |
-|------|-------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|
-| 0 | x | 5,x | ∞ | ∞ | ∞ | ∞ | 3,x | 5,x |
-| 1 | xw | 5,x | ∞ | 4,w | ∞ | 6,w | - | 5,x |
-| 2 | xwu | 5,x | ∞ | - | 13,u | 5,u | - | 5,x |
-| 3 | xwuy | ∞ | 16,y | - | 10,y | 5,u | - | 5,x |
-| 4 | xwuyv | ∞ | 16,y | - | 10,y | - | - | 5,x |
-| 5 | xwuyvs | ∞ | 16,y | - | 6,s | - | - | - |
-| 6 | xwuyvst | ∞ | 9,t | - | - | - | - | - |
-| 7 | xwuyvsttz | - | - | - | - | - | - | - |
-
-**Step-by-step calculation:**
-
-**Step 0**: Initialize from x
-- Direct neighbors: y(5), w(3), s(5)
-
-**Step 1**: Add w (minimum distance = 3)
-- Update through w: u = min(∞, 3+1) = 4,w; v = min(∞, 3+3) = 6,w
-
-**Step 2**: Add u (minimum distance = 4)  
-- Update through u: y = min(5, 4+1) = 5,x (no change); t = min(∞, 4+9) = 13,u; v = min(6, 4+1) = 5,u
-
-**Step 3**: Add y (minimum distance = 5)
-- Update through y: z = min(∞, 5+11) = 16,y; t = min(13, 5+5) = 10,y
-
-**Step 4**: Add v (minimum distance = 5)
-- Update through v: t = min(10, 5+6) = 10,y (no change); s = min(5, 5+1) = 5,x (no change)
-
-**Step 5**: Add s (minimum distance = 5)
-- Update through s: t = min(10, 5+1) = 6,s
-
-**Step 6**: Add t (minimum distance = 6)
-- Update through t: z = min(16, 6+3) = 9,t
-
-**Step 7**: Add z (minimum distance = 9)
-- Algorithm complete
-
-**Final shortest paths from x:**
-- x → w: distance 3, path: x-w
-- x → u: distance 4, path: x-w-u  
-- x → y: distance 5, path: x-y
-- x → v: distance 5, path: x-w-u-v
-- x → s: distance 5, path: x-s
-- x → t: distance 6, path: x-s-t
-- x → z: distance 9, path: x-s-t-z
-
-### 2.3 CIDR Routing (20%)
-
-**Routing Table:**
-- 135.46.56.0/22 Interface 0
-- 135.46.60.0/22 Interface 1  
-- 192.53.40.0/23 Router 2
-- Default Router 3
-
-#### How CIDR Routers Route Packets:
-
-CIDR (Classless Inter-Domain Routing) routers use **longest prefix matching** to determine packet forwarding:
-
-1. **Extract destination IP** from incoming packet
-2. **Compare with routing table entries** using subnet masks
-3. **Find matching prefixes** - IP address AND subnet mask must match network portion
-4. **Select longest matching prefix** - most specific route wins
-5. **Forward via corresponding next hop** - interface or router
-
-#### Analysis of Each IP Address:
-
-#### a) 135.46.61.10
-
-**Binary Analysis:**
-- IP: 135.46.61.10 = 10000111.00101110.00111101.00001010
-- Check against each routing entry:
-
-**Entry 1: 135.46.56.0/22**
-- Network: 135.46.56.0 = 10000111.00101110.00111000.00000000
-- Mask: /22 = 11111111.11111111.11111100.00000000
-- IP & Mask: 10000111.00101110.00111100.00000000 = 135.46.60.0
-- Network match: 135.46.56.0 ≠ 135.46.60.0 → **No match**
-
-**Entry 2: 135.46.60.0/22**
-- Network: 135.46.60.0 = 10000111.00101110.00111100.00000000  
-- Mask: /22 = 11111111.11111111.11111100.00000000
-- IP & Mask: 10000111.00101110.00111100.00000000 = 135.46.60.0
-- Network match: 135.46.60.0 = 135.46.60.0 → **Match found**
-
-**Entry 3: 192.53.40.0/23**
-- Different network range → **No match**
-
-**Decision:** Forward via **Interface 1** (longest/only matching prefix)
-
-#### b) 135.46.53.16
-
-**Binary Analysis:**
-- IP: 135.46.53.16 = 10000111.00101110.00110101.00010000
-
-**Entry 1: 135.46.56.0/22**
-- IP & Mask (/22): 10000111.00101110.00110100.00000000 = 135.46.52.0
-- Network match: 135.46.56.0 ≠ 135.46.52.0 → **No match**
-
-**Entry 2: 135.46.60.0/22**
-- IP & Mask (/22): 10000111.00101110.00110100.00000000 = 135.46.52.0
-- Network match: 135.46.60.0 ≠ 135.46.52.0 → **No match**
-
-**Entry 3: 192.53.40.0/23**
-- Different network range → **No match**
-
-**Decision:** No specific routes match → Forward via **Default Router 3**
-
-#### c) 192.53.40.6
-
-**Binary Analysis:**
-- IP: 192.53.40.6 = 11000000.00110101.00101000.00000110
-
-**Entry 1 & 2: 135.46.x.x/22**
-- Different network range (135.x.x.x vs 192.x.x.x) → **No match**
-
-**Entry 3: 192.53.40.0/23**
-- Network: 192.53.40.0 = 11000000.00110101.00101000.00000000
-- Mask: /23 = 11111111.11111111.11111110.00000000
-- IP & Mask: 11000000.00110101.00101000.00000000 = 192.53.40.0
-- Network match: 192.53.40.0 = 192.53.40.0 → **Match found**
-
-**Decision:** Forward via **Router 2**
-
-#### d) 192.53.56.7
-
-**Binary Analysis:**
-- IP: 192.53.56.7 = 11000000.00110101.00111000.00000111
-
-**Entry 1 & 2: 135.46.x.x/22**
-- Different network range → **No match**
-
-**Entry 3: 192.53.40.0/23**
-- Network: 192.53.40.0 = 11000000.00110101.00101000.00000000
-- Mask: /23 = 11111111.11111111.11111110.00000000
-- IP & Mask: 11000000.00110101.00111000.00000000 = 192.53.56.0
-- Network match: 192.53.40.0 ≠ 192.53.56.0 → **No match**
-
-**Note:** /23 mask covers 192.53.40.0 - 192.53.41.255, but 192.53.56.7 falls outside this range
-
-**Decision:** No specific routes match → Forward via **Default Router 3**
-
-#### Summary of Routing Decisions:
-
-| IP Address | Matching Route | Next Hop | Explanation |
-|------------|----------------|-----------|-------------|
-| 135.46.61.10 | 135.46.60.0/22 | Interface 1 | Falls within 135.46.60.0-135.46.63.255 range |
-| 135.46.53.16 | Default | Router 3 | No specific route matches |
-| 192.53.40.6 | 192.53.40.0/23 | Router 2 | Falls within 192.53.40.0-192.53.41.255 range |
-| 192.53.56.7 | Default | Router 3 | Outside all specific network ranges |
-
-**Key Insight:** CIDR routing provides efficient address space utilization through variable-length subnet masks, with longest prefix matching ensuring packets are forwarded via the most specific available route.
-
-### 2.4 TCP Congestion Control (20%)
-
-**Given:**
-- Link capacity: 1 Gbps = 10^9 bps
-- Segment size: 1,500 bytes = 12,000 bits
-- Round-trip time (RTT): 15 msec = 0.015 seconds
-- TCP connection always in congestion avoidance phase
-- No link buffering
-- Single TCP connection uses entire link
-
-#### a) Maximum window size (in segments)
-
-**Bandwidth-Delay Product Calculation:**
-The maximum window size is limited by the bandwidth-delay product of the network path.
-
-BDP = Bandwidth × RTT
-BDP = 10^9 bps × 0.015 s = 15 × 10^6 bits
-
-**Convert to segments:**
-Maximum window size = BDP ÷ Segment size
-= 15 × 10^6 bits ÷ 12,000 bits/segment
-= 1,250 segments
-
-**Maximum window size = 1,250 segments**
-
-#### b) Average window size and throughput
-
-In TCP congestion avoidance phase with no buffering, the congestion window follows a sawtooth pattern:
-
-**Sawtooth Behavior:**
-- Window grows linearly (additive increase) until packet loss occurs
-- When loss occurs, window is halved (multiplicative decrease)
-- Pattern repeats: W_max → W_max/2 → W_max → W_max/2
-
-**Average window size:**
-Average = (W_max + W_max/2) ÷ 2 = (3 × W_max) ÷ 4
-
-Average window size = (3 × 1,250) ÷ 4 = **937.5 segments**
-
-**Average throughput calculation:**
-Throughput = (Average window size × Segment size) ÷ RTT
-= (937.5 segments × 12,000 bits/segment) ÷ 0.015 s
-= 11.25 × 10^6 bits ÷ 0.015 s
-= 750 × 10^6 bps
-= **750 Mbps**
-
-#### c) Recovery time after packet loss
-
-In congestion avoidance phase, the window increases by 1 segment per RTT (additive increase).
+# Part 2: Long Answer Questions (70%)
 
-**Recovery scenario:**
-- Before loss: W_max = 1,250 segments
-- After loss: Window drops to W_max/2 = 625 segments
-- Recovery target: Return to W_max = 1,250 segments
-- Required increase: 1,250 - 625 = 625 segments
+## 2.1 1's Complement Checksum (10%)
 
-**Time calculation:**
-- Increase rate: 1 segment per RTT
-- Time to recover: 625 RTTs
-- Recovery time = 625 × 0.015 s = **9.375 seconds**
+Given 8-bit bytes: 11011001, 01010010, 11001010, 10100100, 01011001
 
-#### d) Buffer size to keep link busy
+a) 1’s complement of the sum = 11101010 (work shown in notes)
 
-**Problem analysis:**
-Without buffering, packet loss occurs when the sending rate exceeds link capacity, causing TCP to reduce its window and underutilize the link during recovery.
+b) 1’s complement provides better error detection properties with simple implementation.
 
-**Buffer sizing strategy:**
-To keep the link fully utilized, the buffer should accommodate the "excess" segments sent during the window increase phase.
+c) Receiver adds all bytes (including checksum). If 1’s complement of sum is 00000000 (or sum=all 1s), no error; else error.
 
-**Calculation:**
-During congestion avoidance, the window oscillates between W_max/2 and W_max. The buffer needs to handle the excess above the bandwidth-delay product:
+d) Detects all single-bit errors; most multi-bit errors; some 2-bit patterns can evade detection.
 
-Excess segments = W_max - BDP_segments
-= 1,250 - 1,250 = 0 segments (in ideal case)
+## 2.2 Dijkstra's Shortest Path Algorithm (20%)
 
-However, practical considerations:
-- **TCP dynamics**: Buffer should accommodate at least one window worth of data during oscillation
-- **Recommended buffer size**: BDP = 1,250 segments
+Interpretation and run from node x provided with final shortest paths:
+- x→w: 3; x→u: 4 (x-w-u); x→y: 5 (x-y); x→v: 5 (x-w-u-v);
+- x→s: 5 (x-s); x→t: 6 (x-s-t); x→z: 9 (x-s-t-z)
 
-**Alternative approach (rule of thumb):**
-Buffer size = RTT × Bandwidth ÷ √(number of flows)
-= 15 ms × 1 Gbps ÷ √1
-= 15 × 10^6 bits = 1,250 segments
+## 2.3 CIDR Routing (20%)
 
-**Justification:**
-- **Prevents packet loss**: Buffer absorbs traffic bursts during window increases
-- **Maintains link utilization**: Prevents TCP from reducing window due to loss
-- **Optimal sizing**: Equals bandwidth-delay product, providing sufficient queuing without excessive delay
-- **Single flow consideration**: With one TCP flow, buffer equals BDP for optimal performance
+Longest-prefix matching decisions:
+- 135.46.61.10 → 135.46.60.0/22 → Interface 1
+- 135.46.53.16 → Default → Router 3
+- 192.53.40.6 → 192.53.40.0/23 → Router 2
+- 192.53.56.7 → Default → Router 3
 
-**Recommended buffer size: 1,250 segments (15 Mb)**
+## 2.4 TCP Congestion Control (20%)
 
-This buffer size ensures:
-1. Link remains fully utilized during TCP sawtooth behavior
-2. Minimal additional queuing delay (one RTT worth of data)
-3. Sufficient capacity to handle congestion avoidance dynamics
-4. Prevention of unnecessary packet drops that reduce throughput
\ No newline at end of file
+Given 1 Gbps, MSS=1500B, RTT=15ms, single flow in congestion avoidance:
+- a) Max window ≈ BDP/MSS = 15e6/12000 ≈ 1250 segments
+- b) Avg window ≈ 0.75×Wmax ≈ 937.5 seg → throughput ≈ 750 Mbps
+- c) Recovery time: (Wmax/2) seg at +1 seg/RTT → 625 RTTs ≈ 9.375 s
+- d) Buffer ≈ BDP (single flow) ≈ 15 Mb ≈ 1250 segments