RFC 7053 - SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7053
タイトル : RFC 7053 - ストリーム制御伝送プロトコルのSACK-IMMEDIATELY拡張
翻訳編集 : 自動生成

[要約] RFC 7053は、Stream Control Transmission Protocol（SCTP）のSACK-IMMEDIATELY拡張機能に関する規格です。この拡張機能は、SCTPのパフォーマンスを向上させるために、SACK（Selective Acknowledgment）の送信を即座に行うことを可能にします。

Internet Engineering Task Force (IETF)                         M. Tuexen
Request for Comments: 7053                                  I. Ruengeler
Updates: 4960                           Muenster Univ. of Appl. Sciences
Category: Standards Track                                     R. Stewart
ISSN: 2070-1721                                           Adara Networks
                                                           November 2013

SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol

ストリーム制御伝送プロトコルのSACK-IMMEDIATELY拡張

Abstract

概要

This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding Selective Acknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems.

このドキュメントでは、DATAチャンクの送信者が対応する選択的確認応答（SACK）チャンクをすぐに返送し、遅延させないようにする方法を定義することにより、RFC 4960を更新しています。これは、（I）中間ビットと呼ばれるDATAチャンクヘッダーのビットを指定することによって行われます。これは、ストリーム制御伝送プロトコル（SCTP）実装またはSCTPスタックを使用するアプリケーションのいずれかによって設定できます。チャンクヘッダーの不明なフラグはSCTP実装によって無視されるため、この拡張機能は相互運用性の問題を引き起こしません。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7053.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7053で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The (I)mmediate Bit in the DATA Chunk Header  . . . . . . . . . 3
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Triggering at the Application Level . . . . . . . . . . . . 4
     4.2.  Triggering at the SCTP Level  . . . . . . . . . . . . . . . 4
   5.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     5.1.  Sender-Side Considerations  . . . . . . . . . . . . . . . . 5
     5.2.  Receiver Side Considerations  . . . . . . . . . . . . . . . 5
   6.  Interoperability Considerations . . . . . . . . . . . . . . . . 5
   7.  Socket API Considerations . . . . . . . . . . . . . . . . . . . 5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     11.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     11.2. Informative References  . . . . . . . . . . . . . . . . . . 7

1. Introduction

1. はじめに

According to [RFC4960], the receiver of a DATA chunk should use delayed SACKs. This delay is completely controlled by the receiver of the DATA chunk and remains the default behavior.

[RFC4960]によれば、DATAチャンクの受信側は遅延SACKを使用する必要があります。この遅延はDATAチャンクのレシーバーによって完全に制御され、デフォルトの動作のままです。

In specific situations, the delaying of SACKs results in reduced performance of the protocol:

特定の状況では、SACKの遅延により、プロトコルのパフォーマンスが低下します。

1. If such a situation can be detected by the receiver, the corresponding SACK can be sent immediately. For example, [RFC4960] recommends immediately sending the SACK if the receiver has detected message loss or message duplication.

1. そのような状況が受信機によって検出できる場合、対応するSACKをすぐに送信できます。たとえば、[RFC4960]は、受信者がメッセージの損失またはメッセージの重複を検出した場合、すぐにSACKを送信することを推奨しています。

2. However, if the situation can only be detected by the sender of the DATA chunk, [RFC4960] provides no method of avoiding a delay in sending the SACK. Examples of these situations include ones that require interaction with the application (e.g., applications using the SCTP_SENDER_DRY_EVENT, see Section 4.1) and ones that can be detected by the SCTP stack itself (e.g., closing the association, hitting window limits, or resetting streams, see Section 4.2).

2. しかし、状況がDATAチャンクの送信者によってのみ検出できる場合、[RFC4960]はSACKの送信の遅延を回避する方法を提供しません。これらの状況の例には、アプリケーションとの対話が必要な状況（SCTP_SENDER_DRY_EVENTを使用するアプリケーション、セクション4.1を参照）や、SCTPスタック自体によって検出できる状況（例：関連付けを閉じる、ウィンドウの制限に達する、ストリームをリセットする、セクション4.2を参照）。

To overcome the limitation described in the second case, this document describes a simple extension of the SCTP DATA chunk by defining a new flag, the "I bit". By setting this bit, the sender of a DATA chunk indicates that the corresponding SACK chunk should not be delayed.

2番目のケースで説明されている制限を克服するために、このドキュメントでは、新しいフラグ「Iビット」を定義することによるSCTP DATAチャンクの単純な拡張について説明します。このビットを設定することにより、DATAチャンクの送信側は、対応するSACKチャンクを遅延させないように指示します。

