Summary

  • Paul Saab's strongest public record is tied to Facebook and Meta infrastructure: official Meta Engineering bylines on IPv6, co-authorship of the 2013 USENIX paper "Scaling Memcache at Facebook," and a person-specific LinkedIn post connecting him to Meta's Arm CPU port.
  • The record supports a people profile about infrastructure judgment rather than a full personal biography. It shows decisions around network transition, cache architecture, and data-center compute, but it does not establish a complete career history or isolate every individual contribution.
  • The Arm connection should be read carefully: official Meta and Arm intelligence team pages establish the Meta-Arm AGI CPU project, while Saab's personal attribution to starting the port comes from his own LinkedIn post.
  • Registry evidence around ARIN, AS64203, and 8/18 Productions LLC is useful for identity and context, but it is thinner than the Meta/Facebook evidence and should not be treated as the spine of the profile.

The Public Shape of the Record

Paul Saab appears in the public infrastructure record less as a public-facing corporate narrator than as an engineer attached to systems that only become visible when something foundational is changing. The clearest evidence comes from Meta Engineering, where an official author archive lists Paul Saab posts on Facebook's IPv6 work, including pieces published in 2013, 2015, and 2018. That archive is not a full biography. It does not give a complete title history, a complete list of teams, or a narrative of private career choices.

Its value is narrower and more useful: it places Saab's name on technical explanations of how a platform at Facebook's scale moved parts of its network stack into the next internet protocol era.

That distinction matters. A weaker profile would try to inflate sparse public facts into a personality sketch. The stronger reading is more disciplined. Saab is visible where the evidence is visible: in Facebook's IPv6 migration commentary, in an academic systems paper about memcache at Facebook, in a standards-community acknowledgement around parallel NFS device recall requirements, in ARIN registry material, and in a 2026 LinkedIn post about Meta's Arm CPU port. Those traces are enough to profile a particular kind of infrastructure operator, but they are not enough to invent private motives, management style, or undocumented roles.

The public record also spans different layers of modern internet infrastructure. IPv6 is an addressing and routing transition problem, but at a company like Facebook it was also a user-performance problem, a vendor-coordination problem, and a measurement problem. Memcache is an application-performance system, but in Facebook's published account it became a distributed architecture that had to absorb billions of requests per second and trillions of cached items.

The Arm CPU port, if read through Saab's self-published claim and the official Meta and Arm announcements, moves the focus again, this time to data-center silicon and the compute substrate for agentic AI workloads. These are not identical domains. They do, however, share one operating theme: the platform changes only if engineers can translate a broad infrastructure shift into production decisions that survive real traffic.

That is why Saab is a useful subject for BTW coverage. The visible facts do not present him as a celebrity founder or a corporate spokesperson. They present him as a repeat entity in infrastructure transitions that are easy to abstract away and hard to execute. The record begins with named Facebook work around IPv6, reaches back into the cache layer through the USENIX memcache paper, touches storage standards through an IETF draft acknowledgement, and extends into the public Meta-Arm silicon story through a self-attributed post. Each source has limits.

Together, they form a credible picture of an engineer whose public footprint is best understood through the operating surfaces he appears beside.

Why IPv6 Was More Than a Protocol Story

The strongest continuous evidence around Saab is the IPv6 material published by Facebook's engineering organization. In 2013, a Meta Engineering post carrying his byline marked the first anniversary of the global IPv6 launch and described Facebook's follow-through after the public launch event. The same evidence identifies Saab as an infrastructure engineer. The content is important because it treats IPv6 not as a symbolic standards milestone, but as an operational transition that had to be pushed through real infrastructure, internal support, and the wider network ecosystem.

For the broader internet, IPv6 has long carried the awkward status of an obviously necessary migration that still depends on countless local decisions. The address-space argument is familiar: IPv4 was not built for a permanently connected world of phones, cloud regions, residential broadband, carrier networks, and machine-to-machine endpoints. But the migration does not happen merely because the argument is true. It depends on network operators, device vendors, content platforms, access providers, and large-scale application teams all choosing to make the new path work well enough that users do not notice the transition.

Facebook sat in a particularly consequential position. It was a major content destination for consumer networks, a large operator of internal infrastructure, and a platform whose performance problems could be observed at enormous scale. A decision inside Facebook about how to test, prefer, retain, or debug IPv6 traffic could affect not only Facebook's own traffic mix, but also the incentives facing access networks and vendors. The 2013 post, the 2015 post, and the 2018 post together show the same broad operating posture: IPv6 adoption was not treated as an external phenomenon that Facebook passively measured.

