yoloyolo/.planning/research/FEATURES.md

# Feature Research

**Domain:** Network traffic sonification CLI tool (packet capture -> ambient MP3)
**Researched:** 2026-03-24 (v1.0), updated 2026-03-26 (v1.1 custom sound mappings), updated 2026-03-27 (v1.2 extended protocol coverage)
**Confidence:** MEDIUM — niche domain; comparable tools are research prototypes or GUI applications, not CLI tools. Table stakes are derived from tcpdump/packet-capture CLI conventions and sonification research literature.

---

## v1.2 Feature Research: Extended Protocol Coverage with Grouped Protocol Families

This section addresses the milestone question: "How should protocol grouping work for network sonification? What are the most common protocols seen on typical networks? Which protocols are worth adding? What's the right granularity — individual protocol vs group?"

### What Real Networks Actually See

Based on IANA well-known ports, nDPI's traffic classification taxonomy (450+ protocols, 17 application categories), Wireshark's protocol dissector set, and widely-cited network security references, traffic on real networks breaks down into recognizable families.

**Home network (residential broadband):**
The dominant traffic types are HTTPS (streaming, browsing, cloud sync), DNS (constant background noise, every connection starts here), NTP (infrequent but present on all devices), DHCP (device join/renew events), ICMP (ping, router probe), and mDNS/SSDP (device discovery on the local segment). IoT device traffic adds MQTT. Video calls add RTP/SRTP.

**Office network (enterprise LAN):**
Same HTTPS/DNS/NTP/DHCP base, plus: LDAP/Kerberos (domain auth), SMB (file sharing), RDP (remote desktop), SMTP/IMAP/POP3 (mail), SNMP (monitoring), syslog (log aggregation), SSH (server access), FTP (legacy file transfer still common in many environments).

**Server host (Linux box exposed to internet):**
SSH (constant scan attempts), HTTPS (serving), DNS (resolver queries), ICMP (reachability probes), NTP (drift correction), syslog (local log collection), PostgreSQL/MySQL/Redis (local app traffic), SMTP (outbound mail relay).

**Cloud workload:**
HTTPS dominates. DNS for service discovery. Redis/PostgreSQL for app data. Kafka/AMQP for message queues. gRPC (still port 443 via HTTP/2). ICMP suppressed. NTP locked down.

### Why Protocol Grouping Matters for Sonification

Without grouping, adding 20+ individual protocols creates:
1. **Spectrum crowding:** 20+ tones across the audible range become indistinguishable mud.
2. **No perceptual structure:** Listeners cannot form a mental model of what they are hearing.
3. **Frequency allocation complexity:** Designing 20+ non-conflicting frequency slots is difficult.

The nDPI project (the leading open-source DPI library, used by ntopng) faced the same problem and solved it with 17 application categories that group hundreds of protocols. For sonification, the goal is different — not to identify every protocol, but to produce a soundscape where related activity sounds related.

**Recommended approach: Protocol families, not individual protocols.**

A "Mail" family chord — one tonal cluster covering SMTP + IMAP + POP3 — is more musically coherent and more perceptually useful than three separate isolated tones. A user can hear "mail activity is elevated" rather than "something is happening on port 143."

### Protocol Grouping Taxonomy for NetSynth v1.2

After surveying IANA port assignments, nDPI's category taxonomy, and the Wireshark protocol support matrix, the following family groupings are recommended. Each family occupies a frequency region (not individual tones), and protocols within a family use slight detuning or waveform variation to stay distinct.

**Family: Web (already covered)**
- HTTPS / TLS (port 443) — already built in
- HTTP (port 80) — already built in
- HTTP/3 / QUIC (port 443 UDP) — port-based detection is possible (UDP 443)
- Alt-HTTPS ports (8443, 8080) — users can add via custom rules

**Family: Mail**
- SMTP (port 25) — already built in (single class)
- SMTP submission (port 587, 465) — distinct submission path, worth adding
- IMAP (port 143, 993) — pull email; very common on office networks
- POP3 (port 110, 995) — legacy pull email; still common with older mail clients

