ネットワークからの明示的なフィードバックを利用せずに、トランスポート
プロコトルが PMTUDを行う提案。
現在のMTUより少し大きな MTUをあるタイミングで試し、その後に続く
verification periodでロスレートに変化がない場合、そのMTUは安全なサイズと
判断する。この過程を繰り返すことによりPMTUDを行う。
conervativeに実装する場合、verification periodの長さは full RTTとなる。
この場合、１つのMTUサイズの検証に 3RTTかかることになる。最初の RTTは
probe phaseとなり、probe packetが転送されてからACKが受信されるまでの
期間となる。次のRTTは、transition periodとなり、新しいMTUで通信を行う
期間となる。最後のRTTは、transition periodにおける転送のロスレートを
計測する期間となる。
３つの期間中に、タイムアウトや probeパケット以外のロスがある場合は
輻輳と判断し、congestion controlを行う。
この手法は、optionとして Packet Too Big Messageを MTUの検出に利用する
ことができるが、 Packet Too Big Messageは DoSに利用される場合もあるので
注意が必要である。
SCTPの場合、アプリケーションデータに dummyの情報を追加することにより
probeパケットを作成することができる。この方式は probeが失敗して、アプリ
ケーションデータを再送する場合などには便利だが、反面、dummyの情報が
ネットワーク資源を浪費するという問題もある。
TCPの場合、dummyのデータとアプリケーションデータの境界を指定する方法が
ないため、この手法は使えない。したがって、以下の２つの手法が考えられる。
１つの方法は、probe packetの後のパケットの転送を、probe用のデータ分、
overlapさせて送る方法である。この方法は probeが成功した場合、duplicate
ACKが返送されることが問題となる。このため送信側は、probe packetによって
生じる dupackを無視する必要がある。もう１つの手法は、overlapがない様に
転送する方法である。この場合、probeの成功時の処理負荷は非常に少ないが、
失敗時の再送処理が複雑になる。
重要なポイントは、probe packetの後に複数のパケットを転送することである。
この操作により、probe packetの喪失に対して、fast retransmitなどですぐに
paketの再送ができる。
cwndの大きさを packet単位で管理しているような実装では、mtuの増加に伴って
実際のcwndの大きさや転送レートが増加しない様に気をつける。
もし、probe packetのみ lostした場合、cwndを調整することなしに、パケットを
再送してよい。probeの失敗の後は、適切な間隔をおいた後、失敗したMTU値より
も小さな値で PMTUを再開できる。
probe phaseで probe packetは lostせずに他のパケットが lostした場合、
lost packetの再送が終了するまで、transition phaseに入ってはいけない。
probe phaseで probe packetと同時に他のパケットも lostした場合、Packet
Too Big Messageを受信するか否かで振舞いが異なる。Packet Too Bigを受信した
場合、MTUを messageで指定された値にセットし、loss receveryを行う。loss
recovery終了後は、transition phaseへ移行する。
Transition phaseでは packet lossに対して、特別な処理を行わない。
Verification phaseでの lossは、pathが一定でないMTUを持つ場合や、大きなMTUが
loss rateの増加に繋がっている場合があり得る。この場合、深刻な問題の可能性が
あるため、MTU値を以前の値に戻す。
新しい MTU値のprobeは、inconclusive_probe_eventに対応する delayの後に実行
される。もし、このprobeも失敗した場合は、verification_fail_eventの delayの
後、再実行する。verification_frail_eventは、失敗の度に exponential backoffする。
ICMPによってMTU値をセットした後、Verfication Phaseでエラーが生じた場合は、
このpathに対して、"Bogus ICMP message"flagをセットする。
Probe Phaseや Verification Phaseの間に timeoutが生じた場合、特定のイベント
(probe phaseや verification phaseへの移行)の後、すべてのパケット転送が ACK
されないケース(full stop timeout)とそれ以外のケースで処理が異なる。
full stop timeoutでない場合は、re-probingまでやや長めの間隔
(probe_timeout_event, verification_timeout_event)を取る以外は通常のリカバリ
と同じ処理を行う。
probeパケットの送信後に Full stop timeoutが起きた場合、probingが
networkや end nodeに深刻な影響を及ぼし
たと判断し、大きな delay(probe_stop_event)を設定する。
ICMPによって MTU値を設定した後に、Full Stop timeoutが生じた場合は、
pathに対して、Bogus ICMP Message flagをセットした後、比較的短いdelay
(ICMP_fail_event)で、probeを再開できる。
Probeパケットは正しくACKされた後、MTU値を増加させた際に、full stop timeout
が生じた場合、probeが timeoutと関連がない可能性もあるため、比較的短いdelay
(verification_stop_event)の後に、小さなMTU値で probeを再開できる。
Inconclusiveなeventの場合は、以前と同じprobe sizeから再開し、failureな
eventの場合は小さなsizeから再開する。
Path MTU Search Stragegy
Search, Monitor, Suspendの３つのstateがある。
Search Stateでは、pathがサポートする最大のMSSを探索する。その後は Monitor
stateへ移行し、低い頻度で MPS値が大きくなったことを検査する。もし probeが
持続的に failする場合は、suspend stateへ移行し、576, 1240, 1460などの
default値をMPSとして採用する。
Search Stateは、coarse scanにより大まかに MPSを探索し、その後 finer scanで
より正確なMPSを求める。
scan中、もし cwndの値が小さすぎる場合は MPS値を増加させてはいけない。この
cwndの閾値は 20セグメントである。(この値は大きすぎるかもしれない)
Monitor Stateでは最後に失敗した MTUを MONITOR_INTERVAL second毎に実行する。
probeが失敗した場合は、Monitor stateに留まるが、成功した場合 scanning
stateへ移行する。
Search stateか Monitor Stateの状態で、congestionの度合が大きな場合、
MPSは小さな値へ再設定されるべきである。この基準は、ssthrethが 5以下に
なった場合が推奨される。
もしACKが一つも返送されず、タイムアウトが連続的に（MAX_TIMO）発生する場合は、
コネクションが小さな MSS を持つlinkを通る様に変更されたものと見倣し、MSSを
1024byteにセットする。
タイムアウトが発生し、timeout前の cwndの値が 6パケットよりも小さい場合は、
MSSを 512もしくは 1240に設定し、Suspend stateへ移行する。
注意すべき点
TCPでPMTUDをする際にoverrapで転送する場合、Fast Retransmitの誤作動を防ぐために、
MTU値を２倍以上一度に増加させてはいけない。
|
PMTUD related docs