stp

From: Lillie Kittredge (kittredl@u.washington.edu)
Date: Sun Nov 14 2004 - 23:24:47 PST

  • Next message: Shobhit Raj Mathur: "review of paper 22"

    This paper discusses a protocol for allowing nodes to use protocols which
    are in the testing stage without "really" using them or needing to trust
    them.

    The motivation of this paper is that it's difficult to bootstrap the
    adoption of new protocols, since in most cases they must implemented on
    both hosts, and one host is unlikely to upgrade if most of its neighbors
    are not. The authors present a bootstrapping step of equipping each node
    with their protocol, allowing it to run many other protocols in a sandbox.
    This relieves the host of the need to trust the new protocol.

    The key insight is that new protocols don't need to be adopted "for real"
    by the host; instead it can have sort of a trial run. This is achieved by
    deciding on the fly whether to use a new protocol or not, and if a new
    protocol is desired, running it in an isolated kernel sandbox, where it's
    prevented from misbehaving.

    Unfortunately, the main problem and paradox of this paper is that it's
    still a very substantial step to get all these hosts which are reluctant
    to adopt new protocols to adopt STP. Though they claim STP has "low
    barriers to adoption", I'm not convinced. Also, if the authors address
    the issue of what happens when a node running STP attempts to communicate
    with a node not running STP, I didn't see it.

    Another high-level gripe about this system would be that, once STP was in
    place and any node could talk to any other with almost any protocol, why
    would the hosts upgrade to the "real" protocol? We may be stuck in a
    perpetual state of testing.

    But, all griping aside, it does seem like a damn good idea to introduce a
    lower level of bootstrapping to the problem of getting protocols deployed
    on wide networks.


  • Next message: Shobhit Raj Mathur: "review of paper 22"

    This archive was generated by hypermail 2.1.6 : Sun Nov 14 2004 - 23:24:52 PST