It was something Facebook could influence by making the service usable, fast, and persistent over IPv6.

The 2015 Meta Engineering post credited to Saab sharpened the performance argument. According to the public reference, Facebook said it had moved early to IPv6 and observed 10 to 15 percent faster access over IPv6. That is a significant claim because performance changes the adoption conversation. If IPv6 is only a compliance requirement or a defensive response to address scarcity, operators can postpone the work when the short-term business case looks thin. If IPv6 can be associated with faster access for users, the case becomes more operationally attractive. It connects a network architecture transition to everyday product experience.

The same kind of reasoning appears again in the 2018 Meta Engineering post. That post, also carrying Saab's byline, reported that Facebook's U.S. IPv6 traffic crossed 50 percent in 2018. It also said major U.S. mobile carriers directed more than 75 percent of Facebook traffic over IPv6. Those figures placed IPv6 adoption in a concrete traffic frame: not just "more networks support it," but "a large share of real Facebook traffic now reaches the platform this way." For a company serving billions of users, that kind of threshold is not a public-relations detail.

It is a sign that the operational default has begun to shift.

The Happy Eyeballs Lesson

One of the most telling details in the 2018 IPv6 evidence is the connection to Happy Eyeballs, the client-side connection behavior meant to avoid punishing users when one address family is slow or broken. The source summary says the post tied improved IPv6 retention to an implementation adjustment of the Happy Eyeballs connection algorithm. That detail may sound small, but it gets to the core of infrastructure adoption: users do not reward architectural correctness. They reward reliability and speed. If the IPv6 path looks worse, clients and operators will fall back to IPv4, and the migration loses momentum even if support exists on paper.

Happy Eyeballs exists because dual-stack networking can create bad user experiences when software waits too long for the wrong path. A device may have both IPv4 and IPv6 available, but one of those paths may be degraded, misconfigured, filtered, or simply slower in a particular network. A naive implementation can make the user pay for that uncertainty. A better implementation races or stages connection attempts so that the application chooses a working path quickly. The result is not ideological preference for one protocol. It is pragmatic path selection that keeps the application responsive.

For Facebook, that kind of mechanism could change the practical economics of IPv6 traffic. If the platform and its clients moved too aggressively toward IPv6 without protecting user experience, every failure would become evidence against the transition. If they moved too timidly, working IPv6 paths would remain underused. The 2018 evidence suggests that an implementation adjustment helped retain more traffic on IPv6. That is exactly the kind of engineering move that turns a strategic preference into measured adoption: not a speech about the future of addressing, but a change in connection behavior that makes the future less brittle.

Saab's byline on that post does not mean every detail of Facebook's Happy Eyeballs implementation can be attributed personally to him. The source is a corporate engineering publication, and infrastructure work at this scale is collective. The responsible inference is narrower: Saab was a named public author explaining how Facebook understood and improved IPv6 deployment. That is still meaningful. It places him in the small group of engineers whose public work helped translate a protocol migration into operational practice at one of the internet's largest application platforms.

The Happy Eyeballs detail also shows why people profiles in infrastructure require a different lens from profiles in consumer technology. A consumer-product profile can often point to visible features, launches, and user behavior. An infrastructure profile often has to look at thresholds, fallbacks, control loops, and measurement. The work matters because it changes the conditions under which other systems can run.

Saab's IPv6 record is valuable precisely because it sits in that less visible layer, where a connection algorithm adjustment can help determine whether a platform keeps using the modern protocol path or quietly retreats to the old one.

Memcache and the Problem of Internal Scale

The second major public anchor is "Scaling Memcache at Facebook," the 2013 USENIX NSDI paper that lists Paul Saab of Facebook Inc. as a co-author. The paper is not a personal memoir. It does not isolate Saab's individual contribution, and it should not be used to claim that he alone designed Facebook's cache architecture. But co-authorship on that paper is still strong person-level evidence because the system it describes was central to Facebook's ability to serve a massive social application at production scale.

