メインコンテンツまでスキップ

6. ユーザーデータ転送 (User Data Transfer)

本章では、SCTPエンドポイント間のユーザーデータ転送メカニズムについて説明します。

6.1. DATAチャンクの送信 (Transmission of DATA Chunks)​

SCTPエンドポイントは、確立されたアソシエーション上でDATAチャンクを通じてユーザーメッセージを交換します。

6.1.1. ペイロードデータ (Payload Data)​

送信者は、宛先への適切なフラグメンテーションサイズを決定するために「パスMTU発見 (Path MTU Discovery)」（[RFC4821]で定義）を使用すべきです (SHOULD)。

送信者は、ユーザーメッセージを複数のDATAチャンクにフラグメント化してもよく (MAY)、各チャンクはユーザーメッセージの一部を運びます。受信者は、ストリームシーケンス番号 (Stream Sequence Number) とフラグメンテーションフラグ（BビットとEビット）を使用してメッセージを再組み立てします。

ユーザーメッセージが複数のDATAチャンクにフラグメント化される場合：

  • 最初のフラグメントは、Bビットを1、Eビットを0に設定しなければなりません (MUST)
  • 中間のフラグメントは、Bビットを0、Eビットを0に設定しなければなりません (MUST)
  • 最後のフラグメントは、Bビットを0、Eビットを1に設定しなければなりません (MUST)
  • フラグメント化されていないメッセージは、Bビットを1、Eビットを1に設定しなければなりません (MUST)

同じユーザーメッセージのフラグメントを運ぶすべてのDATAチャンクは、同じストリーム識別子 (Stream Identifier) とストリームシーケンス番号 (Stream Sequence Number) を持たなければなりません (MUST)。

6.1.2. 送信シーケンス番号 (Transmission Sequence Number, TSN)​

各DATAチャンクは、有効なTSNを含まなければなりません (MUST)。TSNは32ビットのシーケンス番号で、アソシエーション初期化中に交換された初期TSN値から始まり、DATAチャンクが送信されるたびに1ずつ増加します。

TSNスペースは循環的で、比較にはシリアル番号演算 (Serial Number Arithmetic)（[RFC1982]で定義）を使用します。

送信者は、DATAチャンクで予約されたTSN値（すなわち、ピアによって通知された受信ウィンドウの外側のTSN）を使用してはなりません (MUST NOT)。

6.1.3. 輻輳制御 (Congestion Control)​

SCTPエンドポイントは、ネットワーク輻輳を避けるために輻輳制御を実装しなければなりません (MUST)。SCTPは、TCPと類似した輻輳制御メカニズムを使用します。

各SCTPアソシエーションは、次の輻輳制御パラメータを維持します：

  • cwnd (輻輳ウィンドウ, Congestion Window): 確認なしで送信できるデータ量の上限
  • ssthresh (スロースタート閾値, Slow Start Threshold): スロースタートから輻輳回避に切り替えるタイミングを決定する閾値
  • rwnd (受信ウィンドウ, Receiver Window): ピアによって通知された利用可能なバッファスペース

送信者がいつでも送信できる未確認データの量は、min(cwnd, rwnd)を超えてはなりません (MUST NOT)。

スロースタート (Slow Start):

  • アソシエーションの開始時またはタイムアウト後、cwndを2*MTU以下に設定
  • SACKが受信され、すべての確認されたデータがスロースタート段階で送信された場合、毎回、確認されたバイト数以下でcwndを増加させますが、増加量はMTUを超えてはなりません (MUST NOT)

輻輳回避 (Congestion Avoidance):

  • cwnd > ssthreshの場合、RTTごとに最大1*MTUだけcwndを増加
  • 実装は「適切なバイトカウンティング (Appropriate Byte Counting)」（[RFC3465]で定義）を使用すべきです (SHOULD)

高速再送信と高速回復 (Fast Retransmit and Fast Recovery):

  • 同じTSNが欠落していることを報告する4つの連続したSACKを受信した場合、送信者は再送信タイマーの期限切れを待たずに、そのTSNをすぐに再送信すべきです (SHOULD)

6.1.4. バンドリング (Bundling)​

SCTPエンドポイントは、合計サイズが現在のパスMTUを超えない限り、単一のSCTPパケットに複数のDATAチャンクと制御チャンクをバンドルしてもよい (MAY)。

バンドリングの利点には以下が含まれます：

  • パケットヘッダーオーバーヘッドの削減
  • ネットワーク効率の向上
  • システムコール回数の削減

送信者は、単一のパケットにできるだけ多くのデータをバンドルしようと試みるべきですが (SHOULD)、バンドリングのためにより多くのデータを待つためだけにDATAチャンクの送信を遅延させてはなりません (MUST NOT)。

6.2. DATAチャンク受信時の確認応答 (Acknowledgement on Reception of DATA Chunks)​

受信SCTPエンドポイントは、受信したDATAチャンクを確認するためにSACK (Selective Acknowledgement) チャンクを使用しなければなりません (MUST)。

6.2.1. SACK生成ルール (SACK Generation Rules)​

