FastlyのKazuhoさんが「Address-bound Token for QUIC」という提案仕様を出している、この中で出てくる "Sharing the Congestion Controller" という仕組みが非常に面白かったので、簡単に書いてみようと思う。
address-bound token
この提案では、同一エンドポイント間で複数のQUICコネクションをはる際に、それらのコネクションが同一エンドポイント間でやりとりされていることを確かにする「address-bound token」というものを定義します。
最初のコネクションでサーバからトークンを払い出し、クライアントが続けて同じホスト名か、IPとポートが同じサーバにコネクションを確立する際にこのトークンを提出します。
(transport parameterでaddress_bound_tokenaパラメータを設定した場合のみ、NEW_TOKENがaddress-bound tokenになります)
QUICはUDPを使用しますが、もちろん輻輳制御が行われます。この「address-bound token」を使うことで、同一エンドポイント間における複数のQUICコネクションで輻輳コントローラの状態を共有できるようになります(Sharing the Congestion Controller)。
Sharing the Congestion Controller
QUICではアンプ攻撃の対策として、そのパケットが確かにIPの所持者から送信されている事が確認できるまで、データの送信量が制限されています。address-bound tokenは払い出し先のIPがわかっているので、そのIPからaddress-bound tokenが提出されれば、確かにIPの所持者であるため、この制限は必要なくなります。（払い出したIPとは別の場合は、path validationを行うべきです。）
Sharing the Congestion Controllerによって、新しいコネクションはスロースタートする必要がありません。
送信ウィンドウサイズを共用しますが、それらをどう分配するかは送信者が決めます。
感想
Sharing the Congestion Controller すごい面白い。CDNのように複数のホスト名をホストしているとより有用そう。
Initial + 0RTTの場合はaddress-bound token使えるのかな。リプレイ(正しいIP)された場合に該当コネクションに不要なデータがより送られそうな気もするが大量にはならないか、ハンドシェイク周りの部分自信がない。
