20181111追記
IETF103でも意見が割れ議論となりましたが、Humの結果以下のようになりました。
Spin Bitの仕様は拡張仕様となり必ずしも実装する必要はなくなりました。QUICのコア仕様ではスピンビット用のビットを確保する(好きな台を入れて良い)だけとなっております。なおSpin Bitの領域は、ネゴシエーションもおこなわずに使用されます。
QUICはUDP上でTCP+TLS+HTTP/2の機能を持つ新しいプロトコルであり、IETFで絶賛標準化中です。7月にあったIETF99より、Spin Bitというトピックが議論されているので簡単に書く。
以前、下記記事にも書いたとおりQUICではACKなどを含む殆どの制御情報も暗号化されており、経路上でパケットを観測しても得られる情報は多くありません。
asnokaze.hatenablog.com
パケットロス率やRTTの情報(タイムスタンプ)はネットワークの最適化に利用されているようで、TCPのようにQUICでもそれらの情報を経路上から見れるようなパケットにするか？という議論の中で出てきたのがSpin Bitです。
Spint Bitはパケットが往復するたびにトグルするフラグで、このフィールドは暗号化されていないので経路上からも観測できます。このフラグを観測することで概ねのRTTが推測できる仕組みになっています。
Spint Bit
Spin Bitの仕様については、コアドキュメントではなく「The Addition of a Spin Bit to the QUIC Transport Protocol」という提案にて定義されている。
ハンドシェイクで使用されるロングヘッダのRTTを測定するのは容易であるので、Spin Bitのフラグはショートヘッダにのみ存在する。Sで表記されている部分がSpin Bitであり、現在仕様とくらべてフラグ部分の位置がずれただけである。
このSpin Bitは以下のように設定されます
- サーバが送るSpin Bitは、クライアントから受けっ取ったパケットの内、パケット番号が最も大きいメッセージのSping Bitと同じ値になります。
- クライアントが送るSpin Bitは、サーバから受け取ったパケットの内、パケット番号が最も大きいメッセージのSpin Bitをトグルした値になります。ただし最初に送るときは0。
全てのパケットが順番通りに送られたとすると、Spin Bitは以下のようにトグルされます。パケットがちょうど1往復したときにトグルされることがわかります。
しかしタイムスタンプなどを含まないため、サーバ・クライアント側での処理時間や何かしらの待ち時間があるとその影響をうける点や、パケットの順番の入れ替わりに対してはヒューリスティックな対応が必要なようです。
その他
このSpin BitをQUICの仕様に組み込むにあたって、デザインチームによる実験が行われています。
これは実際にQUICの実装にSpin Bitを組み込み幾つかの通信状況でRTTの測定を行うことと、プライバシー上の問題の考察です。
詳しい報告は以下のとおりです。
「Latency Spinbit Implementation Experience」
RTTの測定について一定の有効性があることが確認されるとともに、プライバシーの問題（特に地理情報の特定等）についても現状(あくまで現状)問題がないという話になっています。
今後もこのようにトランスポートレイヤの変更が議論になる可能性はありますが、このようにデザインとして十分に実験・検討する作業が行われるものと思われます。
チェアである、mnotもMLで触れています
「Spin bit discussion - where we're at」
