RFC8774 "The Quantum Bug"  翻訳 

#はじめに

2020年のJoke RFCの一つ、 [RFC8774 "The Quantum Bug"](https://www.rfc-editor.org/rfc/rfc8774.txt) の翻訳です。英語は苦手なので [DeepL](https://www.deepl.com/translator) や [Google翻訳](https://translate.google.co.jp/?hl=ja) を使用し、さらに感覚で修正しています。
正確性は保証していません。

#対象読者

Joke RFCに興味がある人。

#Joke RFC

Joke RFC は、RFC の中でも4月1日にエイプリルフール・ジョークとして公開されるもので、次のような特徴があります。

- ふざけた内容をまじめに議論している(ように見せかけている)
- インターネット技術や関連技術などの元ネタを知っていると笑える
- RFC文書の記述形式を知っていると笑える
- RFC になじみがないとおもしろさが半減する

一言で言えばマニアック。だが、それがいい。

# Joke RFC の探し方

1. IETFの[RFCのサイト](https://www.ietf.org/standards/rfcs/)に行きます。
2. RFC Index を開きます。[TXT版の一覧](https://www.rfc-editor.org/in-notes/rfc-index.txt)がお勧めです。
3. "1 April" (4月1日固定)で検索します。
4. 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