ietf
[Top] [All Lists]

Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (SpecifyingNewCongestion Control Algorithms) to BCP

2007-05-31 12:02:57

Mitchell-

      The SHOULD type terminology is
      what I thought is standard. 

This is not a protocol spec.  Such language is a little fuzzy in
documents that are not specs.  Unless folks loudly and broadly complain
it seems to me that the language in the current document has been agreed
to.

      And why wouldn't a minimum timeframe be specified? And items
      listed that state how an implementation exits this experimental
      phase, versus subjective evaluation. Ie, a vote of a working
      group that requires xx% acceptance. 

We don't vote.  It happens to be part of our charm. :)

I personally don't see why we'd place a time frame on things.  It seems
more important to look at the available evidence and experimental
results than to try to pick some arbitrary amount of time.  Again,
unless others start yelling, I think we have consensus on this
document. 

      Secondly, I have never understood the non-requirment
      of a REFERENCE implementation. The Reference implmentation
      IMO, doesn't have to be source.

I am not sure how an "reference implementation" does not "have to be
source".  But, we're talking about algorithms here.  It seems clear that
these algorithms will have to be well-specified or the WG (whatever WG
that happens to be) is not going to consider the spec.

      Lastly, should a accepted CC algor ever be re-reviewed
       to see if it has aged well??? And needs updating.

I think that any time folks have an update they should bring it up.  I
would consider that what has actually happened in practice.

      4) Support for a CC algorithm in one environment, ie LFN..

I don't understand what you are getting at here.  But, see guideline
(2).

      Can a implimentation be offered to work in ONLY 1 environment?

See guideline (8):

        As a similar concern, if the alternate congestion control
        mechanism is intended only for specific environments (and not
        the global Internet), the proposal should consider how this
        intention is to be carried out.  The community will have to
        address the question of whether the scope can be enforced by
        simply stating the restrictions or whether additional protocol
        mechanisms are required to enforce the scoping.  The answer will
        necessarily depend on the change being proposed.

(Which is slightly tweaked wording from the current version in the
repository (in response to an IESG comment), but the intent is the
same.)

      All implementations that I have worked on, have a stated
      set of configurables with default values. If a well known accepted
      implimentation is significantly modified, at what point is it
      considered a new implementation. Ie: Removing fast acks in
      small in-flight segment environments

I don't think I can give you a hard-and-fast rule.  This is just
something the WG would have to work through.

allman



Attachment: pgptTkMXp31IS.pgp
Description: PGP signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (SpecifyingNewCongestion Control Algorithms) to BCP, Mark Allman <=