Colin Perkins: How Real-Time Media Learned to Share the Internet

Summary

• Real-time communication cannot wait for the certainty expected by file transfer. It needs deadlines, sequence and timing information, bounded repair, feedback and an explicit response to congestion
• Perkins was not an author of RFC 3550, the defining RTP specification; his significance lies in sustained work around the ecosystem, including repair, payload guidance, SDP, RTCP extensions, multiplexing, security, congestion safety, WebRTC media transport and Transport Services
• His record also contains useful counter-evidence: circuit-breaker logic needed revision after LTE evaluation, DCCP faced deployment barriers, and TCP Hollywood and peer-to-peer QUIC multiplexing remained research or prototype work
• His institutional influence was procedural rather than sovereign, including working-group chair roles, service as IRTF Chair from 2019 to 2025, and later review and steering responsibilities
• The later phase of his career applies the same discipline to the standards system itself, asking how deployment, errata, failed standardisation, affiliations and social graphs can be measured without confusing available traces with causal truth

A call is a deadline, not a file transfer

A video call feels continuous only because software hides discontinuity. The network underneath does not deliver a smooth ribbon of sound and images. It delivers packets that may arrive late, out of order, more than once or not at all. A receiver has to decide when to play what it has, when a missing packet is still worth recovering, when concealment is better than waiting and when the sender is putting too much pressure on the path.

That is a different problem from file transfer. A file can often wait for retransmission because exact recovery matters more than immediate usefulness. Speech and interactive video have playout deadlines. A repaired syllable that arrives after the listener has already heard the next sentence is no longer useful in the same way. Delay can damage a conversation even when every byte eventually arrives.

Congestion adds a collective obligation. A media application that ignores persistent loss can continue sending into a path that is already overloaded, damaging both its own call and traffic that shares the bottleneck. A system designed only to preserve its own picture quality can become a poor Internet citizen. Real-time infrastructure therefore needs a feedback loop that observes reception, estimates whether continued transmission remains responsible and changes behaviour before damage becomes persistent.

Perkins’ work is unusually coherent when viewed through this control problem. Early work asks how redundant information can survive isolated loss without waiting for a round trip. Later standards ask how reception damage should be reported, how streams should be synchronised, how several media types can share a transport context and how congestion controllers should receive packet-arrival information. Circuit-breaker work asks when optimisation has failed so badly that a flow should stop. Transport Services asks whether an application can request useful properties without committing too early to one protocol.

The recurring subject is not video as content. It is the control system that keeps time-sensitive traffic useful without granting it immunity from the rest of the Internet.

That makes real-time media an infrastructure story. The visible application may be a browser tab, conference room or specialist production system, but continuity depends on standards, implementations, middleboxes, access networks, identities, cryptographic choices and operating practice. A person profile becomes useful only when the individual is placed inside that system rather than above it.

Identity without inventor mythology

Colin Perkins is Professor of Internet Technologies in Computing Science at the University of Glasgow. His institutional biography records a BEng in Electronic Engineering from the University of York in 1992 and a PhD there in 1996. It then places him at UCL as a research fellow from 1996 to 2000 and at the University of Southern California’s Information Sciences Institute as a research assistant professor from 2000 to 2003.

His public IETF profile dates the beginning of his IETF and IRTF participation to 1996. That chronology matters because it shows continuity rather than one invention episode. Electronic engineering supplied a language of signals, timing and systems. UCL’s late-1990s multimedia environment placed him near experimental packet conferencing. A dated publisher biography from 2003 credits him with developing an early RTP teleconferencing implementation, a historical claim that is better kept attributed than treated as a complete comparison of early implementations.

USC/ISI connected the work to an institution deeply involved in Internet protocol research. Glasgow became the long-term base from which research, standards authorship, teaching and institutional leadership came together.

At the source cutoff of 3 August 2026, the IETF Datatracker listed 41 RFCs associated with Perkins and three active Internet-Drafts. It also listed current service on the Internet Research Steering Group and the Transport Area Review Team, while the IRTF identified him as an at-large IRSG member. He chaired the IRTF from 2019 through 2025 and had earlier co-chair roles in the Audio/Video Transport, Multiparty Multimedia Session Control and RTP Media Congestion Avoidance Techniques working groups.

