Subject: [Iccrg] Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (SpecifyingNewCongestion Control Algorithms) to BCP
From: [email-masked] (Mark Allman)
Date: Thu May 31 20:03:17 2007

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070531/25fcf520/attachment.bin

From: [email-masked] (Mark Allman)
Date: Tue May 29 14:06:40 2007
Subject: [Iccrg] Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> >    (0) Differences with Congestion Control Principles [RFC2914]
> >
> >        Proposed congestion control mechanisms that do should include a
> >        clear explanation of the deviations from [RFC2914].
> >
> > Is that more clear?
> 
> Yes (though '..that do should..' seemed weird on the first read).

I have fixed this (Sally caught it, too).

> Or do you mean that the proposers should do everything guidelines
> (2), (5), (6) and (7) say, but shortcomings in the results of these
> guidelines (e.g., proposal being only slightly more troublesome than
> TCP) should not block the approval for widespread deployment in the
> global Internet.

Yes.  And, in re-reading the text I think it is clear.

I really can't untangle your comments in this area.  If you have
specific suggestions for the text, please send them along.

About this 'rock fetch' stuff (in terms of metrics and environments): We
do not solve the problem you outline ('go fetch another rock').  But, we
did not aim to solve that problem and we cannot solve that problem in
this document.  We cannot enumerate all environments or all metrics that
might be of interest in the future.  I sympathize with your desire for a
simple checklist that one can go through and be "ready", but this is all
much too complicated for a simple checklist.  (Consider for a moment the
additional metrics that something like XCP brought to the table that
were not germane previously.)  It is not clear to me that we should
pretend we can list metrics.  Note that we have not made this 'rock
fetch' problem any worse, either.  I.e., it exists for any new CC scheme
that would be run through without this document the same as with this
document.

I am not planning to further change the document with respect to adding
metrics or more about environments unless lots of people start yelling.
This document has been widely read at this point and as far as I know
nobody else has had this concern.  (We can call the consensus 'rough' if
you prefer.)

> >> 4) The first evaluation criteria also includes "We also note that this
> >> guideline does not constrain the fairness offered for non-best-effort
> >> traffic."
> >
> > I don't understand your point here.  All we are saying is that if---by
> > some means---we know that some flow is not best effort then it can be
> > subjected to some other criteria then it need not be constrained by the
> > guideline.
> 
> What I try to say is that I can't figure out how operationally and
> practically this could be achieved.  Do you have examples in mind
> how how this could apply in some specific scenario?
> 
> If not -- and it isn't a practical concern right now -- maybe we
> should not overengineer the BCP to address best-effort vs
> non-best-effort at all.

We didn't overengineer anything.  We just said that the guideline
doesn't apply to non-BE cases.  I can't understand your point here at
all.  It is a simple statement of document scope.

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070529/b6c7578a/attachment.bin
>From [email-masked]  Wed May 30 13:25:58 2007
From: [email-masked] (Mark Allman)
Date: Wed May 30 13:30:29 2007
Subject: [Iccrg] Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt
 (Specifying New Congestion Control Algorithms) to BCP
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

>      For other guidelines, i.e., (2), (5), (6), and (7), the author
>      must perform the suggested evaluations and provide recommended
>      analysis.  Evidence that
>      the proposed mechanism has significantly more problems than those of
>      TCP should be a cause for concern in approval for widespread
>      deployment in the global Internet.

Looks OK to me.  I have incorporated it, modulo comments from Sally.

As for the non-BE stuff: This document is a no-op.  But, why is that an
issue?  The IETF would have to grapple with the non-BE case just as it
does today (i.e., without a set of guidelines).  This one document does
not need to solve all the world's problems.  If you want to write a
document about how the IETF should handle non-BE congestion control
proposals, I think that'd be fine.  And, again, I am not hearing outcry
on this point so I think the document is fine (even if the consensus on
this one point is not completely 'smooth').

Thanks,
allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070530/22f4b0ad/attachment.bin
>From [email-masked]  Thu May 31 03:30:02 2007
From: [email-masked] (Mark Allman)
Date: Thu May 31 03:31:54 2007
Subject: [Iccrg] Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt
 (Specifying NewCongestion Control Algorithms) to BCP
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> 	  - two or more implimentations using a new alternate cc algorithm
> 	    could be used as interoperability against each other and another
> 	    cc algor..
>
> 	  - if possible, a Linux, xBSD, etc public reference should be
> 	    available,

This is part of the standards process already.  (Not the public
reference business, but that seems like a whole different can of worms
than we are working on.)

> 	  - experiences using the new cc algorithm should be available,

That is what the guidelines in the document are about.

> 	  - ALL new CC algorithms SHOULD pass through a preliminary
> 	    experimental stage..

The document says:

    Following the lead of HighSpeed TCP [RFC3649], alternate congestion
    control algorithms are expected to be published as "Experimental"
    RFCs until such time that the community better understands the
    solution space.

> 	2) What is the expected consequences if a private entitity
> 	   implements a private/IP CC algorithm that is unfair, etc..

That is out of scope for this document.  Clearly what to do about
"cheaters" is a worthy thing to think / write about.  But, this document
is guidelines for those who want to bring their work to the IETF
community.

> 	3) Classification (ordering) of a CC algorithm that is used
> 	   as a TCP option, so two endpoints can determine which
> 	   CC algorithm is used at each endpoint,