2. Conventions

2. 規約

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. The (I)mmediate Bit in the DATA Chunk Header

3. （DATAチャンクヘッダーの即時ビット

Figure 1 shows the extended DATA chunk.

図1は、拡張されたDATAチャンクを示しています。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0    |  Res  |I|U|B|E|           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Stream Identifier      |     Stream Sequence Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Payload Protocol Identifier                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                           User Data                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Extended DATA chunk format

図1：拡張DATAチャンク形式

The only difference between the DATA chunk in Figure 1 and the DATA chunk defined in [RFC4960] is the addition of the I bit in the flags field of the DATA chunk header.

図1のDATAチャンクと[RFC4960]で定義されたDATAチャンクの唯一の違いは、DATAチャンクヘッダーのフラグフィールドにIビットが追加されていることです。

[RFC4960] defines the Reserved field and specifies that these bits should be set to 0 by the sender and ignored by the receiver.

[RFC4960]はReservedフィールドを定義し、これらのビットを送信側で0に設定し、受信側で無視するように指定しています。

4. Use Cases

4. ユースケース

The setting of the I bit can either be triggered by the application using SCTP or by the SCTP stack itself. The following two subsections provide a non-exhaustive list of examples of how the I bit may be set.

Iビットの設定は、SCTPを使用するアプリケーションまたはSCTPスタック自体によってトリガーできます。次の2つのサブセクションでは、Iビットの設定方法の例をすべて網羅していません。

4.1. Triggering at the Application Level

4.1. アプリケーションレベルでのトリガー

One example of a situation in which it may be desirable for an application to trigger the setting of the I bit involves the SCTP_SENDER_DRY_EVENT in the SCTP socket API [RFC6458]. Upper layers of SCTP that use the socket API as defined in [RFC6458] may subscribe to the SCTP_SENDER_DRY_EVENT to be notified as soon as no user data is outstanding. To avoid an unnecessary delay, the application can request that the I bit be set when sending the last user message before waiting for the event. This results in setting the I bit of the last DATA chunk corresponding to the user message; this is possible using the extension of the socket API described in Section 7.

アプリケーションがIビットの設定をトリガーすることが望ましい状況の1つの例として、SCTPソケットAPI [RFC6458]のSCTP_SENDER_DRY_EVENTがあります。 [RFC6458]で定義されているようにソケットAPIを使用するSCTPの上位層は、ユーザーデータが未解決になるとすぐに通知されるSCTP_SENDER_DRY_EVENTにサブスクライブする場合があります。不要な遅延を回避するために、アプリケーションは、イベントを待機する前に最後のユーザーメッセージを送信するときにIビットを設定するように要求できます。これにより、ユーザーメッセージに対応する最後のDATAチャンクのIビットが設定されます。これは、セクション7で説明されているソケットAPIの拡張を使用して可能です。

4.2. Triggering at the SCTP Level

4.2. SCTPレベルでのトリガー

There are also situations in which the SCTP implementation can set the I bit without interacting with the upper layer.

SCTP実装が上位層と対話せずにIビットを設定できる状況もあります。

If the association is in the SHUTDOWN-PENDING state, setting the I bit reduces the number of simultaneous associations for a busy server handling short-lived associations.

アソシエーションがSHUTDOWN-PENDING状態にある場合、Iビットを設定すると、短期間のアソシエーションを処理するビジーサーバーの同時アソシエーションの数が減少します。

Another case is where the sending of a DATA chunk fills the congestion or receiver window. Setting the I bit in these cases improves the throughput of the transfer.

もう1つのケースは、DATAチャンクの送信が輻輳ウィンドウまたは受信ウィンドウを埋める場合です。これらの場合にIビットを設定すると、転送のスループットが向上します。

If an SCTP association supports the SCTP Stream Reconfiguration extension defined in [RFC6525], the performance can be improved by setting the I bit when there are pending reconfiguration requests that require that there be no outstanding DATA chunks.

SCTPアソシエーションが[RFC6525]で定義されているSCTPストリーム再構成拡張をサポートしている場合、未処理のDATAチャンクがないことを必要とする保留中の再構成要求があるときにIビットを設定することにより、パフォーマンスを改善できます。

5. Procedures

5. 手続き

5.1. Sender-Side Considerations

5.1. 送信側の考慮事項

Whenever the sender of a DATA chunk can benefit from the corresponding SACK chunk being sent back without delay, the sender MAY set the I bit in the DATA chunk header. Please note that why the sender has set the I bit is irrelevant to the receiver.

