QUICにおける信頼性のないストリームの提案仕様

20180923追記

QUICの信頼性のないデータグラム拡張(MESSAGEフレーム/Datagramフレーム)
https://asnokaze.hatenablog.com/entry/2018/09/23/012519

別の拡張仕様案が議論されています

QUICはUDPを使用しますが、内部的にストリームという信頼性のある通信単位をもちます。ストリーム上では正しい順序での配送が保証され、パケットロスしたデータも回復されます。

そのようなQUICに対して、信頼性のないストリーム、つまりパケットロスしても回復しないようなストリームの検討を行うInternet-Draftが出ている。また、合わせてその信頼性のないストリームを用いてHTTPボディを送るための仕様も提出されている。

ぞれぞれ下記の通りである

これらによって、HTTPヘッダは確実に届けるが、HTTPボディはロスしても良いというHTTPが実現できるのは面白い点である。

現状の標準化動向としては、QUICの仕様に取り込まれるかは分からないが(個人的には険しいと思う)

面白そうなので簡単に読む

信頼性のないストリームに関する考慮事項と要件について書かれている。ちなみに、この仕様はQUICのdraft-04を参照している点にも注意である。

コネクション確立時に、この仕様に対応していることを示すaccept_unreliable_stream_framesトランスポートパラメータを用いてネゴシーエションする
信頼性のないストリームをオープンする際に'R' (RELIABLE)フラグを立てる
ゾンビストリームを防ぐため、ストリームのクローズ(FIN)はロスした場合は再送される
信頼性のないストリームは、輻輳制御およびフロー制御をうける
アプリケーションは、任意の再送戦略を取れる(再送しても良い)

メディアなどの配信のために、HTTPボディの送信に信頼性のないQUICストリームを利用するための仕様。基本的には上記の「Unreliable Streams in QUIC」の仕組みを用いる。

クライアントから「Transport-Response-Reliability: unreliable」ヘッダを用いることで、レスポンスに信頼性のないストリームの利用を要求できる
「Transport-Response-Reliability: unreliable-after DATE」で時間を指定することで、指定時間経過後は再送しないことも要求できる
HTTPヘッダに関しては信頼性のあるストリームで送信されるなければならない(draft-ietf-quic-http-04, 05に言及)