This is a detail not a guideline.

> 	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).

> 	5) Well known TCP CC algorithms that may use non-standard options:
> 	ie: 10 Dup-ACKs for a fast re-xmit..

What does this mean?  (I mean, I understand that you are talking about
non-standard stacks.  But, I have no idea what your point here is as it
relates to the i-d.)

> 	6) Specifiying a minimum inter-packet gap based on recent history
> 	   to minimize ANY CC alg from implmenting say a 100 seg burst,
> 	   from a non-slow start re-start...

More details that are fine to think about but are out of scope for this
document.

Folks- this document has been voted on by the IESG and has all but
passed.  We have made a few tweaks from IESG comments and Pekka's
comments.  Clearly big issues can and should still be addressed, but
this document is seemingly past "open season" on small things.

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070530/73c166d6/attachment.bin
>From [email-masked]  Thu May 31 18:17:00 2007
From: [email-masked] (Wesley Eddy)
Date: Thu May 31 18:20:38 2007
Subject: [Iccrg] [[email-masked]: iccrg - Requested session has been
 scheduled for IETF 69]
Message-ID: <[email-masked]>

The ICCRG session in Chicago has been moved to Tuesday, July 24.  We
still have a 2.5 hour slot:

> The sessions that you have requested have been scheduled.
> Below is the scheduled session information followed by 
> the information of sessions that you have requested.
>
> iccrg Session 1 (2.5 hours)
> Tuesday, Afternoon Session III 1740-1840
> Room Name: Breakout 7

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Michael Welzl)
Date: Tue May 29 08:25:16 2007
Subject: [Iccrg] Re: RG feedback on draft-irtf-iccrg-cc-rfcs-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear Gorry,

