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

[Gorry Fairhurst]

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