DATAチャンクの送信側が、対応するSACKチャンクが遅延なく返送されるメリットを享受できる場合は常に、送信側はDATAチャンクヘッダーのIビットを設定してもよい（MAY）。送信者がIビットを設定した理由は受信者とは無関係であることに注意してください。

Reasons for setting the I bit include, but are not limited to (see Section 4 for the benefits):

Iビットを設定する理由は次のとおりですが、これに限定されません（利点についてはセクション4を参照）。

o The application requests to set the I bit of the last DATA chunk of a user message when providing the user message to the SCTP implementation (see Section 7).

o アプリケーションは、ユーザーメッセージをSCTP実装に提供するときに、ユーザーメッセージの最後のDATAチャンクのIビットを設定するように要求します（セクション7を参照）。

o The sender is in the SHUTDOWN-PENDING state.

o 送信側はSHUTDOWN-PENDING状態です。

o The sending of a DATA chunk fills the congestion or receiver window.

o DATAチャンクの送信により、輻輳ウィンドウまたは受信ウィンドウがいっぱいになります。

o The sending of an Outgoing SSN Reset Request Parameter or an SSN/ TSN Reset Request Parameter is pending, if the association supports the Stream Reconfiguration extension defined in [RFC6525].

o 関連付けが[RFC6525]で定義されているストリーム再構成拡張機能をサポートしている場合、発信SSNリセット要求パラメーターまたはSSN / TSNリセット要求パラメーターの送信は保留中です。

5.2. Receiver Side Considerations

5.2. 受信側の考慮事項

Upon receipt of an SCTP packet containing a DATA chunk with the I bit set, the receiver SHOULD NOT delay the sending of the corresponding SACK chunk, i.e., the receiver SHOULD immediately respond with the corresponding SACK chunk.

Iビットが設定されたDATAチャンクを含むSCTPパケットを受信すると、受信者は対応するSACKチャンクの送信を遅らせるべきではない（SHOULD NOT）、つまり、受信者は対応するSACKチャンクで即座に応答する必要がある（SHOULD）。

6. Interoperability Considerations

6. 相互運用性に関する考慮事項

According to [RFC4960], the receiver of a DATA chunk with the I bit set should ignore this bit when it does not support the extension described in this document. Since the sender of the DATA chunk is able to handle this case, there is no requirement for negotiating the support of the feature described in this document.

[RFC4960]によれば、Iビットが設定されたDATAチャンクの受信側は、このドキュメントで説明されている拡張をサポートしていない場合、このビットを無視する必要があります。 DATAチャンクの送信者はこのケースを処理できるため、このドキュメントで説明されている機能のサポートをネゴシエートする必要はありません。

7. Socket API Considerations

7. ソケットAPIの考慮事項

This section describes how the socket API defined in [RFC6458] is extended to provide a way for the application to set the I bit.

このセクションでは、アプリケーションがIビットを設定する方法を提供するために、[RFC6458]で定義されたソケットAPIがどのように拡張されるかについて説明します。

Please note that this section is informational only.

このセクションは情報提供のみを目的としています。

A socket API implementation based on [RFC6458] needs to be extended to allow the application to set the I bit of the last DATA chunk when sending each user message.

[RFC6458]に基づくソケットAPI実装を拡張して、アプリケーションが各ユーザーメッセージを送信するときに最後のDATAチャンクのIビットを設定できるようにする必要があります。

This can be done by setting a flag called SCTP_SACK_IMMEDIATELY in the snd_flags field of the struct sctp_sndinfo structure when using sctp_sendv() or sendmsg(). If the deprecated struct sctp_sndrcvinfo structure is used instead when calling sctp_send(), sctp_sendx(), or sendmsg(), the SCTP_SACK_IMMEDIATELY flag can be set in the sinfo_flags field. When using the deprecated function sctp_sendmsg(), the SCTP_SACK_IMMEDIATELY flag can be in the flags parameter.

これは、sctp_sendv()またはsendmsg()を使用するときに、struct sctp_sndinfo構造体のsnd_flagsフィールドにSCTP_SACK_IMMEDIATELYというフラグを設定することで実行できます。 sctp_send()、sctp_sendx()、またはsendmsg()を呼び出すときに、非推奨のstruct sctp_sndrcvinfo構造体が代わりに使用されている場合、SCTP_SACK_IMMEDIATELYフラグをsinfo_flagsフィールドに設定できます。非推奨の関数sctp_sendmsg()を使用する場合、SCTP_SACK_IMMEDIATELYフラグをflagsパラメータに含めることができます。

