socc-topic-selection

SoCC Topic Selection

Decide the venue before drafting. SoCC — the ACM Symposium on Cloud Computing — is the **only

conference co-sponsored by SIGMOD and SIGOPS**, and that joint sponsorship is its identity: it

sits at the systems-and-data intersection of cloud research. Reviewers read for a **cloud

contribution that matters at scale**, and the venue explicitly welcomes not just clean-slate

systems but measurement studies, experience papers, and cloud-economics work that a pure

OS/networking flagship might treat as second-class. A technically strong paper whose real home is

kernel scheduling, network fabric, or query-optimizer internals is respected and then routed

elsewhere.

The routing question that matters most

The decisive question is rarely "is this cloud?" but **"does this contribution live at the

systems-and-data intersection that SoCC owns, or is it a pure-systems or pure-data result better

served by a specialized flagship?"** SoCC's sweet spot is the paper that a *datacenter operator or

cloud platform team* would act on: storage and data services, resource management and scheduling,

serverless, multi-tenancy, big-data and ML-systems infrastructure, edge/fog, and the cost and

economics of running all of it.

Sibling-venue routing table

| Signal in your project | Better home | Why |

|---|---|---|

| Cloud infrastructure at the systems+data intersection: storage/data services, resource mgmt, serverless, ML-systems infra, multi-tenancy, cloud economics | ACM SoCC | The joint SIGMOD+SIGOPS venue; welcomes systems and measurement/experience |

| Core is a novel OS/kernel or a clean-slate distributed-systems mechanism, depth over cloud framing | OSDI / SOSP | OS and systems flagships; deeper systems-novelty bar |

| Core is the network — datacenter fabric, congestion control, RDMA, SDN | NSDI | Networked-systems flagship |

| General systems contribution, European rotation, OS/runtime flavor | EuroSys | Broad systems venue; ACM, different community and calendar |

| Solid systems/experience result that fits a broad practitioner venue | USENIX ATC | General systems + experience; USENIX template and process |

| Core is a database engine, query processing, transactions, or data mgmt theory | SIGMOD / VLDB | Data-management flagships; SoCC shares SIGMOD sponsorship but is systems-facing |

| Pure ML modeling result whose cloud consequence is incidental | an ML venue | The model, not the cloud system, is the contribution |

Contribution shapes SoCC rewards

• Cloud system + evaluation on a real/realistic deployment — a new storage, scheduling,

serverless, or data-serving mechanism, built and measured on a cluster or testbed against

credible baselines (the Cake / YARN lineage).

• Measurement / trace study — turning production traces or large-scale measurement into

durable findings about how real cloud infrastructure behaves (the Google-trace lineage) — a

distinctly prized SoCC mode, reflecting the SIGMOD half of its identity.

• Benchmark / measurement instrument — a reusable tool the community adopts to compare cloud

systems (the YCSB lineage).

• Experience paper — design decisions and operational lessons from a deployed system at scale,

reported honestly including what failed (the YARN lineage) — SoCC's welcome mat for industry and

operations.

• Cloud economics / data markets — pricing, cost models, SLAs, and the data economy, a scope

the joint sponsorship makes native rather than exotic.

The model-swap and re-label tests

Two quick tests sharpen a borderline verdict:

• Model-swap / mechanism-swap test: if your paper leans on an ML predictor or one specific

engine, ask whether the cloud lesson survives swapping it. If not, the model is the

contribution and an ML venue fits better; if yes, the cloud-systems framing is real.

• Re-label test: could this paper be submitted to OSDI/NSDI/SIGMOD unchanged and read as native

there? If its heart is kernel novelty (OSDI), network fabric (NSDI), or query internals (SIGMOD),

route accordingly. SoCC rewards the paper whose contribution genuinely spans **operating a cloud

service on real data at scale**.

Evidence maturity, without the ladder cliché

Fit is necessary but not sufficient: the same idea sits at different doors depending on how far the

evidence has come. A mechanism evaluated only in simulation needs a testbed or deployment before

the research track; a measurement study needs a trace or corpus a reviewer can scrutinize; an

experience paper needs a system that was actually operated. Submitting a simulation-only systems

claim invites the "does this hold on a real deployment?" reject that both sponsoring communities

apply.

Cheap reconnaissance before committing

[Scope]   scan the last two SoCC programs (dblp conf/cloud, acmsocc.org) for your subarea
          -> 3+ recent papers = a reviewer pool exists; 0 = opening or mismatch
[Citations] is your bibliography a mix of systems (OSDI/NSDI/EuroSys/ATC/SoCC) and data
          (SIGMOD/VLDB) venues? -> a SoCC paper usually cites both lanes
[Calendar] SoCC has two rounds/year; compare the nearer round with OSDI/NSDI/EuroSys/ATC and
          SIGMOD/VLDB dates -> route to the nearest honest fit, but never reuse a Round-1 reject
          in Round 2

Decision procedure

[Audience] who acts differently if the claim holds? -> cloud operators / platform teams / data-infra builders?
[Claim type] cloud system / measurement / benchmark / experience / cloud-economics
[Intersection check] does it span systems AND data/scale, or is it pure-OS / pure-network / pure-DB?
[Sibling check] kernel depth -> OSDI/SOSP; network fabric -> NSDI; DB engine -> SIGMOD/VLDB
[Verdict] SoCC research track / sibling venue, with a one-line reason

Run this before the writing skills; a wrong venue decision wastes every later step. When the

verdict is SoCC, continue with socc-workflow for the two-round calendar and socc-writing-style

for the paper shape.