RFC 3135：proxyのACKはapplication配送の証明ではなかった

要約

RFC 3135は、衛星・無線WAN・無線LANでTCPを改善するPEPを調査した。ACKの間隔調整や削減、local ACKと再送、connection分割、圧縮、切断の隠蔽など、仕組みは一つではなかった。
proxyが出すACKは、中間点がdataを引き受けた証拠になり得る。しかし遠端TCPの受信でもapplicationの完了でもない。feedbackを短くする設計は、責任と障害状態も経路内へ移した。

速く戻ったのはdataではなく返事だった

静止衛星を経由するpathでは、光の往復時間そのものが長い。送信側が遠端からのACKを待つたびにwindowを進めるなら、link容量が残っていても十分なdataを飛行中に置けない。

そこで、難しい区間の入口にいる装置が先にACKを返す。送信側から見たRTTは短くなり、windowは開き、throughputは上がり得る。無線区間の損失も、その近くで再送すれば、遠い送信側を巻き込まずに回復できる。

ただし、早く帰ったのは受領の知らせであって、dataそのものではない。byteはproxyのbufferに残り、衛星、radio、反対側のproxy、remote TCP、applicationという残りの経路を待っているかもしれない。local ACK後に失われれば、元の送信側はすでに受領済みと理解している。修復の責任はproxyが負う。

2001年6月のRFC 3135は、このPerformance Enhancing Proxy、PEPをInformational RFCとして調査した。特定製品の仕様でも、配備命令でもない。遅延、非対称容量、誤り、低帯域、断続的接続に対して、network内の機能がどのように性能を改善し、何を代償にするかを整理した文書だった。

歴史的な焦点は単純な速度比較ではない。ACKの発行者が変われば、ACKが証明できる事実も変わる。

PEPという名前の中には別々の仕組みがあった

transport層のPEPはTCPを観察して、その挙動を変更できる。application protocolそのものはend-to-endで残す場合がある。application層のPEPはHTTPなどの内容を理解し、protocolを終端したり変換したりできる。

一台のintegrated PEPが有線と無線の境界に置かれることもあれば、distributed PEPの二つのcomponentが対象linkを挟むこともあった。非対称linkなら、data方向の装置はlocal ACKで容量を満たし、狭い戻り方向の装置は不要なACKを減らす、といった分担もできた。

split connectionでは、端末が始めたTCPはproxyで終了し、proxyが宛先へ別のTCPを作る。二つのproxyの間には、link用に調整された第三のconnectionや、UDP上の独自protocolが置かれることもある。複数の利用者connectionを一つの中間channelへ多重化する設計もあった。

これに対して、ACK spacingは宛先が作ったACKの時刻を整えるだけかもしれない。ACK filteringは狭いreverse pathから冗長な応答を除く。Snoop型の機能はbase stationでsegmentをcacheし、局所損失を再送する。圧縮は通過byteを減らす。どれもPEPと呼べるが、受領主体や意味への作用は同じではない。

RFC 3135は、透明性とend-to-end semanticsも分けた。hostから見えないproxyがTCPを途中で終端する場合がある。一方、利用者が存在を知るserviceでも、application ACKは本当の宛先まで通せる。transparentとは誰が存在を知るかであり、誰がdataを受領したかではない。

local ACKは回復義務を中間へ移した

通常のTCP ACKにも限界がある。相手側TCP実装への到着を示すが、applicationが読んだ、保存した、処理したことまでは保証しない。業務上の完了を必要とするapplicationは、自分の意味に合ったend-to-end確認を持たなければならない。

local ACKは、その前にさらに一枚の受領証を置く。RFC 3135は、PEPがlocalにACKした後でdataが落ちた場合、その回復責任はPEPにあると述べた。そのためにはbyteのcopy、sequence state、timer、下流ACKの観測、再送判断が必要になる。

効果は現実的だった。radioでのlossを短いloopで修復できる。link切断中は送信側にzero windowを見せ、stateと未確認segmentを保ち、再接続後に再開できる。split connectionとpriority制御を組み合わせれば、background flowを長く止めても、元のsenderのtimerを同じように発火させずに済む。

だが、ACKを先に発行するなら、保管そのものが検証対象になる。bufferは揮発性か。process restartに耐えるか。ACK前に全byteを確保したか。容量不足時に何を捨てるか。下流配送をどのeventで確定するか。

proxyのACKは嘘とは限らない。「私が受け取った」という近い事実を伝えている。誤りは、その一文を「宛先applicationが受け取った」と読み替えるところにある。

一つのstreamに五つの受領点

証拠を守るには、少なくとも五段階を別々に残す必要がある。

第一に送信applicationがlocal TCPへ渡す。第二にPEPが受け、bufferし、ACKする。第三にdataが劣化したsubpathを通る。第四にremote TCPがACKする。第五にremote applicationがprotocol上の意味を確認する。解析、queue投入、永続保存、transaction commit、処理完了は、それぞれ違う。

application ACKでさえ意味を明記しなければならない。RFC 3135が挙げたmail relayでは、中継MTAがmessageを不揮発storageへ書き、application levelでACKし、その後の配送責任を引き受ける。最終到達を即時保証するのではないが、責任移転がprotocolと運用に表れている。

transport PEPは一般にapplication ACKを偽造せず、上位protocolをend-to-endで動かす。この区別は重要である。それでも、最初に見えたtransport ACKを最後のapplication receiptに変えることはできない。二つの間には、linkと受信hostと業務処理が残る。

proxyのstateがconnectionの運命になった

end-to-end設計のfate sharingでは、不可欠なconnection stateを端点が持つ。途中routerが壊れても別経路があれば、端点の記憶を保ったままpacketを迂回できる。

すでにACKしたbyteとsplit connection stateをPEPだけが保持するなら、事情は違う。そのnodeの障害は、別のIP pathが存在してもconnectionを終了させ得る。壊れたのは到達性ではなく、途中にしかなかった約束の記憶である。

RFC 3135は、このtrade-offを常に否定しなかった。PEPは代替pathのないlast hopやprivate networkに置かれることも多い。元の無線断が長ければ、いずれにせよsessionは危うい。利用者が追加riskを理解したうえで、普段の大きなperformance gainを選ぶことはあり得る。

条件は利用者のcontrolだった。どう動くかを知り、故障の意味を理解し、必要なら通常のend-to-end IPを選べること。access networkが透明なPEPを強制し、利用者がACKの発行者すら知らないなら、この条件は崩れる。

network operatorは集計throughputを得る。vendorはbufferとrecoveryを決める。applicationと利用者は欠落の結果を受ける。benefitとriskを負う主体が違うなら、監査可能なcustody recordが必要になる。

end-to-end暗号はproxyの視界を閉じた

ACKを見分け、sequenceやwindowを扱い、connectionを分割するにはTCP headerが見えなければならない。applicationの圧縮や変換ならpayloadも必要になる。

端点間のIPsec ESPは、途中PEPからTCP headerと内容を隠す。RFC 3135は、多くのPEPがこの状態では最適に動けない、あるいは全く動けないと説明した。ACK spacingのようにsemanticsを保つ機能でも、対象ACKを識別できなければ実施できない。

端末とPEP、PEPと遠端の間に別々のsecurity associationを作る方法はある。しかしtrafficは処理のためにPEP内部で復号される。二つの区間が暗号化されても、端点間暗号と同じではない。区間ごとに保護levelが異なれば、片方の端点は全体が自分の交渉した強度だと誤解する恐れもある。

PEP間だけを保護する、特定trafficをbypassする、application層暗号を使う、といった緩和策もある。いずれも信頼境界と設定項目を変えるのであって、proxyへの信頼を消すものではない。

後のRFC 3449も、非対称path向けの多くの技法には暗号化されていないIP/TCP headerとflow識別が必要だとした。RFC 8404とRFC 8517は、暗号化とoperatorのtransport機能の摩擦を後年に記録した。RFC 8684はMultipath TCPで、PEPがdataを先にACKする可能性を再送規則に織り込んだ。これらは2001年の普及率ではないが、境界が残ったことを示す。

障害を隠す機能は診断も変えた

短い無線切断をapplicationから隠すことは有益である。proxyがstateを保ち、senderを止め、復旧後に再開すれば、利用者はconnectionを作り直さずに済む。

同じ設計は、長い故障の発見を遅らせる。senderはもっともらしいTCP stateのまま待ち、下流は進まない。別の通信手段へ切り替えられるapplicationでも、proxyが故障を隠す時間だけfailoverが遅れる。

pingやtracerouteは必ずしも答えにならない。ICMPはPEPを迂回するかもしれない。同じnodeを通ってもTCPと同じ処理を受けない。PEPが遠端の代わりに返答する場合、pingはproxyまでの到達しか証明しない。tracerouteはrouter列を示しても、TCPの終端点とbuffer stateを示さない。

asymmetric routingはdistributed PEPの片方を避け得る。mobile hostのhandoverでは、新しいPEPへstateを移す必要があり、頻繁な移動では間に合わない。scalabilityにも限界がある。高位layerを調べ、connectionごとにmemoryを持つPEPはrouterより重く、並列化すればflow affinityを維持する別の仕組みが要る。

悪いlinkを見えなくする装置は、自分自身を最も見えにくい障害点にしてしまう可能性があった。

surveyは普遍的な判決ではない

RFC 3135はInformational surveyである。Internet Standardではなく、PEP導入の一般勧告でも、製品benchmarkでも、deployment censusでもない。VSAT、wireless WAN、WAP、Snoopなどの例は設計の動機を説明するが、全実装が同じ性質や成果を持つことを証明しない。

著者はend-to-end principleを主流の方法として維持し、同等のend-to-end改善がない特定環境でのみPEPを使うべきだとした。新しいlink technologyは、可能ならこうした補正を不要に設計すべきだとも述べた。同時に、物理遅延やcostを原則だけで消せないことも認めた。

RFC 3234は後にPEPをより広いmiddlebox分類へ置いた。RFC 3426はRFC 3135を、性能benefitとarchitecture costを量るcase studyとして扱った。IPsec制約、新しいfailure point、診断、非対称routing、mobilityまで数えて初めて、改善の帳簿は閉じる。

throughputの横にcustodyの履歴を置く

評価は、元のlink条件から始めるべきである。方向、topology、native RTT、error、disconnect、asymmetry、workload、application successを記録する。次にPEPのowner、version、placement、mechanism、integrated/distributed、split、transparency、利用者bypassを固定する。

各operationについて、送信、proxy ACK、buffer投入、buffer durability、下流送信、local retransmission、remote TCP ACK、application ACK、永続的完了を別eventとして保存する。誰が再送したか、どのtimerが動いたか、restartで何が消えたか、両方向のrouteとhandoverがどうなったかも必要である。

security endpoint、PEPが読めるheaderとpayload、内部plaintext、bypass rule、区間ごとの保護差を残す。apparent RTTやthroughputだけでなく、applicationの完了時間と正しさを比較する。

local ACKが確実な保管より先に出る、restartでACK済みbyteが消える、pingとTCPが矛盾する、暗号化で最適化が黙って止まる、reverse pathがstateを外れる、handoverでstateを失う、transport指標が改善してapplication結果が悪化する。こうした不一致がreview triggerである。

RFC 3135のproxyはfeedback loopを短くした。それは重要な機能だった。しかし近い証人の返事は、遠い宛先の証言にはならない。proxyは「ここまで来た」と言える。applicationが自分のreceiptを返すまで、「届いた」とは言えない。

proxyはbyteをACKした。applicationにはまだ届いていなかった――RFC 3135

なぜ重要か

要約

速く戻ったのはdataではなく返事だった

PEPという名前の中には別々の仕組みがあった

local ACKは回復義務を中間へ移した

一つのstreamに五つの受領点

proxyのstateがconnectionの運命になった

end-to-end暗号はproxyの視界を閉じた

障害を隠す機能は診断も変えた

surveyは普遍的な判決ではない

throughputの横にcustodyの履歴を置く

Sources

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説