RFC 3742 - Limited Slow-Start for TCP with Large Congestion Windows 日本語訳

URL : https://tools.ietf.org/html/rfc3742
タイトル : RFC 3742 - 大混雑のWindowsでTCPのためにスロースタートを制限
翻訳編集 : 自動生成

Network Working Group                                           S. Floyd
Request for Comments: 3742                                          ICSI
Category: Experimental                                        March 2004

        Limited Slow-Start for TCP with Large Congestion Windows

Status of this Memo

このメモの位置付け

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2004）。全著作権所有。

Abstract

抽象

This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows.

この文書では、大混雑窓のTCP接続で使用するTCPのスロースタートのためのオプションの変更について説明します。（MSS送信者の最大セグメントサイズ用）MSSサイズのセグメントの混雑何千ものウィンドウ（あるいは数万人）を使用することができますTCP接続の場合、現在のスロースタート手順は、セグメントの数千人によって輻輳ウィンドウの増加につながることができます1回のラウンドトリップ時間インチこのような増加は、簡単にパケットの数千人が1往復時間にドロップされる可能性があります。これは、TCPフロー自体のためにしばしば反生産的であり、混雑リンクを共有しているトラフィックの残りの部分にハードもあります。このノートでは、輻輳ウィンドウが大混雑窓のTCP接続のパフォーマンスを改善するために、スロースタート時のデータの一つのウィンドウのために増加することにより、セグメントの数を制限するためのオプションのメカニズムとして、スロースタートを限定する方法について説明します。

1. Introduction

1. はじめに

This note describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start, limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows.

このノートでは、大混雑窓のTCP接続で使用するTCPのスロースタートのためのオプションの変更について説明します。（MSS送信者の最大セグメントサイズ用）MSSサイズのセグメントの混雑何千ものウィンドウ（あるいは数万人）を使用することができますTCP接続の場合、現在のスロースタート手順は、セグメントの数千人によって輻輳ウィンドウの増加につながることができます1回のラウンドトリップ時間インチこのような増加は、簡単にパケットの数千人が1往復時間にドロップされる可能性があります。これは、TCPフロー自体のためにしばしば反生産的であり、混雑リンクを共有しているトラフィックの残りの部分にハードもあります。このノートでは、輻輳ウィンドウが大混雑窓のTCP接続のパフォーマンスを改善するために、スロースタート時のデータの一つのウィンドウのために増加することにより、セグメントの数を制限し、スロースタートを限定する方法について説明します。

When slow-start results in a large increase in the congestion window in one round-trip time, a large number of packets might be dropped in the network (even with carefully-tuned active queue management mechanisms in the routers). This drop of a large number of packets in the network can result in unnecessary retransmit timeouts for the TCP connection. The TCP connection could end up in the congestion avoidance phase with a very small congestion window, and could take a large number of round-trip times to recover its old congestion window. This poor performance is illustrated in [F02].

1ラウンドトリップ時間で輻輳ウィンドウの大幅な増加で結果をスロー起動すると、大量のパケットが（でもルータで慎重に調整されたアクティブキュー管理機構を持つ）ネットワーク内で廃棄される可能性があります。ネットワーク内のパケットの数が多いのこの低下は、TCP接続のための不要な再送タイムアウトが発生することができます。 TCP接続が非常に小さい輻輳ウィンドウと輻輳回避フェーズに終わる可能性、およびその古い輻輳ウィンドウを復元するために往復時間を多く取ることができます。このパフォーマンスの低下は、[F02]に例示されています。

2. The Proposal for Limited Slow-Start

2.リミテッドスロースタートの提案

Limited Slow-Start introduces a parameter, "max_ssthresh", and modifies the slow-start mechanism for values of the congestion window where "cwnd" is greater than "max_ssthresh". That is, during Slow-Start, when

限定スロースタートは、パラメータ「max_ssthresh」を紹介し、「CWND」が「max_ssthresh」より大きい輻輳ウィンドウの値に対してスロースタート機構を修正します。これはスロースタート、中に、あります