These are substantial records, but each describes a different kind of authority. An RFC author is accountable for named text but does not own every implementation. A working-group chair manages scope, milestones, review and rough consensus but does not become the author of every document. An IRTF Chair coordinates research groups and publication review but cannot make an experimental result true or compel a vendor to deploy it. A review-team member can expose transport problems without possessing a veto over the Internet.

The most important attribution boundary concerns RTP itself. RFC 3550, the defining Real-time Transport Protocol specification, was authored by Henning Schulzrinne, Stephen Casner, Ron Frederick and Van Jacobson. Perkins was not one of those authors and should not be called the inventor or principal author of RTP.

His contribution begins where a common framework meets operational diversity: packet-loss repair, payload mappings, testing, session description, control feedback, privacy, congestion safety, WebRTC rules, multiplexing and transport evolution. The correct unit of credit is an ecosystem maintained over decades, not a heroic origin story.

RTP’s deliberately incomplete contract

RTP provides a common language for sending real-time data. Sequence numbers allow receivers to detect gaps and reorder packets. Timestamps relate packets to the media clock and help playout. Payload identifiers tell endpoints how contents should be interpreted. Source identifiers distinguish streams, while RTCP supplies reception reports and timing relationships.

These mechanisms make a stream intelligible. They do not guarantee that the stream will arrive on time.

That omission is deliberate. RTP normally runs over UDP and does not reserve capacity, prevent loss, enforce fairness or promise quality of service. Applications and companion mechanisms still have to decide how much buffering is acceptable, how repair should work, which security model fits the session, how congestion should change the sending rate and when the flow has become too harmful to continue.

No extension can erase the fact that the Internet path may have limited or changing capacity. This flexibility allowed RTP to support different media and network conditions, but extensibility has a cost. Every payload format has to define packet boundaries, clock behaviour and loss handling. Every feedback extension has to coexist with RTCP scheduling. Every multiplexing rule has to prevent one packet type from being mistaken for another. Every security choice changes what endpoints and operators can observe.

The standards family therefore grows through disciplined composition rather than one universal operating mode. Perkins’ 2003 book, RTP: Audio and Video for the Internet, made that composition easier to understand. It brought packet formats, timing, RTCP, payloads, error resilience, security and implementation into one technical account. The book was not the source of RTP, and it predates WebRTC and later QUIC work, but it helped practitioners see RTP as a system rather than a header format.

The durability of the framework is visible in the spacing of Perkins’ RFC record. Redundant audio appeared in 1997. Major SDP maintenance followed in 2006 and again in 2021. Port multiplexing, rapid synchronisation and RTCP extension guidance arrived in 2010. Circuit breakers became an RFC in 2017. A cluster of WebRTC, SDP, feedback and multiplexing documents appeared in 2021. Transport Services architecture and API documents followed in 2025.

This is not one invention being rediscovered. It is the maintenance history of an infrastructure substrate exposed to new codecs, browsers, network paths and security expectations.

Repair before the round trip

RFC 2198 addressed a simple timing problem through a measured trade-off. An RTP packet could carry the primary audio encoding and one or more redundant encodings of earlier media. If an earlier packet was lost, the receiver might recover enough information from a later packet without waiting for a round trip.

The mechanism spends bandwidth to improve the probability that useful audio arrives before its deadline. It does not eliminate loss or create free reliability.

The cost depends on codec rate, redundancy depth, loss patterns and congestion. Too little redundancy may not survive a burst. Too much consumes capacity and can make congestion worse. That is why the broader repair taxonomy published in RFC 2354 matters. Retransmission, forward error correction, interleaving and redundant transmission make different assumptions about delay and overhead.

The engineering task is to match a mechanism to the service deadline, not to declare one repair technique universally superior. This early work also established a pattern that runs through Perkins’ later record: design around the failure path. RFC 3158 considered how RTP implementations could be tested rather than assuming compliant behaviour. RFC 2736 turned implementation experience into guidance for authors of payload specifications. Session Announcement Protocol work addressed discovery in a multicast-oriented environment, while a local message bus addressed coordination among components around a session.

Some of those deployment assumptions later lost ground. SAP did not become the universal discovery layer for browser calling. NATs, firewalls, web service models and centralised application discovery changed the environment. A standards document can be well designed for a plausible architecture and still remain peripheral when the market and network path evolve.