A million thanks for all this effort! I'm already looking forward
to incorporating your comments (I know that sounds strange, but
it's true  :)   ). From a quick glance, I think that we'll
generally agree with most if not all of them.

Cheers,
Michael

On Mon, 2007-05-28 at 18:41 +0100, Gorry Fairhurst wrote:
> I am going to say "sorry" to preface this long list of comments, because I
> can see there that has been thought that has gone into this, and many of my
> comments will seem to criticise the wording or detail.
> 
> Below are my comments which may attract more feedback from others in the RG?
> 
> Gorry
> 
> ---
> 
> The abstract does not seem right to me:
> 
>    This document is a survey of congestion control topics within the RFC
>    series.  The intent of this document is to be an informational
>    snapshot of the current state of Internet standards and other IETF
>    products related to congestion control.  This is an initial output of
>    the IRTF's Internet Congestion Control Research Group (ICCRG) and may
>    be used as one reference or starting point for the future work of the
>    research group, especially in noting gaps or open issues in the
>    current IETF standards.
> 
> The issue here is that this does not recommend BCP or reflect IETF consensus
> on these RFCs, could you consider perhaps something more like:
> 
>    This document is an informational snapshot produced by the IRTF's
> Internet Congestion Control Research Group (ICCRG). It provides a survey of
> congestion control topics described by documents in the RFC series.  This
> does not modify or update the specifications or status of the RFC document
> that are discussed. It may be used as a reference or starting point for the
> future work of the research group, especially in noting gaps or open issues
> in the current IETF standards.
> 
> ---
> Page 3:
> 
> I think section 1 could be improved also in the clarity that it does not
> modify published RFCs.
> ---
> Page 4:
> 
> I suggest citing some key RFCs on QoS framework though, since this NOT
> entirely orthogonal, e.g. IP multicast with QoS does not need CC if the
> allocated capacity matches the rate of the sender... etc.  Also note
> QOS-markings can be used for alternate CC semantics.
> ---
> Page 4:
> The draft says: 
> /Furthermore, MAC protocols are not typically discussed in the RFC series,/
> But it does work on IP over link layers --- I think the IETF has many
> ip-over-foo WGs trying to solve this sort of problem! - Maybe wording could
> be tuned?
> ---
> Page 5:
> The draft says: 
> / single class of traffic as per our classification. /
> I do not see the classification, could this please be made clearer?
> ---
> Page 5:
> This does not cite RFC 1122, which seems a good base reference?
> ---
> Page 5:
> RFC 2309, text seems to critique the spec.
> IMHO, this is a judgment call: /and many experts assume/  please provide
> evidence, or choose more careful wording.
> 
> Although you seem to suggest this is obsolete, my understanding was that
> these issues remain and that this is considered best practice by the IETF.
> 
> IMHO, the 2 recommendations in section 6 provide excellent guidance for
> setting priorities within ICCRG. Does the fact that the ICC RG did not state
> this, mean that they do not agree, or did not consider? What was the RG
> consenus on this point?
> ---
> Page 6:
> RFC 2914 is BCP, and hence not just a discussion.
> ---
> Page 6:
> RFC3124 - seems at odds with RFC4614
> RFC 4614 states:
>       Although a
>       Proposed Standard, some pieces of the Congestion Manager support
>       architecture have not been specified yet, and it has not achieved
>       use or implementation beyond experimental stacks, so it is not
>       listed among the standard TCP enhancements in this roadmap.
> These ideas have been implemented in some OS in the form of RFC 2140, which
> has not been described.
> ---
> Page 8:
> Please provide citations to Limited Slow-Start and HighSpeed TCP.
> ---
> Page 11:
> One issue I have is that RFC 2481 is declared HISTORIC, and hence there must
> be a very clear reason why you refer to this rather than RFC3168.
> ---
> Page 12:
> RFC 3540:
> IMHO, this paragraph needs to be rephrased. The word "controversy" is itself
> controversial!
> 
> I have no details on actual implementation - and suspect this is very hard
> to assess. Current deployment is low, but I am equally unsure that a
> transient debate the is the right thing to record in the permanent record.
> ---
> Page 14:
> Explicit Congestion Notification (ECN) is also supported in 4341.
> ---
> Page 17:
> The last section following "WEBRC requires" is true also for ALC. I'd rather
> avoid the impression that the IETF concludes WEBRC is in someway better than
> ALC, can you rephrase please?
> ---
> Page 17:
> RFC 3940:
> There's no problem mentioning NORM, but as far as I know it's not a CC
> method in itself.
> ---
> Page 19:
> Source Quench - are we still mentioning this as if it actually worked as a
> method? - I'd hope not!
> ---
> 
> The document does not mention some other TCP Specs (which could be OK) - but
> I think it would be improved by mentioning something to do with validation,
> as in RFC 2861, and the methods in RFC 3465 - End hosts need to know that
> what they are doing makes sense.
> ---
> 
> The document also does not speak of QuickStart, which seems a valid RFC to
> include here. Are there others also missing?
> ---
> 
> I am assuming that this will be submitted for publication as a RFC - and
> therefore become part of the same volume of work as the other RFCs it
> describes, albeit as a product of the IRTF, rather than IETF. I think it is
> therefore important that this does not judge the value of these RFCs - this
> requires detailed review. Clearly it is best to offer good guidance, but I
> am also urging careful wording.
> 
> I'll also send the more detailed author comments (including editorial NiTs)
> with marking-up text to the authors .  I look forward to reading the next
> revision.
> 
> Best wishes,
> 
> Gorry
> 
> 
> 
> 
> 
> 
> 

From: [email-masked] (Lars Eggert)
Date: Mon May 28 08:54:33 2007
Subject: [Iccrg] Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2007-5-26, at 14:24, ext Pekka Savola wrote:
> (Note: this is still a draft version if you're referring to
> http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt)
>
> This model raises one fundamental question issue of the scope of  
> this document.
>
> Who should be evaluating section 3 and 4 of this document?  Is this  
> solely meant for ICCRG, the IETF or both?  If both, would both  
> parties do everything described in those documents?

The basic idea behind this ION is that a researcher would bring his  
or her proposal, papers and experimental data to the ICCRG, which  
would then evaluate whether a proposal is safe for experimentation in  
the Internet or in more restricted network environments. (According  
to draft-ietf-tsvwg-cc-alt, and probably also draft-irtf-tmrg- 
metrics.) That review will accompany the resulting -00 technical  
specification when it is brought to the IETF.

> It would be clearer if the reviewer was ICCRG, and the IETF would  
> not attempt to perform the same review, and the IETF wouldn't be  
> allowed to second-guess the proposal, e.g., that it's research has  
> not been done well enough if it was already positively evaluated by  
> ICCRG.

There is a strong expectation that the IETF would usually agree with  
the review recommendation that the ICCRG made, and take on the  
document. (Sufficient people overlap, the ICCRG has stronger  
congestion control expertise, etc.) But process-wise it *is* up the  
to the WG (likely TCPM) to come to consensus on whether they want to  
adopt any given work item, and that consensus call can't be  
outsourced to the ICCRG. But I would personally see it as a sign that  
something went very wrong if TCPM would not publish something as  
Experimental that came with a strong ICCRG review.

Lars

PS: I'm editing the ION in response to IESG comments. The latest  
working version is under http://www3.tools.ietf.org/group/iesg/trac/ 
browser/ions/drafts - I'd be interested in hearing suggestions on how  
the text could be improved.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070528/593f6ce3/smime.bin
>From [email-masked]  Mon May 28 18:41:03 2007
From: [email-masked] (Gorry Fairhurst)
Date: Mon May 28 18:42:43 2007
Subject: [Iccrg] RG feedback on draft-irtf-iccrg-cc-rfcs-01
Message-ID: <[email-masked]>

I am going to say "sorry" to preface this long list of comments, because I
can see there that has been thought that has gone into this, and many of my
comments will seem to criticise the wording or detail.

Below are my comments which may attract more feedback from others in the RG?

Gorry

---

The abstract does not seem right to me:

   This document is a survey of congestion control topics within the RFC
   series.  The intent of this document is to be an informational
   snapshot of the current state of Internet standards and other IETF
   products related to congestion control.  This is an initial output of
   the IRTF's Internet Congestion Control Research Group (ICCRG) and may
   be used as one reference or starting point for the future work of the
   research group, especially in noting gaps or open issues in the
   current IETF standards.

The issue here is that this does not recommend BCP or reflect IETF consensus
on these RFCs, could you consider perhaps something more like:

   This document is an informational snapshot produced by the IRTF's
Internet Congestion Control Research Group (ICCRG). It provides a survey of
congestion control topics described by documents in the RFC series.  This
does not modify or update the specifications or status of the RFC document
that are discussed. It may be used as a reference or starting point for the
future work of the research group, especially in noting gaps or open issues
in the current IETF standards.

---
Page 3:

I think section 1 could be improved also in the clarity that it does not
modify published RFCs.
---
Page 4:

I suggest citing some key RFCs on QoS framework though, since this NOT
entirely orthogonal, e.g. IP multicast with QoS does not need CC if the
allocated capacity matches the rate of the sender... etc.  Also note
QOS-markings can be used for alternate CC semantics.
---
Page 4:
The draft says: 
/Furthermore, MAC protocols are not typically discussed in the RFC series,/
But it does work on IP over link layers --- I think the IETF has many
ip-over-foo WGs trying to solve this sort of problem! - Maybe wording could
be tuned?
---
Page 5:
The draft says: 
/ single class of traffic as per our classification. /
I do not see the classification, could this please be made clearer?
---
Page 5:
This does not cite RFC 1122, which seems a good base reference?
---
Page 5:
RFC 2309, text seems to critique the spec.
IMHO, this is a judgment call: /and many experts assume/  please provide
evidence, or choose more careful wording.

Although you seem to suggest this is obsolete, my understanding was that
these issues remain and that this is considered best practice by the IETF.

IMHO, the 2 recommendations in section 6 provide excellent guidance for
setting priorities within ICCRG. Does the fact that the ICC RG did not state
this, mean that they do not agree, or did not consider? What was the RG
consenus on this point?
---
Page 6:
RFC 2914 is BCP, and hence not just a discussion.
---
Page 6:
RFC3124 - seems at odds with RFC4614
RFC 4614 states:
      Although a
      Proposed Standard, some pieces of the Congestion Manager support
      architecture have not been specified yet, and it has not achieved
      use or implementation beyond experimental stacks, so it is not
      listed among the standard TCP enhancements in this roadmap.
These ideas have been implemented in some OS in the form of RFC 2140, which
has not been described.
---
Page 8:
Please provide citations to Limited Slow-Start and HighSpeed TCP.
---
Page 11:
One issue I have is that RFC 2481 is declared HISTORIC, and hence there must
be a very clear reason why you refer to this rather than RFC3168.
---
Page 12:
RFC 3540:
IMHO, this paragraph needs to be rephrased. The word "controversy" is itself
controversial!

I have no details on actual implementation - and suspect this is very hard
to assess. Current deployment is low, but I am equally unsure that a
transient debate the is the right thing to record in the permanent record.
---
Page 14:
Explicit Congestion Notification (ECN) is also supported in 4341.
---
Page 17:
The last section following "WEBRC requires" is true also for ALC. I'd rather
avoid the impression that the IETF concludes WEBRC is in someway better than
ALC, can you rephrase please?
---
Page 17:
RFC 3940:
There's no problem mentioning NORM, but as far as I know it's not a CC
method in itself.
---
Page 19:
Source Quench - are we still mentioning this as if it actually worked as a
method? - I'd hope not!
---

The document does not mention some other TCP Specs (which could be OK) - but
I think it would be improved by mentioning something to do with validation,
as in RFC 2861, and the methods in RFC 3465 - End hosts need to know that
what they are doing makes sense.
---

The document also does not speak of QuickStart, which seems a valid RFC to
include here. Are there others also missing?
---

I am assuming that this will be submitted for publication as a RFC - and
therefore become part of the same volume of work as the other RFCs it
describes, albeit as a product of the IRTF, rather than IETF. I think it is
therefore important that this does not judge the value of these RFCs - this
requires detailed review. Clearly it is best to offer good guidance, but I
am also urging careful wording.

I'll also send the more detailed author comments (including editorial NiTs)
with marking-up text to the authors .  I look forward to reading the next
revision.

Best wishes,

Gorry

From: [email-masked] (Michael Welzl)
Date: Fri May 25 15:15:32 2007
Subject: [Iccrg] Submitting draft-irtf-iccrg-cc-rfcs-01 for IRSG review
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <000b01c79e49$4b6d1630$0200a8c0@fun> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 2007-05-25 at 15:58 +0300, Lars Eggert wrote:
> On 2007-5-25, at 0:20, ext Michael Welzl wrote:
> > Any other concerns?
> 
> Gorry's email made me take a look at -01, which I hadn't read yet.
> 
> I was OK with -00, which was basically a straightforward survey that  
> categorized and summarized existing RFCs. (I didn't think that a  
> congestion control survey was the most important thing for ICCRG to  
> be working on, but if people were willing to put in the effort, that  
> was fine by me.)
> 
> I do think that the new text in -01 is a bit problematic. Looking at  
> the diff [1], several new paragraphs were added that go beyond what  
> I'd expect in a survey. The new text comments and sometimes even  
> speculates on the usefulness, applicability or deployment status of  
> the surveyed RFCs and IETF efforts. It does so without citing  
> sources, and seems to reflect the personal opinion of the authors.

We included the additional text in response to feedback
that we got from the list.

Clearly, our goal was not to provide biased viewpoints,
but rather to provide information which is valuable,
yet is not contained in the documents that we list, just
to give some more context to the whole thing. Here's
an example:

--
At the time of this writing, the IETF's TCP Maintenance and Minor
Extensions Working Group (TCPM) was developing an update to RFC 2581  to
clarify and revise some points. These included the definition of  a
duplicate ACK, initial congestion window and slow start threshold
values, behavior in response to retransmission timeouts, the use of  the
limited transmit mechanism, and security with regards to  misbehaving
receivers that practice ACK division.
--

I think that this information is useful, and you won't
find it by going through the RFCs that we list.

Therefore, I think that we'll just have to go through the
new statements one by one and fix the problem. May I therefore
ask you to tell us which parts exactly you disagree with?

> Even though I personally agree with some of those statements, I'm  
> worried that there doesn't seem to have been any public discussion on  
> them in the ICCRG or the wider transport community. Or, for that  
> matter, a discussion on whether the ICCRG wants to change from  
> publishing a survey of congestion control RFCs to publishing a  
> commentary on such RFCs, which the changes from -00 to -01 have  
> resulted in.

It's not supposed to be a commentary - we just wanted to give
some context, as in the statement above. If we accidentally
wrote anything that represents our personal viewpoints rather
than useful facts, I'm sure that I can speak for Wesley too
when I say that we'd happily agree to remove it.

Cheers,
Michael

From: [email-masked] (Lars Eggert)
Date: Fri May 25 14:01:08 2007
Subject: [Iccrg] Submitting draft-irtf-iccrg-cc-rfcs-01 for IRSG review
In-Reply-To: <000b01c79e49$4b6d1630$0200a8c0@fun>
References: <[email-masked]> <[email-masked]> <000b01c79e49$4b6d1630$0200a8c0@fun>
Message-ID: <[email-masked]>

On 2007-5-25, at 0:20, ext Michael Welzl wrote:
> Any other concerns?

Gorry's email made me take a look at -01, which I hadn't read yet.

I was OK with -00, which was basically a straightforward survey that  
categorized and summarized existing RFCs. (I didn't think that a  
congestion control survey was the most important thing for ICCRG to  
be working on, but if people were willing to put in the effort, that  
was fine by me.)

I do think that the new text in -01 is a bit problematic. Looking at  
the diff [1], several new paragraphs were added that go beyond what  
I'd expect in a survey. The new text comments and sometimes even  
speculates on the usefulness, applicability or deployment status of  
the surveyed RFCs and IETF efforts. It does so without citing  
sources, and seems to reflect the personal opinion of the authors.

Even though I personally agree with some of those statements, I'm  
worried that there doesn't seem to have been any public discussion on  
them in the ICCRG or the wider transport community. Or, for that  
matter, a discussion on whether the ICCRG wants to change from  
publishing a survey of congestion control RFCs to publishing a  
commentary on such RFCs, which the changes from -00 to -01 have  
resulted in.

Lars

[1] http://www3.tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/ 
draft-irtf-iccrg-cc-rfcs-01.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070525/0b2e8a6a/smime.bin
>From [email-masked]  Fri May 25 14:04:21 2007
From: [email-masked] (Wesley Eddy)
Date: Fri May 25 14:10:04 2007
Subject: [IRSG] [Iccrg] Submitting draft-irtf-iccrg-cc-rfcs-01 for 
	IRSGreview
In-Reply-To: <000b01c79e49$4b6d1630$0200a8c0@fun>
References: <000b01c79e49$4b6d1630$0200a8c0@fun>
Message-ID: <[email-masked]>

On Thu, May 24, 2007 at 11:20:03PM +0200, Michael Welzl wrote:
> 
> > It currently seems to be a summary of the various RFCs produced by IETF 
> > TSV area. I suggest at least the tsvwg chairs need to review this (and I 
> > missed this stage - probably through overload, it was certainly not by 
> > intention).
> 
> I don't think that they *need* to review this, but it would surely make
> sense if they did.

Right; at the moment, the document is really for the benefit of the RG,
in giving us all a common knowledge of the scope and breadth of what's
already in existence, and what isn't.  This is important since we want
anything new to play nicely, learn from what's gone before it, etc.

Is explaining the purpose the only worry you had?  Why else is it
unready?  We appreciate the comments, and some more specific criticism
would really be useful.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Michael Welzl)
Date: Thu May 24 22:24:03 2007
Subject: [Iccrg] Submitting draft-irtf-iccrg-cc-rfcs-01 for IRSG review
References: <[email-masked]> <[email-masked]>
Message-ID: <000b01c79e49$4b6d1630$0200a8c0@fun>