cwnd <= max_ssthresh,

CWND <= max_ssthresh、

cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every arriving ACK (acknowledgement) during slow-start, as is always the case. During Limited Slow-Start, when

常にそうであるようにcwndは、スロースタート時にすべての到着ACK（確認応答）のために1 MSS（最大セグメントサイズ）によって増加します。リミテッドスロースタート時には、とき

max_ssthresh < cwnd <= ssthresh,

max_ssthresh <CWND <= SSTHRESH、

the invariant is maintained so that the congestion window is increased during slow-start by at most max_ssthresh/2 MSS per round-trip time. This is done as follows:

輻輳ウィンドウは、ラウンドトリップ時間あたり最大2 / max_ssthresh MSSによってスロースタート中に増加されるようになっている。不変に維持されていますこれは以下のように行われます。

      For each arriving ACK in slow-start:
        If (cwnd <= max_ssthresh)
           cwnd += MSS;
        else
           K = int(cwnd/(0.5 max_ssthresh));
           cwnd += int(MSS/K);

Thus, during Limited Slow-Start the window is increased by 1/K MSS for each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead of by 1 MSS as in standard slow-start [RFC2581].

このように、限られスロースタートウィンドウが各到着ACKのための、K = INT（CWND /（0.5 max_ssthresh））のために、代わりに標準のスロースタートのように1 MSS [RFC2581]で1 / K MSSだけ増加されます。

When

いつ

ssthresh < cwnd,

SSTHRESH <cwndを、

slow-start is exited, and the sender is in the Congestion Avoidance phase.

スロースタートが終了し、送信者は輻輳回避フェーズです。

Our recommendation would be for max_ssthresh to be set to 100 MSS. (This is illustrated in the NS [NS] simulator, for snapshots after May 1, 2002, in the tests "./test-all-tcpHighspeed tcp1A" and "./test-all-tcpHighspeed tcpHighspeed1" in the subdirectory "tcl/lib". Setting max_ssthresh to Infinity causes the TCP connection in NS not to use Limited Slow-Start.)

私たちの推薦は100 MSSに設定するmax_ssthreshのためになります。（これはサブディレクトリにテスト「./test-all-tcpHighspeed tcp1A」および「./test-all-tcpHighspeed tcpHighspeed1" で、2002年5月1日後にスナップショットのため、NS [NS]シミュレータに示されている」TCL / LIB」。無限にmax_ssthreshを設定すると、限定スロースタートを使用しないようにNSでTCPコネクションが発生します。）

With Limited Slow-Start, when the congestion window is greater than max_ssthresh, the window is increased by at most 1/2 MSS for each arriving ACK; when the congestion window is greater than 1.5 max_ssthresh, the window is increased by at most 1/3 MSS for each arriving ACK, and so on.

輻輳ウィンドウがmax_ssthreshよりも大きい場合に限定スロースタートでは、ウィンドウは、各到着ACKのために最も1/2 MSSだけ増加されます。輻輳ウィンドウが1.5 max_ssthreshよりも大きい場合、ウィンドウはその上の各到着ACKのために最も1/3 MSS増加し、されています。

With Limited Slow-Start it takes:

リミテッドは、スロースタートで、それはとります。

log(max_ssthresh)

ログ（max_ssthresh）

round-trip times to reach a congestion window of max_ssthresh, and it takes:

往復時間max_ssthreshの輻輳ウィンドウに到達すると、それはとります。

log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)

（max_ssthresh）+（CWND - max_ssthresh）をログ/（/ 2 max_ssthresh）

round-trip times to reach a congestion window of cwnd, for a congestion window greater than max_ssthresh.

max_ssthreshより大きい輻輳ウィンドウのために、CWNDの輻輳ウィンドウに到達するための往復時間。

Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it would take 836 round-trip times to reach a congestion window of 83,000 packets, compared to 16 round-trip times without Limited Slow-Start (assuming no packet drops). With Limited Slow-Start, the largest transient queue during slow-start would be 100 packets; without Limited Slow-Start, the transient queue during Slow-Start would reach more than 32,000 packets.