Perkins’ later work on failed standardisation makes this point explicit: publication is an event, not proof of adoption. The deeper contribution of the early repair work is the idea of controlled degradation. Real-time communication can remain intelligible when damage is detected, bounded and handled before the deadline. That principle reappears later in RTCP reports, circuit breakers, partial reliability and time-aware transport research.

The goal is rarely perfect delivery. It is a system that knows when information has become useless and which response remains proportionate.

Describing, packetising and discovering a session

Media transport begins before the first RTP packet. Endpoints need a description of what they might exchange: media type, address, port, codec, timing and attributes. The Session Description Protocol provides that compact description.

SDP is declarative. It does not place a call, authenticate a participant, reserve bandwidth or carry media. A signalling system embeds and exchanges SDP so endpoints can negotiate compatible session parameters.

Perkins co-authored RFC 4566, the 2006 SDP revision, and RFC 8866, its 2021 replacement. The fifteen-year interval illustrates what specification maintenance looks like. The later text consolidated errata, clarified grammar and reflected evolved use. It did not convert SDP into a transport protocol.

Its durability lies in serving as an interchange format across signalling environments, including WebRTC, even though the supplied material does not provide an audited count of implementations or sessions. A textual format can look simpler than the behaviour around it. Extensions need registries and conventions. Parsers have to agree on grammar. Attributes have to mean the same thing to endpoints built by different organisations. Ambiguous prose can become divergent code and, in security-sensitive paths, an operational weakness.

That makes Perkins’ later work on parsing protocol standards relevant to his earlier SDP work. The distance between normative text and executable interpretation is itself an infrastructure risk.

Payload formats solve a related translation problem. RTP supplies common timing and sequencing, but a professional video signal and a compressed voice codec do not have the same packet boundaries, bit rates or tolerance for loss.

RFC 2736 offered reusable guidance for writing payload specifications. RFC 3497 mapped SMPTE 292M video into RTP, and RFC 4421 extended support for additional colour sampling modes in uncompressed video. These documents did not invent the media formats or the equipment. They described how existing representations could traverse a shared packet framework.

This kind of standards work is economically quiet but operationally important. A common transport substrate gains value only when heterogeneous media can be mapped into it without every implementation inventing its own interpretation.

The mapping is neither the camera nor the network. It is the agreement that lets independently built systems meet.

RTCP: when feedback becomes infrastructure

A sender cannot adapt responsibly if it knows only what it transmitted. RTCP gives participants a control channel for reception reports, source information and timing relationships.

Sequence gaps, jitter estimates, sender reports and receiver reports do not repair the path by themselves. They make the session observable enough for endpoints to diagnose loss, align media clocks and choose a response.

Perkins’ standards record repeatedly expands this control surface. RFC 5968 explains how RTCP can be extended without breaking packet structure or scheduling. RFC 6051 reduces the delay before related streams can be synchronised. RFC 8015 permits independent reporting of burst and gap discard metrics. RFC 8861 groups reception statistics and related feedback so reports remain associated with the intended streams.

Each document addresses a narrow failure of interpretation that can become significant when independently developed systems interoperate. Congestion control made arrival feedback more consequential. RFC 8888 defines a compact RTCP format for packet-arrival information, while RFC 9392 addresses feedback in interactive conferences.

These specifications provide measurements and reporting behaviour. They do not select one universal congestion-control algorithm. A controller still has to decide how to convert observed arrival patterns into a sending rate, and different access networks can produce similar symptoms for different reasons.

Feedback also creates privacy and scaling problems. RTCP canonical names help correlate streams associated with one endpoint, but persistent identifiers can make sessions linkable. RFC 6222 and its successor RFC 7022 revised guidance to reduce unnecessary exposure.

In large sessions, feedback must also be scheduled so the control plane does not consume the capacity it is trying to protect. Observability is valuable only when its cost and identity consequences remain bounded.

The Virtual RTCP research applied monitoring and incremental repair ideas to UDP-based IPTV. Its value is evidence of a defined architecture and evaluation, not proof of universal operator deployment. Its conceptual significance is stronger than its market claim: media quality emerges from a loop in which receivers expose enough state for a bounded response. That logic runs from early packet repair through WebRTC feedback and into modern transport APIs.

Congestion: safety before optimisation