8. IANA Considerations

8. IANAに関する考慮事項

Following the chunk flag registration procedure defined in [RFC6096], IANA has registered a new bit, the I bit, for the DATA chunk.

[RFC6096]で定義されているチャンクフラグ登録手順に従って、IANAはDATAチャンクの新しいビット、Iビットを登録しました。

The "Chunk Flags" registry for SCTP has been updated as described in the following table.

SCTPの「チャンクフラグ」レジストリは、次の表に示すように更新されています。

DATA Chunk Flags

DATAチャンクフラグ

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+
            | 0x01             | E bit           | [RFC4960] |
            | 0x02             | B bit           | [RFC4960] |
            | 0x04             | U bit           | [RFC4960] |
            | 0x08             | I bit           | [RFC7053] |
            | 0x10             | Unassigned      |           |
            | 0x20             | Unassigned      |           |
            | 0x40             | Unassigned      |           |
            | 0x80             | Unassigned      |           |
            +------------------+-----------------+-----------+

9. Security Considerations

9. セキュリティに関する考慮事項

See [RFC4960] for general security considerations for SCTP. In addition, a malicious sender can force its peer to send packets containing a SACK chunk for each received packet containing DATA chunks instead of every other received packet containing DATA chunks. This could impact the network, resulting in more packets sent on the network, or the peer, because the generating and sending of the packets has some processing cost. However, the additional packets can only contain the simplest SACK chunk (no gap reports, no duplicate TSNs), since in cases of packet drops or reordering in the network a SACK chunk would be sent immediately anyway. Therefore, this does not introduce a significant additional processing cost on the receiver side. This also does not result in more traffic in the network, because a receiver sending a SACK for every packet is already permitted.

SCTPの一般的なセキュリティの考慮事項については、[RFC4960]を参照してください。さらに、悪意のある送信者は、DATAチャンクを含む他のすべての受信パケットの代わりに、DATAチャンクを含む各受信パケットのSACKチャンクを含むパケットをピアに送信させることができます。パケットの生成と送信にはある程度の処理コストがかかるため、これはネットワークに影響を与え、ネットワークまたはピアで送信されるパケットが増える可能性があります。ただし、追加のパケットに含めることができるのは、最も単純なSACKチャンク（ギャップレポートなし、重複TSNなし）のみです。これは、ネットワークでパケットがドロップしたり並べ替えられたりした場合、SACKチャンクがすぐに送信されるためです。したがって、これはレシーバー側に大幅な追加の処理コストをもたらしません。すべてのパケットに対してSACKを送信する受信者がすでに許可されているため、これによってネットワーク内のトラフィックが増えることもありません。

10. Acknowledgments

10. 謝辞

The authors wish to thank Mark Allmann, Brian Bidulock, David Black, Anna Brunstrom, Gorry Fairhurst, Janardhan Iyengar, Kacheong Poon, and Michael Welzl for their invaluable comments.

著者は、貴重なコメントを提供してくれたMark Allmann、Brian Bidulock、David Black、Anna Brunstrom、Gorry Fairhurst、Janardhan Iyengar、Kacheong Poon、およびMichael Welzlに感謝します。

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.

[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。

[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Chunk Flags Registration", RFC 6096, January 2011.

[RFC6096] Tuexen、M。およびR. Stewart、「Stream Control Transmission Protocol（SCTP）Chunk Flags Registration」、RFC 6096、2011年1月。

11.2. Informative References

11.2. 参考引用

[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011.

[RFC6458] Stewart、R.、Tuexen、M.、Poon、K.、Lei、P。、およびV. Yasevich、「Socket Control Extensions for the Stream Control Transmission Protocol（SCTP）」、RFC 6458、2011年12月。

[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012.

[RFC6525] Stewart、R.、Tuexen、M。、およびP. Lei、「Stream Control Transmission Protocol（SCTP）Stream Reconfiguration」、RFC 6525、2012年2月。

Authors' Addresses

著者のアドレス

Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE

マイケルトゥセンミュンスター応用科学大学シュテガーヴァルト通り。 39 48565シュタインフルトDE

   EMail: tuexen@fh-muenster.de

Irene Ruengeler Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE

Irene Ruengeler Muenster University of Applied Sciences Stegerwaldstr。 39 48565シュタインフルトDE

   EMail: i.ruengeler@fh-muenster.de

Randall R. Stewart Adara Networks Chapin, SC 29036 US

Randall R. Stewart Adara Networks Chapin、SC 29036 US

   EMail: randall@lakerest.net