Publishing – or How to get
Out of Grad School
Henning Schulzrinne
Dept. of Computer Science
Columbia University
(updated Feb. 22, 2005)
Why publish?



To go to exotic hotels
To impress your mother with your name in
print
To graduate


To get a job


external review
your advisor thinks all his students are above
average
To satisfy research contract requirements
How many papers do I need to
graduate?



1 Science paper or …
2 Sigcomm papers or …
~5 “real” publications
Publications






Different kinds of publications
Think like a reviewer
Finding the right conference
Advertising your work
Paper types
What if my paper is rejected?
Publication types






Technical reports, including arXiv
Workshops
Conferences
Magazines
(“Archival”) Journals
Internet Drafts and RFCs
Finding out about conferences


CFP = call for papers
Finding out about conferences



http://www.cs.ucsb.edu/~almeroth/conf/stats/
TCCC announcement list (subscribe!)
Wenyu Jiang’s conference list
Technical Reports





CS, IBM and BL TR
arXiv.org
avoids being “scooped”
present additional details (simulation
results, proofs, implementation details)
Can be used to advertise on mailing
lists – read more often than some
conference papers
Workshops

Two kinds:



Smaller, more focused than conferences




invited (Dagstuhl)
topic-focused (“Internet Measurements”, NANOG)
May not have formal proceedings, just copies of
slides
Often, only once or twice, but some for years
(ComSoc)
Selectivity varies – from 100% to 10%
Some events are called workshop, but are
really conferences (NOSSDAV, IWQoS)
Conferences





Hundreds a year
Traditional: ICC, Globecom
Semi-traditional: Infocom, SIGCOMM,
ICNP, Sigmetrics, Usenix, SOSP, …
Newer: WWW, NOSSDAV, IWQoS,
SAINT, Mobicom, Mobihoc, …
Submission size: 5-12 pages
Conferences



Some have short submissions
(“extended abstract”) and longer
accepted papers
Some are effectively the same length
(Infocom)
Few have long submissions and shorter
final papers
Conference reviews


Either technical program committee
(TPC) or TPC + external reviewers
Reviews


blind (most IEEE conferences): author
doesn’t know reviewer, but reviewer knows
author identity
double-blind (ACM): only the chair knows
the author identities
Finding the right conference

Appropriate conference




layer/topic area
style (analysis, system)
selectivity
location (Australia vs. NY)
Traveling to conferences

Many larger conferences have student
travel grants


often for authors
sometimes for non-authors (SIGCOMM)
Magazines

Examples:







IEEE
IEEE
IEEE
IEEE
Network Magazine
Communications Magazine
Wireless Communications
Multimedia Magazine
Large circulation  topics of broad interest
Written for non-specialist (30,000 readers!)
Originality not always most important
Journals





Every PhD thesis should result in at least one
journal publication
Archival – most libraries have them and keep
them forever
Long review cycle
Selectivity varies greatly – can be less
selective than some conferences
Often, given second chance – “resubmit with
major changes”
Journals

Issued principally by

Societies



ACM
IEEE
Commercial publishers



Springer Verlag
Kluwer
North Holland
Journals

Examples
IEEE/ACM Transactions on Networking
 Journal on Selected Areas in Communications
 Computer Communications Review (CCR)
 ACM Transactions on Multimedia Computing,
Communications and Applications
 Computer Networks
 Journal of High Speed Networks
 Journal of Communications and Networks
 …

RFCs – Internet Standards
Documents




RFCs are not papers (and vice versa)
Can take a while, particularly for
standards-track documents
Start with submitting Internet Drafts –
but most Internet drafts never make it
to RFC
Specification vs. description
RFCs




Precision vs. novelty and performance
“How does it work” vs. “how is this
better than existing work”
Good way to get impact
Good for industrial job interviews
Ways to advertise your work





Technical reports
Put link and abstract on web page
(search engines!)
Relevant mailing lists (e.g., end2end)
Send pointer to authors of work that is
closely related
arXiv for tech reports
Finding related work





netbib
citeseer
Google
web pages of well-known network
research groups
Digital Library, IEEEXplore
Types of papers - content

Measurement




measure performance of real systems
test bed or real Internet
careful statistics – how representative is your
data?
Analysis of existing algorithm



TCP, FDDI, DQDB, RED, … - not some obscure
protocol
simulation or analysis
bad protocols are good news for authors…
Types of papers, cont’d.

System description





implement interesting system
describe it in sufficient detail
what’s new and interesting?
prototype, not industrial product
New algorithm or protocol




switching, routing, scheduling, …
performance evaluation
highest risk/reward
don’t describe bit fields
Think like a reviewer


Reviewers are volunteers
Reviewers are not English editors


Abstract and title have to ensure proper routing of
paper (theory vs. systems)



corollary: “if you can’t use a spell checker, why should I trust
your graphs and equations?”
don’t overpromise: “solve QoS problem” vs. “add tweak to
DiffServ to better serve soccer videos”
Reviewers get mad if their work is not cited
Clearly state what your contribution is (and state
other things in future work)
Think like a reviewer, cont’d.

Clear motivation – important for non-specialist reviewers



Sufficient detail to evaluate, but not “used gcc 1.2.3 on a SPARC
Ultra 10 called snoopy to simulate”
Avoid generic motivations


corollary: papers are not suspense novels – need to be able to see
scope, motivation and results on first page
Very carefully distinguish from prior work


“The rapid advances in foo”  cliché!
Repeat main results in introduction and summary


“is the problem important?”
including your own prior work!
Avoid overloading one paper (hard!)

paper should tell a story, not be a research catalogue or brain
dump
Paper submission





Technical report (and RFCs) do no harm
Basic rule: cannot submit same material to
two venues simultaneously (including
conference and journal)
Don’t explore LPU
Conference paper = refined(workshop paper
+ detail)
Journal paper = refined( conference papers)
What if a paper is rejected?




Don’t jump off the GWB - it happens to
everyone
If not, you’re not submitting to the right
conferences
No point complaining if the reviews are
superficial – decisions are effectively final
(except for discoveries of plagiarism, etc.)
Publish as tech report immediately (after
taking reviews into consideration)