The evidence summary describes the paper as a distributed memcache architecture handling billions of requests per second and trillions of items. Those numbers matter because they locate the work in a different class from ordinary caching. In small systems, cache design can be treated as an optimization: add a cache, reduce database load, improve response time. At Facebook's scale, caching becomes a central coordination problem. It has to handle hot keys, data freshness, regional distribution, failure modes, back-end protection, client behavior, and operational visibility. A cache miss is no longer just a local inefficiency.

A poorly managed cache layer can amplify load, expose users to stale or inconsistent experiences, or transfer stress into databases and services that were not designed for that sudden demand.

Memcache at Facebook also reveals a different side of infrastructure judgment from the IPv6 posts. IPv6 work is partly about moving between public internet protocols while preserving user experience and encouraging ecosystem adoption. Memcache work is about internal platform mechanics: how a large service organizes memory, request routing, invalidation, and data access so that a dynamic product remains responsive. The public evidence links Saab to both kinds of problems.

That combination is important because it suggests a career trace not limited to one narrow technology, but to a recurring operating question: how do you make a system behave predictably when the scale is too large for simple assumptions?

The USENIX source also gives the profile a useful external anchor. Corporate engineering blogs are valuable primary sources, but an NSDI technical paper sits in a research venue where system design is presented for peer scrutiny. Again, this does not turn a co-author into a sole inventor. It does show that Saab's name appears on a published system account that the infrastructure community can read, cite, and evaluate. For a people profile, that is stronger than a job title. It is a public technical artifact.

The memcache evidence changes how the IPv6 evidence should be read. Without it, Saab might appear only as a public author on Facebook's network-transition messaging. With it, he appears in the production systems layer beneath the application as well. The through-line is not publicity. It is operational scale. Whether the problem is retaining IPv6 traffic or serving cached data across a massive social graph, the public record places Saab near mechanisms that have to work under load and under failure.

From Network Adoption to Platform Resilience

The 2015 and 2018 IPv6 posts are not only about adoption percentages. They are also about resilience. A platform that supports IPv6 early, measures user performance, and adjusts connection behavior is making a bet that the network layer should become more flexible rather than more fragile. The same is true of a large distributed cache: it absorbs pressure, reduces dependence on slower backing systems, and creates a controllable layer between users and data stores.

These are different technical mechanisms, but they are linked by a shared infrastructure concern: reduce the number of ways a global service can be slowed down by avoidable bottlenecks.

That is why Saab's record should be read as part of the broader history of platform resilience at internet scale. The internet's largest applications did not become reliable merely by buying more servers. They became reliable by learning where to place state, how to route around failures, how to prefer one path over another, when to retry, when to fall back, and how to observe systems whose failure modes were too distributed to debug by instinct alone. The public artifacts attached to Saab sit squarely in that history.

In the IPv6 material, the resilience challenge is outward-facing. Facebook had to deal with access networks, carriers, clients, and the public internet path between users and Facebook infrastructure. The 2018 evidence that major U.S. mobile carriers directed more than 75 percent of Facebook traffic over IPv6 suggests that carrier adoption had reached a point where the platform could observe material traffic shifts. But the Happy Eyeballs detail reminds us that adoption alone was not enough. The path had to stay good enough that clients would keep using it.

In the memcache material, the resilience challenge is inward-facing. Billions of requests per second and trillions of items describe an internal system operating at a scale where small inefficiencies become large costs and small inconsistencies can become user-visible faults. The cache layer had to protect back-end systems while preserving the responsiveness of the product. It had to act as both performance tool and shock absorber. Co-authorship of the USENIX paper places Saab in the public technical record of that internal resilience work.

This is the better way to understand the profile. It is tempting to write about infrastructure people by collecting every named organization around them and treating that as a career map. The evidence here argues for a more selective approach. The strongest record is not the longest list of affiliations. It is the set of public artifacts where Saab's name appears beside systems that changed how Facebook handled scale, network transition, or compute direction. Those artifacts have different levels of specificity, and the caveats matter. But they are enough to show a coherent operating surface.

The Standards-Community Trace

One of the smaller but still useful items in the evidence is the IETF Datatracker entry for a 2014 draft, "Device Recall for pNFS." The source summary says the draft acknowledges Trond Myklebust and Paul Saab in initial requirements. This should not be overread. It is not a full authorship claim, not a product launch, and not a broad standards leadership record. Its value is as a supporting technical trace around storage and infrastructure work.

