Increasing TCP's Initial Window
draft-ietf-tcpm-initcwnd-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-04-26
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-04-15
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-03-26
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-03-16
|
08 | Martin Stiemerling | Shepherding AD changed to Martin Stiemerling |
2013-03-07
|
08 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-03-07
|
08 | (System) | RFC Editor state changed to EDIT |
2013-03-07
|
08 | (System) | Announcement was received by RFC Editor |
2013-03-06
|
08 | (System) | IANA Action state changed to No IC |
2013-03-06
|
08 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement sent |
2013-03-06
|
08 | Amy Vezza | IESG has approved the document |
2013-03-06
|
08 | Amy Vezza | IESG has approved the document |
2013-03-06
|
08 | Amy Vezza | IESG has approved the document |
2013-03-06
|
08 | Amy Vezza | Closed "Approve" ballot |
2013-03-06
|
08 | Amy Vezza | Ballot approval text was generated |
2013-03-05
|
08 | Wesley Eddy | State changed to Approved-announcement to be sent from Approved-announcement sent |
2013-03-05
|
08 | Wesley Eddy | State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2013-03-04
|
08 | Wesley Eddy | Ballot writeup was changed |
2013-02-27
|
08 | Wesley Eddy | We need to add an RFC Editor's note in order to tweak the text to meet Robert's final comment. |
2013-02-27
|
08 | Wesley Eddy | State changed to Approved-announcement to be sent::Point Raised - writeup needed from Approved-announcement to be sent |
2013-02-27
|
08 | Wesley Eddy | State changed to Approved-announcement to be sent from IESG Evaluation |
2013-02-27
|
08 | Wesley Eddy | State changed to IESG Evaluation from IESG Evaluation::AD Followup |
2013-02-25
|
08 | Robert Sparks | [Ballot comment] There's still a logic gap in the paragraph that resulted from this discussion, but I trust the authors and the area directors to … [Ballot comment] There's still a logic gap in the paragraph that resulted from this discussion, but I trust the authors and the area directors to work it out. It is important also to take into account hosts that do not implement a larger initial window. Furthermore, any deployment of IW10 should be aware that there are potential side effects to real-time traffic (such as VoIP). If users observe any significant deterioration of performance, they SHOULD fall back to an initial window as allowed by RFC 3390 for safety reasons. An increased initial window MUST NOT be turned on by default on systems without such monitoring capabilities. This still seems to rely on the users of IW10 (specifically, the users of the hosts that can change their behavior) noticing that their traffic is causing something to go wrong between two other hosts that do not implement IW10. How is that bit of magic going to happen on an IW10 host? They're only really going to be able to monitor their _own_ real-time flows. Better guidance would point to the operation environment - ideally, the operator of the network would be able to monitor for the impact of this on flows between hosts that aren't using IW10 and then work at human (rather than protocol) levels to adjust the experiment if the impact is bad. At the very least, please adjust the text to make it obvious that the potential impact on real-time traffic goes beyond real-time traffic between the hosts using IW10. |
2013-02-25
|
08 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss |
2013-02-22
|
08 | Jerry Chu | New version available: draft-ietf-tcpm-initcwnd-08.txt |
2013-02-09
|
07 | Ralph Droms | [Ballot comment] Thanks for addressing my concerns; I've cleared my Discuss position. |
2013-02-09
|
07 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
2013-01-28
|
07 | Brian Haberman | [Ballot comment] Thanks for addressing my concerns. |
2013-01-28
|
07 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to Yes from Discuss |
2013-01-28
|
07 | Yuchung Cheng | New version available: draft-ietf-tcpm-initcwnd-07.txt |
2013-01-08
|
06 | Suresh Krishnan | Request for Last Call review by GENART Completed: Ready. Reviewer: Suresh Krishnan. |
2012-12-20
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: David Waltermire. |
2012-12-13
|
06 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2012-12-13
|
06 | Benoît Claise | [Ballot comment] I'm pleased to see that you realized some experiments, and that you included the results in this document. I'm with Adrian on his … [Ballot comment] I'm pleased to see that you realized some experiments, and that you included the results in this document. I'm with Adrian on his point: I would really like that Section 12 enhances... Further experiments are required before a larger initial window shall be enabled by default in the Internet. ...with... Larger window sizes MUST NOT be enabled by default in the Internet. |
2012-12-13
|
06 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-12-12
|
06 | Ralph Droms | [Ballot discuss] In my opinion, it's not appropriate to specify explicit changes to a PS document in an Experimental document and show that the Experimental … [Ballot discuss] In my opinion, it's not appropriate to specify explicit changes to a PS document in an Experimental document and show that the Experimental document updates the PS document. This document is not making updates to the PS document that are to be added to every implementation. I will clear if the "Updates" metadata is dropped, and recommend that some additional clarifying text be added that the modifications described in this document may have a deleterious effect on other Internet traffic and should be enabled only in controlled experiments. |
2012-12-12
|
06 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded for Ralph Droms |
2012-12-12
|
06 | Russ Housley | [Ballot comment] Please consider the comments raised in the Gen-ART Review by Suresh Krishnan on 11-Dec-2012. You can find the review here: … [Ballot comment] Please consider the comments raised in the Gen-ART Review by Suresh Krishnan on 11-Dec-2012. You can find the review here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07984.html |
2012-12-12
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-12-12
|
06 | Adrian Farrel | [Ballot comment] I believe this is important work and I want to see the experimentation progress, and feedback should be gathered to hopefully move this … [Ballot comment] I believe this is important work and I want to see the experimentation progress, and feedback should be gathered to hopefully move this or similar work onto the Standards Track. So I am taking the peculiar position of balloting "Yes" while supporting a Discuss from another AD. --- I agree with Brian that this Experiment does not update 3390 and 5681, but that were it to move to the Standards Track at some point, it would update those RFCs. I believe this is a simple editorial change. --- I would really like that Section 12 enhances... Further experiments are required before a larger initial window shall be enabled by default in the Internet. ...with... Larger window sizes MUST NOT be enabled by default in the Internet. |
2012-12-12
|
06 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2012-12-12
|
06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-12-12
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-12-12
|
06 | Robert Sparks | [Ballot discuss] (Based on a last call question from Magnus Westerlund) Can the document point to studies on the impact on queue times at intermediaries, … [Ballot discuss] (Based on a last call question from Magnus Westerlund) Can the document point to studies on the impact on queue times at intermediaries, and discuss how likely the transient spikes in delays this might introduce are to become large enough to cause real-time traffic to be held long enough to make its delivery useless? (For many RTP uses, a packet that arrives too late is discarded - the opportunity to render it has passed). |
2012-12-12
|
06 | Robert Sparks | [Ballot comment] Magnus asked several questions during last call that have not yet received a response. -- It's not clear how this safety requirement will … [Ballot comment] Magnus asked several questions during last call that have not yet received a response. -- It's not clear how this safety requirement will actually help in many circumstances: It is important also to take into account hosts that do not implement a larger initial window. Furthermore, non-TCP traffic (such as VoIP) should be monitored as well. If users observe any significant deterioration of performance, they SHOULD fall back to an initial window as allowed by RFC 3390 for safety reasons. An increased initial window MUST NOT be turned on by default on systems without such monitoring capabilities. Does "systems" mean "hosts"? If so, the host using the larger initial window is not going to see the harm its doing to its neighbor's real-time streams? Or is the intent to restrict turning this on by default to hosts in environements that have comprehensive (system) monitoring capabilities, and the control mechanisms in place to affect the configuration of a host when it is damaging its neighbors? Either way, please make the reqirement more clear and be explicit about the limitations on how it will protect real-time traffic. -- In section 12, you require that a sender SHOULD cache information about whether the larger initial window has created problems, and SHOULD not use the larger window on new connnections that look like they might cause the same problems, but then call out the design of such a cache (and the heuristic for whether a new connection attempt will cause problems) as needing further experimentation. That seems to reduce to "implementations SHOULD experiment". Since this is an experiment in the first place, why not make those MUSTs (or better, encourage the experimentation with explicit prose?) |
2012-12-12
|
06 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded for Robert Sparks |
2012-12-12
|
06 | Stewart Bryant | [Ballot comment] I agree with the issues that Brian raises in his Discuss. |
2012-12-12
|
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-12-12
|
06 | Brian Haberman | [Ballot discuss] I am happy to see this work progressing, but I have one concern that we should discuss... I am troubled by seeing an … [Ballot discuss] I am happy to see this work progressing, but I have one concern that we should discuss... I am troubled by seeing an Experimental document updating Standards Tracks RFCs (3390, 5681). If the WG really believes this work will improve TCP, then it should be a Proposed Standard. However, it is obvious that this proposal needs some experimentation to determine its fitness level. Given that, I would propose that this document NOT update 3390 and 5681. As Wes pointed out, we have precedence to allow a PS follow-on (if it is deemed useful) to this work to update the current standards track documents. Quoting Wes: "If we want to use the 2414 -> 3390 example of how this was done in the past, 3390 updates the standards track (2581) and is on the standards track itself. 2414 was its experimental predecessor and does not update 2001, which would have been the relevant standards track spec at the time." So, I would propose dropping the Updates metadata and explicitly mention in the body of the document those functions/features that differ from 3390 and 5681. |
2012-12-12
|
06 | Brian Haberman | Ballot discuss text updated for Brian Haberman |
2012-12-12
|
06 | Brian Haberman | [Ballot discuss] I am happy to see this work progressing, but I have one concern that we should discuss... I am troubled by seeing an … [Ballot discuss] I am happy to see this work progressing, but I have one concern that we should discuss... I am troubled by seeing an Experimental document updating Standards Tracks RFCs (3390, 5681). If the WG really believes this work will improve TCP, then it should be a Proposed Standard. However, it is obvious that this proposal needs some experimentation to determine its fitness level. Given that, I would propose that this document NOT update 3390 and 5681. As Wes pointed out, we have precedence to allow a PS follow-on (if it is deemed useful) to this work to update the current standards track documents. Quoting Wes: "If we want to use the 2414 -> 3390 example of how this was done in the past, 3390 updates the standards track (2581) and is on the standards track itself. 2414 was its experimental predecessor and does not update 2001, which would have been the relevant standards track spec at the time." |
2012-12-12
|
06 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2012-12-12
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-12-11
|
06 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-12-11
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-12-11
|
06 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2012-12-10
|
06 | Stephen Farrell | [Ballot comment] - section 3, 2nd para says: "A larger initial window will incentivize applications to use fewer concurrent TCP connections." I don't see how … [Ballot comment] - section 3, 2nd para says: "A larger initial window will incentivize applications to use fewer concurrent TCP connections." I don't see how that sentence follows from those before it. Surely the logical conclusion from the text so far is that browsers or other applications will want to benefit from being (more) unfair to other applications? - section 12, para 2: would it be an idea to say that implementers SHOULD provide a way to roll back deployment of this change or that this is currently only suited for applications where such a roll-back is possible? You already say implentations SHOULD monitor and turn this off sometimes, but that's different, it could be that the implementation cannot detect the problem and it could also be that some applications are such that e.g. s/w update is not widely supported for some reason (perhaps sensors that use TCP or something). - If there were a de-facto sockopt for turning this on or off that might be useful to note. - Would running over TLS affect any of the results cited? Either way, that would be useful to note since there are proposals that HTTP/2.0 have TLS always turned on. - Just wondering:-) Has anyone considered whether or not this might make DPI easier and/or interact with traffic analysis of ciphertext? (I expect the answer to be "no" but would be interested if not.) |
2012-12-10
|
06 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-12-10
|
06 | Wesley Eddy | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-12-10
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-12-07
|
06 | Pearl Liang | IANA has reviewed draft-ietf-tcpm-initcwnd-06, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, there … IANA has reviewed draft-ietf-tcpm-initcwnd-06, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, there are no IANA Actions that need completion. |
2012-12-06
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-12-06
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-12-04
|
06 | Wesley Eddy | Ballot has been issued |
2012-12-04
|
06 | Wesley Eddy | [Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy |
2012-12-04
|
06 | Wesley Eddy | Created "Approve" ballot |
2012-12-04
|
06 | Wesley Eddy | Ballot writeup was changed |
2012-11-29
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Waltermire |
2012-11-29
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Waltermire |
2012-11-27
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-11-27
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-11-26
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Increasing TCP's Initial Window) to Experimental … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Increasing TCP's Initial Window) to Experimental RFC The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Increasing TCP's Initial Window' as Experimental RFC 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 ietf@ietf.org mailing lists by 2012-12-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments, with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purpose recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-11-26
|
06 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-11-26
|
06 | Wesley Eddy | Placed on agenda for telechat - 2012-12-13 |
2012-11-26
|
06 | Wesley Eddy | Last call was requested |
2012-11-26
|
06 | Wesley Eddy | Last call announcement was generated |
2012-11-26
|
06 | Wesley Eddy | Ballot approval text was generated |
2012-11-26
|
06 | Wesley Eddy | Ballot writeup was generated |
2012-11-26
|
06 | Wesley Eddy | State changed to Last Call Requested from AD Evaluation |
2012-11-25
|
06 | Wesley Eddy | State changed to AD Evaluation from Publication Requested |
2012-11-20
|
06 | Amy Vezza | Intended Status changed to Experimental from None |
2012-11-20
|
06 | Amy Vezza | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document describes a proposal to increase initial window size of TCP at most 10 segments. As it is indicated in the title page header, the consensus of the WG is to publish this document as an Experimental RFC. We will need further experiments for this proposal to be advanced as described in Section 12. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes an experimental proposal to increase initial congestion window of TCP to at most 10 segments as well as a fall-back mechanism to limit any negative effects in limited buffer or bandwidth situations. It also provides guidelines to enable/disable this features in addition to some metrics to monitor the effect of this. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There has been dominant opinions in the WG to increase initial window size of TCP. Question was whether we have a single updated value, or increasing the value gradually with a certain schedule, or defining a mechanics to adjust initial window size over time. We have explored several possibilities and eventually having a single updated value has become the consensus of the WG as other methods have some difficulties for large-scale deployment. Some of the approach in other methods have been merged into the draft during this process. The consensus was clear as no opinion against this proposal has been raised since then. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Linux has already incorporated this proposal in the main kernel distribution. This document was reviewed by various people and has been discussed in the WG for nearly three years. The authors have provided results from their extensive experiments with a larger initial window. They also provided data to address questions and concerns by reviewers. In addition, there have been some related experiments by other TCPM contributors, mostly based on simulation. The document has been updated based on feedback from the community. I believe the authors did fairly extensive work for an experimental RFC, even if valid questions are still to be answered. The remaining questions, which need further experiments, are hard to address by the authors alone. Appendix A in the document contains the list for major discussion points of the draft. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Wesley Eddy. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I've reviewed the documents and made several editorial suggestions in order to enhance the readability of the drafts. I believe the quality of this draft is matured enough to be published. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concern about it. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. There is no need for particular reviews. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I have no concerns with the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, each authors has confirmed this. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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 is widely supported as we have seen positive comments from various participants in the WG meetings as well as the ML. The consensus was solid and clear. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has indicated discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID nits gives the following errors and warnings. I've put my comments below. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -> I think we can fix this through editing process -- The draft header indicates that this document updates RFC3390, but the abstract doesn't seem to directly say this. It does mention RFC3390 though, so this could be OK. -- The draft header indicates that this document updates RFC5681, but the abstract doesn't seem to mention this, which it should. -> I think these are minor points. As it is explained in the Introduction and the draft tries to update a rather minor portion of RFC3390 and RFC5681. == Unused Reference: 'RFC6077' is defined on line 844, but no explicit reference was found in the text -> It is referred in the text. This might be a bug for ID nits? -- Obsolete informational reference (is this intentional?): RFC 2414 (Obsoleted by RFC 3390) -> This is intentional. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. I believe no formal review is needed. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This draft contains a proposal for adjusting initial window after SYN, SYN/ACK retransmission, which will update RFC3390 and RFC5681. This is described in the Abstract and Introduction and Section 2 explains the motivation. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document does not involve any IANA considerations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There is no need to require expert review for future allocations. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document contains no formal language. |
2012-11-20
|
06 | Amy Vezza | State changed to Publication Requested from AD is watching |
2012-11-20
|
06 | Amy Vezza | Note added 'Yoshifumi Nishida (nishida@sfc.wide.ad.jp) is the Document Shepherd for this document.' |
2012-11-16
|
06 | Jerry Chu | New version available: draft-ietf-tcpm-initcwnd-06.txt |
2012-10-21
|
05 | Jerry Chu | New version available: draft-ietf-tcpm-initcwnd-05.txt |
2012-06-28
|
04 | Jerry Chu | New version available: draft-ietf-tcpm-initcwnd-04.txt |
2012-02-26
|
03 | Jerry Chu | New version available: draft-ietf-tcpm-initcwnd-03.txt |
2011-10-17
|
02 | (System) | New version available: draft-ietf-tcpm-initcwnd-02.txt |
2011-10-16
|
02 | (System) | Document has expired |
2011-10-16
|
02 | (System) | State changed to Dead from AD is watching. |
2011-10-15
|
02 | Wesley Eddy | Draft added in state AD is watching |
2011-04-15
|
01 | (System) | New version available: draft-ietf-tcpm-initcwnd-01.txt |
2010-10-06
|
00 | (System) | New version available: draft-ietf-tcpm-initcwnd-00.txt |