[Iccrg] RG feedback on draft-irtf-iccrg-cc-rfcs-01
gf at erg.abdn.ac.uk
Mon May 28 18:41:03 BST 2007
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?
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.
I think section 1 could be improved also in the clarity that it does not
modify published RFCs.
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.
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
The draft says:
/ single class of traffic as per our classification. /
I do not see the classification, could this please be made clearer?
This does not cite RFC 1122, which seems a good base reference?
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?
RFC 2914 is BCP, and hence not just a discussion.
RFC3124 - seems at odds with RFC4614
RFC 4614 states:
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.
Please provide citations to Limited Slow-Start and HighSpeed TCP.
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.
IMHO, this paragraph needs to be rephrased. The word "controversy" is itself
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.
Explicit Congestion Notification (ECN) is also supported in 4341.
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?
There's no problem mentioning NORM, but as far as I know it's not a CC
method in itself.
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
More information about the Iccrg