The reason it belongs in the profile is that pNFS, like memcache and IPv6, sits below the consumer surface. Parallel NFS concerns how clients and storage systems coordinate access in distributed environments. A device recall mechanism is the sort of detail that matters when storage resources, clients, and layouts must remain correct as conditions change. Even without treating the acknowledgement as a central achievement, it adds texture to the public picture: Saab's visible infrastructure context was not confined to one blog channel or one public paper.

This trace also helps prevent a too-simple reading of the profile. If the story is framed only as "the IPv6 engineer," it misses the cache and storage signals. If framed only as "the Arm CPU port person," it relies too heavily on a single self-published 2026 post and the official corporate announcements that do not name him. A more accurate account is layered. The strongest public evidence is Meta/Facebook engineering work. The memcache paper supplies external systems-publication weight. The IETF acknowledgement adds a smaller standards-community signal.

The Arm material extends the story into data-center compute, but with a clear attribution boundary.

In infrastructure coverage, small traces can be useful when they are handled honestly. They help establish that an engineer appears across adjacent domains, but they do not automatically prove responsibility, hierarchy, or impact. The pNFS acknowledgement should therefore be treated as a minor supporting element. It indicates that Saab's name appeared in a technical requirements context around storage. It does not tell us how much work he did, what role he held, or whether the draft changed later implementations. The article can use it only in that limited way.

That discipline is especially important for people profiles built from public technical records. Infrastructure engineers often leave traces in papers, acknowledgements, registry contacts, conference pages, and corporate engineering posts rather than in formal biographies. The temptation is to connect every trace into a dramatic career story. The better practice is to rank the evidence. For Saab, the pNFS acknowledgement sits below the Meta Engineering posts and the USENIX paper in evidentiary weight, but it still points in the same general direction: systems work below the visible product layer.

Registry Evidence, and Why It Is Not the Story

The ARIN material provides identity and registry context, not a full article spine. The reviewed ARIN evidence identifies "Saab, Paul" as ARIN POC SAABP1-ARIN, with a public registration date of July 18, 2023, and an update date of March 28, 2025. The related AS64203 record connects the 8/18 Productions LLC and AS64203 context to the ARIN registry surface. These records are official registry evidence, and they help confirm that the name appears in network-resource contexts. But they are not comparable in depth to the Meta/Facebook engineering record.

That limitation is not a weakness if it is made explicit. ARIN point-of-contact records are administrative artifacts. They tell readers that a person or organization appears in a registry system, and they can help connect names to network resources. They do not, by themselves, explain why a person matters to infrastructure history. They do not describe engineering decisions, system architecture, performance results, or organizational outcomes. For Saab, the ARIN traces belong in the evidence map because they align with the broader network-resource theme. They do not carry the profile.

The ARIN material also comes with a specific caveat. The evidence says the POC output noted that the contact had not responded to ARIN validation since March 28, 2026. That should not be converted into a broader claim about current contact quality, operational responsiveness, or professional conduct. It is a registry validation note. In this article, it serves only as a caution around how to read the record: the ARIN entry helps identify a public registry contact and related dates, while the validation note limits any inference about current contact status.

The same restraint applies to 8/18 Productions LLC. The relation is registry-backed but thin compared with the Facebook and Meta evidence. It can be named as context because the reviewed registry records connect it to AS64203 and the ARIN registry surface. It should not become the narrative center. A profile built around 8/18 Productions would force too much weight onto too little public information. A profile built around Saab's Meta/Facebook engineering record has a firmer basis: named posts, measurable IPv6 traffic results, a USENIX systems paper, and institutional Arm context.

Registry evidence is valuable in infrastructure journalism precisely because networks are administered through public records. But public records are not all the same kind of evidence. A route record, POC entry, autonomous system record, or company registration can establish presence in an administrative layer. It cannot substitute for technical output. The right use of the ARIN and AS64203 material here is to strengthen identity confidence and acknowledge the network-resource context, while leaving the article's center of gravity where the public technical record is strongest.

The Arm Port Claim and the 2026 Silicon Context

The most current and potentially most consequential item in the record is also the one that requires the most careful attribution. A LinkedIn post attributed to Paul Saab says he started Meta's Arm CPU port with five engineers in 2022 and that the effort had grown to roughly 1,000 engineers by 2026. That is a person-specific statement, but it is self-published. It should be used as Saab's own account, not as independent confirmation of every internal detail.

