From: Daniel Lowd (lowd@cs.washington.edu)
Date: Fri Nov 12 2004 - 19:30:45 PST
This paper discussed a possible mechanism for upgrading transport
protocols using untrusted mobile code. The main motivation for this work
is the observation that one-sided upgrades aren't immediately beneficial,
so improved protocols can take years to deploy. Furthermore, the emphasis
on backwards compatibility may lead to standardization of inferior
protocols. The solution proposed is a mechanism to make upgrading
protocols easy, and to make agreeing on a protocol to use easy as well.
I thought that this paper made a very clear and compelling case for the
soundness of its approach. Safety, flexibility, and performance concerns
were all addressed well. Even the cost of porting C code to Cyclone was
addressed.
There were weaknesses as well. First, only two TCP variants were
implemented. After listing dozens of variants that would all be possible,
why only test two? Is it ever beneficial to switch protocols depending on
the host and application? If so, then maybe a more complicated
configuration, complete with protocol negotiation, would see real
performance gains from STP over one single protocol. And how much does
disabling "delayed ACKs" in NewReno hurt performance? Perhaps that's a
real downside to STP? Unfortunately, no experiments seemed to answer this
question. The experiments seemed like a good start, but I didn't feel
that they really stress-tested every scenario.
I also wish the authors had addressed the challenge of deploying something
like STP. This seems like it would be just as difficult as deploying a
new network protocol, which the authors admit can take years. And what
happens if significant limitations are discovered, and version 2.0 of STP
becomes necessary? This technology is only worthwhile if the ease of
deploying new transport protocols outweighs the hassle of deploying STP.
If STP does perform well in all scenarios, and can survive several
generations of future transport upgrades, then perhaps it could make a
real difference. The idea of "plug-and-play protocols" is certainly
appealing; I hope it's truly practical as well.
-- Daniel
This archive was generated by hypermail 2.1.6 : Fri Nov 12 2004 - 19:30:46 PST