Loading ...
Sorry, an error occurred while loading the content.

Is GUESS 0.2 coming anytime soon?

Expand Messages
  • jbt00000
    Just wanted to see when we should expect GUESS 0.2, or if we were all satisfied with GUESS 0.1. -jason
    Message 1 of 7 , Oct 2, 2002
    • 0 Attachment
      Just wanted to see when we should expect GUESS 0.2, or if we were
      all satisfied with GUESS 0.1.

      -jason
    • Philippe Verdy
      As indicated in the document it does not specify fully the precise usage policy and there are sentences that really indicate that some parts needs to be
      Message 2 of 7 , Oct 2, 2002
      • 0 Attachment
        As indicated in the document it does not specify fully the precise usage
        policy and there are sentences that really indicate that some parts needs to
        be discussed. So this is not a final spec despite it covers a lot of the
        implementation aspects and a new spec is about to be released that includes
        additional features notably regarding security issues and active congestion
        control from the recipient endpoint.

        Some sentences were not clear enough or not emphasized to clarify the
        important required and "shoulds" that will be necessary to implement it
        fully.

        There is also some guidelines that need to be discussed regarding the slow
        start phase and protocol evolution and compatibility.

        Some aspects of the current protocol ignore basic facts: GUESS does not use
        the TTL and Hops model so the corresponding fields are unused. The spec
        should specify their constant values (TTL=1 Hops=0) for the initial release
        and these bytes may be used for further version control of the GUESS
        protocol. This may be a good tool to shut off/ignore implementations that
        reveals to be harmful to the network.

        So yes there will be updates to the proposal.

        However I think that because this is not a spec the proposal should be
        subversioned instead of be increased to multiple ersion numbers.

        So you could consider that version 0.1 is not a spec and further revisions
        of the document should be marked with 0.1.02mmdd until there's an active
        implementation and full-scale experiment of the protocol (at which time the
        version should be changed to 0.2.

        Then further discussions to change the protocol should use the 0.2.yymmdd
        model. Any subversion indicating proposals for revisions but not active
        implementation.
        We don't need to have many versions in the protocol that actually gets
        implemented. Servents should then not be distributed on wide scales which
        would implement subversioned protocol numbers. (these intermediate revisions
        should only be used experimentally by implementors but not used on wide
        scale in any binary distribution).

        To make this effective, care must be taken that open-source projects don't
        include in the main branch of their public CVS repository any implementation
        of features proposed in intermediate protocol revisions (this is important
        for those "clones" using other core engines from Gnucleus or LimeWire and
        that sometimes distribute intermediate code that was not widely tested and
        that could harm the network).

        Before including a branch into your main distribution the final specs of any
        protocol feature must have been released by its maintainer -- this should be
        true for any protocol extensions, not only for GUESS. Before that, no
        distribution should include undocumented or instable protocol revision
        proposals.
        This means that all intermediate versions of a spec should be separated from
        the proposed changes, and that released versions (which include change logs)
        should be kept available.

        Only deprecated and shutdown specifications (that are now using features
        refused by most active servents) should be deleted from the Proposal files
        section. Maintainers of any extension specs should all take care of
        maintaining and not modifying previously released extension. If there is
        some change of status of a document, this should only consist in a big
        warning at the top of the document saying that the old version of the spec
        should no more be implemented, and a reference to the next approved document
        be inserted. There should not be any change in the specification (including
        technical typos, but english typos such as plural marks, missing letters in
        the text may be corrected in the published version, if this does not change
        the released protocol, and an errata section added that specifies all the
        "minor" changes to a past published spec).

        Please keep an history of these protocols, and publish a separate comment
        document for additional "should" and "may" revisions that may be useful to
        slowly correct the usage policy of a given specified feature). No mandatory
        feature (musts) may be removed from any published specification.

        ----- Original Message -----
        From: "jbt00000" <junkmail@...>
        To: <the_gdf@yahoogroups.com>
        Sent: Wednesday, October 02, 2002 5:26 PM
        Subject: [the_gdf] Is GUESS 0.2 coming anytime soon?


        > Just wanted to see when we should expect GUESS 0.2, or if we were
        > all satisfied with GUESS 0.1.
        >
        > -jason
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > the_gdf-unsubscribe@egroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
      • Adam Fisk
        ... All of my e-mail seem to be getting lost in Yahoo Groups land. Hopefully this gets through. The biggest obstacle we currently face is having little idea
        Message 3 of 7 , Oct 2, 2002
        • 0 Attachment
          --- In the_gdf@y..., "jbt00000" <junkmail@j...> wrote:
          > Just wanted to see when we should expect GUESS 0.2, or if we were
          > all satisfied with GUESS 0.1.
          >
          > -jason


          All of my e-mail seem to be getting lost in Yahoo Groups land.
          Hopefully this gets through.

          The biggest obstacle we currently face is having little idea what to
          expect once GUESS is released on a wide scale. We've added very
          detailed statistics gathering to LimeWire that will allow us to
          carefully trace the changes in network traffic patterns as GUESS is
          introduced. This information should allow us to more clearly identify
          the problem areas, potentially leading to the addition of some of the
          congestion control ideas discussed here. We may, for example, add an
          ack to Query Hits, providing more flexibility for servers to limit
          traffic, as several people have suggested. We're also considering
          adding timeouts on pongs.

          Without more information, however, these changes would basically be
          shots in the dark. So, we're taking the conservative approach of
          waiting until we're able to gather more data. Once we have this
          information, we'll likely publish a new version. Other document
          changes involve minor cosmetic tweaks and a new section on
          implementation decisions. We may separate the document number from
          the protocol number to allow these to be released without releasing a
          whole new protocol version.

          -Adam
        • Justin Chapweske
          I might suggest that this system would be a good candidate for simulation. So if any grad students are listening, it might be a good project to code this up
          Message 4 of 7 , Oct 2, 2002
          • 0 Attachment
            I might suggest that this system would be a good candidate for
            simulation. So if any grad students are listening, it might be a good
            project to code this up in NS, and see how it performs.

            I'm personally uncomfortable with the congestion control aspects of this
            system and would like to see that problem dealt with first.

            -Justin

            Adam Fisk wrote:
            > --- In the_gdf@y..., "jbt00000" <junkmail@j...> wrote:
            >
            >>Just wanted to see when we should expect GUESS 0.2, or if we were
            >>all satisfied with GUESS 0.1.
            >>
            >>-jason
            >
            >
            >
            > All of my e-mail seem to be getting lost in Yahoo Groups land.
            > Hopefully this gets through.
            >
            > The biggest obstacle we currently face is having little idea what to
            > expect once GUESS is released on a wide scale. We've added very
            > detailed statistics gathering to LimeWire that will allow us to
            > carefully trace the changes in network traffic patterns as GUESS is
            > introduced. This information should allow us to more clearly identify
            > the problem areas, potentially leading to the addition of some of the
            > congestion control ideas discussed here. We may, for example, add an
            > ack to Query Hits, providing more flexibility for servers to limit
            > traffic, as several people have suggested. We're also considering
            > adding timeouts on pongs.
            >
            > Without more information, however, these changes would basically be
            > shots in the dark. So, we're taking the conservative approach of
            > waiting until we're able to gather more data. Once we have this
            > information, we'll likely publish a new version. Other document
            > changes involve minor cosmetic tweaks and a new section on
            > implementation decisions. We may separate the document number from
            > the protocol number to allow these to be released without releasing a
            > whole new protocol version.
            >
            > -Adam
            >
            >
            >
            > To unsubscribe from this group, send an email to:
            > the_gdf-unsubscribe@egroups.com
            >
            >
            >
            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            >


            --
            Justin Chapweske, Onion Networks
            http://onionnetworks.com/
          • Adam Fisk
            ... this ... That s an excellent idea. Note that I m not advocating just rolling this out. Quite the contrary -- I m advocating testing the current scheme to
            Message 5 of 7 , Oct 2, 2002
            • 0 Attachment
              --- In the_gdf@y..., Justin Chapweske <justin@c...> wrote:
              > I might suggest that this system would be a good candidate for
              > simulation. So if any grad students are listening, it might be a good
              > project to code this up in NS, and see how it performs.
              >
              > I'm personally uncomfortable with the congestion control aspects of
              this
              > system and would like to see that problem dealt with first.
              >
              > -Justin

              That's an excellent idea. Note that I'm not advocating just rolling
              this out. Quite the contrary -- I'm advocating testing the current
              scheme to get a better idea of what issues we're dealing with, as it's
              not trivial to visualize how a change like this will affect such a
              complex network. Network Simulator would be a good candidate for
              this, although I'm not sure it will simulate UDP messages??

              -Adam
            • Justin Chapweske
              NS can do *anything*, plus there are large-scale topology generators available to simulate internet-scale deployments. ... -- Justin Chapweske, Onion Networks
              Message 6 of 7 , Oct 2, 2002
              • 0 Attachment
                NS can do *anything*, plus there are large-scale topology generators
                available to simulate internet-scale deployments.

                >
                > That's an excellent idea. Note that I'm not advocating just rolling
                > this out. Quite the contrary -- I'm advocating testing the current
                > scheme to get a better idea of what issues we're dealing with, as it's
                > not trivial to visualize how a change like this will affect such a
                > complex network. Network Simulator would be a good candidate for
                > this, although I'm not sure it will simulate UDP messages??
                >
                > -Adam
                >

                --
                Justin Chapweske, Onion Networks
                http://onionnetworks.com/
              • Agthorr
                ... FWIW, in my swarming simulations, I m going to be using a simple host- ISP- backbone topology. Using one of the aforementioned topology generators will
                Message 7 of 7 , Oct 2, 2002
                • 0 Attachment
                  On Wed, Oct 02, 2002 at 01:25:11PM -0500, Justin Chapweske wrote:
                  > NS can do *anything*, plus there are large-scale topology generators
                  > available to simulate internet-scale deployments.

                  FWIW, in my swarming simulations, I'm going to be using a simple
                  host->ISP->backbone topology. Using one of the aforementioned
                  topology generators will give you a more detailed, realistic Internet,
                  but simulating all those routers is expensive, and means you won't be
                  able to simulate as many Gnutella nodes.

                  -- Agthorr
                Your message has been successfully submitted and would be delivered to recipients shortly.