受信者は、SACKを生成するために次のルールを使用すべきです (SHOULD)：

  1. 遅延確認応答 (Delayed Acknowledgement):

    • 受信者は、受信した各パケットに対して直ちにSACKを送信すべきではありません (SHOULD NOT)
    • 受信者は、SACKの送信を最大200ms遅延させるべきです (SHOULD)
    • 2番目のパケットが受信された場合、SACKを直ちに送信しなければなりません (MUST)（これ以上遅延しない）

  2. 即座の確認応答の状況:

    • ギャップが検出された場合（順序が乱れたDATAチャンクを受信）
    • 受信したDATAチャンクが以前のギャップを埋めた場合
    • 重複したTSNが受信された場合

  3. SACKの内容:

    • Cumulative TSN Ack: 最高の連続して受信されたTSN
    • Gap Ack Blocks: 累積ポイントの後に受信された連続TSN範囲を示す
    • Duplicate TSNs: 重複して受信されたTSNをリスト

6.2.2. SACK処理 (SACK Processing)​

SACKを受信すると、送信者は次のことをしなければなりません (MUST)：

  1. SACKで示されたCumulative TSN Ackに累積確認ポイントを更新
  2. Gap Ack Blocksで確認されたDATAチャンクを確認済みとしてマーク
  3. 輻輳ウィンドウとスロースタート閾値を更新
  4. 必要に応じて再送信をスケジュール

6.2.3. 受信ウィンドウの更新 (Receiver Window Update)​

SACKチャンクには、受信者の利用可能なバッファスペースを示すadvertised receiver window credit (a_rwnd) が含まれます。

受信者は、SACKで利用可能なバッファスペースを正確に報告すべきです (SHOULD)。受信者は、対応するバッファスペースを消費していない限り、すでに通知されたウィンドウサイズを減少させてはなりません (MUST NOT)。

6.3. 再送信タイマー管理 (Management of Retransmission Timer)​

SCTPは、信頼性の高い送信を保証するために再送信タイマーを使用します。各宛先トランスポートアドレスは、独自の再送信タイマーを維持します。

6.3.1. RTO計算 (RTO Calculation)​

再送信タイムアウト (Retransmission Timeout, RTO) は、TCPと類似したアルゴリズムを使用して計算されます：

SRTT = 平滑化ラウンドトリップ時間 (Smoothed Round-Trip Time)
RTTVAR = ラウンドトリップ時間変動 (Round-Trip Time Variation)

初期値:
RTO.Initial = 3秒 (推奨値)
RTO.Min = 1秒
RTO.Max = 60秒

最初のRTT測定 (R):
SRTT = R
RTTVAR = R/2
RTO = SRTT + 4 * RTTVAR

