**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.
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?"
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.
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.
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.
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.
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."
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.
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.
| 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 |
Features required to call v1.2 complete. Missing these means the milestone goal ("expanded protocol classification with grouped protocol families") is not delivered.
| 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 |
| 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 |
| 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]
| +--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.
| 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 |
- [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)