> IMHO, this document does not look ready to publish. I am also struggling 
> a little to see which part of the Charter this addresses, and the 
> intended purpose of this document, so I suspect the content or abstract, 
> or both need work.

As far as I know, a IRTF RG can publish RFCs which are not
mentioned in its charter. Regarding the purpose, here's the relevant
part from the abstract:

--
The intent of this document is to be an informational
snapshot of the current state of Internet standards and other IETF
products related to congestion control.  This is an initial output of
the IRTF's Internet Congestion Control Research Group (ICCRG) and may
be used as one reference or starting point for the future work of the
research group, especially in noting gaps or open issues in the
current IETF standards.
--

I agree that saying "the intent of the document is to be a document
which is XY" doesn't really say much; the purpose is clearer from
the second sentence - the intention is indeed to provide a starting
point for the future work of the research group, and we hope that
it will help to note gaps or open issues in current IETF standards.

I agree to rephrase the abstract, making this intention more prominent.

As for the content, I think that this part of the 2nd paragraph in the
introduction says quite what the purpose of the document is:

--
   When designing a new Internet protocol, it is therefore important to
   not only understand how congestion control works in TCP but also have
   a broader understanding of congestion control and know about other
   related RFCs -- some of them give guidance, some of them describe
   mechanisms which may have a direct influence on a newly designed
   protocol, and some of them may only be "related work" worth knowing
   about.  The purpose of this document is to facilitate and encourage
   this search for knowledge by providing an overview of RFCs related to
   congestion control that have been published thus far.  This document
   is a product of the IRTF's Internet Congestion Control Research Group
   (ICCRG) as a strong grasp of the existing literature should benefit
   further ICCRG work. 
