はじめに
2020年のJoke RFCの一つ、 RFC8774 "The Quantum Bug"の翻訳です。英語は苦手なので DeepLや Google翻訳を使用し、さらに感覚で修正しています。
正確性は保証していません。
対象読者
Joke RFCに興味がある人。
Joke RFC
Joke RFC は、RFC の中でも4月1日にエイプリルフール・ジョークとして公開されるもので、次のような特徴があります。
- ふざけた内容をまじめに議論している(ように見せかけている)
- インターネット技術や関連技術などの元ネタを知っていると笑える
- RFC文書の記述形式を知っていると笑える
- RFC になじみがないとおもしろさが半減する
一言で言えばマニアック。だが、それがいい。
Joke RFC の探し方
- IETFのRFCのサイトに行きます。
- RFC Index を開きます。TXT版の一覧がお勧めです。
- "1 April" (4月1日固定)で検索します。
- Status: が INFORMATIONAL または UNKNOWN であれば、"Joke RFC である可能性が高い" です。あとはタイトルや中身を見て判断します。
ちなみにこのRFC8774から参照しているRFC6921もJoke RFCです。
RFC 8774 "The Quantum Bug" 翻訳
Independent Submission M. Welzl
Request for Comments: 8774 University of Oslo
Category: Informational 1 April 2020
ISSN: 2070-1721
The Quantum Bug
量子バグ
Abstract
The age of quantum networking is upon us, and with it comes
"entanglement": a procedure in which a state (i.e., a bit) can be
transferred instantly, with no measurable delay between peers. This
will lead to a perceived round-trip time of zero seconds on some
Internet paths, a capability which was not predicted and so not
included as a possibility in many protocol specifications. Worse
than the millennium bug, this unexpected value is bound to cause
serious Internet failures unless the specifications are fixed in
time.
概要
量子ネットワークの時代がやってくると、"もつれ"を使って(ビットの)状態を遅延ゼロで瞬時に転送できるようになる。これはインターネットパス(経路)のラウンドトリップタイム(RTT)がゼロになることを意味するが、それは想定外の能力であり、多くのプロトコル仕様はそのような場合を想定していない。さらにミレニアムバグ(2000年問題)よりもたちが悪いことに、プロトコル仕様が修正されなければ、この予期せぬ動きは深刻なインターネット障害を引き起こす。
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8774.
(この文書はインターネット標準仕様策定のためのものではなく、あくまで情報提供のためのものである、という INFORMATIONAL 文書でお約束の説明)
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
(コピーライトについて)
Table of Contents
1. Introduction
2. Protocols and Protocol Mechanisms That Will Fail
2.1. LEDBAT
2.2. Multipath TCP (MPTCP)
2.3. RTP Circuit Breakers
3. What can be done?
4. Conclusion
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Author's Address
(目次)
1. Introduction
[RFC6921] discusses faster-than-light communication, where packets
arrive before they are sent. While it is amusing to entertain the
possibility of time travel, we have to accept the cold facts: time
travel will never work (or it would already have been used). Quantum
networking, however, is an entirely different matter -- commercial
products are already available, and quantum networks will without a
doubt become the prevalent Internet link-layer technology across the
globe within the next five to ten years.
1.はじめに
[RFC6921]は超光速通信、つまりパケットが送信される前に到着する場合について述べている。タイムトラベルの可能性を想像するのは楽しいが、私たちは冷たい事実を受け入れなければならない: タイムトラベルはうまくいかない (今後タイムトラベルが実現するのであれば、今は既にタイムトラベルを使っているはずだ）。しかし、量子ネットワークは全く別の問題だ。量子ネットワークは商用製品が既に利用できるし、間違いなく今後5年から10年以内に世界中でインターネットのリンク層技術として普及するだろう。
With the help of entanglement, implemented in quantum repeaters,
quantum networks can transfer information faster than ever before: a
state can be transmitted over a long distance instantly, with no
delay. This is so cool that it is also called (and, by some,
mistaken for) teleportation. If a path between a sender and a
receiver is fully quantum-ized, the measured one-way delay (OWD) will
be zero. What's more, assuming that there are blazing fast quantum
computers involved on both ends, the processing time will be well
below anything measurable; hence, even the round-trip time (RTT) will
be zero in these scenarios.
量子リピータに実装された "もつれ" を使うため、量子ネットワークはこれまで以上に速く情報を転送することができる: つまり、遅延なしに長距離で瞬時に状態を送信することができる。これはとてもクールなので、(一部では誤解されているが)テレポーテーションとも呼ばれる。送信者と受信者の間のパスが完全に量子化されている場合、一方向遅延（one-way delay, OWD）の測定値はゼロになる。さらに、パスの両端に超高速量子コンピュータがあると仮定すると、処理時間は計測不可能なほど短くなり、これらのシナリオでは、ラウンドトリップタイム（round-trip time, RTT）さえもゼロになる。
In today's Internet, only very few protocols are prepared for such
"0-RTT" situations (e.g., TCP with "TCP Fast Open" (TFO) [RFC7413],
TLS 1.3 [RFC8446], and QUIC [QUIC-TRANS]). Many others will fail in
interesting ways; we coin the term "Quantum Bug" for such failures.
In the following section, we will discuss some examples of Quantum
Bugs.
今日のインターネットでは、このような "ゼロ-RTT" の状況に対応するプロトコルは非常に限られている (例えば TCP with "TCP Fast Open" (TFO) [RFC7413], TLS 1.3 [RFC8446], QUIC [QUIC-TRANS])。他の多くのプロトコルでは興味深い理由で失敗が起きる; 私たちはこのような失敗を "量子バグ" と呼んでいる。以下の節では量子バグの例をいくつか説明する。
2. Protocols and Protocol Mechanisms That Will Fail
The number of protocols and protocol mechanisms that will fail in the
face of a zero RTT is too large to report here; we are truly heading
towards something close to an Internet meltdown. We can only provide
some guidance to those who hunt for the Quantum Bug, by discussing
examples of specification mistakes that will need to be fixed.
2.失敗するプロトコルおよびそのプロトコル機構について
ゼロ-RTTで失敗するプロトコルやプロトコル機構は、数が多すぎてここでは報告できない; まさにインターネットメルトダウンに向かっているのだ。私たちには、修正すべき仕様の不具合の例を議論することで量子バグの狩人へのガイドを提供することしかできない。
2.1. LEDBAT
The Low Extra Delay Background Transfer (LEDBAT) congestion control
mechanism [RFC6817] is a very interesting failure case: designed to
"get out of the way" of other traffic; it will end up sending as fast
as possible. Specifically, when the algorithm described in
Section 2.4.2 of [RFC6817] obtains a delay sample, it updates a list
of base delays that will all become 0 and current delays that will
also all become 0. It calculates a queuing delay as the difference
between the current delay and the base delay (resulting in 0) and
keeps increasing the Congestion Window (cwnd) until the queuing delay
reaches a predefined parameter value TARGET (100 milliseconds or
less).
2.1.LEDBAT
低外部遅延バックグラウンド・トランスポート(Low Extra Delay Background Transfer, LEDBAT) 輻輳制御機構 [RFC6817] は非常に興味深い失敗例だ。LEDBAT は他の通信の「邪魔にならない」よう設計されており、送信をできるだけ最速にする。具体的には、[RFC6817]の2.4.2節のアルゴリズムで遅延サンプルを取得する場合、全てがゼロになる基準遅延のリストと、同じく全てがゼロになる現在遅延のリストを更新する。そしてキューイング遅延として現在遅延と基準遅延の差を計算し(結果はゼロ)、キューイング遅延が事前に定義されたパラメータ TARGET値 (100 ミリ秒以下) に達するまで 輻輳帯域 (Congestion Window, cwnd) を増加させ続ける。
A TARGET value of 100 milliseconds will never be reached, because the
queuing delay does not grow when the sender increases its cwnd; this
means that LEDBAT would endlessly increase its cwnd, limited only by
the number of bits that are used to represent cwnd. However, given
that TARGET=0 is also allowed, this parameter choice may seem to be a
way out. Always staying at the target means that the sender would
maintain its initial cwnd, which should be set to 2. This may seem
like a small number, but remember that cwnd is the number of bytes
that can be transmitted per RTT (which is 0). Thus, irrespective of
the TARGET value, the sender will send data as fast as it can.
送信者が cwnd を増加させてもキューイング遅延は増加しないため、TARGET値が100ミリ秒に達することはない。これは LEDBAT が無限に cwnd を増加させることを意味する; ただし cwnd の表現ビット数が制限となる。しかしTARGET値にはゼロを指定できるので、上記は回避可能に思える。キューイング遅延が常にTARGET値と等しいということは、送信者が最初のcwndを維持することを意味し、そのcwndは2に設定すべきだ。この数値は小さく思えるかもしれないが、cwndはRTT(= 0)あたりに送信できるバイト数であることを思い出してほしい。つまり、TARGET値に関係なく、送信者はできるだけ早くデータを送信するということだ。
2.2. Multipath TCP (MPTCP)
The coupled congestion control mechanism proposed for MPTCP in
[RFC6356] requires calculating a value called "alpha". Equation 2 in
[RFC6356] contains a term where a value called "cwnd_i" is divided by
the square of the RTT, and another term where this value is divided
by the RTT. Enough said.
2.2.マルチパスTCP (MPTCP)
[RFC6356]でMPTCP用に提案されている結合輻輳制御機構は「アルファ」と呼ばれる値の計算が必要だ。[RFC6356]の式2には、"cwnd_i"と呼ばれるRTTの2乗で割る項と、もう一つRTTで割る項が含まれている。説明はもういいだろう。
2.3. RTP Circuit Breakers
The RTP Circuit Breakers [RFC8083] require calculation of a well-
known equation which yields the throughput of a TCP connection:
2.3.RTPサーキットブレーカー
RTPサーキットブレーカー[RFC8083]は、TCP接続のスループットを算出する有名な方程式を使う：
s
X = -------------------------------------------------------------
Tr*sqrt(2*b*p/3)+(t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p*p)))
where Tr is the RTT and t_RTO is the retransmission timeout of TCP
(we don't need to care about the other variables). As we will
discuss in Section 3, t_RTO is lower-bounded with 1 second;
therefore, it saves us from a division by zero. However, there is
also a simplified version of this equation:
(式は略) ここで、TrはRTT、t_RTOはTCPの再送信タイムアウトだ（今は他の変数を気にする必要はない）。3節で説明するが、t_RTOの下限は1秒だ; つまり、ゼロ除算にはならない。しかし、この式には簡略版もある。
s
X = ----------------
Tr*sqrt(2*b*p/3)
Unfortunately, [RFC8083] states: "It is RECOMMENDED that this
simplified throughput equation be used since the reduction in
accuracy is small, and it is much simpler to calculate than the full
equation." Due to this simplification, many multimedia applications
will crash.
(式は略) 残念ながら、[RFC8083]では次のように述べている: 「精度の低下が小さく、完全な式よりも計算がはるかにシンプルなので、この簡略版スループット式を使用することが"推奨される"」。この簡略化によって、多くのマルチメディアアプリケーションがクラッシュする。
3. What can be done?
Fear not: when everything else fails, TCP will still work. Its
retransmission timeout is lower-bounded by 1 second [RFC6298].
Moreover, while its cwnd may grow up to the maximum storable number,
data transmission is limited by the Receiver Window (rwnd). This
means that flow control will save TCP from failing.
3.何ができるのか？
恐れる必要はない: 他のすべてが失敗しても、TCPは引き続き機能する。TCPの再送信タイムアウトの下限は1秒だ [RFC6298]。さらに、cwndが最大まで拡大しても、データ通信は受信帯域(Receiver Window, rwnd)で制限される。つまり、フロー制御でTCPの失敗を防ぐことができる。
From this, we can learn two simple rules: lower-bound any values
calculated from the RTT (and, obviously, do not divide by the RTT),
and use flow control. Specifications will need to be updated by
fixing all RTT-based calculations and introducing flow control
everywhere. For example, UDP will have to be extended with a
receiver window, e.g., as a UDP option [UDP-OPT].
ここから2つのシンプルなルールが得られる: RTTから計算された値はすべて下限値とし（明示的に、RTTで割らないようにする）、かつフロー制御を使用する。RTTベースの計算をすべて修正し、どこでもフロー制御ができるように仕様を更新する必要がある。例えば、UDPはUDPオプション[UDP-OPT]のように、受信帯域制御で拡張する必要がある。
4. Conclusion
We are in trouble, and there is only one way out: develop a
comprehensive list of all RFCs containing "0-RTT" mistakes (taking
[RFC2626] as a guideline), and update all code. This needs to happen
fast, the clock is ticking. Luckily, if we are too slow, we will
still be able to use TCP to access the specifications. With DNS over
TCP [RFC7766], name resolution to find the server containing the
specifications should also work.
4.結論
私たちは困っており、出口は一つしかない: ([RFC2626]をガイドラインとして) ゼロ-RTT の不具合を持つすべてのRFCの包括的なリストを作成し、すべてのコードを更新することだ。時間はない。早くすべきだ。幸いなことに、私たちの対応が遅すぎた場合でも、仕様書にアクセスするのにTCPを使うことができる。DNS over TCP [RFC7766]を使えば、仕様書があるサーバを見つけるための名前解決も動作するはずだ。
5. IANA Considerations
This document has no IANA actions.
5.IANAでの検討
IANAでは検討されていない。
6. Security Considerations
Flow control must be used on 0-RTT paths, or else an attacker can
completely overwhelm a sender with data in a denial-of-service (DoS)
attack within an instant. Flow control will need to be added to
protocols that do not currently have it, such as UDP or ICMP. IPv6
will not save us.
6.セキュリティに関する考慮事項
フロー制御はゼロ-RTTパスで使用する必要がある。さもないと攻撃者は瞬時にDoS攻撃のデータで送信者を完全に圧倒してしまう。フロー制御は、UDP や ICMP のような、現在は対応していないプロトコルにも追加する必要がある。IPv6は私たちを救わない。
7. References
7.1. Normative References
[RFC2626] Nesser II, P., "The Internet and the Millennium Problem
(Year 2000)", RFC 2626, DOI 10.17487/RFC2626, June 1999,
<https://www.rfc-editor.org/info/rfc2626>.
[RFC6921] Hinden, R., "Design Considerations for Faster-Than-Light
(FTL) Communication", RFC 6921, DOI 10.17487/RFC6921,
April 2013, <https://www.rfc-editor.org/info/rfc6921>.
7.2. Informative References
[QUIC-TRANS]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-27, 21 February 2020,
<https://tools.ietf.org/html/draft-ietf-quic-transport-
27>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>.
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
Congestion Control for Multipath Transport Protocols",
RFC 6356, DOI 10.17487/RFC6356, October 2011,
<https://www.rfc-editor.org/info/rfc6356>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/info/rfc6817>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[UDP-OPT] Touch, J., "Transport Options for UDP", Work in Progress,
Internet-Draft, draft-ietf-tsvwg-udp-options-08, 12
September 2019, <https://tools.ietf.org/html/draft-ietf-
tsvwg-udp-options-08>.
Author's Address
Michael Welzl
University of Oslo
PO Box 1080 Blindern
N-0316 Oslo
Norway
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no