The official institutional context comes from Meta and Arm intelligence team announcements on March 24, 2026. Meta announced a partnership with Arm to develop a new class of data-center silicon, and the evidence summary says Meta is the lead partner and co-developer for the Arm AGI CPU. Arm's announcement likewise identifies Meta as lead partner and co-developer and frames the outcome as data-center or agentic AI infrastructure silicon. Those official pages establish that the Meta-Arm project exists and that it is institutionally important. They do not name Saab directly.

The responsible construction is therefore two-part. First, the official Meta and Arm pages establish the public project: Meta and Arm working together on Arm AGI CPU data-center silicon. Second, Saab's LinkedIn post supplies the person-specific claim that he started the port with a small team in 2022 and saw the effort grow substantially by 2026. The article should not collapse those two evidentiary layers into one. It should not say Meta or Arm credited Saab unless the public record says they did. It should say Saab publicly self-attributed the start of the port, while official company pages confirm the broader institutional project.

If read with that caution, the Arm material extends the same pattern visible in the earlier evidence. Facebook's IPv6 work was about moving a global platform into a new network default without breaking user experience. Memcache at Facebook was about building a cache layer capable of absorbing immense product demand. The Arm CPU port, as Saab described it, would be about moving software and operational assumptions onto a different data-center compute platform. In each case, the technical change is not merely a technology swap.

It is a production transition that forces teams to decide what to measure, what to rewrite, what to tolerate, and how to preserve reliability while the substrate changes.

The 2026 timing also matters. AI infrastructure made data-center compute a more visible strategic surface. A CPU partnership between Meta and Arm is not just a chip announcement; it sits inside the larger contest over how hyperscale operators adapt hardware, software, and workload placement for the next generation of AI and platform services. The available public evidence does not let us describe Saab's internal role beyond his self-published statement.

It does, however, allow a narrower observation: the same public record that connects him to Facebook's earlier internet and cache transitions now connects him, through his own account and official institutional announcements, to Meta's Arm-based data-center compute direction.

What the Evidence Says About Engineering Judgment

The public evidence does not reveal Saab's private management methods, team structure, or complete scope of responsibility. But it does say something about engineering judgment. Across the strongest sources, the recurring problem is how to move a large platform through infrastructure change without losing the properties users and operators already depend on. That is a specific kind of judgment. It is not simply the ability to adopt a new technology early. It is the ability to keep the service intact while the underlying assumptions change.

In the IPv6 case, the judgment appears in the connection between adoption and experience. Facebook could have treated IPv6 as a binary feature: supported or not supported. The public posts instead point to measurement, performance, and retention. The 2015 evidence that Facebook observed 10 to 15 percent faster access over IPv6 made a case that the new path could improve experience. The 2018 evidence that U.S. Facebook IPv6 traffic crossed 50 percent and that major U.S. mobile carriers directed more than 75 percent of Facebook traffic over IPv6 showed the transition in traffic terms.

The Happy Eyeballs adjustment showed that implementation detail mattered.

In the memcache case, the judgment appears in scale discipline. A cache layer handling billions of requests per second and trillions of items cannot be treated as an accessory. It becomes a central production system. Its design has to balance speed, correctness, invalidation, locality, and operational control. Co-authoring a paper on such a system places Saab in a public record of engineering work where the stakes were not theoretical. The service was already enormous, and the architecture had to make that scale tractable.

In the Arm case, the judgment, as far as the evidence permits, appears in the willingness to begin a porting effort before the institutional announcement made the work public. Saab's LinkedIn post says he started the port with five engineers in 2022; official Meta and Arm announcements came in 2026. If that self-published account is accurate, the work illustrates another familiar infrastructure pattern: major platform transitions begin years before they become easy to describe publicly. The visible announcement is the end of a long internal road, not the beginning.

Taken together, these episodes show an engineer attached to transition work rather than maintenance alone. Maintenance is essential, but the public artifacts here emphasize moments when Facebook or Meta had to change a foundational layer: the internet protocol path, the cache architecture, and the compute target. The evidence does not prove that Saab led all of those efforts. It does show his name on the public record at each point, with varying degrees of specificity. That is enough to describe a meaningful public infrastructure footprint.

The Organizational Context: Meta, Facebook, Arm, and the Ecosystem Around Them