---

I'd agree to make the intended purpose more prominent in the
document - as I think that this text already says it quite clearly,
I'd appreciate if you could make a more concrete suggestion,
though.

> It currently seems to be a summary of the various RFCs produced by IETF 
> TSV area. I suggest at least the tsvwg chairs need to review this (and I 
> missed this stage - probably through overload, it was certainly not by 
> intention).

I don't think that they *need* to review this, but it would surely make
sense if they did.

Any other concerns?

Cheers,
Michael

From: [email-masked] (Gorry Fairhurst)
Date: Thu May 24 21:46:44 2007
Subject: [Iccrg] Submitting draft-irtf-iccrg-cc-rfcs-01 for IRSG review
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

IMHO, this document does not look ready to publish. I am also struggling 
a little to see which part of the Charter this addresses, and the 
intended purpose of this document, so I suspect the content or abstract, 
or both need work.

It currently seems to be a summary of the various RFCs produced by IETF 
TSV area. I suggest at least the tsvwg chairs need to review this (and I 
missed this stage - probably through overload, it was certainly not by 
intention).

Please do forgive (and correct me) if I am misunderstanding the IRTF 
process ...

Best wishes,

Gorry

Michael Welzl wrote:

>Dear all,
>
>In conformance with draft-irtf-rfcs-00, Wes and I would like
>to submit draft-irtf-iccrg-cc-rfcs-01 (yep, sorry, almost the
>same name - don't confuse the two!) for IRSG review:
>http://www.ietf.org/internet-drafts/draft-irtf-iccrg-cc-rfcs-01.txt
>
>draft-irtf-rfcs-00 states that a document should have
>a paragraph in the first section describing the level of
>support for the document and the breadth of review for the
>document.
>
>Sorry, this document doesn't have that; the feedback was so little
>that I decided to submit this without an update and simply
>state the review situation in this email instead (I hope that's ok):
>
>The RG was given a 2 week deadline to comment, and, as you
>can see here:
>http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-April/thread.html
>the only feedback was:
>http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-April/000215.html
>and we will definitely take the (very minor) issues that were raised
>into account for the next update.
>
>(...plus there was a direct email, but Wes could satisfactorily
>answer the question that was asked).
>
>The previous version received some feedback, which we addressed -
>Wes put a diff online at:
>http://roland.grc.nasa.gov/~weddy/shared/iccrg/cc-rfcs-00-01-diff.html
>
>Cheers,
>Michael
>
>--
>
>PS: here's the relevant text for IRSG review from Aaron's
>draft-irtf-iccrg document:
>
>   A (firm) eight-week IRSG review period follows after which a poll is
>   taken.  Reviews should be similar to that for a conference paper.
>   Votes can be:
>
>   o  'ready to publish' -- requires a thorough read and reasonably
>      detailed review
>
>   o  'not ready to publish' -- requires a thorough read, reasonably
>      detailed review, and actionable comments.
>
>   o  'no objection' -- I don't object if this document goes forward;
>      I've read the document (perhaps quickly); I have some small
>      comments which are not show stoppers; I don't have great expertise
>      in the area.
>
>   o  'request more time to review' -- a commitment to to provide a
>      thorough review in a specified period of time.
>
>   Reviews should be written to be public.  In particular, they should
>   be sent to the submitted RG mailing list.  (We may need a tracker of
>   some sort to collect reviews.)
>
>   At least two other IRSG members (besides the one sponsoring the
>   document) need to vote 'ready to publish' for the document to move
>   forward.  Any vote of 'not ready to publish' will hold a document's
>   progress until the comments are addressed.  The IRTF chair may choose
>   to override 'not ready to publish' holds that, in the opinion of the
>   chair, have received an adequate response.
>
>
>I hope I did everything right!  :)
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
>  
>

From: [email-masked] (Mark Allman)
Date: Wed May 23 14:56:48 2007
Subject: [Iccrg] Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Pekka-

> 1) the document appears to be slightly inconsistent wrt. what it's
> actually specifying, or there are nuances that may not be sufficiently
> well articulated.  The introduction speaks of "..evaluating suggested
> CC algorithms that _significantly differ_ from the general CC
> principles outlined in [RFC2914]" (emphasis mine).  The abstract does
> not mention 'significantly differ', and there is Rule (0) which seems
> to imply that this BCP could be applied both to the mechanisms that
> significantly differ from the RFC2914 guidelines and other congestion
> control mechanisms that still honor the RFC 2914 guidelines.  Which is
> it?  Does it have implications on the different 'tracks'?

