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>