ギガの減り方など、ユーザのデータプランを考慮して最適化するGoogleサービス

モバイル通信事業者が、ユーザのギガの残量やデータプランなどをGoogleと共有する、「Mobile Data Plan Sharing API」というものがあるらしい。

モバイル通信事業者に提供されているAPIであり、おそらく一般サービス運営者は利用することは出来ない。

GoogleではこのAPIを通してユーザのデータプランを共有し、様々な最適化を行っているようである。

  • ユーザのデータ通信残量を考慮して通信の最適化を行う
  • 通信のオフピークに通信を行う

この連携を行うために、モバイル通信事業者が、DPAと呼ばれるデータプランをGoogleのサーバと共有するサービスや、PlanGloupIDを生成するPGID Endpointと呼ばれる機能を実装する必要がある。

すでに、インドの3通信事業者とYoutubeで非ピーク時にデータ通信をさせる実験済みらしい(Web5Gの文章より)。(YoutubeのSmart Offline

もちろん、サービスやクライアントがどのように最適するかは実装依存である

Mobile Data Plan Sharing API

f:id:ASnoKaze:20180404004442p:plain

共有されるデータは、下記のようなデータで
byteBalanceとしてデータ通信残量や、その他データプランのカテゴリが共有される。

もちろん例の他にも、時間制限の場合は時間残量、最高トラフィック量や、制限を超えた場合のポリシーなどが共有される。
詳しくはレファレンスに記載されている。

{
  "planGroupId": "abcdef",
  "planGroup": {
    "dataPlans": [
      {
        "planName": "ACME Red",
        "planId": "turbulent1",
        "expirationTime": "2020-02-03T04:05:06Z",
        "planModules": [
          {
            "byteBalance": {
              "quotaBytes": "1000000000",
              "remainingBytes": "9876543210"
            },
            "trafficCategories": [
              "GENERIC"
            ],
            "expirationTime": "2020-02-03T04:05:06Z"
          }
        ]
      }
    ],
    "responseStaleTime": "2018-03-04T05:06:07Z"
  }
}

その他

正直自分でためせなさそうだし、資料も多くないので、、、
詳しい人がいたら教えてほしい。

HTTP Server Pushのセマンティクス拡張する、HTTP Server *ush の提案仕様

4/1 に「HTTP Server *ush」という提案仕様が、IETFに提出されています。

4/1にです。

HTTP Server *ush

「HTTP Server Push」の音節構造は非常に舌に馴染むものです。HTTP Server Pushの成功の一つの理由でしょう。

そこで、同じ音節構造を持つ様々な「HTTP Server *ush」を定義しようというのが、この提案です。

このドキュメントでは、HTTP/2でサーバプッシュを利用するのに使用された「SETTINGS_ENABLE_PUSH 」と同様に「SETTINGS_ENABLE_*USH 」というSETTINGSパラメータを定義します。

Server Cush

Server Cushはより豪華なHTTP Server Pushです。
SETTINGS_ENABLE_CUSHで有効にすることが出来ます。

Server Dush

Server Dushはより激しいhTTP Server Pushです。
SETTINGS_ENABLE_DUSHで有効にすることが出来ます。

Server Gush

Server Gushは突然のオーバーフローをサポートするHTTP Server Pushです。
SETTINGS_ENABLE_GUSHで有効にすることが出来ます。

Server Hush

Server Hushはより丁寧なHTTP Server Pushです。
SETTINGS_ENABLE_HUSHで有効にすることが出来ます。

Server Kush

Server Kushは適法性が地域によって異なるHTTP Server Pushです。
SETTINGS_ENABLE_KUSHで有効にすることが出来ます。

Server Lush

Server Lushは植物に関係するリソースのためのHTTP Server Pushです。
SETTINGS_ENABLE_LUSHで有効にすることが出来ます。

Server Mush

Mushにはネガティブな意味があります。このServer Pushは予約されており、使用できません

Server Rush

Server Rushはより迅速にプッシュできるHTTP Server Pushです。
SETTINGS_ENABLE_RUSHで有効にすることが出来ます。

Server Tush

Server Tushはサーバがプッシュプロミスに時間がかかりすぎると不賛成するHTTP Server Pushです。
SETTINGS_ENABLE_TUSHで有効にすることが出来ます。

Server Blush

Server Tushはクライアントが望まないプッシュをしてしまうとサーバは恥ずかしく感じるHTTP Server Pushです。
SETTINGS_ENABLE_BLUSHで有効にすることが出来ます。

Server Flush

Server Flushは北半球と南半球のコリオリ効果を考慮したServer HTTP Server Pushです。
SETTINGS_ENABLE_FLUSHで有効にすることが出来ます。

Server Plush

Server Cushと同義です

Server Slush

Server Slushは過度に感情的なServer HTTP Server Pushです。
SETTINGS_ENABLE_SLUSHで有効にすることが出来ます。

Server Smush

Server SmushはServer GushとServer Slushの論理和です
SETTINGS_ENABLE_SMUSHで有効にすることが出来ます。

QUICの現状確認をしたい 2018/3 (QPACK, Spin Bit, Invariants)

QUICの現状確認をしたい。
(あまり追えてないのでつらい)

前回
asnokaze.hatenablog.com

次回
asnokaze.hatenablog.com


目次

仕様の状況

3月頭に4つのコアドキュメントのdraft-10が出ている。

あまり差分は大きくないが、トランスポートでは前回分で書いたコネクションマイグレーション時に使うPATH_CHALLENGE、PATH_RESPONSEフレームが追加されたほか、ACK周りの再送するフレームに関する情報が追記された。

TLS利用の仕様では、QHKDF-Expandに関する記述が増えている。

おそらく、もうそろそろ draft-11 が出ると思われる。

また、その他の仕様では、QUICのHTTPヘッダ圧縮方式については長らく議論されていたが、QCRAMと呼ばれていた仕様がWG Draftとなっている。なお、非常に紛らわしいところであるが、QCRAMはQPACKに改名された。

QPACKについては以前書いたが、少なからずの変更が入っている。
asnokaze.hatenablog.com

また、将来のQUICバージョンアップデートをデプロイしやすくするための、invariantsと呼ばれる仕様もdraft-01が出ている。WG Last Callとなっている。

asnokaze.hatenablog.com

マイルストーンの変更

WGのマイルストーンに、Header Compression for HTTP over QUICが追加されたほか。

以前、チェアから意見が出たとおり、マルチパス QUICに関するマイルストーンは削除されました。

QUIC V1では、マルチパスQUICは対応されません。
QUIC V1では、マルチパスQUICは対応されません。

IETF101

3/17 ~ 3/23 にかけて、IETF 101がロンドンで開催された。
QUICに関しては、QUIC WGのセッションが2つ開催されたほか、ハッカソンで実装を持ち寄っての相互接続テストも実施された。

下記の発表が行われました

  • Hackathon Update
  • EDITORS UPDATE
  • QUIC DTLS and Stream 0
  • Invariants
  • ECN
  • Spin Bit Proposal

議事録及び発表資料はGithubで公開されている
wg-materials/ietf101 at master · quicwg/wg-materials · GitHub

相互接続性テスト

4th Implementation Draftで、相互接続テストが実施された。これは、 draft-09 と TLS1.3 draft-23の実装です。

f:id:ASnoKaze:20180331005345p:plain

  • V: Version Negotiation
  • H: Handshake
  • D: Stream Data
  • C: Connection Close
  • R: Resumption
  • Z: 0-RTT
  • S: Stateless Retry

次回のinteropは、5月にリモートでの開催が予定されている。
5th Implementation Draftとして、draft-11 と TLS1.3 draft-28で相互接続テストが実施される。

Spin Bit

発表資料: wg-materials/spin-101.pdf at master · quicwg/wg-materials · GitHub

以前書いたSpin BitをQUICとして正式に採用するかという議論が白熱しました。
asnokaze.hatenablog.com

会場参加の実装者の賛同はあまり得られておりませんでしたが、下記の通り hum を取ることになりました。

  • (a) QUIC V1にSpin Bitを入れない
  • (b) 予約bitを確保し、拡張仕様として別ドキュメントで定義する
  • (c) まだわからない

結果としては、(b)となったようです。
後日MLでチェアのmnot氏が下記のようにまとめています。
Spin Bit -- a Path Forward

QUIC DTLS and Stream 0

発表資料:wg-materials/Stream0-EKR.pdf at master · quicwg/wg-materials · GitHub

以前書いた通り、EKR氏よりQUIC over DTLSの提案がありました。
asnokaze.hatenablog.com

この話を発端に、QUICのレイヤリングとストリーム0に関しては専門のチームが結成され、検討が進められるようです。

下記のメール参照
Stream 0 Design Team

A First Look at QUIC in the Wild

発表資料:https://datatracker.ietf.org/meeting/101/materials/slides-101-maprg-a-first-look-at-quic-in-the-wild-00

maprg では、QUICのインターネットでの利用状況に関する発表がありました。ヨーロッパのTier-1 ISPでの、QUIC, HTTPSトラフィック量比較などの調査結果が報告されています

InvariantsのWGLC

Version-Independent Properties of QUICがWG Last Callとなっている。

チェアの「Working Group Last Call: QUIC Invariants」に詳しく書いてあるが、これは QUICの不変部分がより高いレベルで変更されないと信頼できるようにするためである。WGLC後すぐに先のステップに進むのではなく、そのタイミングで停滞させるようである。

なお、強い理由があればInvariantsの仕様を変更する事ももちろんある。

このような戦略的なWGLCは面白いなと思いました。

Symmetric connection IDs

Draft-11で入る、大きな変更点があります。
github.com

Coneection-IDが、Source Connection IDとDestination Connection IDに変更され、さらに可変長となりました。これによって、クライアントのパケット処理がよりシンプルになるようです。

この変更によって、Long Headerは下記の通りになります
f:id:ASnoKaze:20180331013127p:plain

Short Headerは下記の通りになります。Short HeaderはDestination Connection IDだけになります。Lengthが無いのは、その長さがお互いにわかっているため、Lengthはありません。
f:id:ASnoKaze:20180331013233p:plain

あまり自分もちゃんと理解できないので、詳しい人がいれば補足してほしい...

ChromeがWebSockets over HTTP/2に対応したので試す (RFC8441)

2018/09/19追記
RFC 8441 として標準化されました


以前書いたとおり、Websockets over HTTP/2の仕様である「Bootstrapping WebSockets with HTTP/2」が現在標準化が進められている。
asnokaze.hatenablog.com

これにより、複数のWebsocket通信が1つのTCPコネクションに束ねられる。

一つのページで複数WebSocketを使っていたり、複数タブを開いて各ページでWebSocketを利用しているとどうしてもコネクションの本数が多くなってしまう。様々なメリットがあるが、コネクションの数がへらせるのはサーバ側でも嬉しい部分がある。

もちろんひとつに束ねられたWebSocketをばらして処理をする必要があり、サーバやProxy側の実装が整う必要はある。

さて、このWebsockets over HTTP/2にChrome Canaryが対応したので実際に試してみる。

WebSockets over HTTP/2

「WebSockets over HTTP/2」の概要に簡単に触れる

WebSockets over HTTP/2を利用するにはサーバ側からSETTINGSフレームで「ENABLE_CONNECT_PROTOCOL = 1」を送る必要がある。そのため、既存のサーバに対してブラウザが勝手にHTTP/2でWebScoket通信を試みるようなことはない。

具体的な通信手順は以前書いた時より仕様が進んでおり、HEADERSフレームを使用するようになっている。
f:id:ASnoKaze:20180310012152p:plain:w400

Chromeで Websockets over HTTP/2を有効にする

現状はChrome Canaryで有効にすることが出来る。
起動オプションに "--enable-websocket-over-http2"を与えて起動すると、Websockets over HTTP/2が有効になる。

Chromeの実行パスがわからない場合は、URLバーにchrome://version/と打ち、コマンドラインの項目から確認できる

試す

ざっくり適当に、モックサーバを用意した。

f:id:ASnoKaze:20180310014954p:plain

HTTP/2で接続しにいって、WebSocketのonopenイベントが発火するところまで確認した。
(地味な動作確認画面だ...)

QUIC over DTLSの提案仕様

2021/12/21 追記
この記事は古いです。2018年、QUICの標準化において設計段階で行われた議論になります。


QUIC over DTLS」という提案仕様ekr氏が出され、QUIC WGのメーリングリストで「Proposal: Run QUIC over DTLS」としてDTLS上でQUICのメッセージを通信するように変更する提案がされている。

QUICのスタック

現在のQUICのスタックは図のようになっている。
f:id:ASnoKaze:20180306233002p:plain

QUICが提供する信頼性のあるトランスポート上のStream 0でTLS1.3のハンドシェイクのメッセージ(Crypto Handshake)をやりとり、そこから得れられたシークレットから鍵を生成し通信を暗号化します。

詳細は、tatsuhiro-t先生の記事が詳しいです。
qiita.com

しかし、ekr氏の提案で述べられているように、Crypto HandshakeはStream 0に特殊なルールを適用することになっていたり、0-RTTやACKに関するルールを複雑化していると述べています。また、QUICとTLSスタックを密結合にしているとも書かれています。

提案されている 「QUIC over DTLS」では、QUICのスタックは以下のようになります。
f:id:ASnoKaze:20180306234235p:plain

DTLSのハンドシェイクを行った後、その上でQUICのメッセージをやり取りするようになります。
それに伴い、この提案仕様でQUIC部分も変更される部分が出てきます。

  • QUICのVersion Negotiationの変更 (DTLS1.3のsupported_versionsに加え quic_versionsのネゴシエーション)
  • Transport ParametersはTLS拡張へ
  • DTLSの提供するACKと、QUICの提供するACKが分離する

もちろん、QUICとDTLSスタックとやり取りする必要もあるし、そのままDTLSを利用できない部分もあります。

DTLSの変更

QUICの仕様も既に長い間議論されてきており、沢山の事が考慮され現在の形になっています。

そのような様々な考慮事項を満たすために、DTLSはそのまま使用できません。提案仕様の「3. Required Changes to DTLS」にかかれているとおり、幾つか変更する必要があります。

  • DTLS1.3 Connection ID: 別途議論されているDTLSにコネクションIDを導入する拡張の仕様 (「DTLSにコネクションIDを導入する提案仕様」)
  • ハンドシェイクメッセージの難読化
  • ネゴシエーションパケットの難読化
  • パケット番号の暗号化
  • Stateless Reset: サーバがリブートなどして、コネクションの状態情報を失った時に接続をリセット する手段を提供する

各種メッセージの難読化については、以前書いたとおり
asnokaze.hatenablog.com

実装

ekr氏は既に「QUIC over DTLS」を実装しています。
github.com

議論

QUIC WGのメーリングリストで、議論は盛り上がっています。

やはり大きな変更となるため、興味を持つものの好意的でない意見の方が多い印象です。今まで沢山の議論を重ね、GQUICからの知見も得て、QUICは今の仕様になっています。今のデザインのまま、まだまだ改善できる余地はあるのではないかという感じでしょうか。

今月ある IETF101のアジェンダにも既に含まれています。議論となることでしょう。
github.com

HTTP/1.1 (RFC 7230 〜 7235) の改訂作業がはじまる

2021/10/21 追記。変更点について別記事を書きました。
asnokaze.hatenablog.com


HTTP/1.1の仕様は下記の通り、6つのRFCで標準化されています。

これら、HTTPリクエスト・レスポンスヘッダや、ステータスコード、キャッシュや認証の仕組みといったHTTPの意味(セマンティクス)はHTTP/2でもHTTP over QUICでも変わっていません。

つまり、引き続きHTTPのセマンティクスを定義しているこれらのドキュメントは整備(メンテナンス)し続ける必要があります。

また、今回の作業によりHTTP/1.1のシンタックスと、HTTPのセマンティクスの仕様を分離することで、HTTP/3などからはセマンティクスの仕様を参照でき、仕様としてより整理された形となります。

RFCは一度出てしまうと変更することは出来ず、errataと言うかたちで訂正が蓄積していきますが、どこかで改訂版を出す必要が出てきます。上記RFCが出て4年が経ち既にIssueはいくらか溜まっており、その一覧はhttpbis WGのgithubリポジトリで確認できます。現状では48個のissueが登録されています。
github.com

そこで、IETFのhttpbis WGでは、次のHTTP標準の改訂作業が行われる機運が高まっており、前々回のIETF99(2017年11月頃)でもその議論が行われています。発表資料は以下のより確認できる。
github.com

HTTP/1.1は既に一度改定しており、その時は次のHTTPと言う意味で、HTTPbisと呼ばれていました。そして3回目の改訂としてHTTPtreと呼ばれるのが今回のドキュメントです

  • 最初: RFC 2616
  • HTTPbis: RFC 7230 〜 7235
  • HTTPtre: 次のドキュメント

(ちなみに、WGの名前はhttpbisのままで行くようです)

HTTPtre

本日、そのHTTPtreのドラフトが提出されました。Authorは、HTTPbisの改訂でも根強く尽力されたJulian F. Reschke氏と、Roy T. Fielding氏です。

それぞれ、RFC 7230 〜 7235と対応して、各改訂版は下記のとおりです。

Message Syntax and RoutingはHTTP/1.1固有のものですが、それ以外はHTTPとしてのセマンティクスを定義しているため、ドキュメントタイトルから1.1という部分がなくなっています。

これらのドキュメントは、個人ドラフトの00版ですがすでに変更が入っており、各ドキュメントの最後に変更点が記述されています。

HTTPtreのスコープとスケジュール

HTTPtreの作業項目と、そのドラフト更新の目処については、チェアのmnotが去年の段階で言及しています。
DRAFT: more details for HTTPtre

それを見るとHTTPbis(6年かかった)に比べれば、短い期間で改訂作業が進められそうです。

まずは、このドキュメントを元に、今月行われるIETF101で議論を行い、これから編集作業が進んでいくものと思われます。

追記: ドキュメントは3つに統合

HTTPtreよりも、HTTP Core Documentsと呼ばれるようになりました。

現在は、3つの仕様に統合され、HTTPのセマンティクス、HTTP/1.1のフォーマット、キャッシュに関する3つの文書に整理されています。

QUICにおけるヘッダ圧縮の提案仕様 QPACK(旧QCRAM) その2 (draft-04)

20180313追記
QCRAMと呼ばれていた仕様は、QPACKに改称されました。
github.com


HTTP over QUICでは、HTTP/2のフレームを利用するが、HTTPヘッダ圧縮にHTTP/2のHPACKをそのまま使用するのはHoLBの問題が知られている。

HPACKでは、ヘッダが送った順番通りに届く事を想定しており、送信側と受信側が完全に同じ状態を保てる。しかし、QUICではメッセージの届く順番は入れ替わる可能性があり、動的テーブルの参照する際にまだそのインデックスが挿入されていないというケースが生じうる。QUICでは、届いたメッセージから処理できるはずが、ここで待ち状態になってしまう。

そこでQUICでのHTTPヘッダ圧縮は新しい仕組みを導入することが検討されており、幾つか提案されているなかの一つが「Header Compression for HTTP over QUIC」であり、QCRAMと呼ばれている。

そのQCRAMが Call for Adoption となっている、またGo実装でもあるminhqでもQCRAMが試験的に実装されている。IETF101に向けて、事前に仕様を読んでおく。

今回は、前回のdraft-02からのアップデートのみ触れる。詳しくは前回を参照のこと。
asnokaze.hatenablog.com

draft-04

Call for Adoption となっている、現在のQCRAMはdraft-04であり、draft-02から幾つかの変更点がある。

主な変更点である、下記について書く

  • HEADER_ACK
  • BLOCKING flag
  • ヘッダブロックプレフィックス
HEADER_ACK フレーム

新しく HEADER_ACKフレームが定義される。これは、デコーダ側がヘッダブロックを処理した際にControl Streamでエンコーダ側へ通知される。このHEADER_ACKフレームをエンコーダ側が受信することで、送ったヘッダがどこまで処理されてるか判別することが出来るようになる。

f:id:ASnoKaze:20180212221216p:plain

  • Stream ID: ヘッダブロックを処理したストリームID(可変長)

trailersなどで複数回ヘッダブロックを処理する可能性があるが、おそらくその都度送信される。

BLOCKING フラグ

HEADERSフレームとPUSH_PROMISEフレームにBLOCKING フラグが追加されます。

前述のHEADER_ACKによってエンコーダ側は送信したヘッダブロックがどこまで処理されているかを知ることが出来ます。そこで、ヘッダブロックを送信する際に、そのデコーダ側がヘッダブロックを処理するのにブロックされうるのかが分かります。

このフラグが0の場合は、デコーダ側はすぐにそのヘッダブロックを処理できます。1の場合は、依存するヘッダブロックが処理されるまで待つ可能性があります。

ヘッダブロックプレフィックス

以前の記事で説明したとおり、QCRAMではヘッダブロックにプレフィックスが追加されます。このプレフィックスもdraft-02から変更されています。

このヘッダブロックプレフィックスは、BLOCKING フラグによって変わります。
BLOCKINGフラグが0の場合が左、BLOCKINGフラグが1の場合は右です。


f:id:ASnoKaze:20180212231947p:plain

  • Base Index: 現在のヘッダブロックを初果する前の、追加されたエントリの合計
  • Depends: Base Indexの位置よりどれくらい前のインデックスに依存するか。Base Index - Dependsが依存する最大のインデックス値になります。

HPACKではエントリを挿入するたびにインデックス値がずれていきましたが、Base Indexから場所を計算することで順番通りでない挿入でも正しい場所にエントリを挿入できます。

Dependsがあることで、ブロックの処理を開始する前に必要なインデックス値を確認できるようになっています。