Packet Delivery - Learning Module

Loading content...

0/228

Delivery Types Comparison

The Complete Picture: Choosing the Right Delivery

We've explored each packet delivery type individually—unicast, broadcast, multicast, and anycast. But the real skill isn't just understanding each in isolation; it's knowing when to use which and understanding how they complement each other in real-world systems.

This page brings everything together. We'll compare all four delivery types across multiple dimensions, examine decision criteria, and analyze how modern applications combine these mechanisms to achieve their goals. By the end, you'll have a practical framework for selecting the appropriate delivery type for any networked application.

What You Will Learn

By the end of this page, you will understand: (1) How all four delivery types compare across key dimensions, (2) A decision framework for selecting the right delivery type, (3) How real-world applications combine multiple delivery types, (4) The evolution from IPv4 to IPv6 in delivery mechanisms, and (5) Practical implementation considerations for each scenario.

Side-by-Side Comparison

Let's begin with a comprehensive comparison of all four delivery types across key characteristics. This table serves as a quick reference for the fundamental differences.

Comprehensive Delivery Type Comparison
Dimension	Unicast	Broadcast	Multicast	Anycast
Communication Pattern	One-to-one	One-to-all	One-to-many	One-to-nearest
Sender Count	One	One	One or more	One
Receiver Count	Exactly one	All on segment	Group members	One of many
Address Type	Host-specific	Special (255.x or all-1s)	Class D / FF00::	Regular unicast
Receiver Selection	Sender chooses	All hosts forced	Receivers opt-in	Network chooses
Scope	Global (routable)	Local (broadcast domain)	Configurable	Global (routable)
IPv4 Support	Yes	Yes	Yes (IGMP)	Yes (operational)
IPv6 Support	Yes	No (replaced)	Yes (MLD)	Yes (defined)
Stateful Protocols	Yes (TCP)	No	Limited	Challenging
Sender Bandwidth	Scales with receivers	Fixed (one packet)	Fixed (one packet)	Fixed (one packet)

Visual Representation

Delivery Types Visualization
UNICAST: One packet → One destination
═════════════════════════════════════
    Source ───────────────────────────► Destination
         Single directed transmission
 
 
BROADCAST: One packet → All hosts on segment
═════════════════════════════════════════════
                     ┌────► Host A
    Source ──────────┼────► Host B
                     ├────► Host C
                     ├────► Host D
                     └────► Host E
         Everyone receives (whether they want it or not)
 
 
MULTICAST: One packet → Interested group members
═════════════════════════════════════════════════
    Source ──────────┬────► Member 1 ✓
                     │      Host A ✗ (not a member)
                     ├────► Member 2 ✓
                     │      Host B ✗ (not a member)
                     └────► Member 3 ✓
         Only group members receive
 
 
ANYCAST: One packet → Nearest of multiple servers
═════════════════════════════════════════════════
                       ╱ Server A (far)
    Client ───────────────► Server B (NEAREST) ← selected
                       ╲ Server C (far)
         Network picks the closest instance

Efficiency Analysis

Choosing the right delivery type often comes down to efficiency—balancing sender effort, network utilization, and receiver processing. Let's analyze each approach.

Sender Bandwidth Efficiency

Sender Efficiency Comparison
Scenario: Deliver 1 MB of data to N recipients
 
UNICAST:
  Sender bandwidth = N × 1 MB
  Linear scaling with recipients
  
  N=10:     10 MB    ▓▓▓▓▓▓▓▓▓▓
  N=100:    100 MB   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓...
  N=10000:  10 GB    [Source becomes bottleneck]
 
BROADCAST/MULTICAST/ANYCAST:
  Sender bandwidth = 1 MB (constant)
  
  N=10:     1 MB     ▓
  N=100:    1 MB     ▓ (same!)
  N=10000:  1 MB     ▓ (still same!)
 
CONCLUSION:
  For one-to-many with identical content,
  non-unicast approaches are dramatically more efficient.
  
  Break-even point: unicast beats broadcast/multicast
  only when N=1 (trivially) or when recipients need
  different content.

Network Utilization Efficiency

Network-Wide Efficiency
Metric	Unicast	Broadcast	Multicast	Anycast
Packets in network	N × path length	1 per segment	Branches at routers	1 path only
Redundant data on links	High (same data, different packets)	None (one packet)	None (replicates at branches)	None
Cross-network traffic	Yes	No (stopped at router)	Yes (if routed)	Yes
Wasted delivery	None	High (uninterested hosts)	None (only members)	None

The Multicast Sweet Spot

