The above document has successfully completed a WGLC that ended in
March 2006, and was re-called in October 2006. After both WGLC's
there was feedback from the list, and neither call raised issues
of concern on progress as an Experimental RFC.
On behalf of the DCCP WG, I am now forwarding this for AD review
with a request that it is published as an Experimental RFC.
A copy of the Request-to-Publish write-up is enclosed below.
Best wishes,
Gorry Fairhurst & Tom Phelan
(DCCP WG co-Chairs)
--------------------------------------------------------
WG Chair's write-up
WG Internet Draft: draft-ietf-DCCP-tfrc-voip-07.txt
TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant
DCCP WG Chair: G Fairhurst <gorry@xxxxxxxxxxxxxx>
DCCP WG Chair: "Phelan, Tom" <tphelan@xxxxxxxxxxxx>
WG Shepherd: "Phelan, Tom" <tphelan@xxxxxxxxxxxx>
1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?
Yes, and v06 includes responses to the WG Chair review and WG inputs
following WGLC. v07 corrected language on PMTUD and small NiTs.
No outstanding items remain.
2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?
The document is a result of contributions primarily by the authors,
and many edit cycles inspired by WG feedback. WGLC was completed in
March 2006. The document was announced as completed WGLC at IETF 65,
IETF 66, and IETF 66.
After a further WGLC, the WG now considers this ready for publication.
(No further comments were received by the list or the Chairs at IETF-66,
comments were received in the final WGLC seeking clarification of meaning.)
There are likely to be further doubts on implementation, and deployment
cases - but these are to be expected for an experimental spec.
3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?
No, this document has already been reviewed by people from the
AVT WG, and most concerns remaining in the previous revision related to
its suitability for particular applications, notably applicability
of this profile for VoIP.
Revision v05 removed this concern, and resulted in a name change to
not suggest this as "the" solution for VoIP.
4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.
There was strong WG consensus that there was a need for work on this
topic.
At IETF-65, there were discussions on fairness, based on ns-2
simulations, but no practical experience in real networks or with real
applications. This solution seems safe compared to other IETF-defined
transport protocols, and fair (except in a few unusual cases of high
loss, where TFRC itself is also sub-optimal).
In itself, this represents an experimental change to the way CC is
thought about in the IETF.
Applicability of the methods and the way in which the techniques should
be developed are not yet clear and further work is required to progress
this. The WG therefore proposes publication of this document as a a
useful reference for this work and a possible basis for new CC protocols
(i.e. Experimental).
5) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and agree
with it?
The document has received feedback from many in the WG. There was no
feedback suggesting that the document should not be published.
6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.
No.
7) Have the chairs verified that the document adheres to _all_ of the
ID nits?
Yes.
8) Please provide a draft write-up to appear in the ballot and
approval announcement:
- Technical Summary
This document proposes a mechanism for further experimentation, but
not for widespread deployment at this time in the global Internet.
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism
for unicast flows operating in a best-effort Internet environment
[RFC3448]. TFRC was intended for applications that use a fixed
packet size, and was designed to be reasonably fair when competing
for bandwidth with TCP connections using the same packet size. This
document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that
is designed for applications that send small packets. The design
goal for TFRC-SP is to achieve the same bandwidth in bps (bits per
second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP
enforces a minimum interval of 10 ms between data packets, to
prevent a single flow from sending small packets arbitrarily
frequently.
Flows using TFRC-SP compete reasonably fairly with large-packet TCP
and TFRC flows in environments where large-packet flows and small-
packet flows experience similar packet drop rates. However, in
environments where small-packet flows experience lower packet drop
rates than large-packet flows (e.g., with Drop-Tail queues in units
of bytes), TFRC-SP can receive considerably more than its share of
the bandwidth.
- Working Group Summary
This document is a chartered item of the DCCP WG. The document provides
a description of an experimental method to provide congestion control
that is based on TFRC, but is adapted to sources that transmit small
fixed-sized packets at a fixed rate.
The document also provides simulation results to demonstrate the
fairness with other IETF-defined transport protocols and may serve as a
basis for future congestion control methods (e.g. to be developed in the
DCCP WG).
- Protocol Quality
The document defines a new experimental algorithm.
Further experimentation is required to understand the implications of
implementation, its suitability to specific applications and the
deployment within the general Internet.
---
The questionnaire and writeup is sent to the ADs and
iesg-secretary@xxxxxxxx with a request to publish the document.
The publication request SHOULD also indicate which chair will be
shepherding the document, so that this can be entered into the ID
Tracker [IDTRACKER]. In addition to making life easier for the
ADs, this lets the IETF chair know where to send Gen-ART [GEN-ART]
reviews.
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