I think you are reading a little much into this.  I have just tweaked
the language in the document to include 'significantly different' in the
abstract and have changed (0) to this:

    (0) Differences with Congestion Control Principles [RFC2914]

        Proposed congestion control mechanisms that do should include a
        clear explanation of the deviations from [RFC2914].
    
Is that more clear?

> Section 2 also says "Each alternate CC algorithm published is
> required to include a statement in the abstract indicating whether
> or not the proposal is considered safe for use on the Internet".
> Which documents this applies to is not clear enough: all IETF
> documents (through WG or through an AD)? IAB documents?  IRTF
> documents?  Individual RFC-editor submissions? It is not clear to me
> whether this document would have the authority (without explicit
> discussion within the RFC-editor publications constituencies) to
> impose further requirements on non-IETF document streams especially
> if it doesn't include 'Updates: 3932' in its header.  I suspect the
> document only means to affect the IETF RFC publication stream but is
> not clear enough about it.

The document is intended to apply to IETF-produced documents.  I added
the following to the 'Status' section.  Does this help?

    Note: we are not changing RFC publication process for non-IETF
    produced documents (e.g., those from the IRTF or independent
    RFC-Editor submissions).  However, we would hope the guidelines in
    this document inform the IESG as they consider whether to add a note
    to such documents.