後続のRTT測定 (R'):
RTTVAR = (1 - Beta) * RTTVAR + Beta * |SRTT - R'|
SRTT = (1 - Alpha) * SRTT + Alpha * R'
RTO = SRTT + 4 * RTTVAR

ここで: Alpha = 1/8, Beta = 1/4

各再送信時に、RTOは倍増すべきです (SHOULD)（指数バックオフ）、RTO.Maxに達するまで。

6.3.2. タイマールール (Timer Rules)​

T3-rtxタイマー (再送信タイマー):

  • DATAチャンクが宛先に最初に送信され、その宛先のT3-rtxタイマーが実行されていない場合、それを開始しなければなりません (MUST)
  • 宛先に送信されたすべての未確認DATAチャンクが確認された場合、その宛先のT3-rtxタイマーを停止しなければなりません (MUST)
  • T3-rtxタイマーが期限切れになった場合、その宛先で最も古い未確認DATAチャンクを再送信しなければなりません (MUST)

T3-rtxタイムアウト処理:

  1. 宛先を非アクティブとしてマーク（該当する場合）
  2. ssthreshをmax(cwnd/2, 4*MTU)に設定
  3. cwndを1*MTUに設定
  4. 最も古い未確認DATAチャンクを再送信
  5. RTOを倍増

6.3.3. ハートビートメカニズム (Heartbeat Mechanism)​

宛先の到達可能性を監視するために、SCTPエンドポイントは、各アイドル宛先に定期的にHEARTBEATチャンクを送信すべきです (SHOULD)。

HEARTBEAT間隔は設定可能であるべきで (SHOULD)、推奨されるデフォルトは30秒です。

HEARTBEATが送信されるとき：

  • Heartbeatタイマーを開始
  • HEARTBEATに送信タイムスタンプと宛先アドレス情報を含める

HEARTBEAT ACKが受信されたとき：

  • RTTを計算
  • RTOを更新
  • 宛先をアクティブとしてマーク

HEARTBEATがタイムアウトした場合（HEARTBEAT ACKが受信されない）：

  • 宛先のエラーカウントを増加
  • エラーカウントが閾値を超えた場合、宛先を非アクティブとしてマーク

6.4. マルチホームSCTPエンドポイント (Multi-Homed SCTP Endpoints)​

SCTPは、複数のIPアドレスを持つエンドポイントであるマルチホームエンドポイントをサポートします。

6.4.1. プライマリパスと代替パス (Primary and Alternate Paths)​

各SCTPエンドポイントは以下を維持します：

  • プライマリパス (Primary Path): 通常のデータ送信に使用される優先パス
  • 代替パス (Alternate Paths): プライマリパスが失敗したときに使用されるパス

エンドポイントは、プライマリパスを通じてデータを優先的に送信すべきであり (SHOULD)、プライマリパスが利用できない場合にのみ代替パスを使用します。

6.4.2. パス選択 (Path Selection)​

送信者は次のようにすべきです (SHOULD)：

  • 新しいデータを送信するためにプライマリパスを使用
  • 再送信のために代替パスを使用（プライマリパスが失敗した場合）
  • すべてのパスをHEARTBEATを使用して定期的にプローブ

プライマリパスが非アクティブであると判断された場合、送信者は、アクティブな代替パスを新しいプライマリパスとして選択すべきです (SHOULD)。

6.4.3. パス障害検出 (Path Failure Detection)​

パスは次の場合に失敗したと見なされます：

  • 連続した複数の送信失敗が発生（Path.Max.Retransに達する）
  • 連続した複数のHEARTBEATタイムアウトが発生

すべてのパスが失敗した場合、アソシエーションは上位層に報告されるべきであり (SHOULD)、終了される可能性があります。

6.5. ストリーム識別子とストリームシーケンス番号 (Stream Identifier and Stream Sequence Number)​

SCTPは、複数の並行ストリームをサポートし、各ストリームはストリーム識別子 (Stream Identifier, SI) によって一意に識別されます。

ストリーム識別子 (Stream Identifier, SI):

  • 16ビット値、範囲0から65535
  • アソシエーション初期化中にストリームの数が交渉される
  • 各ストリームは独立してユーザーメッセージを配信

ストリームシーケンス番号 (Stream Sequence Number, SSN):

  • 16ビット値、各ストリームごとに独立して維持
  • 受信側でメッセージを並べ替えて再組み立てするために使用
  • ストリームごとに増加

ストリームは、メッセージの論理的な分離を提供し、複数の独立したデータフローが同じアソシエーション上で同時に送信されることを可能にし、ヘッドオブラインブロッキング (Head-of-Line Blocking) を回避します。

6.6. 順序付き配信と順序なし配信 (Ordered and Unordered Delivery)​

SCTPは、2つのメッセージ配信モードをサポートします：

6.6.1. 順序付き配信 (Ordered Delivery)​

デフォルトモード。メッセージは、各ストリーム内で送信された順序で上位層に配信されます。

  • DATAチャンクのUビットが0に設定
  • ストリームシーケンス番号を使用して順序を保証
  • 同じストリームのメッセージがSSN順に配信

6.6.2. 順序なし配信 (Unordered Delivery)​

メッセージは、受信されるとすぐに上位層に配信され、順序に関係ありません。

  • DATAチャンクのUビットが1に設定
  • ストリームシーケンス番号は無視される
  • 受信後すぐに配信され、以前のメッセージを待たない

順序なし配信は、順序保証が不要なリアルタイムデータ（ビデオストリームなど）に適しています。

6.7. 受信DATA TSNのギャップの報告 (Report Gaps in Received DATA TSNs)​

受信者が受信シーケンスにギャップを検出した場合（すなわち、順序が乱れたデータを受信）、SACKでこれらのギャップを報告しなければなりません (MUST)。

Gap Ack Block形式:

Gap Ack Block Start: Cumulative TSN Ackからの相対オフセット
Gap Ack Block End: Cumulative TSN Ackからの相対オフセット

例えば、Cumulative TSN Ack = 100で、TSN 102-105が受信された場合：

Gap Ack Block Start = 2  (102 - 100)
Gap Ack Block End = 5    (105 - 100)

受信者は、単一のSACKで複数のギャップブロックを報告してもよい (MAY)。

6.8. CRC32cチェックサム計算 (CRC32c Checksum Calculation)​

SCTPは、そのチェックサムアルゴリズムとしてCRC32c (Castagnoli) を使用し、単純なチェックサムよりも強力なエラー検出機能を提供します。

6.8.1. チェックサム計算ステップ (Checksum Calculation Steps)​

  1. SCTPパケットのチェックサムフィールドをすべて0に設定
  2. SCTPパケット全体（SCTP共通ヘッダーとすべてのチャンクを含む）に対してCRC32cを計算
  3. 計算されたCRC32c値をチェックサムフィールドに配置

CRC32c多項式:

x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 + 
x^18 + x^14 + x^13 + x^11 + x^10 + x^9 + x^8 + x^6 + x^0

受信者は、受信した各SCTPパケットのCRC32cチェックサムを検証しなければなりません (MUST)。チェックサムが一致しない場合、パケットを静かに破棄しなければなりません (MUST)。

本章では、信頼性の高い送信、輻輳制御、マルチホーミングサポート、およびストリーム多重化を含む、SCTPユーザーデータ転送の中核メカニズムを包括的にカバーしています。

に最終更新