Multicast combines the sender efficiency of broadcast (one packet) with the targeted delivery of unicast (only interested receivers). It's theoretically optimal for one-to-many with identical content. The catch? Deployment complexity limits its use to controlled environments (enterprise networks, IPTV).

Decision Framework

How do you choose the right delivery type for your application? Follow this decision framework based on your requirements.

Converting Mermaid diagram...

Key Decision Questions

Questions to Guide Your Choice

•How many destinations? Single destination → Unicast. Multiple destinations → Continue analysis.
•Is content identical for all recipients? Personalized content → Unicast to each. Identical content → Consider broadcast/multicast.
•Is the scope local or global? Local segment only → Broadcast may work. Cross-router delivery needed → Multicast or unicast.
•Do receivers need to opt-in? Receivers choose participation → Multicast. All hosts must receive → Broadcast.
•Is service location flexible? Any server will do → Anycast. Specific server required → Unicast.
•Is TCP required? Reliable delivery needed → Unicast (or anycast with care). UDP acceptable → All options viable.
•What's the deployment environment? Internet-wide → Unicast or anycast. Controlled network → Multicast viable.

The Default is Unicast

When in doubt, unicast is the safe choice. It works everywhere, supports all protocols, and has no deployment prerequisites. Broadcast, multicast, and anycast are optimizations for specific scenarios. Don't reach for them until you've identified a clear need that unicast can't efficiently address.

Real-World Application Patterns

Real applications often combine multiple delivery types to achieve their goals. Let's examine common patterns.

Pattern 1: DNS Resolution Journey

DNS Resolution Delivery Types
DNS Name Resolution: Multiple Delivery Types
═════════════════════════════════════════════
 
Step 1: Device gets DNS resolver address
  • DHCP Discover → BROADCAST (255.255.255.255)
  • DHCP Offer contains DNS server IP
  
Step 2: Device queries local resolver (e.g., 192.168.1.1)
  • Query to resolver → UNICAST
  • Reply from resolver → UNICAST
  
Step 3: Resolver queries root server (e.g., 198.41.0.4)
  • Query to root → ANYCAST (one of many A-root instances)
  • Reply from root → UNICAST (from that instance)
  
Step 4: Resolver queries TLD server
  • Query to .com TLD → ANYCAST (many TLD servers)
  • Reply → UNICAST
  
Step 5: Resolver queries authoritative server
  • Query to ns1.example.com → UNICAST (or ANYCAST if CDN)
  • Reply → UNICAST
 
SUMMARY:
  Broadcast: Bootstrap (DHCP)
  Unicast:   Client-resolver, most responses
  Anycast:   Root servers, TLD servers, some CDN DNS

Pattern 2: IPTV Service Architecture

IPTV Delivery Architecture
IPTV Service: Multicast Core, Unicast Edge
═══════════════════════════════════════════
 
Content Distribution:
  
  [Headend] ──MULTICAST──► [Regional Hub] ──MULTICAST──► [DSLAM/OLT]
                                                              │
                                                         MULTICAST
                                                              │
                                                              ▼
                                                       [Set-top Box]
 
Channel Selection:
  • User presses "Channel 5" on remote
  • Set-top box sends IGMP Join for 239.1.1.5 (Channel 5 multicast group)
  • DSLAM/OLT adds this subscriber to the multicast tree
  • Video stream flows to that subscriber
  
Video-on-Demand (different!):
  • User selects a movie
  • VOD server streams UNICAST to that specific subscriber
  • Each viewer has independent stream, different position
  
Control & Billing:
  • EPG updates → often MULTICAST (same data to all)
  • Billing, authentication → UNICAST (personalized)
  
Why this mix?
  • Live TV: Identical content to many → MULTICAST efficient
  • VOD: Personalized position/content → UNICAST necessary
  • Bootstrap/discovery → Sometimes BROADCAST in home network

Other Combined Patterns

•CDN Architecture: Anycast for initial connection → Unicast for content delivery → Multicast for cache invalidation (internal)
•Enterprise Network Boot: Broadcast for DHCP → Multicast for PXE/imaging → Unicast for post-boot communication
•Gaming Services: Anycast for matchmaking → Unicast for game server connection → Multicast for lobby announcements
•Financial Trading: Multicast for market data feeds → Unicast for order submission → Anycast for redundant gateways

IPv4 to IPv6 Evolution

IPv6 was designed with lessons learned from IPv4's delivery mechanisms. Understanding the evolution helps explain why IPv6 made certain choices.