> Section 4 only talks of 'minimum requirements for a document to be
> approved as Experimental with approval for widespread deployment in
> the global Internet.' and further down "..approval for widespread
> deployment".  What about the rest?  Also, is omitting "in the global
> Internet" intentional? The flow of text doesn't go well as it is if
> that's the case, and if it's intentional, I'd rather use two
> entirely different wordings to make 'encouraged for widespread
> deployment' and 'encouraged for widespread deployment in the global
> Internet' more clearly distinct from each other. (Also, it isn't
> clear if the text is out of sync regarding guideline (2) compared to
> what it says in section 3 and what it says here.)

I agree the text is a little weird.  I beat it a little.  Does this:

    The minimum requirements for approval for widespread deployment in
    the global Internet include guidelines (1) on assessing the impact
    on standard congestion control, (3) on investigation of the proposed
    mechanism in a range of environments, guideline (4) on protection
    against congestion collapse and guideline (8), discussing whether
    the mechanism allows for incremental deployment.

    For other guidelines, i.e., (2), (5), (6), and (7), evidence
    that the proposed mechanism has significantly more problems
    than those of TCP should be a cause for concern in approval for
    widespread deployment in the global Internet.

work better?

> 2) the document requires that 'serious scientific study .. needs to have
> been done'.  Yet there is no metrics an outsider could use to evaluate
> whether this test is met or not.  It may be that TCP congestion
> control community has de-facto oral tradition what needs to be
> evaluated before an algorithm can be looked at seriously, but based on
> this proposed BCP, such metrics are not clear enough.
> 
> Unless we can define clearer requirements and metrics for evaluation,
> perhaps the IETF should not attempt to make such an evaluation but
> leave it to the scientific community.  I'm not sure how the IETF can
> liaise with the scientific community on that, e.g., whether it's
> possible to get a consensus statement from IRSG or an IRTF RG or
> something that could meet this requirement (if we don't want specify
> these criteria within the IETF).

The IETF and the IRTF have worked out a procedure for working on these
sorts of things (and Lars has documented it in an ION).  

At the end of the day, IMO, the IETF needs to be able to make decisions
about new CC schemes.  The document we wrote lays out a set of areas in
which authors of such proposals need to provide information to the IETF
community such that the IETF community can make sound engineering
judgments about the proposals.  For a document that intends to live for
a long time it is pretty hard to go beyond "sound scientific evaluation"
and a big-picture list of *areas* where we know we want information.

> Also, checklist (2) has "A minimum goal for experimental mechanisms
> proposed for widespread deployment in the Internet should
> be that they do not perform significantly worse than TCP
> in these environments."
> 
> However, 'these environments' refers to a non-exhaustive list of
> scenarios.  This checklist does not provide adequate information to
> evaluate whether sufficient testing in the non-exhaustively defined
> "difficult environments" has taken place or not.  I do not believe we
> can require assessments in various environments unless it's better
> specified what which environmets that various refers to.

You are right that we may want to better enumerate things.  But, we
cannot necessarily illuminate all such environments that one might
encounter.  I hacked out the following text (to be added, not replacing
anything that is there now).

        While it is impossible to enumerate all possible "difficult
        environments", we note that the IETF has previously grappled
        with paths with long delays [RFC2488], high delay bandwidth
        products [RFC3649], high packet corruption rates [RFC3155],
        packet reordering [RFC4653] and significantly slow links
        [RFC3150].  Aspects of alternate congestion control that impact
        networks with these characteristics should be detailed.

Is that better?

> 3) The first evaluation criteria includes ".. should be evaluated when
> competing with standard IETF congestion control."
> 
> What is that standard IETF congestion control referred to?  RFC 793
> plus RFC 1122?  These are the only two IETF _Standard_ specifications
> I can think of. Or does this include proposed standards as well?  What
> constitutes "IETF congestion control" or "standard congestion control"
> (in another place) that a CC algorithm should be evaluated against?
> 
> Please do not cite the TCP roadmap RFC on this.  It's Informational
> and not an IETF consensus statement, and as such has no authority to
> define what constitutes "standard congestion control".