RTP commonly uses UDP because applications need control over timing and loss response, but UDP does not supply congestion control. One attempt to combine datagram semantics with a congestion-controlled transport was the Datagram Congestion Control Protocol. RFC 5762 specified RTP over DCCP, while RFC 6773 proposed UDP encapsulation to improve traversal through NATs. RFC 6679 took another route by defining how RTP over UDP could negotiate and report Explicit Congestion Notification marks.

These documents expose a recurring deployment trap around transport innovation. A protocol can be technically attractive and still fail across paths that have accumulated assumptions about familiar traffic. Middleboxes may recognise TCP and UDP while treating something new as suspicious or unsupported. Encapsulation can improve traversability but adds overhead and another failure surface. ECN can signal congestion before packet loss, but only if network devices, endpoints and signalling preserve the marks.

Standards status therefore establishes a design and review record, not end-to-end availability. Perkins’ circuit-breaker work begins from a narrower problem than full congestion control. A controller tries to optimise sending rate so quality remains useful without causing persistent congestion. A circuit breaker asks when conditions have become so poor that continued transmission is no longer acceptable.

The distinction matters. An optimiser searches for a better operating point. A circuit breaker defines a safety boundary beyond which the flow stops.

The research history includes important counter-evidence. A 2013 proposal defined conditions and evaluated them in controlled settings. A 2014 LTE study found that mobile-network behaviour exposed weaknesses and motivated revisions. That is more informative than a clean success story because it shows the fail-safe being tested against a different path and then corrected before later standardisation.

The principle survived; the first assumptions did not survive unchanged. RFC 8083 eventually specified multimedia circuit breakers for unicast RTP sessions. The RFC does not promise perfect fairness, immediate recovery or a good call. It defines conditions under which continued transmission has become sufficiently harmful that the application must cease the problematic behaviour.

RMCAT, which Perkins co-chaired, provided a broader venue for congestion-control algorithms, traffic models and evaluation cases. The group concluded in 2023 after its planned work. Closure should not be read as proof that one controller conquered the market. It records the end of a standards work programme.

University and UK Research Excellence Framework material later linked the circuit-breaker programme to WebRTC standards and industry use. Those sources are relevant institutional evidence, but they are not an independent market census. A defensible causal chain is that research informed standards, and standards were implemented through collective engineering. It is not defensible to assign every resulting browser call to one paper or one researcher.

The circuit-breaker story is valuable precisely because it contains both impact and correction. Real-time media needs mechanisms that pursue quality, but it also needs a rule that local optimisation cannot outrank the health of a shared path.

WebRTC turned a standards family into browser infrastructure

WebRTC made many of these transport mechanisms visible to ordinary users without making the mechanisms themselves obvious. Browser communication has to work across access networks of uneven quality, through NATs and firewalls, with encryption, codec negotiation, congestion response and application APIs.

WebRTC is not one protocol. It is a collection of mechanisms whose interoperability depends on several standards and implementations working together.

RFC 8834 specifies media transport and RTP use in WebRTC. Perkins is a co-author, but the document represents working-group consensus built on the core RTP architecture and years of implementation experience. Calling it his personal design of WebRTC would erase the other authors, reviewers, browser engineers and service operators who made the stack usable.

The 2021 RFC cluster shows why mature infrastructure still requires maintenance. RFC 8860 allows several media types in one RTP session. RFC 8861 associates feedback and reception statistics with related streams. RFC 8866 revises SDP. RFC 8872 provides multiplexing guidance. RFC 8888 supplies congestion-control feedback.

Together these documents reduce some transport and port overhead while expanding the importance of identifiers, parsing and testing. That is not a contradiction. A system can become easier to deploy at the edge by becoming more explicit internally. Fewer ports and shared sessions can improve traversal through NATs and firewalls, while software has to distinguish packet types, stream identities and feedback relationships correctly.

Complexity does not disappear. It moves from the number of transport flows into structured state.

The social importance of browser media is clear in qualitative terms. Remote work, education, telemedicine and everyday communication rely on real-time media stacks. The source material for this profile does not provide a defensible global user count attributable to Perkins, one RFC or one implementation.

RFC 9075, the report from the IAB workshop on the network impacts of COVID-19, is evidence that Internet institutions were examining a sudden demand shock. It is not evidence that Perkins personally measured or solved every consequence of that shift.

The more useful conclusion is structural. WebRTC converted a standards ecosystem into browser infrastructure by requiring many narrow agreements to work together: description, connectivity establishment, secure keying, media transport, feedback, congestion safety and multiplexing. Perkins’ record is significant because it crosses many of those interfaces without making him the owner of the whole stack.

