1 / 27

Publishing – or How to get Out of Grad School

Publishing – or How to get Out of Grad School. Henning Schulzrinne Dept. of Computer Science Columbia University (updated September 2009). Why publish?. To go to exotic hotels To impress your mother with your name in print To graduate external review To get a job

denver
Download Presentation

Publishing – or How to get Out of Grad School

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Publishing – or How to get Out of Grad School Henning Schulzrinne Dept. of Computer Science Columbia University (updated September 2009)

  2. Why publish? • To go to exotic hotels • To impress your mother with your name in print • To graduate • external review • To get a job • your advisor thinks all his students are above average • To satisfy research contract requirements

  3. How many papers do I need to graduate? • 1 Science paper or … • 2 Sigcomm papers or … • ~5 “real” publications

  4. Publications • Different kinds of publications • Think like a reviewer • Finding the right conference • Advertising your work • Paper types • What if my paper is rejected?

  5. Publication types • Technical reports, including arXiv • Workshops • Conferences • Magazines • (“Archival”) Journals • Internet Drafts and RFCs

  6. Finding out about conferences • CFP = call for papers • Finding out about conferences • http://www.cs.ucsb.edu/~almeroth/conf/stats/ • http://wikicfp.com • TCCC announcement list (subscribe!) • SIGCOMM and ComSoc web pages

  7. 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

  8. Workshops • Two kinds: • invited (Dagstuhl) • topic-focused (“Internet Measurements”, NANOG) • Smaller, more focused than conferences • 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)

  9. 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

  10. 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

  11. 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

  12. Finding the right conference • Filter #1: only submit to conferences archived in IEEE eXplore or ACM DL • except maybe for some workshops • Appropriate conference • layer/topic area • style (analysis, system) • selectivity • location (Australia vs. NY)

  13. Traveling to conferences • Many larger conferences have student travel grants • often for authors • sometimes for non-authors (SIGCOMM)

  14. Magazines • Examples: • IEEE Network Magazine • IEEE Communications Magazine • IEEE Wireless Communications • IEEE Multimedia Magazine • Large circulation  topics of broad interest • Written for non-specialist (30,000 readers!) • Originality not always most important

  15. 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”

  16. Journals • Issued principally by • Societies • ACM • IEEE • Commercial publishers • Springer Verlag • Kluwer • North Holland

  17. 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 • …

  18. 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

  19. 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

  20. 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

  21. Finding related work • netbib • citeseer • Google • web pages of well-known network research groups • Digital Library, IEEEXplore

  22. 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…

  23. 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

  24. Think like a reviewer • Reviewers are volunteers • Reviewers are not English editors • corollary: “if you can’t use a spell checker, why should I trust your graphs and equations?” • Abstract and title have to ensure proper routing of paper (theory vs. systems) • 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)

  25. Think like a reviewer, cont’d. • Clear motivation – important for non-specialist reviewers • “is the problem important?” • Sufficient detail to evaluate, but not “used gcc 1.2.3 on a SPARC Ultra 10 called snoopy to simulate” • Avoid generic motivations • “The rapid advances in foo”  cliché! • Repeat main results in introduction and summary • 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 • including your own prior work! • Avoid overloading one paper (hard!) • paper should tell a story, not be a research catalogue or brain dump

  26. Paper submission • Technical report (and RFCs) do no harm • Basic rule: cannot submit same material to two venues simultaneously (including conference and journal) = double submission • Don’t explore LPU • Conference paper = refined(workshop paper + detail) • Journal paper = refined( conference papers)

  27. 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)

More Related