このように、100 MSSにmax_ssthreshセットで限定スロースタートで、それは（何のパケットを廃棄しないと仮定して）リミテッドスロースタートせずに16往復時間に比べ、83,000パケットの輻輳ウィンドウに到達するために836往復時間がかかります。リミテッドスロースタートでは、スロースタート時の最大過渡キューは100のパケットになります。リミテッドスロースタートせずに、スロースタート時の過渡的なキューは、32,000人以上のパケットに達するでしょう。

By limiting the maximum increase in the congestion window in a round-trip time, Limited Slow-Start can reduce the number of drops during slow-start, and improve the performance of TCP connections with large congestion windows.

ラウンドトリップ時間の輻輳ウィンドウの最大増加を制限することにより、限定スロースタートはスロースタート時の液滴の数を削減し、大混雑窓のTCP接続のパフォーマンスを向上させることができます。

3. Experimental Results

3.実験結果

Tom Dunigan has added Limited Slow-Start to the Linux 2.4.16 Web100 kernel, and performed experiments comparing TCP with and without Limited Slow-Start [D02]. Results so far show improved performance for TCPs using Limited Slow-Start. There are also several experiments comparing different values for max_ssthresh.

トムDuniganは、Linux 2.4.16のWeb100カーネルに限定スロースタートを追加し、スロースタート[D02]とし、限定せずにTCPを比較する実験を行いました。結果は、これまでのところ限定スロースタートを使用したTCPのための改善された性能を示します。 max_ssthreshに異なる値を比較するいくつかの実験もあります。

4. Related Proposals

4.関連提言

There has been considerable research on mechanisms for the TCP sender to learn about the limitations of the available bandwidth, and to exit slow-start before receiving a congestion indication from the network [VEGAS,H96]. Other proposals set TCP's slow-start parameter ssthresh based on information from previous TCP connections to the same destination [WS95,G00]. This document proposes a simple limitation on slow-start that can be effective in some cases even in the absence of such mechanisms. The max_ssthresh parameter does not replace ssthresh, but is an additional parameter. Thus, Limited Slow-Start could be used in addition to mechanisms for setting ssthresh.

TCPの送信者が利用可能な帯域幅の制限について学ぶために、ネットワーク[VEGAS、H96]から輻輳表示を受信する前に、スロースタートを終了するためのメカニズムにかなりの研究がなされてきました。他の提案は、同じ宛先[WS95、G00]に、前のTCP接続からの情報に基づいて、TCPのスロースタートパラメータSSTHRESHを設定します。この文書もそのような機構が存在しない状態である場合に有効であることができるスロースタートに単純な制約を提案しています。 max_ssthreshパラメータはSSTHRESHに代わるものではありませんが、追加のパラメータがあります。このように、スロースタートLimitedはSSTHRESHを設定するためのメカニズムに加えて使用することができます。

Rate-based pacing has also been proposed to improve the performance of TCP during slow-start [VH97,AD98,KCRP99,ASA00]. We believe that rate-based pacing could be of significant benefit, and could be used in addition to the Limited Slow-Start in this proposal.

レートベースペーシングも[VH97、AD98、KCRP99、ASA00]スロースタート時のTCPのパフォーマンスを改善することが提案されています。私たちは、レートベースペーシングが大きな利点であることができ、そしてこの提案で限定スロースタートに加えて使用することができることを信じています。

Appropriate Byte Counting [RFC3465] proposes that TCP increase its congestion window as a function of the number of bytes acknowledged, rather than as a function of the number of ACKs received. Appropriate Byte Counting is largely orthogonal to this proposal for Limited Slow-Start.

適切なバイトカウント[RFC3465]はバイトの数の関数ではなく、受信したACKの数の関数としてよりも、肯定応答としてTCPが輻輳ウィンドウを増やすことを提案しています。適切なバイトカウントは限定スロースタートのためにこの提案に大部分が直交しています。

