Use this when revising the main paper. INFOCOM papers are read by a broad networking TPC that spans theory and systems, inside a nine-page IEEEtran budget and (traditionally) with no rebuttal. Two constraints follow: the paper must be legible to both an analyst and a systems reader, and it must pre-empt the reviewer's objection in the text, because you will not get to answer it later.
| Section | Job it must do | Common failure |
|---|---|---|
| Intro | Problem, setting, gap, contribution, what improves — by the first column or two | Leads with a trend, not a networking problem |
| System model | Topology, traffic, constraints, assumptions, notation, stated plainly | Assumptions hidden or introduced only in the evaluation |
| Analysis / design | Theorems + proof sketches, or the protocol/algorithm, reproducibly | A model no result uses; a design too thin to re-implement |
| Evaluation | Each claim answered with proportional evidence, honest baselines | Toy topology; untuned baseline; metric that proxies the claim |
| Discussion / limits | The regime where the result holds; deployment caveats | No limits stated (invites the objection you cannot rebut) |
| Related work | Delta-first positioning against the networking literature | Citation catalog with no contrast |
| Draft pattern | INFOCOM-safe rewrite |
|---|---|
| "Our scheme significantly improves throughput." | "improves median throughput by X% (95% CI ...) over |
| "We prove our algorithm is optimal." | "We prove a (1-1/e) approximation under |
| "We evaluate on a large simulation." | "We simulate <N nodes> in <ns-3/custom>, |
| "The model captures the system." | "Under assumptions A1-A3 (stated and justified in §III), the model yields Theorem 1" |
| "State-of-the-art performance." | Claim scoped to the topology, traffic, and regime actually tested |
[Assumption] which modeling assumption will a theory reviewer challenge? -> justify it in §III
[Baseline] which comparison will a systems reviewer call unfair? -> tune it, document the budget
[Scale] does the evaluation reach a realistic size? -> if not, scope the claim and say so
[Regime] where does the result break? -> state it before a reviewer finds it
-> each objection answered in the PDF, because there is no turn to answer it in a reply
A draft with two models, five theorems, and a sprawling evaluation: keep the one model the design uses, the two theorems that carry the insight (full proofs compressed or sketched), and the two evaluation figures that test the headline claim; move notation-heavy derivations into a tight in-budget appendix (remember it counts toward the nine pages); cut the second model to a remark. The test of a good cut: a reviewer should be able to state your assumptions, your main result, and why your baseline is fair — from the body alone.
[Writing diagnosis] clear / under-modeled / over-claimed / evidence-mismatched / over-scoped
[First-page fix] <new framing leading with the networking problem + system model>
[Claim audit] <claim -> proof or simulation/measurement -> proportional? yes/no>
[Defensive gaps] <assumption/baseline/scale/regime objection -> where to pre-empt it>
[Anonymity edits] <self-citations / tool / testbed names / acks to rewrite>