Delivery Type Evolution: IPv4 to IPv6
Aspect	IPv4 Approach	IPv6 Approach	Why the Change
Unicast	Host-specific addresses	Host-specific addresses	Fundamental; no change needed
Broadcast	255.255.255.255 and directed	ELIMINATED	Scalability issues; multicast replaces
Local All-Hosts	Limited broadcast	FF02::1 multicast	More control; scoped
Multicast	Class D, IGMP	FF00::/8, MLD (ICMPv6)	First-class support; built-in scoping
Anycast	Operational only	Formally defined	Recognized importance; still implementation-based
ARP	Broadcast-based	Neighbor Discovery (multicast)	Solicited-node reduces processing
DHCP Discovery	Broadcast	Multicast to FF02::1:2	More targeted; routable to DHCP relays

The Death of Broadcast in IPv6

IPv6's elimination of broadcast deserves special attention. Every IPv4 broadcast use case has an IPv6 replacement:

IPv4 Broadcast to IPv6 Multicast Migration
IPv4 Broadcast → IPv6 Multicast Replacements
══════════════════════════════════════════════
 
ARP (Address → MAC resolution):
  IPv4: Broadcast ARP Request to FF:FF:FF:FF:FF:FF
        "Who has 192.168.1.50?"
        → ALL hosts process, only one responds
        
  IPv6: Multicast Neighbor Solicitation to FF02::1:FFxx:xxxx
        "Who has 2001:db8::1234?"
        → Only hosts with matching suffix process
        → Dramatically reduced interrupt load
 
DHCP Discovery:
  IPv4: Broadcast to 255.255.255.255
        → All hosts on segment process
        
  IPv6: Multicast to FF02::1:2 (All DHCP Servers)
        → Only DHCP servers listen on this group
        → Other hosts ignore
 
Router Discovery:
  IPv4: Various (often implicit via ARP)
  
  IPv6: Router Solicitation to FF02::2 (All Routers)
        Router Advertisement to FF02::1 (All Nodes)
        → Clean, standardized, multicast-based
 
General Announcements:
  IPv4: Limited broadcast (255.255.255.255)
  
  IPv6: All-Nodes Multicast (FF02::1)
        → Functionally equivalent but scoped
 
KEY INSIGHT:
  IPv6 didn't eliminate the NEED for one-to-all messaging.
  It replaced the MECHANISM with multicast, which allows:
  • Scoping (link-local, site-local, global)
  • Protocol-specific groups (not all-or-nothing)
  • Better hardware filtering (multicast MAC addresses)

The Solicited-Node Optimization

IPv6's solicited-node multicast (FF02::1:FFxx:xxxx) is brilliant engineering. Instead of broadcasting to ALL hosts (ARP), it multicasts to a group derived from the target's address. Only hosts whose addresses share those last 24 bits need to process the request. In practice, this is usually just the target host—reducing broadcast-style interrupts by 99%+ on large networks.

Performance and Scalability

Different delivery types have vastly different scalability characteristics. Understanding these helps architect systems that will perform at scale.

Scalability Comparison

Scalability Characteristics
Delivery Type	Sender Scaling	Network Scaling	Receiver Scaling	Limiting Factor
Unicast	O(N) bandwidth	O(N) paths	O(1) per receiver	Sender capacity
Broadcast	O(1) bandwidth	O(1) in segment	O(N) processing	Segment size, host load
Multicast	O(1) bandwidth	Tree branches	O(M) for M members	Router state, IGMP overhead
Anycast	O(1) bandwidth	O(1) path	O(1) per instance	Instance capacity distribution

When Delivery Types Break Down

Scalability Limits

•Unicast fails when sender bandwidth can't match receiver demand. A server streaming 4K video to 1 million unicast clients would need 1+ Tbps of bandwidth. This is why CDNs distribute the load.
•Broadcast fails when segment size grows. A /16 network (65,000+ hosts) experiencing broadcast storms becomes unusable. This is why enterprise networks use VLANs to limit broadcast domains.
•Multicast fails when router state exceeds memory. Each (S,G) or (*,G) entry consumes router resources. Thousands of active multicast groups can overwhelm routing tables.
•Anycast fails when routing can't balance load evenly. If one anycast instance's path is preferred by 90% of the Internet, it receives 90% of traffic. Geographic coverage matters.

Scalability Example: 1 Million Viewers
Scenario: Live video stream to 1,000,000 concurrent viewers
Stream bitrate: 5 Mbps
 
UNICAST (naive):
  Sender bandwidth needed: 1,000,000 × 5 Mbps = 5,000 Gbps (5 Tbps)
  → Impossible for a single origin
  → CDN required: 1,000 edge servers × 1,000 unicast streams each
  → Still expensive
 