Limited Slow-Start is also orthogonal to other proposals to change mechanisms for exiting slow-start. For example, FACK TCP includes an overdamping mechanism to decrease the congestion window somewhat more aggressively when a loss occurs during slow-start [MM96]. It is also true that larger values for the MSS would reduce the size of the congestion window in units of MSS needed to fill a given pipe, and therefore would reduce the size of the transient queue in units of MSS.

リミテッドスロースタートにもスロースタートを終了するための仕組みを変更するには、他の提案に直交しています。例えば、FACK TCPは損失がスロースタート[MM96]中に発生した場合、幾分より積極的に輻輳ウィンドウを減少させる過減衰機構を含みます。与えられたパイプを埋めるために必要なMSSのためのより大きな値は、MSSの単位で輻輳ウィンドウのサイズを小さくするということも事実であるので、MSSの単位で過渡キューのサイズを低減するであろう。

5. Acknowledgements

5.謝辞

This proposal is part of a larger proposal for HighSpeed TCP for TCP connections with large congestion windows, and resulted from simulations done by Evandro de Souza, in joint work with Deb Agarwal. This proposal for Limited Slow-Start draws in part from discussions with Tom Kelly, who has used a similar modified slow-start in his own research with congestion control for high-bandwidth connections. We also thank Tom Dunigan for his experiments with Limited Slow-Start.

この提案は大渋滞窓とのTCP接続のための高速TCPのための大きな提案の一部であり、デブAgarwalさんとの共同作業で、Evandro・デ・ソウザによって行われたシミュレーションの結果で。限定のためにこの提案スロースタートは、高帯域幅の接続のための輻輳制御と彼自身の研究で同様の変更スロースタートを使用していたトム・ケリー、との議論から部分的に描画します。我々はまた、限定スロースタートと彼の実験のためにトムDuniganに感謝します。

We thank Andrei Gurtov, Reiner Ludwig, members of the End-to-End Research Group, and members of the Transport Area Working Group, for feedback on this document.

私たちは、この文書についてのフィードバックのために、アンドレイGurtov、ライナールートヴィヒ、エンド・ツー・エンドの研究グループのメンバー、および交通地域作業部会のメンバーに感謝します。

6. Security Considerations

6.セキュリティの考慮事項

This proposal makes no changes to the underlying security of TCP.

この提案は、TCPの基本的なセキュリティを変更しません。

7. References

7.参考

7.1. Normative References

7.1. 引用規格