Security and multiplexing move complexity rather than remove it

Media security has no single deployment context. A private enterprise conference, public broadcast, browser call and regulated communication system have different trust boundaries.

RFC 7201 surveys security options for RTP sessions, while RFC 7202 explains why RTP does not mandate one universal solution. The existence of several options can reflect genuinely different requirements, but it also creates configuration and interoperability work.

Encryption protects content without automatically hiding every signal. RFC 6562 examines variable-bit-rate audio with Secure RTP because packet sizes and timing can still reveal information. Later work on transport-header confidentiality makes the wider trade-off clear: encrypting more metadata can protect users and permit endpoint evolution, while reducing information available for network diagnosis and middlebox operation.

Multiplexing creates a parallel trade-off. RFC 5761 allows RTP and RTCP to share a port when packet formats can be distinguished safely. RFC 8108 describes multiple RTP streams in one session. RFC 8860 extends that model across media types, and RFC 8872 supplies guidance.

The gain is fewer flows and ports. The cost is more demanding identifier management, collision handling and feedback association.

RFC 8861 shows why the detail matters. If a receiver attributes statistics to the wrong stream, a repair function or congestion controller can act on the wrong evidence. The protocol has not abolished complexity; it has moved that complexity into explicit grouping and demultiplexing rules.

The same issue appears in RFC 9443’s updates for QUIC multiplexing. Several logical protocols can share a secure connection only if endpoints agree unambiguously on what each unit belongs to.

Security and observability therefore cannot be treated as opposing absolutes. Operators need enough information to diagnose and control a service. Users need protection against unnecessary exposure and against intermediaries that freeze protocol behaviour around what they can inspect.

The standards record does not establish one permanent balance. It provides mechanisms and constraints through which each deployment has to make the trade-off visible.

Working around an ossified transport layer

Conventional TCP gives applications a reliable, ordered byte stream. For file transfer that is often exactly the right abstraction. For interactive media, one missing segment can hold newer but still useful information behind it.

New transports that provide partial reliability or message boundaries can solve the semantic problem and still face a deployment problem. Paths, operating systems and middleboxes have accumulated assumptions about TCP and UDP. A technically better transport can fail if the network does not carry it consistently.

TCP Hollywood explored whether an application could obtain unordered, time-lined delivery while retaining a TCP-compatible wire image. The prototype changed interfaces and receiver behaviour so useful data could be exposed before every earlier byte had arrived.

It was research, not an IETF standard or production replacement for TCP. Its value lies in making the compromise explicit: deployment may improve when a new service hides inside a familiar substrate, but some architectural constraints survive with it.

QUIC offered a different opportunity. It combines secure connection establishment, congestion control, multiplexed streams and user-space evolution over UDP. Yet an ordinary reliable stream can still be a poor fit for media that expires.

Perkins and collaborators examined deadlines, partial reliability and multiplexing for real-time audio-visual traffic. A public quic-p2p-mux repository records design and revision work. Repository activity proves that code or documents changed; it does not prove standards adoption or production deployment.

RFC 9443 later updated multiplexing schemes for QUIC. That RFC should remain separate from the earlier research and expired proposal. Some ideas move into standards maintenance. Others remain experiments whose value lies in the constraint they reveal.

An expired draft is not automatically a failed product, and an RFC is not evidence that every deployment uses it. QUIC also sharpens the observability question. Encryption protects protocol metadata and allows endpoints to evolve without waiting for every intermediary to understand the change. The same protection can remove signals operators once used for diagnosis. That makes transport-header confidentiality part of the same control problem that runs through RTCP: who can observe enough to keep a service safe, and under which privacy boundary?

From named protocols to requested properties

The traditional sockets API asks an application to choose a transport protocol early and then exposes mechanics associated with that choice. Once software is written around TCP or UDP assumptions, adopting a later transport can require substantial redesign.

The Post Sockets research proposed moving that decision boundary. An application should be able to describe communication intent and required properties rather than name a protocol as its first act.

RFC 9621 defines the architecture and requirements for Transport Services, and RFC 9622 describes an abstract API. Perkins is one of several authors in a multi-institutional standards lineage.

