[Iccrg] Re: RG feedback on draft-irtf-iccrg-cc-rfcs-01

[Michael Welzl]

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