**Family: Remote Access**
- SSH (port 22) — already built in
- Telnet (port 23) — unencrypted, legacy; worth representing (security signal)
- RDP (port 3389) — Windows remote desktop; ubiquitous in enterprise
- VNC (port 5900) — remote frame buffer; common on servers/developer machines

**Family: Infrastructure (already partially covered)**
- DNS (port 53) — already built in
- DHCP (ports 67/68) — already built in
- NTP (port 123) — already built in
- mDNS (port 5353 UDP) — Bonjour/Avahi discovery; prominent on home/office LANs
- SSDP (port 1900 UDP) — UPnP device discovery; common with IoT devices
- LLMNR (port 5355) — Windows local name resolution; common on Windows networks
- SNMP (port 161/162 UDP) — network monitoring; common on office/server networks
- Syslog (port 514 UDP) — log forwarding; common on server and enterprise networks

**Family: File Transfer**
- FTP (port 21) — still widely used in legacy environments, NAS devices
- TFTP (port 69 UDP) — boot/config transfer; common in network infrastructure (switches, PXE boot)
- SMB (port 445) — Windows file sharing; ubiquitous on any Windows or Samba network

**Family: Database**
- MySQL/MariaDB (port 3306) — most common SQL database port
- PostgreSQL (port 5432) — second most common SQL database
- Redis (port 6379) — in-memory cache; present on almost every modern app server
- MongoDB (port 27017) — document store; very common in web apps

**Family: VoIP / Real-Time**
- SIP (port 5060/5061) — VoIP signaling; present in any office with IP phones
- RTP (ports 16384-32767 UDP, dynamic) — voice/video payload; hard to detect by port alone

**Family: Directory / Authentication**
- LDAP (port 389, 636) — Active Directory / OpenLDAP; present on any enterprise network
- Kerberos (port 88) — Active Directory authentication; present on any Windows domain network

Note: gopacket/layers does NOT natively decode SMTP, IMAP, POP3, FTP, TFTP, SMB, MySQL, PostgreSQL, Redis, SIP, RTP, LDAP, or Kerberos at the application layer. Classification must happen at the transport layer (port number matching), which is exactly how the existing Rule classifier works. No new dependencies required.

### Which Protocols to Include: Priority Tiers

**Tier 1 — Add immediately (high real-world frequency, low complexity)**

| Protocol | Ports | Network Type | Detection Method | Family |
|----------|-------|-------------|-----------------|--------|
| IMAP / IMAPS | TCP 143, 993 | Home, Office, Server | Port match | Mail |
| POP3 / POP3S | TCP 110, 995 | Home, Office | Port match | Mail |
| SMTP Submission | TCP 587, 465 | Home, Office, Server | Port match | Mail |
| FTP | TCP 20, 21 | Office, Server, NAS | Port match | File Transfer |
| SMB | TCP 445 | Office, Windows networks | Port match | File Transfer |
| RDP | TCP 3389 | Office, Enterprise | Port match | Remote Access |
| mDNS | UDP 5353 | Home, Office | Port match | Infrastructure |
| SSDP | UDP 1900 | Home, IoT | Port match | Infrastructure |
| SNMP | UDP 161, 162 | Office, Server | Port match | Infrastructure |
| MySQL | TCP 3306 | Server, Cloud | Port match | Database |
| PostgreSQL | TCP 5432 | Server, Cloud | Port match | Database |
| Redis | TCP 6379 | Server, Cloud | Port match | Database |

**Tier 2 — Include if groups are being formed (moderate frequency)**