The documents do not abolish sockets, guarantee operating-system support or prove broad deployment. They define a model in which an application can request properties such as reliability, ordering, latency sensitivity, connection racing or interface preferences and allow the system to choose among available mechanisms.

The attraction is evolvability. A system could select a transport that fits the host, path and policy without requiring every application developer to understand each protocol.

This can weaken transport ossification by making new mechanisms available behind a stable intent interface. It can also hide consequential decisions. If two systems interpret the same preference differently, performance and failure behaviour become harder to reproduce.

For TAPS to become accountable infrastructure, applications and operators need to know what was selected, why it was selected, which fallback occurred and what properties were actually delivered. Abstraction should remove unnecessary coupling, not remove evidence. That is the same balance Perkins’ earlier work repeatedly confronts: a control layer is useful only when it exposes enough state to diagnose its decisions.

The institutions behind the packets

The IETF divides work so specialised communities can maintain different parts of the system. AVT and its AVTCORE successor focus on RTP payloads, feedback and maintenance. MMUSIC dealt with multimedia session description and control. RMCAT concentrated on congestion-control techniques for interactive media.

Perkins’ authorship and chairing crossed those boundaries, but the boundaries matter because they prevent one title from being mistaken for ownership of every result. Working-group chairs clarify scope, judge rough consensus, organise review, track milestones and escalate unresolved issues. They can determine whether a question receives sustained attention and whether a document is ready to progress. They cannot compel independent implementation or convert their own preference into a standard without the wider process.

This procedural authority is real because attention and review are scarce. It is also bounded because the work remains collaborative and voluntary.

The distinction between the IETF and IRTF is equally important. The IETF develops voluntary standards. The IRTF supports longer-term research through research groups and the Internet Research Steering Group. An IRTF publication can influence engineering without becoming an IETF standard.

When Perkins chaired the IRTF from 2019 to 2025, his responsibilities included supporting research-group chairs, coordinating the IRSG, overseeing publication review, representing the IRTF and maintaining relationships with the IETF, IAB and wider research community. The role carried ex-officio IAB participation, but not command over Internet architecture.

After that chair term, Perkins remained listed as an at-large IRSG member at the source cutoff and served on TSVART. He also appeared in current Applied Networking Research Workshop steering and IRTF travel-grant selection roles.

ANRW brings peer-reviewed work into the IETF meeting environment. The Applied Networking Research Prize recognises recent research relevant to Internet engineering. Travel grants address the cost of participation. These programmes influence visibility and access, which means criteria and conflict handling matter even though selection does not certify that a paper should become a standard.

RFC 9775, the IRTF Code of Conduct, belongs to this institutional layer. Conduct rules are infrastructure in the sense that a voluntary technical community can lose expertise if harassment or unmanaged conflict drives contributors away.

A code cannot prove that the culture is healthy, and the source material does not audit individual cases. It creates an explicit reference for expected behaviour, reporting and response. Perkins is a co-author, not the private owner of the policy.

The active draft on the role of the IRTF reflects the same period of institutional self-description. Its repository history records revision after review, including discussion of how the organisation is sustained. At the cutoff it remained an Internet-Draft, not an adopted constitutional rule. The distinction between reflection and authority should remain visible.

When standards become a research dataset

Perkins’ later research asks whether standards organisations can measure themselves with the same caution used to measure networks. The deployment study challenges an easy assumption: publication and citation do not necessarily show whether an RFC is implemented. Researchers can infer deployment from observable artefacts, but every inference depends on datasets, matching rules and what the public Internet exposes.

The RFC errata study uses reported mistakes as evidence about specification quality. Errata are useful because they record places where readers or implementers encountered trouble. They are also biased. A heavily implemented document may attract more reports than an obscure one. A low count can mean clarity, low use or defects that were never reported.

Measurement becomes misleading when a convenient proxy is treated as the phenomenon itself. “How not to IETF” examines unsuccessful standardisation attempts. Negative cases can reveal weak problem framing, missing implementation interest, unsuitable scope or process errors. A proposal that does not become an RFC is not automatically a failure. Some research remains useful because it identifies constraints or influences later work.

The useful object of study is the path and decision, not merely the final publication status. Protocol-parsing research looks at another gap: standards are written for people while implementations need precise machine behaviour. Extracting machine-usable descriptions can reduce ambiguity and support testing or code generation, but automation cannot resolve a contradiction that the specification itself leaves unclear.