[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.

[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。

[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.

[RFC3465]オールマン、M.、RFC 3465、2003年2月 "適切なバイトカウント（ABC）とTCP輻輳制御"。

7.2. Informative References

7.2. 参考文献

[AD98] Mohit Aron and Peter Druschel, "TCP: Improving Start-up Dynamics by Adaptive Timers and Congestion Control"", TR98-318, Rice University, 1998. URL "http://cs-tr.cs.rice.edu/Dienst/UI/2.0/Describe/ncstrl.rice_cs/TR98- 318/".

[AD98] MohitアロンとピーターDruschel、「TCP：適応タイマーと輻輳制御によりスタートアップダイナミクスの改善」「TR98-318、ライス大学、1998年URL」http://cs-tr.cs.rice.edu /Dienst/UI/2.0/Describe/ncstrl.rice_cs/TR98- 318 /」。

[ASA00] A. Aggarwal, S. Savage, and T. Anderson, "Understanding the Performance of TCP Pacing", Proceedings of the 2000 IEEE Infocom Conference, Tel-Aviv, Israel, March, 2000. URL "http://www.cs.ucsd.edu/~savage/".

[ASA00] A.アガルワル、S.サベージ、およびT.アンダーソン、 "TCP Pacingのパフォーマンスについて"、2000 IEEEインフォコム会議議事録、テルアビブ、イスラエル3月、2000年URLは「http：// WWW .cs.ucsd.edu /〜野蛮/」。

[D02] T. Dunigan, "Floyd's TCP slow-start and AIMD mods", 2002. URL "http://www.csm.ornl.gov/~dunigan/net100/floyd.html".

[D02] T. Dunigan、 "フロイドのTCPスロースタートとAIMD改造"、2002年URL "http://www.csm.ornl.gov/~dunigan/net100/floyd.html"。

[F02] S. Floyd, "Performance Problems with TCP's Slow-Start", 2002. URL "http://www.icir.org/floyd/hstcp/slowstart/".

[F02] S.フロイド、 "TCPのスロースタートとパフォーマンスの問題"、2002年URL "http://www.icir.org/floyd/hstcp/slowstart/"。

[G00] A. Gurtov, "TCP Performance in the Presence of Congestion and Corruption Losses", Master's Thesis, University of Helsinki, Department of Computer Science, Helsinki, December 2000. URL "http://www.cs.helsinki.fi/u/gurtov/papers/ms_thesis.html".

[G00] A. Gurtov、「混雑や腐敗損失の存在下でのTCPの性能」、修士論文、ヘルシンキ大学、コンピュータサイエンス、ヘルシンキ、2000年12月URL「の部門http://www.cs.helsinki.fi /u/gurtov/papers/ms_thesis.html」。

[H96] J. C. Hoe, "Improving the Start-up Behavior of a Congestion Control Scheme for TCP", SIGCOMM 96, 1996. URL "http://www.acm.org/sigcomm/sigcomm96/program.html".

[H96] J. C.鍬、SIGCOMM 96「TCP輻輳制御方式のスタートアップ動作の改善」、1996年URL「http://www.acm.org/sigcomm/sigcomm96/program.html」。

[KCRP99] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge, "A Simulation Study of Paced TCP", BBN Technical Memorandum No. 1218, 1999. URL "http://www.ir.bbn.com/documents/techmemos/index.html".

【KCRP99] J.クーリック、R.コールターD.ロックウェル、およびC.ヤマウズラ、 "ペースTCPのAシミュレーション研究"、BBNテクニカルメモランダム番号1218 1999 URLは「http：//www.ir.bbn。 COM /文書/ techmemos / index.htmlを」。

[MM96] M. Mathis and J. Mahdavi, "Forward Acknowledgment: Refining TCP Congestion Control", SIGCOMM, August 1996.

[MM96] M.マシスとJ. Mahdavi、 "フォワード謝辞：精錬TCP輻輳制御"、SIGCOMM、1996年8月。

[NS] The Network Simulator (NS). URL "http://www.isi.edu/nsnam/ns/".

[NS]ネットワークシミュレータ（NS）。 URL "http://www.isi.edu/nsnam/ns/"。

[VEGAS] Vegas Web Page, University of Arizona. URL "http://www.cs.arizona.edu/protocols/".

[VEGAS]ラスベガスのWebページ、アリゾナ大学。 URL "http://www.cs.arizona.edu/protocols/"。

[VH97] Vikram Visweswaraiah and John Heidemann, "Rate Based Pacing for TCP", 1997. URL "http://www.isi.edu/lsam/publications/rate_based_pacing/".

[VH97]ビクラムVisweswaraiahとジョンHeidemann、 "TCPのためのレートベースペーシング"、1997年URL "http://www.isi.edu/lsam/publications/rate_based_pacing/"。

[WS95] G. Wright and W. Stevens, "TCP/IP Illustrated", Volume 2, Addison-Wesley Publishing Company, 1995.

[WS95] G.ライトとW.スティーブンス、 "TCP / IPイラスト"、第2巻、アディソン・ウェズリー出版社、1995。

Authors' Address

著者の住所

Sally Floyd ICIR (ICSI Center for Internet Research)

サリーフロイドICIR（インターネットリサーチのためのICSIセンター）

Phone: +1 (510) 666-2989 EMail: floyd@icir.org URL: http://www.icir.org/floyd/

電話：+1（510）666-2989 Eメール：floyd@icir.org URL：http://www.icir.org/floyd/

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。