| Protocol | Ports | Network Type | Detection Method | Family |
|----------|-------|-------------|-----------------|--------|
| Telnet | TCP 23 | Legacy, embedded | Port match | Remote Access |
| VNC | TCP 5900 | Office, Developer | Port match | Remote Access |
| TFTP | UDP 69 | Infrastructure, PXE | Port match | File Transfer |
| SIP | TCP/UDP 5060, 5061 | Office, VoIP | Port match | VoIP |
| LDAP / LDAPS | TCP 389, 636 | Enterprise | Port match | Directory/Auth |
| Kerberos | UDP/TCP 88 | Enterprise, Windows | Port match | Directory/Auth |
| Syslog | UDP 514 | Server, Enterprise | Port match | Infrastructure |
| MongoDB | TCP 27017 | Server, Cloud | Port match | Database |
| QUIC/HTTP3 | UDP 443 | Home, Office | Port match (UDP 443) | Web |

**Tier 3 — Defer or leave to user custom rules**

| Protocol | Reason to Defer |
|----------|----------------|
| MQTT (TCP 1883/8883) | IoT-specific; not present on most general networks |
| AMQP (TCP 5672) | Message queue; only relevant on specific server workloads |
| Kafka (TCP 9092) | Rarely seen outside distributed systems environments |
| BGP (TCP 179) | Routing protocol; not visible on end-host captures |
| OSPF | Link-state routing; IP protocol 89, not TCP/UDP; gopacket has native decoder but it is infrastructure traffic only |
| RADIUS (UDP 1812/1813) | Authentication forwarding; only on network infrastructure |
| gRPC | Uses HTTP/2 on port 443; indistinguishable from HTTPS at transport layer |
| XMPP (TCP 5222) | Near-obsolete for general messaging |

### What Granularity Is Right: Individual Protocol vs Group?

**Recommendation: Implement individual protocol classes, but group them for frequency allocation.**

This gives the user the most information value while maintaining musical coherence:
- Each protocol gets a distinct `TrafficClass` constant and rule (e.g., `ClassIMAP`, `ClassSMB`).
- Related protocols are assigned frequencies within a shared family frequency band (e.g., all Mail protocols live in 400-550 Hz).
- Within a family band, slight detuning (5-15 Hz apart) produces audible distinction without crowding.
- Family identity is perceivable because the tones are harmonically close.

This matches how nDPI handles the tension: individual protocol identity for precise classification, category grouping for user-facing display and policy. NetSynth's "display" is sonic — the grouping manifests as tonal proximity.

The alternative — collapsing IMAP+SMTP+POP3 into a single "Mail" class — loses information. A user cannot tell whether mail noise is inbound (IMAP) or outbound (SMTP). Individual classes preserve that distinction.

### Frequency Allocation for New Families

The current frequency map uses 65 Hz – 1047 Hz across 14 classes. Adding ~20 new protocols requires rethinking the allocation.

**Current allocation issues:**
- The range from 65-110 Hz (ICMP, DNS) is very low; adding families in this region creates muddiness.
- The unknown buckets at 862-1047 Hz occupy space that could be used for real protocols.
- The spread from 600-780 Hz (DHCP, OtherTCP, OtherUDP) is dense.

**Recommended approach for v1.2:**
- Assign families to distinct octave/register bands rather than a linear frequency sweep.
- Use musically meaningful intervals within each family (minor thirds, perfect fourths — intervals that sound related without clashing).
- Keep the existing 10 class frequencies backward-compatible; assign new protocols to new frequency slots.
- Push unknown buckets above 1200 Hz (the current auto-assign range already does this via FNV hash).

**Proposed family frequency bands:**