A parser can reproduce ambiguity at greater speed. Work on IETF social graphs and two decades of affiliations expands the object of study from documents to people and institutions. Such datasets can show collaboration patterns and concentration, but names change, affiliations overlap and mailing-list participation is an incomplete proxy for influence.

The active draft on analysing standards-organisation data adds explicit warnings about identity resolution, missing records, privacy and ethics. At the cutoff it was an individual draft, not consensus guidance.

This research is most persuasive when it resists the temptation to rank people from incomplete traces. Standards memory includes RFCs, errata, mailing lists, repositories, meeting records and deployment evidence. It can expose blind spots and improve process. It can also create false precision or privacy harm. An institution studying itself therefore has to disclose method, uncertainty and the interests of the people whose activity is being measured.

Teaching, code and knowledge transfer

Perkins’ academic role ties the standards record to teaching and research supervision. The public evidence supports a long Glasgow base, collaboration across networking and distributed systems, and a technical bibliography that extends beyond media into routing, measurement and governance.

It does not provide a complete student list or justify attributing every later project to his mentorship. The RTP book remains the clearest synthesis of his early domain. Its value lies in turning dispersed specifications into an implementer’s model of packet formats, timers, feedback and failure. Its 2003 publication date also creates a useful boundary: it explains the conceptual foundation around the RTP revision of that era, not the later WebRTC, QUIC or TAPS environment.

Public repositories provide narrower evidence. The crtp project models RTP parsing, timed datagrams and session state in Rust. Its commit history shows particular code changes, while the project remained experimental and became inactive after 2017.

The quic-p2p-mux repository documents an experimental design process. ietfdata-rs shows maintenance of tools for analysing Datatracker data, including a 2026 test update rather than a major new method.

These records are valuable because they show specifications becoming types, timers and data pipelines. They do not establish production deployment or sole authorship of a field.

Knowledge transfer is broader than a lecture or code release. It includes specifications, review practices, testing guidance, books, repositories, workshops and institutions through which other engineers learn what assumptions a protocol makes. That teaching function helps explain how a career can influence infrastructure without owning a product company or operating a network.

The current frontier, with status kept intact

Three RFCs from 2025 show how far Perkins’ record had widened. RFCs 9621 and 9622 define Transport Services architecture and an abstract API. RFC 9775 addresses conduct in the IRTF.

One pair formalises how applications express transport intent. The other formalises how a research community expects participants to behave. Both replace tacit assumptions with interfaces or rules that can be inspected.

A 2026 paper on AS112 deployment shifts attention to a quiet part of DNS infrastructure that absorbs reverse queries for private-use addresses. The work is measurement, not ownership or operation of AS112. It reflects the same interest in what shared infrastructure actually does rather than what a document says it should do.

The active IRTF-role and standards-data drafts were both updated on 3 July 2026. They should be described by version and date because Internet-Drafts are temporary works in progress.

The Looma draft, dated 2 March 2026 in the supplied record, proposes low-latency post-quantum authentication for data-centre environments. It has several authors and, at the source cutoff, no standards standing, deployment record or completed security review established by the supplied evidence.

Its relevance is directional rather than conclusive: latency-sensitive infrastructure and cryptographic migration are beginning to meet in the same design space. Current roles and draft status are among the most time-sensitive facts in this profile. The Glasgow title, IRSG and TSVART membership, ANRW and travel-grant roles, draft versions and any additional RFCs should be rechecked at publication if the source cutoff changes. This manuscript uses the source record’s 3 August 2026 cutoff and does not turn that snapshot into a permanent biography.

A relationship map built through shared work

Perkins’ professional network is visible through co-authorship and institutions rather than a company hierarchy. The core RTP specification belongs to Schulzrinne, Casner, Frederick and Jacobson. Perkins’ later RFCs connect him with changing groups of media, transport, security and standards-process specialists.

The record does not describe one laboratory that owned a stack from end to end. It describes repeated collaboration around problems that crossed working-group and organisational boundaries.

The relationship between academia and the IETF is equally layered. Glasgow supplied a research and teaching base. Peer-reviewed papers tested mechanisms before or alongside standards work. The IETF provided open engineering forums. Browser and product teams supplied implementation pressure. The IRTF created space for questions not ready for an IETF charter.

