IETF DCCP WG
Additional DCCP web page
RFCs
Datagram Congestion Control Protocol (DCCP)
DCCPの Core Specを定義したもの。
DCCPの特徴。
- ACKを利用する Unreliableな通信を提供する。
- コネクションセットアップ時と終了時には Reliableなhandshakeを行う
- Reliableに optionのネゴシエーションを行う。
- ECNをサポートした Congestion Controlを行う。
- パケットロスや ECNを ACKする仕組みを持つ。
- アプリケーションに詳細な通信状況を伝達する仕組みをオプションで持つ。
- PMTUDをサポート
- 複数のCongestion Control Algorithmをサポート
DCCPは以下の10タイプのパケットを持つ。
- DCCP-Request .. コネクション開始のリクエスト
- DCCP-Response .. DCCP-Requestに対するレプライ
- DCCP-Data ... application dataの転送に使用
- DCCP-Ack ... pure ackの転送に使用
- DCCP-DataAck .. application data + ackの転送に使用
- DCCP-CloseReq .. コネクション終了のリクエスト
- DCCP-Close .. コネクションを closeする際に使用。peerから resetが送られる。
- DCCP-Reset .. コネクション終了時に使用
- DCCP-Sync, DCCP-SyncAck.. 大きな burstロスが起きた後に peer間で再 syncをする際に使用。
TCPとの違い
- 最大オプション長が 1008バイト
- 異なる ACK形式をサポート。例えば CCID2では TCPの様に 2 data packet毎に ACKを返送するが、CCID3では 1 RTTに１ ackしか返送しない。
- DoS Protection
- TCPは受信パケットが正しく queueに入れられるまで ACKを返送しないが、DCCPはヘッダ処理の段階で ACKを返送できる。
- DCCPには Flow Controlがないので、 Receive Windowが存在しない。
- Simultaneous openはサポートしない。Half-Close Stateは存在しない。
パケットフォーマットの概要
- Generic Header + Additional Fields (depending on type) + Options (optional)から構成される
- Generic Headerは基本１２バイトだが、Extended Sequence Numbers bit=1の場合は16バイト。
- コネクションの開始、終了に関わるパケットは、Extended Sequence Numbersを利用する。
- Mandatory Optionがセットされている場合、直後のオプションを処理できないreceiverはコネクションをリセットしなければならない。
Featureネゴシエーション
- Featureネゴシエーションは Change L, Confirm L, Change R, Confirm Rの４つのDCCP optionの交換で行われる。
- Lは feature location, Rは feature remoteが利用する。従って Feature locationが受信側の場合は、送信側は Change Rを送信する。
- Chnage R/L Optionによる交渉が完了すると、メッセージタイプにより、Confirm L/Rのどちらかを送信する。
- 機能の調停には、現在、Server Priorityと Non-Negotiableの２つのルールが提案されている。現在定義されているオプションはどちらかのルールを採用している。
- Server Priorityでは、Change optionは最も望ましい値から順に固定長のオプション値のリストを送り、Confirm側は現在のconfirmされた値と望ましい値のリストを返送する。オプション値は、Server側とClient側の双方の Prefernce Listにある値で、サーバからみて最も望ましい値が採用される。もし共通の値がない場合は以前の値を confirmする。
- Non-Negotiableでは、Feature locationが Change Lメッセージを送信し、Feature Remoteは
その値が有効である限り無条件に受け入れる。もし Change L中の値が無効な場合、空の
Confirm Rメッセージを返送する。
- Changeメッセージは、返答が返るまで再送され続ける。
シーケンス番号
- シーケンス番号はパケット毎。再送パケットの場合もシーケンス番号を増加させる。
- Large Burst Lossでシーケンス番号の同期がとれなくなった場合は、SyncとSyncACKメッセージを交換する。
- Data/ACK packetには Short Seqno機能が使えるが、Allow Short Sequence Numbers Feature messageを使ってこの機能を disableしても良い。特に高速な通信の場合は Short Seqnoは disableすべきである。高速な通信の目安は、1500byteのMTUで 800Mbps以上である。
チェックサム
- DCCPのチェックサムはアプリケーションデータ全体、もしくは一部分の整合性を確認できる。
- checksumの coverageはヘッダ中のCsCovの値で決定される。CsCoV=0の場合、パケット全体をカバーし、1-15の場合は、(CsCoV-1)*4 byteのアプリケーションデータをカバーする。
- Partial Checksum機能は、MinimumChecksumCoverageメッセージを交換することで利用できる。
|
I-Ds
Datagram Congestion Control Protocol (DCCP) User Guide.
DCCPの利用方法について解説したもの。
DCCPを利用すべきアプリケーションとしては、UDPを使っているもの、TCPを使っているが
timelinessが重要なもの、strict reorderが必要でないもの、小さなデータの固まりを
大量に送るもの、TCPの様に急激に送信レートが変動するのを好まないものなどが対象と
なる。
CCID2では AIMDによりノコギリ歯の様にデータ転送レートが変化するが、CCID3では転送
レートは平滑化されたサインカーブの様に変化する。
とちらのCCIDを利用するかはアプリケーションによって異なる。
単純にできるだけ多くのデータを転送する様なアプリケーションは CCID2を使うべきである。
転送レートに制限があるものや、唐突な転送レートの変動を好まないアプリケーションは
CCID3を使うべきである。
|
Profile for DCCP Congestion Control ID 2: TCP-like Congestion Control.
CCID2の輻輳制御アルゴリズムを規定している。
CCID2は TCPのAIMD型の輻輳制御を行うため、できるだけ帯域を多く利用したいアプリケーションや
転送レートの急激な変化に対応できるアプリケーションに適している。
CCID2による通信の一例
- SenderがDCCP-Dataを送る時、送信するパケット数は cwndによって制御される。Senderは
Ack Ratio Feature PacketによりReceiverの ACKの送信レートを変更できる。
(Defaultは 2)
- Receiverは ACK-Ration毎に１ACKパケットを送信する。ACKするseqnoは TCPの様な
Cumulative Seqnoではなく、単に Highest Seqnoを返す。
- Senderは ACK Packet中の ACk-Vectorよりパケットのロス情報を得る。その情報を基に
cwndの値を更新する。
- DCCPは ACK packetにも Seqnoがあるので、ACK Packetのロスを検出できる。また ECNを
サポートしていれば ACK側の経路の輻輳を検出できる。この様な場合、Sender側は
Ack Ratio Featureで ACk-Rateを下げることができる。
- Senderは 1 cwnd毎に少なくとも 1回、ACKに対する ACKを返送する。
- Senderは、TCPと同様 ACKの到着時間や Timestamp Optionを用いて、RTOを決定する。
CCID2では、Ack Vectorの利用は必須なので、Connnection Setup時に必ずこのFeatureの利用を
指定する。
CCID2による cwndの値の決定方法は RFC3517に従う。(Ack-Vectorの利用は SACKの利用と
同等なので)。但し、DCCPの cwndはパケット単位でありバイト単位ではないことに注意。
Senderは、cwnd/R(Ack-Ratio)/RTTを Ackのレートとして計測する。Lossがあった場合は
Ack Ratioを2倍に、ない場合は Additive DecreaseによりAck-Ratioを減らしていく。
但し ACK-Ratioは２より小さい値は取らない。
|
Profile for DCCP Congestion Control ID 3: TFRC Congestion Control.
CCID3の輻輳制御アルゴリズムを規定している。
CCID3は、TCP-Friendlyベースの輻輳制御を行うので、急激な転送レートの増減を
望まないアプリケーションに適している。
CCID3による通信の一例
- Senderは RFC3448と同様の手法で決定された転送レートでデータパケットを転送する。
ヘッダ中の CCValフィールドには window counterの値がセットされる。この値は
1つのloss eventで複数のパケットロスが起きた場合などに利用される。
- Receiverは、1RTT毎に少なくとも１回は ACKを返送する。ACKには最後に受け取った
パケットの情報と、Lossレートに関する情報が含まれる。
- Senderは ACKの情報を元に Loss Event Rateを計算し、転送レートを更新する。
Receiverからの Loss Event Rateの情報も利用しても構わない。
- Senderは RTTを計測し、一定時間経過してもReceiverからの Responseがない場合は
転送レートを半減させる。
Receiver側から返送される ACKは次のいずれかのオプションを利用する。これらの
オプションを含まない ACKパケットは Feedback情報として扱われない。
- Elapsed Time Optionか、Time Stamp Option
ACKパケットに対応するデータパケットが到着してから現在までの経過時間
- Receive Rate Option
最後に DCCP-ACKを送ってから現在までのデータ受信レート
- Loss Interval Option
最新の Loss Intervalをレポートする。
DCCPでは一般的に ACKに対する ACKを返送する必要がないが、Ack_Vectorを利用する場合は
定期的に ACKの ACKを返送しなければならない。(受信側の ACK statusを開放させるため)
この際には上記のオプションは送らなくてもよい。
|
DCCP CCID 3-Thin.
CCID3の簡略化版。CCID3の機能をフル実装したくない小さなシステムでの利用を想定している。
CCID3との主な相違点。
- Connection Setup時に CCID3-Thin optionが送信される。
- 双方の Half-Connectionはともに CCID3を利用する。
- Feature Parameterのいくつかが固定値となり、変更できない。
例:
- Short Seqnoは必ず許容する
- Sequence Window Featureは100
- ECNは Incapable
- Ack Ratio Featureは0
- Ack Vectorは使わない
- Checksumは full-coverageだけ。
- Data Checksum Optionは使わない
- Loss Interval Optionは使わない
- Slow Receiver, Init Cookie, Ack Vector, Data Dropped (except
on a DCCP-Response), Timestamp, Timestamp Echo, Identification,
Challenge, Payload Checksum, or Loss Intervals options, or DCCP-
DataAck or DCCP-CloseReqは送信しない。
以上の条件以外は、CCID3-Thinは通常の CCID3 Connectionと同様に動作する。
もし、上記の条件が守られなかった場合は、Rason 195でコネクションがリセットされる。
|
Problem Statement for DCCP (RFC4336)
DCCPの様な unreliableな transport serviceと e2e congestion controlを提供する
プロトコルの課題について言及したもの。
Major Issues
- congestion controlの欠如による congestion collapseの危険性
- unreliable data flowに congestion controlをいかに実装するか
- reliableな congestion feedbackをいかに実装するか？
- ECN negotiationの実装
- TCP friendly schemeの実現
IP telephonyなどでは、小さな Payloadを low delayで転送する。このような
場合、TCPよりも低overheadのプロトコルが望ましい。
Firewallをいかに通過させるかも難しい課題の一つ。
UDPの上位層でcongestion controlを実装する場合、application designerに
負荷がかかる、ECNの処理が難しくなる、userがCongestion Controlを回避する
のが容易になるなどの問題がある。
UDPの下位層でcongestion controlを実装する場合、application側で sequence
numberや congestion feedbackをサポートすると、上位層に実装する場合と
同様の問題が起こる。UDPの下位層で sequence numberをサポートする場合、
新しいパケットヘッダや新しいIP optionなどが必要になる。IP optionは IPv4
ルータで問題を引き起こしやすいし、新しいパケットヘッダの導入は新しい
プロトコルを導入するのと大きな違いがない。
Transport層で UDPの代わりに congestion controlを提供するプロトコルを
設計すると上述の問題を回避できる。TCPを改変して、unreliableな転送が
できるものを作るアプローチは、TFRC型のフローとの相性が悪い。またTCPは
byte単位でデータを扱うが、パケット単位の方が望ましい。
SCTPは機能が豊富なため header sizeのオーバヘッドが大きいので、
単純に congestion contorolを利用したい場合にはあまり向いていない。また
SCTPの congestion controlは今のところ TCP-likeなものしか定義されていない。
RTPにcongestion controlを実装する場合も SCTP同様プロトコルのoverheadが
問題となる。
以上の様な理由で、congestion controlを提供する simpleな transportプロトコル が新たに必要である。
また新しいプロトコルは以下の点も考慮すべきである。
- Mobility
- DoS attackへの対策
- RTPとの相性
- API
|
その他
Designing DCCP: Congestion Control Without Reliability (technical report)
DCCPの概念をまとめたもの。最初に読むと良いかもしれないが、現在の仕様と異なる点があることに注意。
DCCPの特徴
- 12バイトのヘッダ。Ackオプションを追加する場合さらに４バイト。(オプションヘッダは最大で 1008バイトまで追加できる。)
- DCCPは TCPと異なり 4bitの typeスペースを持つ。TCPが 4bitの flagを
使い分けるのに対してより多くのタイプを定義できる。
- Connectionの開始時にパラメータのネゴシエーションを行う。この時に
EndPointは "Change" (パラメータの変更を要求)、"Prefer"(違う値をオファーする),"Confirm"(パラメータの変更を了承)などのメッセージを交換する。
- sender側は定期的に receiver側から受信した ACKの情報を receiverに対して
レポートする。（そうしないとreceiverはいつまで ACKの情報を保持すべきかわからない)
- 通信は双方向。それぞれの方向についてパラメータをネゴシエーションする。
- 通信のセットアップ時に Congestion Control ID(CCID)を決定する。現在、CCID2と CCID3が提案されている。CCID2は TCP的な(AIMDベースの)制御を行う。CCID3は TFRC的な制御を行う。
- DCCPは、ヘッダとペイロードでそれぞれチェックサムを利用できる。Partial Checksumもサポートする。
- Hi-jackingに備えるため、DCCPは Lost Windowを定義し、Receiveできる Seqnoの範囲を制限する。
- Mobilityもサポートする。MD5などを利用する。
|
back
|
DCCP related docs