Saab's profile also illustrates how infrastructure work rarely belongs to one organization alone. The Facebook and Meta evidence is strongest, but the systems around it involve carriers, standards bodies, conference communities, registries, and silicon partners. IPv6 adoption required alignment across content platforms and access networks. The 2018 evidence around major U.S. mobile carriers shows that the traffic shift was not an internal Facebook-only event. It depended on networks carrying user traffic over IPv6 at meaningful scale.

The memcache work, although internal to Facebook's production environment, entered the public systems community through USENIX. That publication route matters because it let the wider community learn from Facebook's architecture. Large internet companies often build systems whose details remain private. When they publish, the record becomes a way for other engineers to understand the tradeoffs behind a production design. Saab's co-authorship places him in that outward-facing technical exchange.

The IETF draft acknowledgement points to another form of ecosystem participation. Standards work and requirements discussions often move slowly and leave partial traces. They are not always headline-making. But they shape the shared assumptions under which infrastructure components interoperate. Saab's acknowledgement in the pNFS device recall draft is modest evidence, yet it sits in a familiar pattern for infrastructure engineers: part of the work happens in the spaces where requirements, implementations, and operational needs are negotiated.

The Arm project adds a different ecosystem layer. Meta and Arm's 2026 announcements frame the AGI CPU as a data-center silicon effort, with Meta as lead partner and co-developer. That places Meta not only as a software and services operator, but as a direct entity in hardware direction for AI-era infrastructure. Saab's own LinkedIn attribution, used carefully, connects him personally to the earlier porting work that would make such a transition possible. Again, the article must keep the company statements and the self-published attribution separate.

But the combined context shows how platform infrastructure now stretches from application behavior down to silicon.

This ecosystem view also helps explain why the 8/18 Productions and ARIN traces are context rather than core narrative. Network-resource records are part of the infrastructure environment, and they can help verify identities or relationships. But the article's public-interest value comes from the higher-confidence technical record around Facebook and Meta. The strongest story is not that Saab appears in a registry. It is that his name appears across multiple public artifacts tied to how very large systems change.

What Remains Unproven

A disciplined profile should make the limits as visible as the claims. The first limit is biographical. The public evidence reviewed here does not provide a complete biography of Paul Saab. It does not establish education, early career, personal history, full title history, compensation, reporting lines, or private decision-making. The article therefore avoids those topics. It treats Saab as a public technical subject because the available record supports that, not as a fully mapped executive figure.

The second limit is attribution. Official Meta Engineering bylines identify Saab as an author on the IPv6 posts. The USENIX page lists him as a co-author of the memcache paper. The IETF draft acknowledges him in initial requirements. Those are public attributions, but they do not isolate every individual contribution inside team efforts. Infrastructure work at Facebook scale is collaborative by nature. The article can say Saab was publicly attached to these works. It should not claim he alone drove outcomes that the sources describe as organizational systems.

The third limit concerns LinkedIn. The 2026 Arm port claim is person-specific, but it is self-published and may be constrained by login or JavaScript access in some contexts. The available evidence supports using it for Saab's own attribution. It does not support presenting the claim as independently verified by Meta or Arm. The official company pages establish the Meta-Arm AGI CPU project and Meta's role as lead partner and co-developer. They do not name Saab. This distinction is central to any fair reading of the Arm material.

The fourth limit concerns registry and company context. ARIN POC evidence and AS64203 context are real but administrative. The 8/18 Productions LLC relation is registry-backed, but thin compared with the Meta/Facebook record. The ARIN validation note says the contact had not responded to ARIN validation since March 28, 2026; this is a caution about the registry record, not a basis for a broader judgment. Those facts belong in the evidence map, not in the lead.

The fifth limit is visual. No clean public frontal portrait was verified for this pass. Any image associated with this article should therefore be non-face contextual: data-center hardware, network operations, IPv6 routing context, cache infrastructure, or a silicon-development workspace. It should not imply that a generated face is Saab, use a private likeness, include logos, or insert readable text. The image should help readers understand the infrastructure domain, not fabricate identity.

Why Saab's Record Matters Now

Paul Saab's public record matters because the internet's most important transitions increasingly happen in layers that ordinary users cannot see. IPv6 adoption determines how networks address and route a growing world of devices. Cache architecture determines whether a social platform can answer dynamic requests at planetary scale. Data-center CPU strategy determines how a company like Meta adapts compute to AI-era workloads, power constraints, software portability, and hardware supply. These are not glamorous surfaces, but they are governing surfaces.

