Independent Submission R. Hay
Request for Comments: 5841 W. Turkal
Category: Informational Google Inc.
ISSN: 2070-1721 1 April 2010
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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].
为了将全球无数物理层网络上的比特流拟人化，我们提出了一种TCP选项来表达数据包情绪[DSM-IV]。
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报头添加TCP选项[RFC793]来解决，使用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字节。所有通过这种机制描述为可表达的简单情绪都可以用两个或三个7位ASCII编码字符来显示。TCP报头中可能会出现多个情绪选项，以便表达比此处定义的更复杂的情绪（例如，如果数据包感到高兴和惊讶）。
TCP Header Format
TCP头格式
Kind Length Meaning
---- -------- -------
25 Variable Packet Mood
Kind Length Meaning
---- -------- -------
25 Variable Packet Mood
In more detail:
更详细地说：
+--------+--------+--------+--------+
|00011001|00000100|00111010|00101001|
+--------+--------+--------+--------+
Kind=25 Length=4 ASCII : ASCII )
+--------+--------+--------+--------+
|00011001|00000100|00111010|00101001|
+--------+--------+--------+--------+
Kind=25 Length=4 ASCII : ASCII )
+--------+--------+--------+--------+--------+
|00011001|00000101|00111110|00111010|01000000|
+--------+--------+--------+--------+--------+
Kind=25 Length=5 ASCII > ACSII : 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
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 |
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).
有两种方法来表示数据包语气。一种是根据TCP会话中的事件推断情绪。另一种是从更高层的高阶动作（例如有效载荷的主题）中衍生情绪。
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会话中的活动推断出“mood”的数据包，“mood”必须由监视触发事件的主机设置。如果客户端发送一个帧而没有接收到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 ms内从发送方堆栈端对端返回到接收方堆栈，然后再返回，这将反映高速双向能力，并且如果不需要重新传输并且接收到所有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!!!!
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?
如果这样一个笑话在包中，那么，老实说，你怎么能不被三年级仅存的一个敲门笑话逗乐呢？
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段或错误定向的数据包，也可以这样说。接收机可能知道数据包被混淆了，但是在入口无法知道这是否是帧的命运。
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会话期间的随机keepalives可以设置为作为客户端和服务器连接的系统之间的应答。这种随意甚至好玩的交换应该被标记为愚蠢。
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报头添加扩展需要付出代价。将TCP扩展与数据包的ASCII编码方式一起使用会降低数据有效负载可用的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.
如果替换出具有相同数量的0和1的ASCII字符，则TCP校验和（作为16位值）可能会出错。一个快乐的“：”可以被恶意攻击者用眨眼的方式用皱眉来代替“（”。这可能会向接收者歪曲发送者的预期情绪。
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。其他情绪和表情表示需要IESG批准或标准行动[RFC5226]。
[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.，“传输控制协议”，标准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圆形剧场Pkwy Mountain View，加利福尼亚州94043电子邮件：rhay@google.com
Warren Turkal Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 EMail: turkal@google.com
Warren Turkal谷歌1600圆形剧场加利福尼亚州山景城Pkwy 94043电子邮件：turkal@google.com