> Beware! HICSS has a very spotty research track record.
Quite! I mean, come on, Adam won "Best Paper" in the minitrack and the s.e.
track :-)
Seriously, let me say I agree and that we're submitting precisely FOR the
reasons you outlined.
> Some papers are good,
> others not -- it varies tremendously from track to track.
Adam spent some time scoping out the Web track and has some hope it will be
decent. The wireless one is a gamble, though (as is our unwritten
gedankenexperiment).
> Typically you don't
> want more than 1 paper on your CV from HICSS (most people will understand the
> desire for a Hawaiian vacation, and will overlook it once).
Well, your CV doesn't have to have dancing pigs highlighting the fact, either
:-). It's an all-conference academic publication list like
http://www.cs.caltech.edu/~kiniry/projects/Writing/Academic_Papers/index.html
to watch for (Hi Joe! yes, I know it's only temporary ;-). This will hopefully
be balanced out as only one of many pubs.
> The conventional
> wisdom is that if the research is any good, you'll be able to get it accepted
> in the primary research conference for the particular field.
Yep. The HICSS thing is being treated as the forum it is: a sounding board,
and a place to test the breadth of an idea (in this case, two quite broad
theses).
> The other
> rationale is that by submitting the paper to the primary research conference
> for the field, you get much better feedback in the reviews, and acceptance
> also carries some acceptance into the research community (which HICSS does
> not do nearly as much).
Granted. Again, on the two-three year track it will take to develop this
research, this is just a first step. And even within that context, this is the
first preliminary abstract submission step.
> I think submitting the *TP paper to HICSS is a tactical mistake -- this is a
> very good idea, and could be accepted in a far better conference than HICSS.
Thanks. I hope it will indeed become so. I should go pencil Sigcomm'98 in,
actually. That's the real target audience, on the way to becoming a
Journal-quality survey article and perhaps Stevens-like textbook.
> >Our survey compares the distribution algorithms, naming models, reliability,
> >performance and extensibility of two decades' worth of TP development.
>
> You're going to do a thorough job of this in 12 pages? Ha!
Of course not! We wouldn't want to lock up too many good ideas in there. The
HICSS angle is more the recommendation to adopt and adapt HTTP than it is the
careful historiography.
> Sure,
> you may not see this in print until 1999, but the time will have been far
> better spent, and the final product will be a seminal work.
We hope so -- and that could very well include Irvine folks, too.
> >Telnet, FTP, SMTP, NNTP, HTTP
>
> I think a thorough survey of transport protocols should include the
> point-to-point protocols of Xmodem, Ymodem, Zmodem, Kermit etc. By examining
> these protocols, you'll be able to clearly identify the advantage the other
> protocols had by building on top of TCP/IP (i.e., a clearer separation of
> concerns between low-level and high-level transport).
Now this is an excellent new point. I haven't thought much about the
evolution of p2p links. Perhaps there is companion research to do; ideally, if
someone *has* done this kind of historical analysis, it would be a good model
for our own kind of survey.
> Also, I think you'll
> find that the point-to-point protocols are more efficient. So, there's a
> tradeoff between efficiency and abstraction (separation of concerns).
Excellent point. What's been lost is the ability to *recombine* those
concerns. In the channel-making world, the TCP/IP connection has largely
supplanted its competitors (unlike the app-layer world). So today, we can only
hack around the margins of TCP/IP -- e.g. PPP, SLIP -- to adapt to channels,
or drop down to UDP to adapt to content (lossy). Ideally, we can pick and
choose, so that we can ask the network layer to provide channels of various
properties (latency, jitter). Today, we hack at the margin above, too: RSVP,
flow tags. But we don't have any real competition for channel services anymore
to choose amongst.
Cool,
Rohit