The profile also shows how infrastructure continuity works across time. The 2013 IPv6 anniversary post and the 2013 memcache paper belong to an earlier era of Facebook scale, when the company was turning rapid growth into durable systems. The 2015 and 2018 IPv6 posts show an adoption curve maturing into measurable traffic results. The 2026 Arm context belongs to a different era, one in which large platform operators are increasingly explicit about shaping their own silicon paths. The technologies changed, but the operating question stayed familiar: can the platform move to a better substrate without breaking the service?

That continuity is useful for readers watching the next generation of internet infrastructure. The public conversation about AI data centers often focuses on chips, model training, power, and capital expenditure. Those issues matter. But the work of moving real services onto new hardware also depends on porting, compatibility, performance measurement, and long-running engineering persistence. Saab's self-published claim about starting the Arm port with five engineers in 2022, if read with the proper caveat, is a reminder that institutional announcements are often preceded by years of practical engineering work.

The IPv6 evidence offers a parallel lesson. Protocol transitions can look slow and abstract until enough operational decisions accumulate. Facebook's reported 2018 U.S. IPv6 threshold did not arrive only because IPv6 existed. It arrived because networks deployed it, clients used it, platforms supported it, and implementation details such as Happy Eyeballs behavior made the path tolerable. The people who work on those details rarely become household names. Their decisions still shape the internet's default path.

The memcache evidence adds a third lesson: scale is not one problem. It is a sequence of constraints that appear at different layers. A cache system, a network protocol transition, and a CPU port do not share the same code. They do share the same demand for disciplined engineering under load. Saab's public footprint is compelling because it touches those different layers without requiring the profile to invent a broader mythology. The record is enough. It shows a person repeatedly attached to infrastructure work where the hidden layer becomes strategic.

Evidence Map

The main source for Saab's Meta/Facebook IPv6 record is the official Engineering at Meta author archive, which lists multiple Paul Saab posts, including 2013, 2015, and 2018 IPv6 coverage [S3]. The 2013 post identifies Saab by byline, describes Facebook's post-launch IPv6 work, and identifies him as an infrastructure engineer [S4]. The 2015 post, also bylined to Saab, says Facebook moved early to IPv6 and observed 10 to 15 percent faster access over IPv6 [S5]. The 2018 post reports that Facebook's U.S. IPv6 traffic crossed 50 percent, ties improved IPv6 retention to a Happy Eyeballs implementation adjustment, and says major U.S.

mobile carriers sent more than 75 percent of Facebook traffic over IPv6 [S6].

The main source for the cache layer is the USENIX NSDI page for "Scaling Memcache at Facebook," which lists Paul Saab of Facebook Inc. as a co-author and describes a Facebook memcache architecture handling billions of requests per second and trillions of items [S7]. The standards-community trace comes from the IETF Datatracker page for "Device Recall for pNFS," whose source summary says the draft acknowledges Trond Myklebust and Paul Saab in initial requirements [S8].

The Arm context has two layers. Saab's person-specific attribution comes from a LinkedIn post in which he says he started Meta's Arm CPU port with five engineers in 2022 and that the effort had grown to roughly 1,000 engineers by 2026 [S9]. The official institutional context comes from Meta's March 24, 2026 announcement of a partnership with Arm to develop data-center silicon and from Arm's March 24, 2026 announcement framing the Arm AGI CPU, with Meta identified as lead partner and co-developer [S10, S11]. Those company announcements do not name Saab, so the person-specific attribution should remain tied to the LinkedIn post.

The registry context comes from ARIN RDAP records. The SAABP1-ARIN entity identifies "Saab, Paul" as a public ARIN POC and shows public registry dates including a 2023 registration date and a 2025 update date [S1]. The AS64203 RDAP record provides a registry locator connected to the 8/18 Productions LLC and AS64203 context [S2]. The ARIN POC validation note says the contact had not responded to ARIN validation since March 28, 2026; this article treats that note as a limit on contact-status inference, not as a broader claim.

The result is a profile with a clear center and clear boundaries. The center is Saab's public technical attachment to Meta/Facebook infrastructure transitions: IPv6 adoption, memcache scale, and the Arm CPU port context. The boundaries are equally important: no invented personal biography, no overclaiming of individual authorship inside team systems, no use of 8/18 Productions as the main story, no claim that Meta or Arm officially named Saab in their 2026 announcements, and no portrait imagery where none was verified.