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

[Pekka Savola <[e-mail]>]

On Fri, 4 May 2007, The IESG wrote:
> The IESG has received a request from the Transport Area Working Group WG
> (tsvwg) to consider the following document:
>
> - 'Specifying New Congestion Control Algorithms '
>   <draft-ietf-tsvwg-cc-alt-02.txt> as a BCP
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [e-mail] mailing lists by 2007-05-18.

Sorry for missing the comment DL by a couple of days.  Too slow to

I believe this document is in a serious need of more work regarding 
its applicability and evaluation criteria.  Some of the TCP community 
may already be aware of (some of) these criteria through oral and/or 
scientific tradition.  However if IETF is requested to perform 
evaluation of these congestion control mechanisms by writing a BCP on 
it, it seems conducting a fair evaluation is impossible if it isn't 
clear enough what is evaluated.

More below.

substantial
-----------

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

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.

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

All things considered, the document needs to be much clearer what its scope
is intended to be, and if the document applies to a number of different
kinds of CC algorithms, more clearly define which rules apply to which
categories of documents.

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

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.

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

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

How does a TCP congestion control algorithm know whether a particular TCP
session is best-effort or non-best-effort?  You likely have an assumption
here that may need to be spelled out.

However, it is not clear why this distinction is even relevant.  The users
may not be able to control whether their traffic is labeled best-effort or
not (to a higher or lower class), and as a result if the user wants to test
a congestion control mechanism, its classification may change without the
TCP implementation knowing it, and as such causing havoc in the network.

Further, in many implementations, I believe it is not possible to choose
which TCP sessions should use a specific congestion control mechanism (I
think on recent Linux there is a setsockopt option for this though).  As
such even if in theory or in RFC a CC algorithm is only meant to be used for
non-BE traffic, in practise it may end up being used for all traffic on a
host due to implementation limitations.

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.

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.

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.


-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings