P2P QUICの提案仕様

P2P QUIC」という提案仕様がIETFに提出さています。著者はMicrosoftのPeter Thatcher氏になっています。

Peter Thatcher氏らは、W3Cでも「QUIC API for Peer-to-peer Connections」という提案を行っており、ブラウザ上でQUICを用いたP2P メディア・コミュニケーションを行えるようにより組んでいます。

まだ標準化の議論が盛り上がってるわけではないが、「P2P QUIC」自体はかなり短い仕様ですのでざっくり目を通しておく

P2P QUICについて

P2P QUICではICEを用います。

その中で次の値をネゴシエーションします

  • どちらがactive (client)とpassive (server) の役割を担うか
  • 証明書のフィンガープリント
  • QUICでgrease bitを使うか
  • MuliplexingIDを使うか (MuliplexingIDはQUICコネクションに複数の通信を多重化する仕組み)
SDP

SDPの例として次のとおりになります

v=0
o=- 4962303333179871722 1 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-ufrag:7sFv
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=ice-options:trickle
a=quic-options:grease
a=fingerprint:sha-256
   7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35:
   DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
a=group:BUNDLE 1 2 3
m=audio 9 UDP/QUIC/RTP/AVPF 99
a=mid:1
a=sendrecv
a=rtpmap:99 OPUS/4800/2
m=video 9 UDP/QUIC/RTP/AVPF 100
a=mid:2
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
m=application 9 UDP/QUIC generic
a=mid:3

QUICの機能など

P2P QUICにおいては、QUICの持ってる機能について幾つか言及があります

  • ALPNでは、"q2q"を使う
  • 各ピアは証明書の検証を行う (クライアント証明書の検証を行う)。なお自己署名証明書を許容してもよい(MAY)
  • Multipathを使うべきではない (SHOULD NOT)
  • QUIC Datagramsをサポートするべき (SHOULD)
  • コネクションマイグレーションはICEを通して行い、コネクションIDを変更すべきでない (SHOUD NOT)