Added refs:

        Proposed congestion control mechanisms should be evaluated when
        competing with standard IETF congestion control
        [RFC2581,RFC2960,RFC4340].

> 4) The first evaluation criteria also includes "We also note that this
> guideline does not constrain the fairness offered for non-best-effort
> traffic."

I don't understand your point here.  All we are saying is that if---by
some means---we know that some flow is not best effort then it can be
subjected to some other criteria then it need not be constrained by the
guideline. 

> 5) Normative references is empty, yet this is a BCP document which, among
> other things, referred to "standard congestion control" without
> providing a reference (as raised above).  Please move some
> informational references over here and/or add applicable references.

I have now put the references to RFCs 2581, 2914, 2960 and 4340 under
normative references.

(And, splitting the references was the dumbest thing we ever did---it
causes no end to the haggling.)

> editorial
> ---------
> 
>      networks).  Recent research has yielded many alternate congestion
>      control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP],
>      [XCP], and many more).  Using these new congestion control
> 
> ==> please remove the references from the abstract per ID-nits.

Done.

> 2.  Status
> 
> ==> this title seems too short, and a somewhat longer and a more
> descriptive one would be useful.  Actually the section seems to be a
> mix and match of different topics and a better organization might help
> the document considerably.  E.g., if there was a numbered list or
> subsection of different "publication paths" and descriptions of each
> the scope of the document and the intent of this section would likely
> be much clearer.

I changed the title to "Document Status", but I am not inclined to
re-arrange it further because lots of people have read this now and
nobody has complained.

The major caveat here is that *I* hacked out the changes described
above.  Sally may want to wordsmith or just plain disagree.

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070523/992d20a6/attachment.bin
>From [email-masked]  Wed May 23 17:19:36 2007
From: [email-masked] (Wesley Eddy)
Date: Wed May 23 17:22:05 2007
Subject: [Iccrg] chicago meeting day/time
Message-ID: <[email-masked]>

FYI, there is a preliminary schedule for the Chicago IETF meeting
available at:

https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=69.

The ICCRG meeting is set for 9:00 AM on Friday, July 27, with a 2.5 hour
time slot.  We will start developing an agenda closer to the meeting,
but if you'd like to present, you could start letting us know now.

Note all the caveats that it is not final and is subject to revision
until July 2, but with that said, I think there are good odds that this
particular meeting will stay at that time.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] ([email-masked])
Date: Thu May 10 16:40:48 2007
Subject: [Iccrg] Email Confirmation - Response Required
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070510/9d12feb2/attachment.html
>From [email-masked]  Tue May 15 16:12:14 2007
From: [email-masked] (Michael Welzl)
Date: Tue May 15 16:14:45 2007
Subject: [Iccrg] Submitting draft-irtf-iccrg-cc-rfcs-01 for IRSG review
Message-ID: <[email-masked]>

Dear all,

In conformance with draft-irtf-rfcs-00, Wes and I would like
to submit draft-irtf-iccrg-cc-rfcs-01 (yep, sorry, almost the
same name - don't confuse the two!) for IRSG review:
http://www.ietf.org/internet-drafts/draft-irtf-iccrg-cc-rfcs-01.txt

draft-irtf-rfcs-00 states that a document should have
a paragraph in the first section describing the level of
support for the document and the breadth of review for the
document.

Sorry, this document doesn't have that; the feedback was so little
that I decided to submit this without an update and simply
state the review situation in this email instead (I hope that's ok):

The RG was given a 2 week deadline to comment, and, as you
can see here:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-April/thread.html
the only feedback was:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-April/000215.html
and we will definitely take the (very minor) issues that were raised
into account for the next update.

(...plus there was a direct email, but Wes could satisfactorily
answer the question that was asked).

The previous version received some feedback, which we addressed -
Wes put a diff online at:
http://roland.grc.nasa.gov/~weddy/shared/iccrg/cc-rfcs-00-01-diff.html

Cheers,
Michael

--

PS: here's the relevant text for IRSG review from Aaron's
draft-irtf-iccrg document:

   A (firm) eight-week IRSG review period follows after which a poll is
   taken.  Reviews should be similar to that for a conference paper.
   Votes can be:

   o  'ready to publish' -- requires a thorough read and reasonably
      detailed review

   o  'not ready to publish' -- requires a thorough read, reasonably
      detailed review, and actionable comments.

   o  'no objection' -- I don't object if this document goes forward;
      I've read the document (perhaps quickly); I have some small
      comments which are not show stoppers; I don't have great expertise
      in the area.

   o  'request more time to review' -- a commitment to to provide a
      thorough review in a specified period of time.

   Reviews should be written to be public.  In particular, they should
   be sent to the submitted RG mailing list.  (We may need a tracker of
   some sort to collect reviews.)

   At least two other IRSG members (besides the one sponsoring the
   document) need to vote 'ready to publish' for the document to move
   forward.  Any vote of 'not ready to publish' will hold a document's
   progress until the comments are addressed.  The IRTF chair may choose
   to override 'not ready to publish' holds that, in the opinion of the
   chair, have received an adequate response.

I hope I did everything right!  :)