sigcomm-author-response

SIGCOMM Author Response

SIGCOMM has two distinct author-facing replies, and conflating them is a strategic error.

The rebuttal is a short argument during the discussion phase; the one-shot revision is

a month-long, shepherd-managed contract. Reopen the current CFP to confirm the mechanics

before drafting.

First, know which reply you are writing

| Signal in the letter | You are in | The move |

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

| Reviews plus an invitation to respond, no verdict | Rebuttal / discussion phase | Answer the decision-critical objection concisely |

| A merits summary and a list of required changes | One-shot revision | Treat the list as a binding contract; resubmit with a packet |

| An early notification of rejection | Early reject | No reply reopens it; redirect the work |

Writing the rebuttal

• Answer the concern that decides the paper first: evaluation realism, a missing baseline, a

correctness question, or a generalization doubt. Style complaints wait.

• Anchor every answer in evidence already in the submission — a table, a figure, an appendix

measurement — rather than promising new experiments the reviewers cannot see.

• Stay anonymous: no institution, deployment name, or private link that breaks double-blind.
• Concede cleanly what cannot be fixed in the window, and scope a camera-ready wording change

instead of overclaiming a result you cannot produce now.

• One precise, decision-focused reply per reviewer beats an exhaustive point-by-point that

buries the objection that actually matters to the discussion.

Executing the one-shot revision

The revised paper can only be accepted or rejected, so the required-changes list is the

grading rubric. Build the packet the CFP expects:

1. Point-by-point response mapping each required change to exactly what you did and where.
2. Change-marked manuscript so the shepherd and reviewers see the diff without hunting.
3. List of changes at a high level, so a reader gets the shape before the detail.

Then work the contract, not the margins:

• Address every listed issue explicitly; a revision that improves adjacent things but

dodges a listed item is the classic one-shot rejection.

• Engage the shepherd through HotCRP early — clarify an ambiguous requirement before you

build the wrong fix, not after.

• Keep results honest to the new evidence; if a required experiment weakens a claim,

rescope the claim rather than hiding the outcome.

Reviewer pushback patterns and SIGCOMM-ready fixes

| Pushback | What it signals | SIGCOMM-ready fix |

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

| "Evaluated only in simulation" | Evaluation-realism doubt | Point to the testbed/trace result, or commit one in the revision and report it plainly |

| "Baseline is weak" | The strongest alternative was skipped | Add or defend the state-of-the-art comparison at matched conditions |

| "Only mean latency reported" | Tail behavior hidden | Report the relevant percentiles over repeated trials with stated variance |

| "Does it generalize beyond this topology?" | Mechanism looks tuned | Add a topology/parameter sweep, or scope the claim to what was tested |

Micro-example (revision)

Reviewer requires a comparison against the deployed state-of-the-art at matched throughput.

Packet skeleton: (1) response entry naming the added baseline and the section/table that now

holds it; (2) change-marked Section 5 with the new column; (3) change-list line "Added

state-of-the-art baseline X at matched throughput (Table 2)." No unlisted claims sneak in.

Output format

[Reply type] rebuttal / one-shot revision / n-a (early reject)
[Priority issue] <the objection that decides the outcome>
[Evidence anchor] <table / figure / appendix / new run>
[Revision packet] response / marked diff / change list — status
[Shepherd touchpoint] <what to confirm before building>
[Forbidden content removed] <identity leaks, unlisted new claims>