[Iccrg] Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP

[[e-mail] (Lars Eggert)]

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 [e-mail]  Mon May 28 18:41:03 2007
From: [e-mail] (Gorry Fairhurst)
Date: Mon May 28 18:42:43 2007
Subject: [Iccrg] RG feedback on draft-irtf-iccrg-cc-rfcs-01
Message-ID: <[e-mail]>

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