| Family | Band | Rationale |
|--------|------|-----------|
| Infrastructure (DNS, DHCP, NTP, mDNS, SNMP, Syslog, SSDP) | 80-200 Hz | Low, grounding tones; infrastructure is the "bass" of the network |
| Web (HTTP, HTTPS, QUIC) | 220-320 Hz | Mid-low; dominant traffic, warm register |
| Mail (SMTP, IMAP, POP3) | 350-480 Hz | Mid; distinct from web, harmonically separate |
| Remote Access (SSH, Telnet, RDP, VNC) | 500-620 Hz | Mid-high; noticeable — admin activity is important |
| File Transfer (FTP, TFTP, SMB) | 650-750 Hz | Upper-mid; distinct texture |
| Database (MySQL, PostgreSQL, Redis, MongoDB) | 800-950 Hz | Upper register; database chatter is server-side signal |
| Directory / Auth (LDAP, Kerberos) | 960-1050 Hz | High; auth traffic is sparse but significant |
| VoIP (SIP, RTP) | 1100-1200 Hz | High; real-time traffic stands out |
| Unknown buckets | 1300+ Hz | Highest; unclassified traffic is "noise above the signal" |
| ICMP | 65 Hz | Remains as fundamental ping pulse below all families |

---

## Table Stakes for v1.2

Features required to call v1.2 complete. Missing these means the milestone goal ("expanded protocol classification with grouped protocol families") is not delivered.

