[要約] RFC 5841は、パケットのモードを示すためのTCPオプションについての仕様です。このRFCの目的は、ネットワークトラフィックの制御と品質の向上を可能にするため、パケットのモード情報を伝達する方法を提供することです。
Independent Submission R. Hay
Request for Comments: 5841 W. Turkal
Category: Informational Google Inc.
ISSN: 2070-1721 1 April 2010
TCP Option to Denote Packet Mood
パケットムードを示すTCPオプション
Abstract
概要
This document proposes a new TCP option to denote packet mood.
このドキュメントでは、パケットムードを示す新しいTCPオプションを提案しています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5841.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5841で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
In an attempt to anthropomorphize the bit streams on countless physical layer networks throughout the world, we propose a TCP option to express packet mood [DSM-IV].
世界中の無数の物理層ネットワーク上のビットストリームを擬人化するために、パケットムード[DSM-IV]を表現するためのTCPオプションを提案します。
Packets cannot feel. They are created for the purpose of moving data from one system to another. However, it is clear that in specific situations some measure of emotion can be inferred or added. For instance, a packet that is retransmitted to resend data for a packet for which no ACK was received could be described as an 'angry' packet, or a 'frustrated' packet (if it is not the first retransmission for instance). So how can these kinds of feelings be conveyed in the packets themselves. This can be addressed by adding TCP Options [RFC793] to the TCP header, using ASCII characters that encode commonly used "emoticons" to convey packet mood.
パケットは感じられません。これらは、データをあるシステムから別のシステムに移動する目的で作成されます。ただし、特定の状況では、感情の尺度を推測または追加できることは明らかです。たとえば、ACKが受信されないパケットのデータを再送信するために再送信されるパケットは、「怒っている」パケット、または「欲求不満の」パケットとして説明できます（たとえば、最初の再送信ではない場合）。したがって、これらの種類の感情をパケット自体でどのように伝えることができますか。これは、TCPオプション[RFC793]をTCPヘッダーに追加することで対処できます。これは、一般的に使用されている「絵文字」をエンコードするASCII文字を使用してパケットムードを伝えることで対処できます。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
キーワードは、このドキュメントに表示される場合、[RFC2119]に記載されているように解釈される場合、必要な、必須、必要は、推奨されない、推奨することはできません。
A TCP Option has a 1-byte kind field, followed by a 1-byte length field [RFC793]. It is proposed that option 25 (released 2000-12-18) be used to define packet mood. This option would have a length value of 4 or 5 bytes. All the simple emotions described as expressible via this mechanism can be displayed with two or three 7-bit, ASCII-encoded characters. Multiple mood options may appear in a TCP header, so as to express more complex moods than those defined here (for instance if a packet were happy and surprised).
TCPオプションには1バイトの種類のフィールドがあり、その後に1バイトの長さフィールドが続きます[RFC793]。オプション25（リリース2000-12-18）を使用して、パケットムードを定義することが提案されています。このオプションの長さは4バイトまたは5バイトです。このメカニズムを介して表現可能と呼ばれるすべての単純な感情は、2つまたは3つの7ビットのAscii-Encoded文字で表示できます。TCPヘッダーには、複数のムードオプションが表示され、ここで定義されているムードよりも複雑なムードを表現することができます（たとえば、パケットが幸せで驚いた場合）。
TCP Header Format
TCPヘッダー形式
Kind Length Meaning
---- -------- -------
25 Variable Packet Mood
In more detail:
さらに詳細に：
+--------+--------+--------+--------+
|00011001|00000100|00111010|00101001|
+--------+--------+--------+--------+
Kind=25 Length=4 ASCII : ASCII )
+--------+--------+--------+--------+--------+
|00011001|00000101|00111110|00111010|01000000|
+--------+--------+--------+--------+--------+
Kind=25 Length=5 ASCII > ACSII : ASCII @
It is proposed that common emoticons be used to denote packet mood. Packets do not "feel" per se. The emotions they could be tagged with are a reflection of the user mood expressed through packets.
一般的な絵文字を使用して、パケットムードを示すことが提案されています。パケットはそれ自体を「感じる」ことはありません。彼らがタグ付けすることができる感情は、パケットを通して表現されたユーザーの気分を反映しています。
So the humanity expressed in a packet would be entirely sourced from humans.
したがって、パケットで表現された人類は、人間から完全に供給されるでしょう。
To this end, it is proposed that simple emotions be used convey mood as follows.
この目的のために、単純な感情を使用することが、次のように気分を伝えることが提案されています。
ASCII Mood
===== ====
:) Happy
:( Sad
:D Amused
%( Confused
:o Bored
:O Surprised
:P Silly
:@ Frustrated
>:@ Angry
:| Apathetic
;) Sneaky
>:) Evil
Proposed ASCII character encoding
提案されたASCII文字エンコード
Binary Dec Hex Character
======== === === =========
010 0101 37 25 %
010 1000 40 28 (
010 1001 41 29 )
011 1010 58 3A :
011 1011 59 3B ;
011 1110 62 3E >
100 0000 64 40 @
100 0100 68 44 D
100 1111 79 4F O
101 0000 80 50 P
110 1111 111 6F o
111 1100 124 7C |
For the purposes of this RFC, 7-bit ASCII encoding is sufficient for representing emoticons. The ASCII characters will be sent in 8-bit bytes with the leading bit always set to 0.
このRFCの目的のために、7ビットASCIIエンコードでは、絵文字を表すのに十分です。ASCII文字は8ビットバイトで送信され、先行ビットが常に0に設定されます。
There are two ways to denote packet mood. One is to infer the mood based on an event in the TCP session. The other is to derive mood from a higher-order action at a higher layer (subject matter of payload for instance).
パケットムードを示す2つの方法があります。1つは、TCPセッションのイベントに基づいて気分を推測することです。もう1つは、より高い層（例えばペイロードの主題）で高次のアクションから気分を導き出すことです。
For packets where the 'mood' is inferred from activity within the TCP session, the 'mood' MUST be set by the host that is watching for the trigger event. If a client sends a frame and receives no ACK, then the retransmitted frame MAY contain the TCP OPTION header with a mood set.
TCPセッション内のアクティビティから「ムード」が推測されるパケットの場合、「ムード」は、トリガーイベントを監視しているホストが設定する必要があります。クライアントがフレームを送信してACKを受信しない場合、再送信されたフレームには、ムードセットを備えたTCPオプションヘッダーが含まれる場合があります。
Any packet that exhibits behavior that allows for mood to be inferred SHOULD add the TCP OPTION to the packets with the implied mood.
気分を推測できる動作を示すパケットは、暗黙のムードでパケットにTCPオプションを追加する必要があります。
Applications can take advantage of the defined moods by expressing them in the packets. This can be done in the SYN packet sent from the client. All packets in the session can be then tagged with the mood set in the SYN packet, but this would have a per-packet performance cost (see Section 5, "Performance Considerations").
アプリケーションは、パケットでそれらを表現することにより、定義されたムードを利用できます。これは、クライアントから送信されたsynパケットで実行できます。セッション内のすべてのパケットは、Synパケットに設定されたムードでタグを付けることができますが、これにはパケットごとのパフォーマンスコストがあります（セクション5、「パフォーマンスに関する考慮事項」を参照）。
Each application MUST define the preconditions for marking packets as happy, sad, bored, confused, angry, apathetic, and so on. This is a framework for defining how such moods can be expressed, but it is up to the developers to determine when to apply these encoded labels.
各アプリケーションは、パケットをマークする前提条件を、幸せ、悲しい、退屈、混乱、怒り、無関心などとして定義する必要があります。これは、そのような気分をどのように表現できるかを定義するためのフレームワークですが、これらのエンコードされたラベルを適用する時期を決定するのは開発者次第です。
Healthy packets are happy packets you could say. If the ACK packets return within <10 ms end-to-end from a sender's stack to a receiver's stack and back again, this would reflect high-speed bidirectional capability, and if no retransmits are required and all ACKs are received, all subsequent packets in that session SHOULD be marked as 'happy'.
健康的なパケットはあなたが言うことができる幸せなパケットです。ACKパケットが送信者のスタックからレシーバーのスタックまで10ミリ秒未満のエンドツーエンド以内に戻り、再び戻ってきた場合、これは高速双方向機能を反映し、再送信が不要で、すべてのACKを受信すると、すべての後続のパケットそのセッションでは、「幸せ」としてマークされるべきです。
No loss, low-latency packets also makes for happy users. So the packet would be reflecting the end-user experience.
損失はありません。低遅延パケットは、幸せなユーザーにもなります。したがって、パケットはエンドユーザーエクスペリエンスを反映しています。
If retransmission rates achieve greater than 20% of all packets sent in a session, it is fair to say the session can be in mourning for all of the good packets lost in the senseless wasteland of the wild Internet.
再送信率がセッションで送信されたすべてのパケットの20％以上を達成した場合、野生のインターネットの無意味な荒れ地で失われたすべての良いパケットのためにセッションが喪に服している可能性があると言うのは公平です。
This should not be confused with retransmitted packets marked as 'angry' since this tag would apply to all frames in the session numbed by the staggering loss of packet life.
これは、このタグがパケットの寿命の驚異的な損失によって麻痺したセッションのすべてのフレームに適用されるため、「怒っている」とマークされた再送信パケットと混同しないでください。
Any packet that is carrying a text joke SHOULD be marked as 'amused'.
テキストジョークを運んでいるパケットは、「面白がっている」とマークする必要があります。
Example:
例：
1: Knock Knock
2: Who's there?
1: Impatient chicken
2: Impatient chi...
1: BAWK!!!!
If such a joke is in the packet payload then, honestly, how can you not be amused by one of the only knock-knock jokes that survives the 3rd grade?
そのような冗談がパケットペイロードにある場合、正直なところ、3年生を生き残る唯一のノックノックジョークの1つに面白がらないのはどうしてですか？
When is a packet confused? There are network elements that perform per-packet load balancing, and if there are asymmetries in the latencies between end-to-end paths, out-of-order packet delivery can occur.
パケットはいつ混乱しますか？パケットごとの負荷分散を実行するネットワーク要素があり、エンドツーエンドパス間のレイテンシに非対称性がある場合、オーダーのないパケット配信が発生する可能性があります。
When a receiver host gets out-of-order packets, it SHOULD mark TCP ACK packets sent back to the sender as confused.
レシーバーホストがオーダーアウトパケットを取得すると、混乱して送信者に送信されるTCP ACKパケットをマークする必要があります。
The same can be said for packets that are sent to incorrect VLAN segments or are misdirected. The receivers might be aware that the packet is confused, but there is no way to know at ingress if that will be the fate of the frame.
同じことが、誤ったVLANセグメントに送られているか、誤った方向に向けられているパケットについても言えます。受信機は、パケットが混乱していることを知っているかもしれませんが、それがフレームの運命であるかどうかをIngressで知る方法はありません。
That being said, application developers SHOULD mark packets as confused if the payload contains complex philosophical questions that make one ponder the meaning of life and one's place in the universe.
そうは言っても、アプリケーション開発者は、ペイロードに複雑な哲学的質問が含まれている場合、パケットを混乱させているとマークする必要があります。
Packets carrying accounting data with debits, credits, and so on MUST be marked as 'bored'.
借方、クレジットなどの会計データを運ぶパケットは、「退屈」としてマークする必要があります。
It could be said that many people consider RFCs boring. Packets containing RFC text MAY be marked as 'bored'.
多くの人がRFCを退屈だと考えていると言えます。RFCテキストを含むパケットは、「退屈」としてマークされる場合があります。
Packets with phone book listings MUST be marked 'bored'.
電話帳のリストを備えたパケットは、「退屈」とマークする必要があります。
Packets containing legal disclaimers and anything in Latin SHOULD be marked 'bored'.
法的免責事項とラテン語のあらゆるものを含むパケットは、「退屈」とマークする必要があります。
Who doesn't love when the out-of-order packets in your session surprise you while waiting in a congested queue for 20 ms?
あなたのセッションのオーダーアウトパケットが20ミリ秒間混雑したキューで待っている間にあなたを驚かせたとき、誰が好きではありませんか？
Packets do not have birthdays, so packets can be marked as surprised when they encounter unexpected error conditions.
パケットには誕生日がないため、予期しないエラー条件に遭遇したときにパケットに驚くようにマークされる可能性があります。
So when ICMP destination unreachable messages are received (perhaps due to a routing loop or congestion discards), all subsequent packets in that session SHOULD be marked as surprised.
したがって、ICMP宛先の到達不可能なメッセージが受信されると（おそらくルーティングループまたは輻輳廃棄のため）、そのセッションの後続のすべてのパケットは驚いたとマークされるべきです。
Not all packets are sent as part of a session. Random keepalives during a TCP session MAY be set up as a repartee between systems connected as client and server. Such random and even playful interchanges SHOULD be marked as silly.
すべてのパケットがセッションの一部として送信されるわけではありません。TCPセッション中のランダムキープライブは、クライアントとサーバーとして接続されたシステム間のパーティーとして設定される場合があります。このようなランダムで遊び心のあるインターチェンジは、愚かなものとしてマークされるべきです。
Packets that are retransmitted more than once SHOULD be marked as frustrated.
複数回再送信されるパケットは、欲求不満としてマークする必要があります。
Packets that are retransmitted SHOULD be marked as angry.
再送信されるパケットは、怒っているとマークする必要があります。
When sending a RST packet to a connected system, the packet should be marked as apathetic so that the receiver knows that your system does not care what happens after that.
RSTパケットを接続されたシステムに送信する場合、受信者がシステムがその後何が起こるかを気にしないことを認識できるように、パケットを無関心としてマークする必要があります。
When a packet is used in a particularly clever way, it SHOULD be marked as sneaky. What is "clever" is rather subjective, so it would be prudent to get a few opinions about a particular use to make sure that it is clever.
パケットが特に賢い方法で使用される場合、それは卑劣なものとしてマークする必要があります。「賢い」とはかなり主観的なので、特定の使用についていくつかの意見を得ることは賢明です。
It is hard for a TCP packet to discern higher moral quandaries like the meaning of life or what exactly defines 'evil' and from whose perspective such a characterization is being made. However, developers of TCP-based applications MAY choose to see some activities as evil when viewed through their particular lens of the world. At that point, they SHOULD mark packets as evil.
TCPパケットが、人生の意味や「悪」を正確に定義するもの、そしてそのような特性評価が行われているような、より高い道徳的な困惑を識別することは困難です。ただし、TCPベースのアプリケーションの開発者は、世界の特定のレンズを通して見たときに、いくつかの活動を悪と見なすことを選択する場合があります。その時点で、彼らはパケットを悪としてマークする必要があります。
Some organizations are prohibited from using this mood by mission statement. This would also prohibit using the security flag in the IP header described in [RFC3514] for the same reasons.
一部の組織は、ミッションステートメントでこのムードを使用することを禁止されています。これは、同じ理由で[RFC3514]で説明されているIPヘッダーのセキュリティフラグを使用することも禁止されます。
Adding extensions to the TCP header has a cost. Using TCP extensions with the ASCII-encoded mood of the packet would detract from the available MSS usable for data payload. If the TCP header is more than 20 bytes, then the extra bytes would be unavailable for use in the payload of the frame.
TCPヘッダーに拡張機能を追加するにはコストがかかります。パケットのASCIIエンコードされたムードでTCP拡張機能を使用すると、データペイロードに使用可能な利用可能なMSSが損なわれます。TCPヘッダーが20バイトを超える場合、フレームのペイロードで使用するために追加のバイトが利用できません。
This added per-packet overhead should be considered when using packet mood extensions.
パケットムード拡張機能を使用する場合は、パケットごとのオーバーヘッドを追加する必要があります。
The TCP checksum, as a 16-bit value, could be mistaken if ASCII characters with the same number of zeros and ones were substituted out. A happy ":)" could be replaced with a frown by a malicious attacker, by using a winking eye ";(". This could misrepresent the intended mood of the sender to the receiver.
16ビットの値としてのTCPチェックサムは、同じ数のゼロとその数のゼロを持つASCII文字を置き換えた場合、誤っている可能性があります。幸せな「:)」は、ウィンキングアイを使用して、悪意のある攻撃者に眉をひそめたものに置き換えることができます。
This document does not seek to build a sentient network stack. However, this framework could be used to express the emotions of a sentient stack. If that were to happen, a new technical job class of network psychologists could be created. Who doesn't like new jobs? :)
このドキュメントでは、知覚力のあるネットワークスタックの構築を求めていません。ただし、このフレームワークは、感覚的なスタックの感情を表現するために使用できます。それが起こった場合、ネットワーク心理学者の新しい技術的な仕事クラスが作成される可能性があります。誰が新しい仕事が好きではありませんか？:)
If this work is standardized, IANA is requested to officially assign value 25 as described in Section 3. Additional moods and emoticon representations would require IESG approval or standards action [RFC5226].
この作業が標準化されている場合、IANAはセクション3で説明されているように、公式に値25を割り当てるように要求されます。
[DSM-IV] "Diagnostic and Statistical Manual of Mental Disorders (DSM)", http://www.psychiatryonline.com/ resourceTOC.aspx?resourceID=1.
[DSM-IV]「精神障害の診断および統計マニュアル（DSM）」、http://www.psychiatryonline.com/ resourcetoc.aspx？resourceId = 1。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003.
[RFC3514] Bellovin、S。、「IPv4ヘッダーのセキュリティフラグ」、RFC 3514、2003年4月1日。
Authors' Addresses
著者のアドレス
Richard Hay Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 EMail: rhay@google.com
Richard Hay Google 1600 Amphitheater Pkwy Mountain View、CA 94043メール：rhay@google.com
Warren Turkal Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 EMail: turkal@google.com
Warren Turkal Google 1600 Amphitheater Pkwy Mountain View、CA 94043メール：turkal@google.com