MULTICAST (in controlled network like IPTV):
  Sender bandwidth needed: 1 × 5 Mbps = 5 Mbps
  Network replication: Routers copy to branches
  → Dramatically efficient
  → Limited deployment (ISP internal only)
 
ANYCAST + CDN (common Internet approach):
  Origin bandwidth: 1 stream × number of edge PoPs (~100-500)
  Each edge handles local unicast: ~2,000-10,000 streams each
  → Scales by adding edge servers
  → Each user gets low latency from nearby edge
  
Real-World: Netflix uses unicast from CDN edges
  → 1,000+ Open Connect Appliances worldwide
  → Each appliance serves local users via unicast
  → Content replicated to edges overnight
  → Live streams use similar CDN pattern

Security Considerations

Each delivery type has distinct security characteristics. Understanding these helps build secure network architectures.

Security Comparison by Delivery Type
Delivery Type	Confidentiality	Authentication	Key Vulnerabilities
Unicast	End-to-end encryption possible (TLS)	Standard auth mechanisms	Spoofing, man-in-the-middle
Broadcast	No encryption (everyone receives)	No authentication	Eavesdropping, spoofing, amplification
Multicast	Group encryption complex	Group membership unverified	Unauthorized receivers, source spoofing
Anycast	Encryption possible per-instance	Which instance responded?	BGP hijacking, traffic interception

Attack Vectors by Delivery Type

Broadcast Attacks

•Smurf Attack: Ping to directed broadcast with spoofed source; amplified response floods victim
•DHCP Starvation: Exhaust DHCP pool via broadcast requests
•ARP Spoofing: Fake ARP replies via broadcast to redirect traffic
•Broadcast Storms: Intentional or accidental network flooding

Anycast Attacks

•BGP Hijacking: Attacker announces anycast prefix to intercept traffic
•Route Manipulation: Force traffic to attacker-controlled server
•Service Impersonation: Malicious 'nearest' server
•Routing Instability: Intentional flapping causes connection drops

Multicast Security Challenges

Multicast has inherent security challenges: (1) No receiver authentication — anyone can join any group, (2) Group encryption complexity — key distribution to all members is hard; adding/removing members requires key rotation, (3) Source spoofing — attackers can send to multicast groups. These issues have limited multicast deployment for sensitive applications. Secure multicast protocols exist but add significant complexity.

Summary: The Complete Delivery Picture

We've now explored all four packet delivery types and compared them across multiple dimensions. Let's consolidate this knowledge into actionable guidance.

Key Takeaways

•Unicast is the workhorse — Default choice for most applications. Reliable, well-understood, works everywhere. Use when content is personalized or TCP is required.
•Broadcast is local and limited — IPv4 only, segment-scoped. Use only for bootstrapping (DHCP) and local discovery. Keep broadcast domains small.
•Multicast is efficient but complex — Excellent for one-to-many identical content. Deployment limited to enterprise/IPTV. Consider only when efficiency gains justify complexity.
•Anycast is for global services — Ideal for stateless services needing geographic distribution (DNS, CDN). Requires BGP expertise and careful TCP handling.
•IPv6 replaces broadcast with multicast — Better scoping, reduced host interrupts, more elegant design. Plan for this in dual-stack environments.
•Real applications combine types — DNS uses broadcast+unicast+anycast. IPTV uses multicast+unicast. CDNs use anycast+unicast. Match delivery type to each sub-task.
•Security differs by type — Unicast supports TLS easily. Broadcast/multicast expose data. Anycast enables BGP-based attacks. Design security for your chosen delivery.

Quick Reference: When to Use Each Delivery Type
Use Case	Best Delivery Type	Why
Web browsing	Unicast	Personalized content, TCP required
DHCP configuration	Broadcast (IPv4)	Unknown server address
Live TV in enterprise	Multicast	Identical stream to many, controlled network
Public DNS	Anycast	Geographic distribution, stateless UDP
Video on demand	Unicast	Personalized playback position
Service discovery (local)	Broadcast/Multicast	Find nearby devices
CDN edge selection	Anycast	Route to nearest edge
Database replication	Unicast	Stateful, reliable required

Module Complete: Packet Delivery

You've completed the Packet Delivery module. You now understand how packets travel from source to destination using unicast, broadcast, multicast, and anycast delivery. This knowledge is fundamental to network design, application architecture, and troubleshooting. You're equipped to choose appropriate delivery mechanisms for any networked application and understand the trade-offs involved.