None can substitute for the others. A paper without implementation can remain an interesting result. A working group without research can repeat untested assumptions. A product without shared specifications can create dependence on one vendor’s behaviour.

The circuit-breaker history makes the relationship concrete. Research proposed a safety condition. An LTE experiment exposed weaknesses. RMCAT provided a collective standards context. RFC 8083 recorded the resulting specification. University impact material later described industrial significance.

Each source establishes a different part of the chain. No one source proves the whole causal story, and no one participant owns all four stages.

The same is true of WebRTC. Perkins’ RFC authorship connects directly to browser-media infrastructure, but browser teams, codec developers, congestion-control designers, security specialists and service operators implemented the system.

Standards provide an interoperability framework. Running software decides which options are enabled, which errors users see and how quickly a fix reaches deployed endpoints. A profile that names only the standards author would hide the institutions with the greatest operational discretion.

His current relationships also cross technical and institutional domains. IRSG and TSVART service place him in review roles. ANRW steering and travel-grant selection connect research outreach with standards participation. Active drafts involve collaborators on governance methodology and post-quantum authentication.

These are forms of influence, but they remain bounded by review, co-authorship and the work-in-progress status of the documents. This map explains why “bridge” is a better description than “owner”. Perkins connects media transport, experimental research, specification writing and institutional governance. A bridge can shape which communities meet and which evidence travels between them. It does not control the destinations.

Limits, counter-evidence and what remains unknown

The first limit is deployment opacity. An RFC proves that text completed a publication process. It does not show how many systems implement the mechanism, whether an implementation is enabled or how it behaves in production.

The record is strong for SDP’s long life and the collective WebRTC implementation context. It is much weaker for current DCCP use, TCP Hollywood, peer-to-peer QUIC multiplexing and the scale of TAPS implementations.

The second limit is feedback quality. RTCP reports, ECN marks and arrival information can be delayed, aggregated or absent. Wireless loss, queueing and receiver constraints can produce signals that are easy to misread.

The LTE circuit-breaker study is important because it demonstrates that a safety mechanism can behave poorly in a new environment even when the principle remains sound. The third limit is the exchange between security and operability. More encryption can protect users and permit protocol evolution while reducing diagnosis. More security options can fit different trust models while increasing configuration risk. Multiplexing can reduce port count while increasing identifier and parser complexity. Machine-readable specifications can reduce manual translation while reproducing unresolved ambiguity.

These are design exchanges, not flaws that disappear under a new acronym. The fourth limit is institutional legitimacy. Open participation still has financial, geographic and professional barriers. Social and affiliation data can reveal concentration while exposing individuals or misclassifying relationships. Conduct codes, workshops, prizes and travel support address parts of the problem; the supplied evidence does not show that structural inequality has been solved.

Conventional personal biography is deliberately sparse. The source material provides no reliable basis for claims about Perkins’ birth date, age, citizenship, family, compensation, wealth, university equity or commercial ownership.

It does not support a founder-wealth story. The strongest profile remains technical and institutional: an account of standards, research and governance rather than an invented private life.

Why Perkins’ work matters now

The Internet did not become suitable for real-time media by acquiring a universal guarantee of timeliness. Endpoints learned to work with uncertainty. They sequence and timestamp packets, conceal or repair bounded loss, exchange feedback, adapt to capacity, protect content, distinguish streams and stop when continued sending becomes destructive.

The network remains best effort. The control system around media became more capable.

Perkins helped build that control system across several layers. His record begins with redundant audio and repair, extends through payload guidance, SDP and RTCP, reaches congestion safety and WebRTC, and continues into QUIC and Transport Services.

The sequence is useful because it includes mechanisms that became embedded in widely used infrastructure, mechanisms whose current use is unclear and experiments that remained outside standards. A mature infrastructure history needs all three categories.

His institutional work adds the second half of the argument. Protocols are not maintained by documents alone. They need working groups, review teams, research communities, conduct rules, outreach, measurement and institutional memory.

These institutions distribute authority and can also concentrate attention. Perkins’ later research asks them to make their evidence and limitations more visible.

The strongest conclusion is therefore neither celebratory nor reductive. Perkins did not invent Internet video. He became one of the persistent architects and stewards of the ecosystem that lets real-time media fail gracefully, learn from feedback and coexist with other traffic. The same career then applied those habits to the standards process itself: observe the system, test the claim, preserve the counter-example and distinguish what is published from what is actually used.