summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authormo khan <mo@mokhan.ca>2025-09-27 23:55:34 -0600
committermo khan <mo@mokhan.ca>2025-09-27 23:55:34 -0600
commit68fa55d27afc8117ba59d8307f0399ae61a137bf (patch)
tree090a40d3690ab2059c3b301f4672ec25b9738de0
parentd222003664789f61fcf2b079764765a68e5be5db (diff)
Update assignment 2
-rw-r--r--assignments/2/README.md26
1 files changed, 13 insertions, 13 deletions
diff --git a/assignments/2/README.md b/assignments/2/README.md
index 255fc76..6884c34 100644
--- a/assignments/2/README.md
+++ b/assignments/2/README.md
@@ -61,7 +61,7 @@ Preferable features:
> (5%) BGP is a routing protocol used for routing among ISPs. One problem that BGP faces is detecting loops in paths. What are the loops? Why should loops be avoided? How does BGP detect the loops in paths?
-- Loops: Paths that revisit the same AS/router (e.g., A→B→C→B→...).
+- Loops: Paths that revisit the same AS/router (e.g., A->B->C->B->...).
- Avoidance: Loops waste bandwidth, add delay, and cause instability.
- Detection: AS_PATH attribute lists traversed ASes; if a received route’s AS_PATH contains the local AS, discard it. Policies/filters and max-path-length provide additional safeguards.
@@ -110,16 +110,16 @@ b) Apply Dijkstra from source x (see figure). The following table shows the iter
| Step | N’ | D(s),P(s) | D(t),P(t) | D(u),P(u) | D(v),P(v) | D(w),P(w) | D(y),P(y) | D(z),P(z) |
|:----:|:----------------|:----------|:----------|:----------|:----------|:----------|:----------|:----------|
-| 0 | {x} | 5,x | ∞ | ∞ | ∞ | 3,x | 5,x | ∞ |
-| 1 | {x,w} | 5,x | ∞ | 4,w | ∞ | 3,x | 5,x | ∞ |
-| 2 | {x,w,u} | 5,x | ∞ | 4,w | 5,u | 3,x | 5,x | ∞ |
-| 3 | {x,w,u,s} | 5,x | 6,s | 4,w | 5,u | 3,x | 5,x | ∞ |
-| 4 | {x,w,u,s,v} | 5,x | 6,s | 4,w | 5,u | 3,x | 5,x | ∞ |
-| 5 | {x,w,u,s,v,y} | 5,x | 6,s | 4,w | 5,u | 3,x | 5,x | ∞ |
+| 0 | {x} | 5,x | $\infty$ | $\infty$ | $\infty$ | 3,x | 5,x | $\infty$ |
+| 1 | {x,w} | 5,x | $\infty$ | 4,w | $\infty$ | 3,x | 5,x | $\infty$ |
+| 2 | {x,w,u} | 5,x | $\infty$ | 4,w | 5,u | 3,x | 5,x | $\infty$ |
+| 3 | {x,w,u,s} | 5,x | 6,s | 4,w | 5,u | 3,x | 5,x | $\infty$ |
+| 4 | {x,w,u,s,v} | 5,x | 6,s | 4,w | 5,u | 3,x | 5,x | $\infty$ |
+| 5 | {x,w,u,s,v,y} | 5,x | 6,s | 4,w | 5,u | 3,x | 5,x | $\infty$ |
| 6 | {x,w,u,s,v,y,t} | 5,x | 6,s | 4,w | 5,u | 3,x | 5,x | 9,t |
| 7 | {x,w,u,s,v,y,t,z}| 5,x | 6,s | 4,w | 5,u | 3,x | 5,x | 9,t |
-Final shortest-path costs from x: w=3; u=4 (x→w→u); s=5 (x→s); y=5 (x→y); v=5 (x→w→u→v); t=6 (x→s→t); z=9 (x→s→t→z).
+Final shortest-path costs from x: w=3; u=4 (x->w->u); s=5 (x->s); y=5 (x->y); v=5 (x->w->u->v); t=6 (x->s->t); z=9 (x->s->t->z).
## 2.3 CIDR Routing (20%)
@@ -155,17 +155,17 @@ Decisions:
Given: Single TCP flow over a 1 Gbps link, no buffering at the link; MSS=1500 B (12,000 bits); two-way propagation delay (RTT) ≈ 15 ms; always in congestion avoidance.
a) Maximum window (segments):
-- BDP = C × RTT = 1e9 bps × 0.015 s = 15e6 bits
+- BDP = C x RTT = 1e9 bps x 0.015 s = 15e6 bits
- W_max ≈ BDP / MSS = 15e6 / 12,000 ≈ 1,250 segments
b) Average window and throughput:
-- AIMD sawtooth average ≈ 0.75 × W_max ≈ 937.5 segments
-- Average throughput ≈ (937.5 × 12,000 bits) / 0.015 s ≈ 7.5e8 bps ≈ 750 Mbps
+- AIMD sawtooth average ≈ 0.75 x W_max ≈ 937.5 segments
+- Average throughput ≈ (937.5 x 12,000 bits) / 0.015 s ≈ 7.5e8 bps ≈ 750 Mbps
c) Time to recover to W_max after a loss:
- After halving to W_max/2, cwnd increases by ~1 MSS per RTT → needs W_max/2 RTTs
-- 625 RTTs × 0.015 s ≈ 9.375 s
+- 625 RTTs x 0.015 s ≈ 9.375 s
d) Buffer sizing to keep the link busy:
- For a single flow, provision on the order of the BDP to absorb bursts and maintain full utilization despite window dynamics: ≈ 15 Mb ≈ 1.875 MB ≈ ~1,250 MSS-sized segments.
-- With many flows, smaller buffers (≈ BDP/√N) can suffice, but for N=1, BDP is the safe choice.
+- With many flows, smaller buffers (≈ BDP/sqrt(N)) can suffice, but for N=1, BDP is the safe choice.