| Feature | Why Expected | Complexity | Depends On |
|---------|--------------|------------|------------|
| Mail family (IMAP, IMAPS, POP3, POP3S, SMTP submission 587/465) | Requested directly in todo; mail traffic is high-frequency on any office network | LOW | Existing Rule/TrafficClass pattern; add constants + rules |
| Remote Access expansion (RDP, VNC, Telnet) | SSH is already present; the family is incomplete without RDP on enterprise captures | LOW | Same as above |
| File Transfer family (FTP, SMB, TFTP) | FTP/SMB appear on almost every office or NAS-connected home network | LOW | Same as above |
| Infrastructure expansion (mDNS, SSDP, SNMP, Syslog) | These are constant background noise on every LAN; without them they land in other-UDP | LOW | Same as above |
| Database family (MySQL, PostgreSQL, Redis, MongoDB) | Any developer machine has these; they currently all land in other-TCP | LOW | Same as above |
| Frequency rebalancing to accommodate new classes | Without rebalancing, the new classes crowd the existing spectrum | MEDIUM | requires touching synth.ClassFreqConfigs; backward-compatible if existing class constants keep their names |
| TrafficClass constants and AllClasses() updated | Config, synth, and print-config must know about new classes | LOW | classify/types.go extension |
| DefaultRules updated with new port rules | New classes only work if packets reach them via rules | LOW | classify/rules.go extension |
| --print-config reflects new classes | Users need to see and override the new classes | LOW | Falls out automatically once ClassFreqConfigs and AllClasses() are updated |
| Group concept exposed in --print-config | Grouped comments (# Mail family, # Database family) make the config readable | LOW | PrintConfig formatting only; no struct changes needed |

## Differentiators for v1.2

Features that make the extended protocol coverage polished beyond the minimum.

| Feature | Value Proposition | Complexity | Notes |
|---------|-------------------|------------|-------|
| Within-family tonal design: shared waveform within a family | Mail protocols all use the same waveform (e.g., sawtooth); listeners perceive the family by timbre as well as frequency | LOW | Assign waveform by family at design time; no new code needed |
| Within-family detuning: minor third intervals between protocols in a family | Protocols within a family are harmonically close; the family "chord" is identifiable | LOW | Frequency assignment arithmetic at design time |
| Directory/Auth family (LDAP, Kerberos) | Present on every enterprise network; their absence means enterprise traffic sounds like "other-TCP" noise | LOW | 2 more class constants + rules |
| VoIP family (SIP, SIP-TLS) | IP phone traffic is prominent in offices; SIP port 5060 is easily matched | LOW | 2 more class constants + rules |
| QUIC / HTTP3 class (UDP 443) | HTTP/3 now represents a significant fraction of web traffic; treating it identically to HTTPS when it arrives via UDP is perceptually meaningful | LOW | 1 rule: UDP port 443 maps to ClassQUIC or ClassHTTPS3 |

## Anti-Features for v1.2

Features that seem natural for this milestone but should be avoided.

| Anti-Feature | Why Avoid | What to Do Instead |
|--------------|-----------|-------------------|
| Application-layer (DPI) detection | gopacket does not decode SMTP, SMB, Redis, etc. at the application layer. Implementing DPI requires a full protocol parser per protocol — massive scope. | Port-number matching is sufficient for classification purposes; DPI adds complexity without enough sonification value |
| Single "Mail" or "Database" class (collapsing all protocols in family) | Loses per-protocol information. "Mail" does not tell you if it is inbound or outbound. "Database" does not distinguish Redis latency spikes from a slow Postgres query. | Keep individual TrafficClass per protocol; use frequency proximity for family grouping |
| Dynamic port detection (e.g., FTP data port 20 bidirectional, ephemeral RTP ports) | FTP uses negotiated dynamic ports for data transfer; RTP uses ports negotiated over SIP. Tracking these requires stateful flow tracking across packets — significant architectural change. | Classify on well-known control/server ports only; dynamic data flows land in other-TCP/UDP. Document this limitation. |
| Runtime group concept (Group struct with members) | Adding a Group abstraction to TrafficClass, Rule, or FreqConfig requires touching multiple packages and complicates the TOML schema. | Groups are a classification/display concept only, not a data structure. Implement them as naming conventions and config comment sections. |
| Backward-incompatible frequency changes to existing 10 classes | Users who have existing TOML configs relying on the current frequencies would have their carefully tuned soundscapes broken | Keep ICMP=65Hz, DNS=110Hz, HTTPS=175Hz, HTTP=220Hz, SSH=330Hz, SMTP=440Hz, NTP=520Hz, DHCP=600Hz, OtherTCP=700Hz, OtherUDP=780Hz; assign new protocols to unoccupied slots |
| Replacing other-TCP / other-UDP with something smarter | The catch-all classes serve an important role: unrecognized traffic is still represented. Removing them creates silent gaps. | Keep other-TCP and other-UDP as catch-alls; new specific classes reduce how much traffic lands there |
| SRC port matching rules | Some protocols run on ephemeral source ports; adding src-port rules would double rule count and create false matches. Current architecture matches dst-port only. | Stick to dst-port matching. This is how nmap, iptables, and most classifiers work by default. |

## Feature Dependencies for v1.2

```
[classify/types.go: add ~20 new TrafficClass constants]
    |
    +--enables--> [classify/rules.go: add new Rule entries per protocol]
    |                  |
    |                  +--feeds--> [classify.Classifier: matches packets to new classes]
    |
    +--enables--> [synth/config.go: add FreqConfig entries for new classes]
    |                  |
    |                  +--requires--> [Frequency rebalancing: shift new classes into family bands]
    |                  |              (backward-compatible: existing 10 classes unchanged)
    |                  |
    |                  +--feeds--> [synth.Bank: synthesizes new layers]
    |                              (NumLayers constant must increase from 14 to cover new classes)
    |
    +--enables--> [classify.AllClasses(): include new classes in display order]
                       |
                       +--feeds--> [config.PrintConfig(): groups appear in --print-config output]
                       +--feeds--> [aggregate.Summary: new classes appear in exit summary]
```

### Dependency Notes for v1.2

- **NumLayers constant must increase.** `synth/config.go` has `NumLayers = 14` and derives `GainPerLayer = 1.0 / float64(NumLayers)` from it. Adding 20 protocols brings total classes to ~34. `NumLayers` must be updated, or the gain calculation must become dynamic. This is a straightforward arithmetic change but affects all layers' amplitude. Test the mix with more layers to confirm it still sounds balanced.

- **AllClasses() ordering determines --print-config output order.** Currently returns a flat slice. For v1.2, ordering by family group (all Mail classes together, all Database classes together) makes --print-config more readable. This is a display concern only — the order has no effect on classification.

- **No new external dependencies required.** All new protocols are detected via port number using the existing Rule struct. gopacket is not being asked to decode new application-layer protocols.

- **QUIC/HTTP3 requires a UDP 443 rule.** The current rules only match TCP 443 for HTTPS. Adding a separate rule for UDP 443 is one line. The question is naming: `ClassHTTPS3` or `ClassQUIC`. QUIC is the transport; HTTP/3 is the application. For sonification purposes, `ClassQUIC` is clearer because it describes the observable port behavior.

- **SIP detection covers control plane only.** SIP signals calls on port 5060/5061, but the actual voice/video payload travels via RTP on dynamically negotiated ports (typically in 16384-32767 range). The current classifier cannot detect RTP payloads without stateful flow tracking. Classify SIP only; document that RTP payload traffic lands in other-UDP.

---

## Protocol List: Final Recommended Set

This is the complete recommended protocol class list for v1.2, including existing + new.

### Existing (unchanged, backward-compatible)
| Class | Protocol | Port | Transport |
|-------|----------|------|-----------|
| ICMP | ICMP/ICMPv6 | — | ICMP |
| DNS | Domain Name System | 53 | TCP+UDP |
| HTTPS | HTTP Secure / TLS | 443 | TCP |
| HTTP | HTTP | 80 | TCP |
| SSH | Secure Shell | 22 | TCP |
| SMTP | Mail Transfer (server-to-server) | 25 | TCP |
| NTP | Network Time Protocol | 123 | UDP |
| DHCP | Dynamic Host Config | 67, 68 | UDP |
| other-TCP | Unclassified TCP | — | TCP |
| other-UDP | Unclassified UDP | — | UDP |
| unknown-1..4 | Hash-bucketed unknowns | — | any |

### New: Tier 1 (high frequency, recommended for v1.2)
| Class | Protocol | Port | Transport | Family |
|-------|----------|------|-----------|--------|
| IMAP | IMAP / IMAPS | 143, 993 | TCP | Mail |
| POP3 | POP3 / POP3S | 110, 995 | TCP | Mail |
| SMTP-Submission | SMTP client submission | 587, 465 | TCP | Mail |
| FTP | File Transfer Protocol | 20, 21 | TCP | File Transfer |
| SMB | Server Message Block | 445 | TCP | File Transfer |
| RDP | Remote Desktop Protocol | 3389 | TCP | Remote Access |
| mDNS | Multicast DNS (Bonjour) | 5353 | UDP | Infrastructure |
| SSDP | Simple Service Discovery | 1900 | UDP | Infrastructure |
| SNMP | Simple Network Mgmt | 161, 162 | UDP | Infrastructure |
| MySQL | MySQL database | 3306 | TCP | Database |
| PostgreSQL | PostgreSQL database | 5432 | TCP | Database |
| Redis | Redis in-memory store | 6379 | TCP | Database |

### New: Tier 2 (moderate frequency, recommended for v1.2 completeness)
| Class | Protocol | Port | Transport | Family |
|-------|----------|------|-----------|--------|
| Telnet | Telnet (unencrypted shell) | 23 | TCP | Remote Access |
| VNC | VNC / Remote Frame Buffer | 5900 | TCP | Remote Access |
| TFTP | Trivial File Transfer | 69 | UDP | File Transfer |
| SIP | SIP VoIP signaling | 5060, 5061 | TCP+UDP | VoIP |
| LDAP | Directory Access Protocol | 389, 636 | TCP | Directory/Auth |
| Kerberos | Kerberos authentication | 88 | TCP+UDP | Directory/Auth |
| Syslog | System log forwarding | 514 | UDP | Infrastructure |
| MongoDB | MongoDB document store | 27017 | TCP | Database |
| QUIC | QUIC / HTTP/3 transport | 443 | UDP | Web |

**Total: 11 existing known + 21 new = 32 known protocol classes + 4 unknown buckets = 36 total.**

---

## Implementation Complexity Summary

| Area | Complexity | Reason |
|------|------------|--------|
| New TrafficClass constants (~21) | LOW | Add string constants; no logic change |
| New Rule entries in DefaultRules (~25 rules for 21 classes, some need 2 ports) | LOW | Add Rule structs; existing matcher handles them |
| New FreqConfig entries (~21) | LOW | Add map entries with chosen Hz values and waveform |
| Frequency rebalancing design | MEDIUM | Must assign ~21 new Hz values that (a) stay within audible range, (b) are musically coherent within families, (c) do not collide with existing 10 classes |
| NumLayers update | LOW | One constant change; test mix amplitude |
| AllClasses() family-ordered output | LOW | Reorder the returned slice by family |
| PrintConfig family section headers | LOW | Add comment lines between family groups in PrintConfig |
| Test updates | LOW | Add new classes to classifier tests; confirm no regressions |

**No new external dependencies required for v1.2.**

---

## Competitor Feature Analysis (Updated for v1.2)

| Feature | SoNSTAR (Python) | Network-Sonification (C# GUI) | Peep (C, Unix) | NetSynth v1.1 | NetSynth v1.2 |
|---------|-----------------|-------------------------------|----------------|----------------|----------------|
| Protocol count | ~8 (TCP flow types) | ~10 | ~6 | 10 known + 4 unknown | ~32 known + 4 unknown |
| Family grouping | No | No | No | No | Yes (7 families) |
| Tonal family identity | No | No | No | No | Yes (freq proximity + shared waveform) |
| Database protocols | No | No | No | No | Yes (MySQL, PostgreSQL, Redis, MongoDB) |
| Mail family (IMAP/POP3) | No | No | No | SMTP only | Yes (SMTP + IMAP + POP3) |
| Enterprise protocols (RDP, LDAP, Kerberos, SMB) | No | No | No | No | Yes |
| Infrastructure expansion (mDNS, SNMP, Syslog) | No | No | No | No | Yes |

---

## Sources

- [IANA Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers) — authoritative port assignments
- [List of TCP and UDP port numbers — Wikipedia](https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers) — comprehensive reference for well-known ports
- [Common Ports Cheat Sheet — StationX](https://www.stationx.net/common-ports-cheat-sheet/) — grouped protocol reference used for family taxonomy
- [nDPI Protocols List — ntop](https://www.ntop.org/guides/nDPI/protocols.html) — nDPI's 450+ protocol list and 17-category taxonomy; source for family grouping inspiration
- [nDPI 5.0: Enhanced Traffic Fingerprinting — ntop blog](https://www.ntop.org/ndpi-5-0-enhanced-traffic-fingerprinting-and-fpc-many-new-protocols/) — confirms category-based grouping as the production approach for managing large protocol sets
- [SoNSTAR: Sonification of Network Traffic — Paul Vickers](https://paulvickers.github.io/SoNSTAR/) — academic network sonification tool; uses TCP/IP flow features rather than protocol families
- [Sonification of network traffic flow for monitoring and situational awareness — PLoS One 2018](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0195948) — research literature on what protocol-level groupings are perceptually useful in sonification
- [pkg.go.dev/github.com/gopacket/gopacket/layers](https://pkg.go.dev/github.com/gopacket/gopacket/layers) — confirmed that gopacket natively decodes DNS, DHCP, NTP, ICMP, OSPF, BGP, but NOT SMTP, IMAP, FTP, SMB, MySQL, Redis, SIP, RTP, LDAP at the application layer; port-based classification is the correct approach for v1.2
- [Realtime High-Speed Network Traffic Monitoring Using ntopng — LISA 2014](https://luca.ntop.org/Lisa2014.pdf) — confirms category-based protocol grouping as standard in production monitoring tools
- Internal codebase review: `/home/dev/workspace/yoloyolo/classify/rules.go`, `types.go`, `synth/config.go` — confirmed existing 10 known classes, Rule struct pattern, FreqConfig pattern, NumLayers=14 constant, and auto-assign frequency range (1200-2350 Hz)

---
*v1.0 research: 2026-03-24*
*v1.1 custom sound mappings research: 2026-03-26*
*v1.2 extended protocol coverage research: 2026-03-27*